 |
 |
Hey all, I work in UX for a little company (Brass Nine Design) and joined the group to chime in on this UX discussion: Our library website is currently being redesigned to be responsive. > The work is being done by an outside design firm and the project is > being managed by University Relations, our school's PR department. The > mobile version of our responsive site has several accordion menus "Unfortunately, no, as this isn’t best practice. Accordions should > require a click each to open and close; in other words, nothing on your > page should move without a user action. This is true throughout our sites. > See the universal Quick Links in mobile." This is confusing because it's bad advice portrayed as "best practices." Let's deconstruct it: *Self-Closing Accordions* At the most basic, a "self-closing" accordion is just a standard accordion. Many UI frameworks will actually offer 2 rendering modes for tabs, one where it's presented as tabs along the top or sides and the relevant pane for a tab is displayed, another where it's rendered as a vertical or horizontal accordion. In both of these constructs the other panes are "self-closing." Forbidding that UI would mean forbidding tabs, which would be especially strange given many sites' top navs are essentially a tabbed interface. So, forbidding the self-closing accordion is bad policy. *Responsive Design in General* It's also likely that whoever provided that advice is not thinking Responsive. If you have your site built for 2 things, "mobile" and "not mobile," you're not building a Responsive site. A Responsive site is one that can handle: - Today's devices - desktops, laptops, touch-laptops, tablets, smartphones, and watches. - Tomorrow's devices - likely smaller displays and larger displays, higher DPI displays, and blind UI / voice-only. The "tomorrow's devices" obviously requires a bit of forecasting but there are things we know are coming, like the above higher DPI and need for blind/driver's interfaces. Even today, users of the Apple Watch are going to be happier talking through your site's resources than flipping through it staring down at the little display on their wrist. This leads to some technical requirements: - No device should be assumed to be touch, mouse, or mouse-only. For example many designers will add "Quick Links" to mobile figuring mobile is touch and desktop/laptop is mouse. On mobile plodding fingers need to get around the site more easily than a smaller, fiddly nav - but what about Surface Pro users holding a high-DPI touch tablet, looking at the desktop-render of your site - how are they going to deal with your fiddly nav? You need to design and build it to interact well with both at all sizes. - No screen size can really be assumed, although there are a couple of industry-standard minimums being established: Devices smaller than 640 physical pixels in width aren't in today's device mix, and smaller than 280 "virtual pixels" aren't either. "Virtual pixels" is the width Bootstrap sees on a screen, the number of pixels available to font rendering if the screen dpi were the historical standard of 72dpi. Usually the real dpi is much higher - for example Apple's Retina phones will render at 96dpi, 144dpi, even 200dpi. - Designers can't design for and devs build for a few discrete sizes, like "desktop 1280" and "iPhone 320." The site needs to work at every single pixel step from 280 on to infinity, or for now, 3200. - The usual mechanics of building sites - don't use Flash, replace PDF with HTML, deal with browser bugs in today's top devices. - If you are going to be kind to blind users and build forward for voice-only or voice-primary users like those driving, exercising or interacting with a watch or Alexa or some future wearable, you should follow Accessibility guidelines, and ARIA. Accessibility guidelines are pretty old as the web goes and include placing alt text on some images - any images that contain important information a blind user would miss out on. And, avoid using CSS and JS tricks that would hide important text from a screen reader. Following these also happens to help your SEO score a little bit. Since the original question was about a University site I should also warn that not doing this may be illegal, as there are laws <http://webaim.org/articles/laws/usa/> in the US about government and institutional websites and accessibility to the blind. The laws are largely toothless as I've never heard of a web designer being cuffed and lead away in shame (IN SHAME!) for designing an inaccessible site, but if the conflict is budget vs blind users you might be able to use the law as a cudgel in a conversation with management to get a win in for the blind. ARIA is basically what someone earlier in this thread was wondering about - how would a Screen Reader know a certain section of an accordion was open or closed? The answer is you mark the panes that are closed as aria-hidden and the control itself as role=tab: http://accessibility.athena-ict.com/aria/examples/tabpanel2.shtml http://www.webteacher.ws/2010/10/14/aria-roles-101/ http://www.w3.org/TR/wai-aria/roles#abstract_roles