This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Currently, the spec says > User Agents are encouraged to expose the full semantics of hidden > elements to Assistive Technology when such elements are referenced > from WAI-ARIA attributes such as aria-describedby. It's come to my attention that some have interpreted this statement to mean that UAs should include hidden="" elements in the ordinary accessibility tree when they happen to be so referenced. Were this true, it would be potentially harmful because users might navigate into that part of the ax tree. We should try to reword this so that such an interpretation is impossible for people to draw from the statement.
I suspect that part of the problem is that some people use "Assistive Technology" and Screen Readers interchangeably, which is a problem. There are many Assistive Technologies that are used by sighted or partially sighted users that may also avail themselves to ARIA properties (the latest version of ZoomText comes to mind, which is both a screen magnifier and a screen reader). If this techniques is intended for screen readers only, then it should clearly state so, and avoid adding confusion by referencing Assistive Technology. > > User Agents are encouraged to expose the full semantics of hidden > > elements to Assistive Technology when such elements are referenced > > from WAI-ARIA attributes such as aria-describedby. > > It's come to my attention that some have interpreted this statement to > mean that UAs should include hidden="" elements in the ordinary > accessibility tree when they happen to be so referenced. Were this true, > it would be potentially harmful because users might navigate into that > part of the ax tree. But is that not a given when you speak of "Full Semantics"? If you are instead envisioning some partial, specific semantics, then say so as well. If @aria-describedby is pointing to an @hidden ordered list of links (completely legitimate and possible with this current change), then of course a tool such as ZoomText needs to navigate into that part of the ax tree, and further it needs to be rendered visually on screen. > We should try to reword this so that such an interpretation is > impossible for people to draw from the statement. I look forward to seeing how this might look (outside of the fact that the entire Issue 204 decision currently has 2 Formal Objections filed against it).
James Craig proposed the following text during the 30 August HTML a11y TF call: [[ Where accessibility APIs allow nodes to be marked as hidden, User Agents are encouraged to expose the full semantics of hidden="" elements when they are referenced via relationship attributes (such as aria-describedby in WAI-ARIA). This allows Assistive Technologies to access the content structure upon user request, while keeping the content hidden in all presentations of the normal document flow. ]] Ted, do you have further refinements to that proposed text?
(In reply to comment #2) > James Craig proposed the following text during the 30 August HTML a11y TF call: > > [[ > Where accessibility APIs allow nodes to be marked as hidden, User Agents are > encouraged to expose the full semantics of hidden="" elements when they are > referenced via relationship attributes (such as aria-describedby in WAI-ARIA). > This allows Assistive Technologies to access the content structure upon user > request, while keeping the content hidden in all presentations of the normal > document flow. > ]] +1 from me.
Ping-pong. I've posted updated wording over at bug 18744 based on Steve's proposal to use a non-ARIA example.
I too have posted comments on bug 18744
I too have posted comments on <a href="https://www.w3.org/Bugs/Public/show_bug.cgi?id=18744">bug 18744</a>
I've added updated text to the other bug which tries to address both issues.
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the Editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the Tracker Issue; or you may create a Tracker Issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Accepted Change Description: https://github.com/w3c/html/commit/ca896aab1f7a3ad54b36721c6a32da5cf243d65f Rationale: Adjusted spec text per the chairs' request. This new, expanded text goes to great lengths to avoid the implications of the old text.