In this post, I will give a brief overview of the specifications and explorations so far; examine the concept from a more holistic perspective of UX, accessibility and performance; share some quirks that I came across in my implementation and a few challenges that I solved to add on to the existing information contributed by other awesome developers referred in the links here and any others that I may have missed.
How does the HTML5 accordion code differ from the current implementations?
Furthermore, the open and unopen/native states are easily stylable with CSS including custom markers (arrow indicators) for the summary elements as :before pseudo elements which are discussed in much detail in some of the links I've shared in this post.
Here's a markup snippet in brief. Note that summary is a child element of the details in the DOM (?!).
And a simple example of corresponding CSS below.
With this brief introduction, I consider this an appropriate, useful and semantic HTML element for a major UI, UX pattern that we can harness with basic markup and CSS.
Why an accordion/"show more" element?
As with any UI, UX pattern and implementations of it, I think it is important to do our due diligence weighing in on all aspects (usability, accessibility, performance) and justify its use before jumping in and littering the “interwebs” with questionable patterns, which we have a good many of and struggling to get away from.
Used appropriately, coupled with good “information scent”, especially on mobile, I think a 'show more'/reveal/accordion/FAQ pattern is helpful in presenting a user with progressive disclosure and the benefit of scanning available options before focusing in on one, instead numerous choices thrown all at once, while also conserving crucial mobile real-estate.
It might be stating the obvious (but still seen quite often), but it shouldn't be used to just hide the most important content of a page, eg. the top 5 things that we’ve chosen carefully that you will need on this page/portal/app which are now hidden needing a click to reveal, just beats the purpose of having carefully curated such content, and as with any other UX interaction pattern, the usability analysis and user behaviors on your site is what matters most, although we can use general industry studies and data as a starting point, many of which may very well resonate with the ours, such as the ones below.
I agree with the above article to a great extent that accordions should be minimally and carefully used on desktop experiences, although I feel the use of accordion for FAQs on content rich pages helps users with glance and focus from my own experience and other studies even if involving an additional click.
Current browser support; is it worth using now with a polyfill and what about accessibility?
While I wouldn’t recommend using this approach for something that can be accomplished with simple hide/show div script if that’s all you need on a page, but if you're using multiple patterns e.g. an FAQ accordion; a show more navigation element (for mobile) or a show more content feature... this helps consolidate all of them with one markup presented with multiple CSS (or common CSS when applicable), which I think is a big win with reducing/consolidating code and patterns.
- Semantic markup, clean and lean code when compared to the bloat that goes into many current implementations.
- Polyfills such as these below, address and fix accessibility issues
while taking advantage of the browsers that already support natively. One can roll their own work-arounds for any specific options needed and as soon as more browser support becomes available just drop the polyfill script.
- Many existing cross-browser support scripts/polyfills are light-weight and accessible, more so than some current non HTML5 implementations I’ve seen on pages. Eg. jQuery UI library dumped in to just provide this one functionality!! eg. the polyfill linked here adds aria-expanded="true" tabindex="0" to the elements to be better accessible. To quote WebAIM, "A tabindex value of 0 indicates that the element should be placed in the default navigation order. This allows elements that are not natively focusable (such as
<p>) to receive keyboard focus".
There are some Vanilla JS polyfills as well in the above links.
Quirks, issues and additional information that I came across in my implementation
Not being able to deep link into a specific FAQ (e.g. http://localhost:8888/yourpage.html#faq3) was one of the issues/caveats that folks have raised in the above links/discussions, which I was able to address and make it work, as briefly described below, by treating each summary element as a named anchor tag, coupled with a few additional lines in jQuery below the mark-up.
Although I’ve tested this in multiple browsers, this has not been tested exhaustively just yet and I may be updating this post with more issues/solves if any. This markup and related script I added (for deep-linking into the accordion) is in conjunction with the polyfill script in the above link, so some of my notes and code may correspond to that (extending it) although this approach may very well work with other scripts for cross-browser support also.
Get the location hash for the anchor link into a variable.
Make sure you have checked for the presence of location hash with anchor name. Then find the details element closest to that anchor and set the attribute of that to open, so when the URL with that hash is hit, users will see the specific FAQ/content open.
NOTE: I used .attr as .prop doesn't work in non-compliant browsers. Also needed to include an empty value for open instead of 'true' as Firefox, implemented via the polyfill was choking on the latter and wouldn’t enable 'close' on the 'opened' details element within the focused summary element.
The above approach was also to make it work in Firefox which doesn’t seem to fire a focus event for anchor tags in the URL as opposed to something like below which worked in browsers that did fire a focus event on anchor tags in a URL (obviously our friend Chrome) by focusing in on the class of the summary element containing current anchor name in focus e.g. #faq3 and getting to its closest detail by (this). So if you're thinking like below, it didn't work cross-browser.
While styling with CSS, make sure you include styles for both details element and details .open class that the polyfill above adds to non-supporting browsers.
NOTE: As of this writing, the height transition of CSS didn’t quite work in spite of trying out a set height for details[open] element although I wouldn’t really recommend a set height for most cases as it is better left at auto height.
Well, it ended up to be quite a longer post than I expected for a 'simple' accordion. Hope you learned something new here and hope more browsers implement this soon and your analytics will show mostly browsers that support. We can only wish.