Using the aria-controls attribute

There are a handful of ARIA1.0 attributes that can be used to indicate relationships between elements, when those relationships can’t be ascertained easily from the DOM. One such attribute is aria-controls.

The aria-controls attribute creates a cause and effect relationship. It identifies the element(s) that are controlled by the current element, when that relationship isn’t represented in the DOM. For example a button that controls the display of information contained within a div:

<button onclick="showInfo();" aria-controls="I">Show info</button>
<div id="I">Information.</div>

The more widely the two elements are separated in the DOM, the more useful the aria-controls attribute becomes. Imagine a checkbox that controls the filtration of search results, or a tab that controls a tabpanel:

<ul role="tablist">
   <li role="presentation"><a href="#" onclick="displayTab(1);" role="tab" aria-controls="panel1" aria-selected="true">Tab 1</a></li>
   <li role="presentation"><a href="#" onclick="displayTab(2);" role="tab" aria-selected="false">Tab 2</a></li>

<div role="tabpanel" id="panel1">...</div>
<div role="tabpanel" id="panel2">…</div>

When a User Agent (UA) supports aria-controls, it makes it possible for focus to be moved from the current element directly to the element it controls. The alternative is to navigate through all the intervening content in hopes of discovering what might have changed elsewhere on the page. For this reason, aria-controls should only be used to point to something that is available in the DOM and which can be navigated to.

UA support for aria-controls is still somewhat inconsistent. Firefox and Internet Explorer both expose aria-controls through their accessibility API (IAccessible2 and UIAutomation respectively). Assistive Technology (AT) support is less encouraging though. Jaws (14+) supports aria-controls, but only in Firefox. When Jaws encounters the aria-controls attribute it announces “Use the Jaws key Alt and m to move to the controlled element”. NVDA, VoiceOver and Window Eyes don’t seem to support it at all in any browser.

Despite the fact support amongst browsers and screen readers could be better, the aria-controls attribute is still worth using. Creating relationships within the DOM is certainly more robust, but it isn’t always practical or achievable. The presence of aria-controls won’t damage the User Experience (UX) for people using UA that don’t support it, but it will enormously improve the UX for those people whose browser/screen reader combinations do.

8 comments on “Using the aria-controls attribute”

Skip to Post a comment
  1. Comment by Taylor Hunt

    Say I have a widget for advancing/navigating a slideshow. Should I use aria-controls? Is there a DOM-native technique I should use instead, because of the AT support issue?

    1. Comment by Léonie Watson


      I think that’s a good use case for aria-controls. I don’t think there is an equivalent in HTML, so despite the inconsistent support it’s still worth using for those browsers/screen readers that do support it.

  2. Comment by Madhusudan

    Hi Leonie,

    How to achieve aria-controls functionality on VO?

    JAWS is able to recognize aria-controls attribute but not VO. I need to make it work for both VO and JAWS. Any idea on how to do it?

    1. Comment by Léonie Watson

      Unfortunately the attribute needs to be supported by Safari and VO for this to happen. Until then, there isn’t anything you can do to make it work.

  3. Comment by Venkatesh

    Hi Leonie,

    I always face challenges to understand relationship attributes like aria-controls and aria-owns. When aria-controls is not used to build relation between tab and its respective tab panel is that focus doesn’t move to tab panel when I press tab key from selected tab item? Can I understand like this? But I think this focus can be managed through tab index then what way it impacts screen reader users if aria-controls/ aria-owns are avoided. I know that I am too much confused with my perceptions but looking for better understanding here.

    1. Comment by Léonie Watson

      ARIA does not change keyboard behaviour. It just exposes accessibility information to screen readers. In the case of aria-controls, it tells the screen reader that one element controls another. It’s then up to the screen reader to implement support – which in the case of Jaws means providing a keyboard shortcut to move from the control element to the one being controlled.

  4. Comment by Siddhant Chothe

    Can a menuitem have aria-controls pointing to the subsequent menu that it would popup? Like File menuitem in menubar controls the menu that contains Open/Save/Exit.

  5. Comment by Siddhant Chothe

    Also whenever an element controls multiple elements, what is the use of even the JAWS keystroke? JAWS won’t know which of the elements to focus.

Comment on this post

Will not be published

This site uses Akismet to reduce spam. Learn how your comment data is processed.