Editorial: aria-controls spec update #1996
Conversation
resolves #995 The intent with this update is, 4 years later, to propose a draft solution for the issue I opened. With the progress made on aria-details, and the overlaps in how this attribute could have been useful, I did take great liberty in pulling in further explanation/examples for aria-controls from the existing aria-details spec text. Things i didn't overly call out in this pr, but should probably make their way in there concern recommendations on whether or not to expose the controlling relationship depending on DOM/a11y API relationship. E.g., we probably don't need an explicit user exposed controlling relationship if a controlled element is directly after the controlling element in the dom (e.g., a disclosure widget) but we _would_ want AT to know they could make this association clear if the elements were located in different portions of the a11y tree - e.g., a button opening a non-modal dialog that happens to be at the bottom of the DOM, but the button is somewhere else entirely.
|
linking this issue to make sure any resolution to it is taken into account here or necessary updates to resolve are contained in this PR #1956 (comment) |
|
@scottaohara did you want this to be reviewed in draft stage? |
|
@spectranaut absolutely. i need feedback to move forward. |
|
@jnurthen thought he was waiting to review until it wasn't in draft, so here is your answer james :) |
There was a problem hiding this comment.
I think my review was requested because I had voiced that I care about aria-controls.. My question after reading the initial issue and this PR is,... pardon my directness for a lack of better phrasing, what does this PR resolve?
Problems raised in the issue:
- JAWS tried to support
aria-controlsbut failed to provide a good experience so it was removed/hidden. - It's unclear if
aria-controlsis supposed provide navigation mechanism.
Both the intro to Heydon's post and developers confusion as to when and if we should use it remain:
It's poorly supported, does very little, and does what it does when it does badly.
- does very little: in terms of "forms an association", with unknown behavior.
- what it does badly: navigation.
And so with this PR
- I don’t think this provides a clearer explanation as to how AT should implement
aria-controls. - It is still debatable whether a navigation mechanism should to be implemented ("user agent MAY ... allow for a mechanism to cycle through those elements"), but that was a MAY example for when it controls multiple elements, specifically.
It seems to me from the initial issue that the most valuable use case of aria-controls is navigation (NVDA issue, @carmacleod's comment and Léonie's agreement, Heydon's post suggesting "what we think it does") WHEN the controlled element(s) are not the immediate siblings of the controller (or widget).
Is is possible to spell the ideal behaviors out with some SHOULD behaviors?
To quote @patrickhlauke's comment:
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.
which I am afraid may still be the case after this PR.
index.html
Outdated
| </ul> | ||
| <p> | ||
| <p>Additionally, the <code>aria-controls</code> property supports referring to multiple elements. For example, a button is pressed to highlight different instances of spelling errors in a document. A user agent MAY expose to a user that there are X number of controlled elements and allow for a mechanism to cylcle through those elements, and returning to the controlling element when the user chooses to do so.</p> |
There was a problem hiding this comment.
| <p>Additionally, the <code>aria-controls</code> property supports referring to multiple elements. For example, a button is pressed to highlight different instances of spelling errors in a document. A user agent MAY expose to a user that there are X number of controlled elements and allow for a mechanism to cylcle through those elements, and returning to the controlling element when the user chooses to do so.</p> | |
| <p>Additionally, the <code>aria-controls</code> property supports referring to multiple elements. For example, a button is pressed to highlight different instances of spelling errors in a document. A user agent MAY expose to a user that there are X number of controlled elements and allow for a mechanism to cycle through those elements, and returning to the controlling element when the user chooses to do so.</p> |
There was a problem hiding this comment.
And do we mean "user agent" here or "assistive technologies"?
For example:
Assistive technologies SHOULD enable users to quickly navigate to elements with role banner
There was a problem hiding this comment.
yes. thank you. i had started to write the sentence based on what use agents should expose, but then drifted into what AT could provide. I'll get this corrected.
Co-authored-by: Mu-An Chiou <me@muanchiou.com>
Co-authored-by: Mu-An Chiou <me@muanchiou.com>
|
Hey @muan, yeah.... I can completely understand your response to this PR, especially since I see you were added as a reviewer without any context as to the 'why'. So, to back up a bit - this PR is not done and was meant as a starting point to get the ball rolling of ways to extend/improve the currently lacking definition into something that would provide more guidance for how AT could expose it to users. This really should have a "not ready for merge" or "needs help" label. The PR is not ready, nor expected to be ready for any level of merging. The initial take I made with this PR was to incorporate some aspects of Talking with @smhigley about this some more, another way this could go would be to double down on what aria-controls does well now - and that is how it is used to associated comboboxes with their popups, or even with how a text field can be associated with a listbox for a type-ahead/filtering component. For instance, NVDA and Narrator - when an aria-controls association is made between a searchbox and a listbox - will announce the newly selected option as the listbox options are filtered. Some very rough example text pertaining to the above:
So there are a couple of ways this could go. I think it's probably important to acknowledge that any past assumptions/criticisms of the attribute need to be taken into account, but may also not be exactly what needs to be done here - especially since aria-details has been introduced and arguably serves the need that some people were looking at aria-controls to solve. But there is also potential overlap here. Or, per the direction sarah and i were discussing, we potentially forgo that overlap and go a different direction... or maybe it's a combination of the two... something else entirely? I hope all that helps, and again i'm sorry you didn't have that context before you spent time reviewing. Really appreciate any additional thoughts you may have on this. |
|
@scottaohara No problem. I understand now. Thanks for the explanation. |
There was a problem hiding this comment.
All of these are small improvements to the prose around aria-controls without really solving any of the real problems (I know you're aware of this as you have already commented similarly in the PR comments)
In order to get something useful I think we really do need to work out how to add the suggestion that AT allow navigation to/from the controlled region(s) when useful (and how to work out when it is useful). Some language around when not to use aria-controls might also be good so we can try to avoid many of the cases which caused the noise and JAWS to disable their implementation by default.
I don't have any good suggestions as to how to do this though.
|
from today's call - the scope of this is going to be reduced to be an editorial update to expand on the current definition of aria-controls. we don't have the ability to do adequate testing for any updates to improve/change the way aria-controls should work right now, so if we move forward with this PR at all, it will be limited to just editorial description of the attribute, rather than changes to it. |
|
Link to minutes from today's meeting: https://www.w3.org/2024/01/04-aria-minutes.html#t06 |
| <p><a>Identifies</a> the <a>element</a> (or elements) whose contents or presence are controlled by the current element. See related <pref>aria-owns</pref>.</p> | ||
| <p>For example:</p> | ||
| <p><a>Identifies</a> the <a>element</a> (or elements) whose contents or presence are controlled by the focused element or composite widget. See related <pref>aria-details</pref>.</p> | ||
| <p>The <code>aria-controls</code> property is for referencing elements which are modified through user interaction of the current element or composite widget the user is interacting with. The presence of <code>aria-controls</code> enables <a>assistive technologies</a> to make users aware of the current element's association with the controlled elements, or that an association exists for instances where the controlled element was previously in the hidden state, but through user interaction of the controlling element, the associated element has become accessible.</p> |
There was a problem hiding this comment.
Editorial Nit: Second sentence is run-on. Can you break it up into multiple or turn it into an example list?
Co-authored-by: James Craig <cookiecrook@users.noreply.github.com>
Co-authored-by: James Craig <cookiecrook@users.noreply.github.com>
resolves #995
The intent with this update is, 4 years later, to propose a draft solution for the issue I opened.
With the progress made on aria-details, and the overlaps in how this attribute could have been useful, I did take great liberty in pulling in further explanation/examples for aria-controls from the existing aria-details spec text.
Things i didn't overly call out in this pr, but should probably make their way in there concern recommendations on whether or not to expose the controlling relationship depending on DOM/a11y API relationship. E.g., we probably don't need an explicit user exposed controlling relationship if a controlled element is directly after the controlling element in the dom (e.g., a disclosure widget) but we would want AT to know they could make this association clear if the elements were located in different portions of the a11y tree - e.g., a button opening a non-modal dialog that happens to be at the bottom of the DOM, but the button is somewhere else entirely.
Preview | Diff