What to do about aria-controls

[scottaohara]

aria-controls did not have the widest support, but with the JAWS release notes (April 2019) it will no longer be announced by default.

If you encounter an element on a web page with a defined ARIA controls relationship, JAWS will no longer say “use JAWSKEY+ALT+M to move to controlled element” by default. In most cases, the target of the controls relationship is adjacent to the element or does not provide any useful information.

This update appears to have been made specifically to address "In most cases, the target of the controls relationship is adjacent to the element or does not provide any useful information." But testing should be done to verify.

Additional reading from past aria-controls discussion:
2017 Ticket about aria-controls should only point to visible elements.

[carmacleod]

More reading from other past aria-controls discussion: #716

[joanmarie]

Do we happen to know what "no longer say ... by default" means? Is it:

• JAWS will apply some logic to determine if presenting the controls information and if that logic determines the relationship is useful, make the announcement and continue supporting the navigation, OR
• JAWS thinks aria-controls is useless, but doesn't want to rip out the support entirely until they are darned sure, so now it's a preference which end users have to explicitly enable

[scottaohara]

@joanmarie currently asking about that, will report back.

[scottaohara]

re: mention in ARIA WG call today, JAWS does have this set to ignore by default now.

[carmacleod]

I have been told that a menu button inside a scrollable table can have its menu clipped if the button and the menu are siblings (i.e. if the menu is inside the table).

Here's an example: https://www.codeply.com/go/QnOrPZvtHt/bootstrap-dropdown-overlay-table-cell
Drop down the first menu - it is not clipped because there's enough room to show the menu on top of the table rows.
Drop down the 2nd or 3rd menu - they are clipped and the table needs to scroll to reveal the whole menu.

For this reason, the menu was moved to another part of the DOM (i.e. not inside the table) and aria-controls was used to establish a relationship between the button and its menu.

As far as I know, using aria-controls is the only way to make this use case accessible. I'm not a CSS expert, though - perhaps there's a way to float a sibling-markup menu over top of the table boundaries.

[LJWatson]

I agree with @scottaohara carmacleod that there is a use case to answer and that aria-controls is the only real solution, even if it seems to be disappearing from our grasp.

Do we have any data on why it was never implemented in other screen readers?

[carmacleod]

Hi, @LJWatson!

Do we have any data on why it was never implemented in other screen readers?

I found a request to support aria-controls navigation in NVDA, but there's no reply yet. Interestingly, the requester did mention some disadvantages to the JAWS implementation, namely:

1. It is pretty verbose
2. It doesn't allow you to jump back from the controlled element to the controlling element
3. It does not deal properly with an element controlling multiple other elements, which is allowed according to the spec.

There's also a bit of discussion about aria-controls in the 2 aria issues referenced above: #531 and #716, where @mcking65 said:

I am not sure that the primary purpose [of aria-controls] is assistive technology navigation; it is expressing the relationship for the benefit of forming an accessibility tree.

A lot of the time, the controlled element is right after the controlling element in the tab order and/or reading order, which, as @scottaohara noted, seems to be the reason given in the JAWS release notes for no longer announcing the navigation key by default:

In most cases, the target of the controls relationship is adjacent to the element or does not provide any useful information.

This may partially explain why other AT didn't implement an aria-controls navigation key?

[mcking65]

I still believe there are valid use cases for aria-controls both for AT users and automated testing. And, the dearth of support in screen readers is partly a chicken and egg problem.

I think the ARIA 1.3 time frame is right for attacking this given our other priorities. And, we are finally at a point in authoring practices where we can realistically help address the topic.

I for one am happy for the change to JAWS. The announcement created a lot of noise with essentially 0 benefit. The reason there was 0 benefit was not because benefit was out of reach, it is because the JAWS implementation was not well designed.

If the design was such that:

1. The relationship was exposed to users only when there was value.
2. The relationship was announced in a way that could be easily understood by anyone.
3. The relationship could be utilized in a simpler manner.
   Then, perhaps it would have been a smashing success.

As it was, the announcement was extremely verbose. It was made even if there was no possibility of navigating to the target, i.e., the target was not visible. It used words like "controlled element", which are meaningless to typical users. It had a new, dedicated key command that required constant reminding. Even if you just solved the first three issues without taking on the massive key command bloat problem, it could have been much more successful. For instance, What if you just read or actived a tab named "Discussion" and then, if you have tutor messages turned on, you hear "Move to discussion panel with insert+alt+m". You should never hear this for a tab that controls a panel that is not visible. You should never hear words like "element" or "controls" as they are useless to the user. JAWS can know the type of element that is the target. JAWS can also know its name and visibility as well as its distance in the virtual buffer.

[DavidMacDonald]

I think at the least in the short term, in the aria-practices document, we can leave off aria-controls when the content that is being controlled immediately follows the controller.

[LJWatson]

<I think at the least in the short term, in the aria-practices document, we can leave off aria-controls when the content that is being controlled immediately follows the controller.> I think this would establish an anti-pattern. Would the absence of aria-controls mean there was no controlled content, or that there is controlled content but it's next in the DOM order? The user has no way to tell.

[mcking65]

@DavidMacDonald wrote:

<I think at the least in the short term, in the aria-practices document, we can leave off aria-controls when the content that is being controlled immediately follows the controller.

@LJWatson wrote:

I think this would establish an anti-pattern. Would the absence of aria-controls mean there was no controlled content, or that there is controlled content but it's next in the DOM order? The user has no way to tell.

I agree with Léonie. Assistive tech could use the aria-controls relation to determine where the controlled content is and decide what to do based on the location, visibility, the type of element controled, the name of the element, other properties and states it has, etc. As with all accessibility semantics, it is the responsibility of the AT developer to determine the ideal way to use the semantics to the advantage of their users and design their experiences accordingly. As with several other ARIA features, assistive technology developers have not yet made these investments. One of the goals of the w3c/aria-at project is to spur not just basic support for ARIA, but once that is in place, inspire greater value add. The aria-controls property is just one example of where there is ample room for that kind of improvement.

Additionally, if you are leveraging ARIA in automated testing, like the regression tests built into the APG build process, a sometimes its there and sometimes its not approach wouldn't work.

[mcking65]

Oops, in wrong issue, sorry; deleting previous comment and re-opening. I meant to close the APG issue.

[barlowm]

Dropping my 2 cents in here simply because I just came across this issue on an app I'm testing and discovered this interesting read - aria-controls is poop. I discovered it when the app had a control with the aria-controls attribute that pointed to non-existant elements.

[scottaohara]

Related APG issue 805 on ARIA controls

[patrickhlauke]

i seem to vaguely remember that there can also be problems with aria-controls if it points to the id of an element that is currently not in the accessibility tree (e.g. because it's aria-hidden). then, even IF JAWS is set to give you a hint that you can move to the controlled element, it will have no effect because the controlled thing doesn't exist as far as JAWS is concerned unless it was opened/activated. [edit: ah, i see this was already mentioned in that other issue #531]

if it has no actual real-world benefit, and other AT have been loathe to implement any useful behavior for it...it feels like it should be removed perhaps. it's certainly not something i would advise people use, because it's more of an empty gesture at this point.

[craigkovatch]

We recently went through a bunch of pain to put aria-controls on all our dropdown buttons so...if it's just an empty gesture, I would love to remove that sooner than later :)

[mcking65]

@craigkovatch wrote:

We recently went through a bunch of pain to put aria-controls on all our dropdown buttons so...if it's just an empty gesture, I would love to remove that sooner than later :)

I recommend you keep it.

[basher]

@craigkovatch wrote:

We recently went through a bunch of pain to put aria-controls on all our dropdown buttons so...if it's just an empty gesture, I would love to remove that sooner than later :)

I recommend you keep it.

Hi...

I've just come across this discussion, having re-read Heydon Pickering's aria-controls is poop article.

I'm in the process of re-working a whole bunch of out-dated and inaccessible UI components (dropdown menus, show/hide content toggles, tabs, accordions, etc) and was going to omit aria-controls.

I'm intrigued about the comment.

I recommend you keep it.

Why?

[carmacleod]

I recommend you keep it.

Why?

Because the ARIA working group will be discussing aria-controls to come up with recommendations (for AT and/or UA and/or authors) in the ARIA 1.3 time frame (i.e. "sometime this year" although global events causing meeting cancellations may delay this).

[mitchellevan]

Here's another kind of potential use case for aria-controls: unsubmitted user input in a form field triggers a disclosure or other content updates in the web page. Examples:

• a postal code field controls a city field
• a checkbox unhides more fields (progressive disclosure)
• a radio button selection unhides a legal disclaimer (progressive disclosure)
• typing in a text field updates a display of structured content, such as a real-time lookup for word definitions in a dictionary with further links

Other solutions have various problems.

• aria-expanded is not allowed on form fields with roles such as textbox or checkbox
• aria-haspopup is appropriate only for specific interaction patterns, such as a menu, which are rarely triggered by form fields
• augment the field's accessible name, to inform users where to find controlled content: cognitive load for users; author one-off effort (code, editorial, localization); sure to be inconsistent across the web
• a live region is okay sometimes, but it doesn't help the user navigate to updated content, and has similar problems to augmenting the field's accessible name
• an <output> element could be an elegant solution in some cases, but only for particular interactions and content; problems similar to the generic live region

[carmacleod]

@mitchellevan

In case it's useful to know for other reasons, note that aria-expanded is now allowed on checkbox as of May 2019:

02-May-2019: Add aria-expanded support to application and checkbox roles.

[mitchellevan]

Thanks @carmacleod. I've filed w3c/html-aria#251 to stay in sync.

[jnurthen]

@scottaohara @mcking65 still in scope for 1.3?

[jnurthen]

Need to talk to AT about expectations

[sandrina-p]

Hi all. Two years late, is there any update about the recommendation for aria-controls?

[guyhickling]

I think Heydon Pickering makes a very valid point, in his article "Aria-controls is poop", when he says this attribute encourages web devs to not worry about having their source code and DOM in a sensible and meaningful order. It encourages the kind of thinking:

"Because we've used aria-controls, 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?"

Finally JAWS changing the default to not making those awful, repetitive announcements was the right way to go. I think it is one of those things that power screen reader users might like to switch on, but that most ordinary, non-tech users were probably just mystified and/or annoyed by. Certainly when testing I hated those announcements, especially when there were maybe 20 or so instances on a page!