Rethink how "hidden" is aria-hidden content?

[scottaohara]

Now that inert is implemented in browsers, essentially doing what aria-hidden could never really do - fully preventing all users from being able to access content the attribute is applied to, should this be noted for the aria-hidden attribute? That, depending on context, there may be a more robust host language tool available?

Additionally, as we are aware that use of the attribute can often be.... problematic (re: incorrect), and there have already been actions taken to re-expose hidden content when it receives keyboard focus, the question was raised to me whether aria-hidden=true should instead not prune the content from the accessibility tree, but instead mark it as "hidden". The intent there being to still expose the content via the a11y tree, but allow AT to inform users they have reached hidden content, and give them the choice to go venturing into it, or to navigate to the content that isnt' marked as hidden.

[accdc]

I don't recommend this as a general statement, mainly because this is only valid on modal dialogs and not on any other valid implementations of aria-hidden where the option of tunneling into hidden content would only cause confusion.

E.G. Often aria-hidden is used within interactive widgets to prevent the announcement of redundant content or non-sensical Unicode characters.

Examples: https://whatsock.com/Templates/Switches/Standard/index.htm Or the use of aria-hidden on SVG elements to hide child nodes.

I don't have a problem with singling out the use of inert with dialogs, just that aria-hidden is used for many things that are not all dialog-centric.

Another more complex example of this is within the datepicker at: https://whatsock.com/Templates/Datepickers/Basic/index.htm Where the week day elements don't make sense to be included within the accessibility tree and need to be hidden, but not from sighted users.

My point is that aria-hidden has many uses that are hard to predict and genralize, and many of them would cause issues when combined with inert or if there was an option to tunnel into their content.

[scottaohara]

@accdc not sure i follow the rational for your examples, since each of those instances of aria-hidden that you're using could now instead use inert to achieve the same effect. but maybe you're thinking of something specific that i'm not noticing. i did review each and for each instance of aria-hidden that i found, inert works just as well unless i missed something?

the point i'm trying to bring up is that there is presently no recourse for AT to help their users if the hidden content is completely dropped from the accessibility tree. the manner in which they could make people aware of this fact - that there is extra content that can be seen or even interacted with is largely outside of the scope of what they can even work around, without being given access to the content that has been purged.

Agreed that people have used aria-hidden in many ways which are hard to predict and generalize. That was never my intent to indicate that they were, or to even try to solution this away into a neat little bow. But looking forward to discussing this more. I'm sure there's a lot of counter points and use cases that might make this hard to impossible to revise. But maybe it can be the starting point to think of something better, or at the very least, a way to uncover an escape hatch for people who can't access content due to highly inappropriate use of aria-hidden which goes unnoticed since it doesn't impact anyone not using AT.

[spectranaut]

Put on agenda for 29th meeting

Edit: we did not get to this topic yet, putting on July 13th meeting

[spectranaut]

@aaron if you could link related issues

[aleventhal]

I think it's worth experimenting with these and perhaps putting behind a flag in one of the browsers, to see if people like the changes:

• Consider allowing aria-hidden=false on visibly rendered elements inside an ancestor with aria-hidden=true
• aria-hidden error case: remove attribute aria-hidden=true on elements that become focused, and any ancestor of the element that is currently focused
• aria-hidden error case: disallow aria-hidden on root or document element (e.g. <html> or <body>)

[stevefaulkner]

+1 for TPAC

[scottaohara]

@scottaohara todo: add notes here for things to consider for the f2f discussion

[css-meeting-bot]

The ARIA Working Group just discussed Rethink how "hidden" is aria-hidden content?.

The full IRC log of that discussion

<spectranaut_> TOPIC: Rethink how "hidden" is aria-hidden content?
<spectranaut_> issue: https://github.com/w3c/aria/issues/1951
<Matt_King> github: https://github.com/w3c/aria/issues/1951
<Matt_King> scribe+
<Matt_King> Aaron: the 401k problem: we can't do anything for users when aria-hidden was used and the user is trying to access their 401k page. Critical information is hidden due to author error.
<Matt_King> Author may use aria-hidden on body. There are many example of misuse.
<Matt_King> The problem is that the information marked hidden is actually visible to other people.
<jamesn> q+
<jamesn> zakim, open the queue
<Zakim> ok, jamesn, the speaker queue is open
<jamesn> q+
<Matt_King> One proposal: let aria-hidden=false unide the content.
<jamesn> q- Marcelo_Paiva_
<jamesn> ack me
<Marcelo_Paiva_> Scott has written about this - https://www.scottohara.me/blog/2018/05/05/hidden-vs-none.html
<Matt_King> Correction: change so that if an ancestor has aria-hidden=true, chang browsers so that if a descendant has aria-hidden=false, it will unhide the node.
<Matt_King> Today, browsers don't process elements that ar descendants of aria-hidden=true nodes.
<Matt_King> We have broad agreement to change that.
<melsumner> Question: what is a valid use case of aria-hidden on the body element
<jamesn> https://w3c.github.io/aria/#tree_inclusion
<Matt_King> Next migigation proposal: If user focuses an area inside of a aria-hidden=true area, browser will unhide the elements in the aria-hidden=true area.
<spectranaut_> Matt_King: this is what I wanted to happen
<spectranaut_> s/migigation/mitigation/
<Matt_King> James Craig: There are potentially other things that are hidden that should be hidden.
<jamesn> qv?
<Matt_King> JNurthern: It was already an author error. And, we could do a console errior, right?
<jamesn> s/JNurthern/jamesn/
<Matt_King> Aaron: Another mitigation proposal: On platforms that support it, if there is a hidden state in the accessibility tree, use that instead of pruning the AX tree.
<Matt_King> This allows AT to access those elements.
<Matt_King> JNurthen: the spec says the UA SHOULD NOT include the hidden elements in the tree. So, it is a should not, not a must not b/c of gecko
<StefanS> q+
<melsumner> q+
<Matt_King> James Craig: We could let the AT have a trigger that tells webkit to show your hidden items?
<Matt_King> If we were not not prune the tree, we would have to change a lot of AT that use webkit. Instead, we could still prune the tree but give the AT a way to trigger webkit to hand over the hidden items.
<jamesn> q?
<jamesn> ack StefanS
<jcraig> s/tells webkit to show /tells the browser enginer to show /
<jcraig> s/enginer/engine/
<Matt_King> StefanS: if a node is inert and a descendant has aria-hidden false, who wins.
<jamesn> qv?
<Matt_King> Aaron: in our implementations, inert wins; it would be hidden.
<StefanS> q-
<jamesn> ack melsumner
<jcraig> s/If we were not not prune the tree, we would have to change a lot of AT that use webkit. Instead, we could still prune the tree but give the AT a way to trigger webkit to hand over the hidden items./Either solution requires work... The difference is mainly whether you do the work in the engines or in every AT. Another potential solution is to still prune the tree but give the AT a way to trigger the engine to hand over the hidden items./
<Matt_King> Melanie: Why are 401k vendors asking for their errors to be fixed.
<Matt_King> Aaron: it is the sr users that are asking. We try to help the users. It is hard to get every vendor to fix their web site. The users are blocked, and we want to unblick them.
<jcraig> s/unblick/unblock/
<Marcelo_Paiva_> would it be appropriate to mention or acknowledge how role="none" impacts aria-hidden?
<Matt_King> Melanie: I had to work in a univ dev dept where we often had to write code to fix content from vendors, why can't they do that?
<Jem> +1 to Aaron's philosophy..
<Matt_King> Aaron: we just have compassion for the users. They often don't have anyone who can clean up the errors that are blocking them from accessing critical content that.
<jamesn> q+ to ask if we would expect all these things to remain authoring errors
<jamesn> ack me
<Zakim> jamesn, you wanted to ask if we would expect all these things to remain authoring errors
<Matt_King> JNurthen: would we still expect all of these things to be author errors?
<Matt_King> James Craig: Yes.
<Matt_King> JNurthen: these changes will not fix all the issues; it will improve situations and probably show some content should be legit hidden.
<Matt_King> Aaron: who wants to write and review the PRs for these changes?

[spectranaut]

Discussed during TPAC this week, notes here: https://www.w3.org/2023/09/11-aria-minutes#t06

And draft PR already up here: https://github.com/w3c/aria/pull/2037

[scottaohara]

I think if https://github.com/w3c/aria/pull/2181 is accepted, then this issue can probably be closed - as the majority of error cases that might result in someone wanting to be able to unhide aria-hidden content will largely be taken care of by that PR as well as https://github.com/w3c/aria/pull/1880