button element that toggles the
aria-hidden property on a chunk of markup.
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:
<button aria-controls="content">Reveal</button> <div id="content"></div>
Here’s what I have now:
<a href="#content" aria-controls="content">Reveal</a> <div id="content"></div>
- Find any elements that have an
aria-controlsattribute (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
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-expandedwhen there’s a click event.
aria-hiddenis set to false on an element (thereby revealing it), focus that element.
You can see it in action on CodePen.