Accessible progressive disclosure revisited
Earlier this week I had a chance to hang out with accessibility experts Derek Featherstone and Devon Persing so I took the opportunity to pepper them with questions about this pattern. My main question was “Should I automatically focus the toggled content?”
Derek’s response was very perceptive. He wanted to know why I was using a button. Good question. When you think about it, what I’m doing is pointing from one element to another. On the web, we point with links.
There are no hard’n’fast rules about this kind of thing, but as Derek put it, it helps to think about whether the action involves controlling something (use a button) or taking the user somewhere (use a link). At first glance, the progressive disclosure pattern seems to be about controlling something — toggling the appearance of another element. But if I’m questioning whether to automatically focus that element, then really I’m asking whether I want to take the user to that place in the document — in other words, linking to it.
I decided to update the markup. Here’s what I had before:
Here’s what I have now:
<a href="#content" aria-controls="content">Reveal</a>
- Find any elements that have an aria-controls attribute (these were buttons, now they’re links).
- Grab the value of that aria-controls attribute (an ID).
- Hide the element with that ID by applying aria-hidden=”true” and make that element focusable by adding tabindex=”-1".
- Set aria-expanded=”false” on the associated link (this attribute can be a bit confusing — it doesn’t mean that this element is not expanded; it means the element it controls is not expanded).
- Listen for click events on those links.
- Toggle the aria-hidden and aria-expanded when there’s a click event.
- When aria-hidden is set to false on an element (thereby revealing it), focus that element.
You can see it in action on CodePen.
This was originally posted on my own site.