Results of the Accordion Pattern survey
A few months back we shared our current thinking on the "accordion" navigation component, and asked the community of web developers and designers who read this blog to take a survey to help us determine defaults, current practices, and other guidelines to incorporate into an Accordion pattern and provide input into an Accordion YUI component. I've had some time now to review and study the results and I wanted to share them with the community as we write up a "beta" version of the pattern and get ready to share it, so without further adieu, here are the results (note that this survey should not be considered strictly scientific). Who Responded Respondents identified themselves the following ways:
- Designer 21.4%
- Developer 32.1%
- Hybrid (Both designer and developer) 42.3%
- None of the Above 4.2%
- Accordion and Accordion Menu mean the same thing (73%)
- Accordions and Tree Controls are two different things (89%)
Opening a panel should require explicit action. If an accordion has multiple panels, opening on hover could be a jarring experience. Rather, use a tooltip to convey summary details of what is in the panel, and have the user explicitly "click" to open that panel.
Depends on the configuration of each accordion. I put these examples together [multiple, rollover], so the developer can actually use the "best fit" for each use case. Also, there should be the option to use rollover with different rules: (one most be open) or (elements should be opened on mouseover only).
For advanced usages, an accordion should open on hover during drag and drop operations. In any other circumstance, you can't trust that the hover is intentional.Accessibility Finally, we asked an open-ended question fishing for any known accessibility issues with accordions and got a lot of great answers. (For our example issue, most people agreed that making the entire label clickable and not just a small icon is important.) Here is a sampling of other insight about accessibility with accordions:
I think it's safe to assume that an Accordion interaction is an advanced interaction. Lots of accessibility problems can arise.
- Content is hidden behind panels so people may not find it.
- Depending on the size of the clickable area or the trigger to open/close the panels there could be issues with the manual dexterity needed.
It depends on whether content in the hidden panels is present in the DOM or is retrieved upon opening the panel. If it is being retrieved, focus needs to be placed on the newly opened panel.
Well, I really believe the title should be clickable, specially if the content of the element will be loaded using AJAX (just like a tabview approach), but the reality is that sometimes the developer (should have)/(want) the control to customize that behavior. Here is the list of examples that I created for an accordion widget implementation based on YUI 2.x, it's probably one of the most used components from the bubbling YUI extension.
We've had a case where the 'label' of the accordion was a link to a full blog post, and so could not be accordion-clickable. In that case, we wrote an icon into the source with js to do the job. Provided the icon is sufficiently large and/or comes with an accesskey, I don't see a major difficulty...
Accordion controls server the purpose of fitting lots of content into less space. Since this is a visual concern, it would be fine for a screen reader to simply read all of the content and ignore the fact that it is displayed as an accordion visually. It is sufficient for an icon to be clickable to expand a panel. There could be a configuration option to allow the entire label to expand a panel, or it can be left up to the implementing developer to attach a listener to the label that calls a public "open" or "expand" function to add that functionality.
Just think of an accordion as a tabbed view. The entire panel label area should be clickable, but if it contains other controls (e.g. a "dismiss" or "close" button) I suggest only the label (text) be clickable, or at least the clikable area only expand up to the interactive controls (i.e. for a caption containing a button, the area above, below and "after" the button should be clickable).Releasing the Draft Pattern One commenter questioned the artificial constraints of the survey (a fair cop, if you ask me):
I didn't like this survey. The questions were not flexible enough. As a designer/developer, I believe all interface elements need to be tailored to particular site or web application. Asking black and white questions does not leave room for the obvious differences between projects. Some projects need a hard and fast rule, while the same rule might be totally inappropriate for another application. For the most part, I could of answered every question with a "it depends" result.Rest assured that the pattern will only gently recommend and the YUI code will be flexible and powerful. The survey wasn't designed to limit people's choices but rather to gather opinions and preferences, so even feedback about not having hard-and-fast rules is useful. We've published a beta version of the Accordion pattern in the Yahoo! Design Pattern Library. If you'd like to give further feedback on the pattern, in a free-form manner, please drop by or visit the related forum discussion.