do we need aria-controls for content that immediately follows the control

[DavidMacDonald]

I'm wondering if it would make sense to simplify disclosure buttons. In the code below there is an aria-expanded, the intuitive thing for a screen reader user to do is to arrow into the group below the question. I would think we would only need aria-controls if the user might have some confusion about what is being opened closed (i.e. a tabbed interface) or where they would want a keyboard shortcut to move there. See this http://www.heydonworks.com/article/aria-controls-is-poop

My suggestion is that we move forward with a normal assumption that if the content that is being "controlled" immediately follows its trigger in the DOM, that we leave aria-controls off.

<dl class="faq">
  <dt>
    <button aria-expanded="false" aria-controls="faq1_desc">
      What do I do if I have a permit for an assigned lot, but can't find a space there?
    </button>
  </dt>
  <dd>
    <p id="faq1_desc" class="desc">
      Park at the nearest available parking meter without paying the meter
      and call 999-999-9999 to report the problem. We will note and approve your alternate
      location and will investigate the cause of the shortage in your assigned facility.
    </p>
  </dd>

So in this one above it would be.

 <button aria-expanded="false" >
      What do I do if I have a permit for an assigned lot, but can't find a space there?
    </button>

Which is a little simpler for a developer and looses nothing for a screen reader user. Its a lot less verbose.

[LJWatson]

Without aria-controls there will be uncertainty. To find out whether the content below the button is associated or not, the screen reader user has to toggle the disclosure a couple of times, and move up/down, to find out whether the subsequent content has changed. That doesn't strike me as a good UX.

[LaurenceRLewis]

If aria-controls is problematic, I would like to hear other testimony on this considering the article was written in August 2016. Could an alternative be to wrap the collapsible section in a role region with aria-labelledby referencing the trigger (button).

[LJWatson]

I don't think aria-controls is a problem. It fulfills a useful and, for a screen reader user, necessary function.

Critically, aria-controls also enables the provision of a navigational shorcut. Jaws provides a shortcut that lets the user move directly from the control to the controlled content. That, as I think I mentioned in the comments on @Heydon's article, is invaluable when you have no visual clue as to what is being controlled, let alone where that thing might be on the page.

[LaurenceRLewis]

Thank you Leonie for the useful information. I didn’t know that particular Jaws shortcut.

Update: I thought I did not know it. Use JAWs key plus ALT plus M to move to controlled element. And I never associated that with aria-controls 🤔. Ah well common sense was never my strong point 😁

[Heydon]

Any shift in aria-controls support? Last I looked it was just JAWS. The main reason I recommend placing aria-expanded content directly after the control is because aria-controls simply has very scant support (at least in terms of actually providing any kind of announcement/interface).

[devarshipant]

@Heydon "Any shift in aria-controls support? Last I looked it was just JAWS. "

If it helps, in the Example of Tabs with Manual Activation, JAWS (18 and 2018) correctly set virtual cursor on the target (controlled element) on executing the JAWS (or Insert) key plus Alt plus M key.

@DavidMacDonald "My suggestion is that we move forward with a normal assumption that if the content that is being "controlled" immediately follows its trigger in the DOM, that we leave aria-controls off."

Question -- Does the expand / collapse type control display text when expanded? I have seen instances where the shortcut key will not have a controlled element to move to when aria-controls is set on a button that is collapsed (aria-expanded false).

[LJWatson]

@devarshipant

Question -- Does the expand / collapse type control display text when expanded? I have seen instances where the shortcut key will not have a controlled element to move to when aria-controls is set on a button that is collapsed (aria-expanded false).>

This is not because of the state of aria-expanded. It happens when aria-controls has been set to point to an element that is not currently visible in the accessibility layer (because it has display:none; set for example).

[LaurenceRLewis]

@LJWatson In that case would it be better if aria-controls was added only when the associated content was visible? Thanks.

[LJWatson]

@Decrepidos this was suggested before in #93 but dismissed as "invalid" (a finding I continue to disagree with).