Consider allowing aria-hidden=false on visibly rendered elements inside an ancestor with aria-hidden=true

[cookiecrook]

In relation to aria-hidden error cases #1254 and #1255, @aleventhal suggested that we reconsider allowing aria-hidden=false on visibly rendered elements inside an ancestor with aria-hidden=true

The example of this is aria-hidden=true on a main section, but aria-hidden=false to "unhide" the descendant, such as a dialog or menu. In this case, the WG generally agreed that the author intention is pretty clear.

<main aria-hidden="true">
  ... main content hidden during this state, and usually "grayed out" visually ...
  <div role="menu" aria-hidden="false">
      ... dialog or menu content "unhidden" ...
  </div>
</main>

It's worth noting that, years ago, @asurkov was opposed to having aria-hidden="false" expose non-rendered elements to the accessibility tree, and I think in most cases that concern is still valid. This issue is proposing that visible, rendered elements could use this pattern... somewhat similar to a non-inert descendant of an inert ancestor.

Opening for discussion. @aleventhal suggested both @asurkov and @jcsteh may have comments.

[aleventhal]

If we do this, I think we wouldn't want to implement the proposal in issue 1254, because a valid use case would be to put aria-hidden=true on the html/body, and aria-hidden=false on a descendant.

[jongund]

I think we should be limiting rather than expanding the scope of aria-hidden, we should look at limited the creativity of this problematic property.

I have some questions:

1. Is there a place for this property in a website that is engineered for accessibility, or is it primary purpose to support some type of repair of an inaccessible website?
2. Can aria-hidden be more like the hidden attribute and have no values, if present it just removes content from the accessibility tree?
3. Do we need a ARIA property that shows content in the accessibility tree, but is not in the DOM rendering tree?
4. Do we need an ARIA property or technique that is clearer that content is "decorative", like role="img" aria-label="" to build off current HTML technique of img alt="" element or an aria-decorative property?

The original goal Tim Burners-Lee had for the web was for people to write something once and have it viewable everywhere. Maybe modern web development left this principle behind many years ago, but I have mostly heard in this discussion developers using aria-hidden have to do a lot of testing to see if it will have the effect they want, assuming they even understand the effect they are looking for is supporting accessibility. A feature that requires more testing is something we should be trying to limit, rather than expand the scope.

From the authoring practices perspective we should be emphasizing that content should be visible or not visible in both the DOM and accessibility tree, and the use of existing HTML and CSS standards to do this.

Hiding/Showing Options for the web

Technology	Property	Graphical Rendering	Accessibility Tree
HTML	hidden attribute	not rendered	not included
CSS	display: none	not rendered	not included
CSS	visibility: hidden	content not rendered, but box dimensions are maintained, descendant content can be rendered by applying visibility: visible	only content made visible by descendant elements with visibility: visible is available in the accessibility tree
CSS	position: absolute; top: -300px; left: -3000px	rendered off screen	included
ARIA	aria-hidden=true	content rendered normally	not included, but some browsers make descendant content with aria-hidden="false" avialable in the accessibility tree

[aleventhal]

Hi Jon, I think the problem is that when you have a boolean property, developers naturally expect both boolean values to work. Can you think of a single other boolean property where only one value works? No developer expects this, and you can see the results when you visit websites like vanguard.com that are peppered with aria-hidden=false.

I think the rule to remove aria-hidden=false as a value happened later? I'm not sure the history, but I think removing that value may have been a mistake because there were some implementation concerns.

There are some valid uses of aria-hidden, and it's too late now to change the values to something not boolean.

[jcsteh]

It's worth noting that the idea of hidden not being something you can override on a descendant is not specific to aria-hidden. CSS display: none cannot be overridden by a descendant, nor can the HTML hidden attribute. So I don't think the "authors expect both values to work" argument holds by itself.

[scottaohara]

to be fair though, it's not always consistent.
yes, display: block within a display: none container won't be re-exposed.
but, visibility: visible within a visibility: hidden container will.

[jongund]

So the proposed behavior for aria-hidden including content in the accessibility tree is the model used by CSS visibility property for graphical rendering?

[sinabahram]

Folks, I think we’re getting seriously derailed on this conversation, IMHO. The problem is that authors and frameworks are using aria-hidden incorrectly in the wild. We’ve identified a few cases where we feel the browser can detect this with low or no false positives. False negatives are obviously to be preferred over false positives here. So, this issue, as I see it, is not trying to solve anything with CSS or what aria-hidden “should have been” or the nature of Boolean values or really anything else, other than … in these few targeted cases, spanning thousands of experiences, where a person wit a disability is being prevented from accessing deeply important web content e.g. their 401K, their bank account, their educational software, are we good with the browser saying … author, you did something against the spec. My heuristic detected this, corrected the issue, notified you via console.log or whatever you wish to use, and even gave you a link to explain how to fix. I’m a fan of both of the proposals, this one, and removing aria-hidden on body. I’ve worked on just countless projects spanning junior to super-senior developers, all of whom have messed this up in one way or another. Does anyone disagree that browsers should do this?

[stevefaulkner]

Related discussion from 7 years ago: Add accessibles that have aria-hidden="false" to the tree even if HTML5 hidden or CSS hidden or display: none

[carmacleod]

I'm not sure the history ...

I managed to find some history from 2014: https://www.w3.org/2014/01/13-pf-minutes.html

I don't completely understand the "weak vs strong mapping" part of the discussion, but it seems that the goal was to enable the following markup:

<div hidden aria-hidden="false">This content is available to ATs</div>

Edit: Which is what @stevefaulkner just said... ^

[aleventhal]

@jcsteh there are 3 things that make it different from display:none

1. It's a boolean, and it's natural to assume a boolean will work both ways. Imagine if instead of display:none, it was display:false. Wouldn't it be confusing if display:true didn't work?
2. It's a hidden error. Most web developers don't use a screen reader, and barely notice problems they create with ARIA when they using something incorrectly. So if they use aria-hidden=false, and it's natural to assume that it would work, we're lucky if they notice it didn't. In contrast, if you create display:block subtree inside a display:none container, it will be obvious to everyone that it didn't work.
3. Web developers in general know CSS much better than they know ARIA

[aleventhal]

Also, as others have pointed out, aria-hidden=false actually does work sometimes, when it's used on something styled as hidden.

So it's even more confusing that it doesn't consistently work. I'd make that point 4 for my previous comment.

[jongund]

I think we need a clear model of how aria-hidden is suppose to work and analogies to CSS will be helpful to developers with a technology they maybe more familiar to them. The HTML hidden property is also a boolean at the DOM level node.hidden=true; and node.hidden=false; are available in Javascript. I think we need to have a clearer model of when authors should use it and then look at the abuses that commonly occur based on those use cases.

[asurkov]

I indeed was opposed to aria-hidden="false" on not rendered elements, and I think I am, at least until ARIA provides a way to specify visual info like boundaries.

I'd say nested aria-hidden="false" on visual elements is a different story. Dialog use case feels natural with me, and I'm not surprised that people tend to put aria-hidden="true" on body and aria-hidden="false" on the dialog to hide everything but the dialog. I think I would try to do that myself if I was less familiar with aria-hidden :)

So as I understand it people use this pattern in the wilds, and @sinabahram point seems valid with me as well: if the browsers can fix it with no false positives, and if it helps to the web development, then it's worth to do. The only downside of aria-hidden="false" I can see it complicates (noticeably) the browsers implementation (but same time I wouldn't say it has to be deal breaker).

Then, hidden and display:none indeed cannot be overridden in subtree, and aria-hidden is also speced out and implemented this way. Having said that, the web has the opposite example, which is CSS visibility style, which can be overridden in subtree. I heard that CSS/layout engineers are not very happy about it, but it is something the web has and web developers use.

Then, there is some discrepancy between aria-hidden boolean values and HTML boolean attribute definition, which (might be not obvious) doesn't allow "false" value according to HTML spec (https://whatpr.org/html/4288/bcd5d61...f538a12/common-microsyntaxes.html#boolean-attribute). That's why you can't have HTML hidden="false". I think it is misleading that ARIA spec always referred to aria-hidden as aria-hidden="true" which gives a false impression to the web developers that aria-hidden="false" has to exists. And thus I think aria-hidden="false" exists in the wilds now :)

So, I'd say aria-hidden may behave similar to HTML hidden attribute/CSS display:none (the current state), or stay close to CSS visibility property (the proposed change). I'd say we should be guided by the use case in order to define it. If it helps to the web developers then it's worth to do. I don't feel very confident on the last item, it could be there are other guidelines I miss here, so I'd grab opinion from HTML folks too (cc'ing @annevk).

[aleventhal]

@jongund that's a good idea. How about the analogue being CSS visibility: hidden/visible?

@asurkov we're currently doing the opposite of what you suggest. What I mean is that aria-hidden =false works on content that is actually hidden via style, but doesn't work on visible content nested inside aria-hidden=true. However, I think we should just make it work for both cases. It would be weird to take a case away now.

[scottaohara]

the issue i see here with exposing aria-hidden=false within aria-hidden=true containers is that there will be instances where authors (and users) don't want or expect the aria-hidden=false content exposed.

for instance, using the dialog example, this could work as long as there are no other aria-hidden=false elements contained within the aria-hidden=true container:

<!-- body or could be a div#app that contains the content of the document -->
<body aria-hidden=true>
  ...
  <div role=dialog aria-hidden=false>...</div>
  ...
</body>

But, if you get a page that happens to have a dialog exposed as demonstrated in the previous markup pattern, as well as various other elements with aria-hidden=false on them (often I see this for no reason other than the 'framework' added them) then you can have many elements being exposed when they shouldn't be.

<!-- dialog outside of the primary container -->
<div role=dialog>...</div>

<!-- primary container set to aria-hidden=true to hide contents while dialog is open -->
<div aria-hidden=true>
  ...
  <input type=checkbox aria-hidden=false> <!-- would be exposed but really shouldn't be -->
  ...
  <button aria-expanded=false>disclosure trigger</button>
  <div aria-hidden="false">...</div>
  <!-- div uses aria-hidden=true/false as CSS selector to toggle display block/none. -->
</div>

When reviewing websites/apps (specifically SPAs) I come across elements with aria-hidden=false on them for no real reason, daily. Yes the attribute often shouldn't be there... but, per current behavior, aria-hidden=false on these elements is presently more of a code smell than resulting in any actual issues. Making a change to expose aria-hidden=false within aria-hidden=true containers would potentially create issues in situations where there presently were no issues, as much as I personally like the idea of making that change...

[aleventhal]

@scottaohara that's indeed a good point, however, I'd rather we err on the side of exposing too much content, due to the "can't access my 401k" problem. I don't think it will be that bad, I really don't.

[scottaohara]

As mentioned, I like the idea so I’m not going to try to much harder to convince otherwise.

I just think stuff like that needs to be called out and would need to be reflected in any updates to the spec / authoring guidance, since this would effectively change the false value from having a note basically saying “don’t use” to “this may really do something to your current code now!”

As an aside, which can be commented on later / in the appropriate thread, but would making this change to how aria-hidden=false works potentially make aria-modal=true moot?

[jnurthen]

How about we only do these corrections in certain cases - just ideas could do one or all or none of these:

• we ignore aria-hidden=false only when there is nothing in the tree (i.e. if they have hidden the body)
• we only allow aria-hidden=false on certain roles. Perhaps start with just the window roles but potentially expand to allow other structural roles too. Continue to treat aria-hidden=false as a no-op on widgets.

[sinabahram]

I feel it’s critical that we undo aria-hidden=”false” upon focus. This had universal agreement on the call from all parties, but I’m concerned that these two criteria don’t account for that case. If something is focused, and there’s aria-hidden=”true” on it, is there any valid use case we would violate by undoing aria-hidden=”true”?

[jnurthen]

I feel it’s critical that we undo aria-hidden=”false” upon focus. This had universal agreement on the call from all parties, but I’m concerned that these two criteria don’t account for that case. If something is focused, and there’s aria-hidden=”true” on it, is there any valid use case we would violate by undoing aria-hidden=”false”?

That is a separate issue

[scottaohara]

@sinabahram that use case still has #1255

[sinabahram]

@jnurthen I'm sorry, I read your comment as trying to be the only two rules, not just scoped to this issue. Please disregard.

[scottaohara]

i like @jnurthen's proposal, as it would mitigate against the scenario i raised of developers correctly hiding the primary document, while exposing a dialog as a sibling to it.

so in this scenario:

<body aria-hidden="true">
  ...
  <input type=checkbox aria-hidden=false>
  ...
  <div role=dialog aria-hidden=false>...</div>
</body>

both the checkbox and the dialog would be exposed, because otherwise the aria-hidden=true would have resulted in no content in the a11y tree.

but in the scenario i was mentioning:

<body>
  <div role=dialog ...>...</div>
  <div aria-hidden="true">
    ...
    <input type=checkbox aria-hidden=false>
    ...
  </div>
</body>

the aria-hidden=false content within the aria-hidden=true container wouldn't be exposed because another element (the dialog) is present in the accessibility tree. This would then make sure that modal dialog setups that currently work as expected wouldn't regress and allow certain elements outside of the dialog to re-appear in the accessibility tree.

[sinabahram]

RE @jnurthen's suggestion:
"we ignore aria-hidden=false only when there is nothing in the tree (i.e. if they have hidden the body)"

I don't feel that goes far enough to fix the issues being observed in the wild. We all say body casually, but this could be on main or on a div that acts in place of main or a few layers down from that but still spanning tons of items. I think it's impossible that this won't result in some errors somewhere like @scottaohara's example, but I also claim every single error it results in is a case of invalid code, not valid code (ever, or so we all claim, right?), therefore if the worst that happens is that invalid aria usage exposes "more" not "less" content. While that is absolutely "annoying", it can lead to good changes in the long-term, and the up-side to any such pain, no matter how small it is, is that many users will now be able to access content they otherwise couldn't, which I think must always superceed the former in any comparison.

[jnurthen]

@sinabahram I don't think there is anything invalid in @scottaohara 's example. I think it is a real use case. Yes - it would be better without the aria-hidden=false but that doesn't mean we should break it.

[sinabahram]

@jnurthen, then I'm missing something, because I thought having aria-hidden="false" inside of aria-hidden="true" was clearly invalid.

[jnurthen]

The spec states "An element is considered hidden if it, or any of its ancestors are not rendered or have their aria-hidden attribute value set to true."

I've always considered aria-hidden=false to be a no-op based on this unless it was applied to the element which is hidden itself (i.e. <div hidden aria-hidden='false'>) - not that I would recommend doing that as I think (have not tested though) that implementations are all over the place.

[aardrian]

If this moves forward, I urge you to also create guidance documents and/or supporting WCAG Techniques documents and roll them out at the same time.

The pattern @scottaohara referenced is prominent in screens built by developers leaning on frameworks who have little understanding of ARIA. Getting dev teams, libraries, frameworks, etc. to yank this will take time and it will require "official" WCAG documents to get some orgs to move at all.

Until implementations catch up, testing for some orgs will be a bear, so having clear human-readable Techniques may be the only real "testing" they can do.

[jcsteh]

@jcsteh there are 3 things that make it different from display:none

1. It's a boolean, and it's natural to assume a boolean will work both ways. Imagine if instead of display:none, it was display:false. Wouldn't it be confusing if display:true didn't work?

This does not apply to the HTML hidden attribute, though. I'm not saying this is a reason not to implement this proposal. I'm saying that arguing that the current behaviour is counter-intuitive "because it's a boolean" is invalid, since we already have this behaviour with HTML hidden. If we're going to make arguments for/against, they should be valid ones. Your other two points are entirely valid.

Also, as others have pointed out, aria-hidden=false actually does work sometimes, when it's used on something styled as hidden.

It does not work this way in Gecko and it never has. I'd argue the spec doesn't explicitly cover this, though it's also fair to say that it does not explicitly disallow it. From the spec:

User agents determine an element's hidden status based on whether it is rendered, and the rendering is usually controlled by CSS. For example, an element whose display property is set to none is not rendered. An element is considered hidden if it, or any of its ancestors are not rendered or have their aria-hidden attribute value set to true.
Authors MAY, with caution, use aria-hidden to hide visibly rendered content from assistive technologies only if the act of hiding this content is intended to improve the experience for users of assistive technologies by removing redundant or extraneous content.

Note there is no mention of exposing non-rendered content. Then there's the definition of "hidden":

Indicates that the element is not visible, perceivable, or interactive to any user. An element is considered hidden if it or any one of its ancestor elements is not rendered or is explicitly hidden.

Again, there's no mention of non-rendered content being "not hidden" if overridden by aria-hidden.

[sinabahram]

It feels like we have some consensus around this issue. Would love to move this into next steps.

[aardrian]

Citing #1256 (comment) from @scottaohara:

When reviewing websites/apps (specifically SPAs) I come across elements with aria-hidden=false on them for no real reason, daily. Yes the attribute often shouldn't be there... but, per current behavior, aria-hidden=false on these elements is presently more of a code smell than resulting in any actual issues.

I regularly encounter cases of aria-hidden=false in a financial / banking site that are being inserted automagically by the client's chosen framework (as I noted above).

Lately I have seen some of these aria-hidden=false nodes within aria-hidden=true nodes that contain content that should not be exposed. The developers are sometimes pre-loading content that will be displayed if the user makes a selection on the screen.

In these cases, if aria-hidden=false overrides the parent aria-hidden=true, that nested content will say the opposite of what the user has chosen (in addition to what the user has chosen). These scenarios can have grave financial consequences when it comes to things like moving funds, assigning account owners, and so on.

I am specifically not arguing for or against overriding, but guidance must be provided and clearly documented if overriding is allowed. This guidance may be necessary for some clients to consider this arbitrary use of aria-hidden=false as truly an issue instead of a browser or screen reader bug (often their go-to defense).

That guidance can also be used to push frameworks and libraries to drop their cavalier use of aria-hidden=false, and help push some other clients to update them when it happens.

[aleventhal]

@aardrian are you saying that you commonly see examples where the author put aria-hidden=false nested in an aria-hidden=true, but it's vital to keep it hidden? In this case is the content visible for the sighted user? This does sound like a potential counter argument, but at the same time, really is horribly marked-up content.

I think we all agree with your point that guidance must be provided to the author.

[aardrian]

@aleventhal

are you saying that you commonly see examples where the author put aria-hidden=false nested in an aria-hidden=true, but it's vital to keep it hidden?

Yes.

In this case is the content visible for the sighted user?

No.

To expand on this a bit, I logged into the client customer-facing financial system and searched for this Xpath in the Chrome dev tools:

//*[@aria-hidden="true"]//*[@aria-hidden="false"]

On a single page showing transaction history I got 38 hits. I then manually walked up the DOM to ensure the nodes with aria-hidden=false were indeed descendants of a node with aria-hidden=true.

Most of those were all the individual rows in a grid (ARIA grid, but <div>s otherwise) set to aria-hidden=false while the parent grid was set to aria-hidden=true and visually hidden on the page.

If this data was exposed to screen reader users while the developers intended it to be hidden, the context of the page (headings, messaging) would suggest these transactions belong to a different account. If a user takes action on that information (canceling transactions, changing anything, panicking) that could have a catastrophic consequence on their finances.

In another case, there was a "loading" element with aria-hidden=false that is a child of a node with aria-hidden=true. When the page is rendering, the parent node is toggled to aria-hidden=false and, when the loading has completed, it is toggled back to aria-hidden=true. The actual "loading" text is never changed from aria-hidden=false.

These examples generally corresponded with an ng-show attribute and ng-show and ng-hide classes on those elements, suggesting this behavior is baked into the Angular implementation they are using. As opposed to developers intentionally setting these attributes.

Having worked with these developers, I can assure you they are generally unfamiliar with aria-hidden.

[jnurthen]

Likely caused by this in ngAria - https://docs.angularjs.org/guide/accessibility#ngshow

[scottaohara]

Have similarly run across the same sort of situation in a number of angular apps that also used ng-aria

[scottaohara]

so @aleventhal and I apparently did a re-hash of this entire issue thread today without either of us realizing it.

essentially, we went back and forth on almost every point made in this thread, and somehow again came to the conclusion that if aria-hidden=false were to be treated like visibility: visible inside of a parent visibility: hidden parent - that'd generally be a good idea to ensure that people could review their pokedex - an example of an ARIA dialog with aria-hidden=false being rendered within a body element with aria-hidden=true.

i again raised the points about frameworks willy nilly adding aria-hidden=false to other components, and how this could then reveal those items unexpectedly as well. A very quick example for the purposes of demonstrating that Foundation 6.5 uses aria-hidden=false when rendering its accordion panel content https://codepen.io/scottohara/pen/wvEBbxJ. a slap dash ARIA dialog was added to that as an example of where the content of those panels SHOULD NOT be exposed, but they would be to mitigate the pokedex (or more importantly the 401k) scenario mentioned previously.

Without realizing it, I raised apparently the same idea did 2ish years ago

where if we could expose aria-hidden=false content inside of an aria-hidden=true parent, but then also make sure that if the ARIA dialog has an aria-modal=true, that the virtual cursor would continue to not be able to (easily) navigate to any other aria-hidden=false content outside of the modal dialog, then that'd seem a good way to both mitigate (current) author error for rendering a dialog within an aria-hidden parent, but not immediately re-expose content that users "should not" be accessing at that point in time.

<body aria-hidden=true">
  <div aria-hidden=false>content and focusables and whatever</div>

  <div aria-hidden=false role=dialog aria-modal=true>
    this should be accessible, but immediate access to the other aria-hidden=false content
    should still happen.
  </div>
</body>

And a situation like this, without the use of aria-modal=true, both content areas would be accessible because there's no additional signal that the dialog is actually supposed to be modal.

<body aria-hidden=true">
  <div aria-hidden=false>
    this would be accessible because of aria-hidden=false
  </div>

  <div aria-hidden=false role=dialog>
    this would be accessible because of aria-hidden=false
  </div>
</body>

But, regarding Carolyn's last comment here, 2ish years later developers finally have wider support for inert and native dialog elements... it'd sure be nice to push people to use those and away from these easy to mess up ARIA dialogs :(

[aardrian]

where if we could expose aria-hidden=false content inside of an aria-hidden=true parent, but then also make sure that if the ARIA dialog has an aria-modal=true, that the virtual cursor would continue to not be able to (easily) navigate to any other aria-hidden=false content outside of the modal dialog, then that'd seem a good way to both mitigate (current) author error for rendering a dialog within an aria-hidden parent, but not immediately re-expose content that users "should not" be accessing at that point in time.

I like this exception in theory. I expect some digging for mis-uses of aria-modal=true is in order here (with a firm look at those that mis-use aria-hidden already).

So yeah, novel approach that requires some research. Assuming I understood this.

[zcorpan]

Now that inert is again a thing, this issue makes it hard to specify mapping for inert and dialog. (It was already an issue for dialog in an aria-hidden=true subtree.)

See w3c/html-aam#410

In particular, a modal dialog element should be unhidden/uninerted.

[cookiecrook]

@zcorpan aria-hidden=false is a somewhat controversial topic. I think what you're looking for would need to be a feature of inert.

[aleventhal]

@cookiecrook I believe the proposal is to allow it to work, to revive it for certain situations, because authors are using it thinking it will work, and users are left with nothing.

[cookiecrook]

Sorry. Some cross-issue context was lost in my comment. @scottaohara summarized it well in a reply to this thread on inert mappings.

[cookiecrook]

Of note, this is related to visibility: visible; in the same context.

• fix aria-hidden text for visibility: visible; #1618

WebKit Accessibility is open to the proposed change, but given how different the initial implementations ended up, I'm hesitant to proceed with implementation changes until after a computedhidden or computedaccessibilitynode.hidden is available in WebDriver/TestDriver, and those aren't specified yet. Nevertheless @twilco has a WIP patch in WebKit 241393.

[cookiecrook]

Clarifying the change I'm understanding for WebKit would be:

• keep support for aria-hidden="false" on "rendered" (TBD definition) elements
• remove support for aria-hidden="false" (No Op) in unrendered subtrees (e.g. display: none;)

[cookiecrook]

• aria-hidden=false issues core-aam#58

[scottaohara]

in another conversation with @aleventhal about this, it resulted in the rehashing of some of the points raised in this thread, particularly the reminder about JS framework/component libraries having used aria-hidden=false on components that could very well be put inside of an aria-hidden=true subtree.

With that in mind, and the fact that the ARIA spec has essentially warned people away from using aria-hidden=false for years, maybe the best thing to do is nothing for aria-hidden=false.

Aaron created this chromium bug to do just that:
https://bugs.chromium.org/p/chromium/issues/detail?id=1500299

[cookiecrook]

Overcome by #2090. Closing.