Leo

<p>We need to talk about <code>aria-controls</code>. It's poorly supported, does very little, and does what it does <em>when</em> it does badly. It is <em>poop</em> and we rely on it way too much. We are short-changing assistive technology users when we do.</p> <h2>What it is</h2> <p>The <code>aria-controls</code> attribute is a 'relationship attribute' which denotes which elements in a page an interactive element or set of elements has control over and affects. It's commonly used to describe a relationship between a button and the expandable region revealed by that button.</p> <pre> <code style="white-space: pre-wrap"> <button aria-expanded="false" aria-controls="expandable">open / close</button> <div id="expandable" hidden>content of the expandable region</div> </code> </pre> <h2>What we think it does</h2> <p>Wishfully thinking, we assume that marking up relationships with <code>aria-controls</code> means screen reader users can effortlessly flit between the moving parts of a web application, like a mechanic tinkering in a ship's engine room.</p> <p>Because we've used <code>aria-controls</code>, we don't have to worry about source order, right? We've connected up the dots explicitly, with our magic attribute! And it doesn't matter about all the elements between a controller and its subject because we've tunneled between them, right?</p> <pre> <code style="white-space: pre-wrap"> <button aria-expanded="false" aria-controls="expandable">open / close</button> <div>  </div> <div id="expandable" hidden>content of the expandable region</div> </code> </pre> <h2>Good luck with that</h2> <p>First of all, only the JAWS screen reader supports <code>aria-controls</code>. If a user is operating NVDA or VoiceOver (or others), they would have no idea it's even there. That's reason enough not to use it.</p> <p>But, just for giggles, let's talk about <em>how</em> JAWS supports <code>aria-controls</code>. When you focus an element with the attribute included, JAWS will announce, "<em>press the JAWS key plus Alt and M to move to the controlled element.</em>" Verbose and clumsy. Then again, I'm not sure how else you'd go about supporting it.</p> <p>But, that's not the only problem. <strong>How in the hell do I move back?</strong> And, even if I could, how would that be communicated and how long should the option to move back remain active? No wonder the other screen reader vendors are giving this a wide berth.</p> <h2>Multiple controlled elements</h2> <p>You can create a one-to-many relationship by supplying a space separated list of <code>id</code>s, representing different, simultaneously controlled elements.</p> <pre> <code style="white-space: pre-wrap"> <button aria-controls="elem1 elem2 elem3 elem4">open / close</button> </code> </pre> <p>Cute! And good luck with implementing a half-decent UX there, everybody. In case you're interested, JAWS just says "<em>press the JAWS key plus Alt and M to move to the controlled element</em>" as normal. Genius.</p> <h2>Conclusion</h2> <p>The <em>aria-controls</em> attribute is a prime example of something we'd love to 'just work'. Trouble is, there's no clear way <em>how</em> it should work. JAWS makes a perfunctory attempt at implementation, but it's incomplete and I suspect it creates much more confusion than it provides clarity for real users.</p> <p>In the absence of a good purpose-built solution for letting folks using an interface aurally move between and around tools and their outputs, try a combination of the following:</p> <ul> <li>Same-page links to move users from one part of the interface to another</li> <li>Landmark roles to encapsulate major areas of the interface's functionality</li> <li>Expandable areas that come immediately after their <code>aria-expanded</code> controllers in the source (and in focus order)</li> </ul> <p>There's also the question of 'focus management'. In keyboard and screen reader accessibility terms, focus management usually means using the <code>focus()</code> method in JavaScript to move focus between elements. Be aware that, in almost all cases, users <strong>do not</strong> want to be moved from one place to another without their explicit say-so. Even when they <em>do</em> want to, providing a link is probably your best bet.</p> <p>I think I'll give the focus management wasps' nest a proper poke on another occasion.</p>