Closed Bug 945194 Opened 10 years ago Closed 8 years ago

Add accessibles that have aria-hidden="false" to the tree even if HTML5 hidden or CSS hidden or display: none

Categories

(Core :: Disability Access APIs, defect)

defect
Not set
normal

Tracking

()

RESOLVED WONTFIX

People

(Reporter: MarcoZ, Unassigned)

References

(Blocks 2 open bugs, )

Details

Proposal: Add accessibles that are explicitly requested by web developers to the tree via aria-hidden="false".

Background is this test page by Steve: http://www.html5accessibility.com/tests/hidden2013.html
Firefox currently fails with both JAWS and NVDA for tests 5 and 6. I think it's a good idea if we implemented support for these two test cases to ease the burden of web developers. If they want text to be un-hidden for screen reader users, and go to the trouble of using ARIA for this, we should support them. This could also go a long way towards making CSS off-scree hacks largely obsolete.
Note the mapping for the hidden attribute in HTML5 allows it to be overridden by aria-hidden=false:


Element with a hidden attribute, default mapping = aria-hidden state set to "true". If specified by an author, the aria-hidden state may be set to "true" or "false". 

http://www.w3.org/html/wg/drafts/html/master/dom.html#sec-implicit-aria-semantics
aria-hidden attacks an another wing :) I didn't like an idea to make aria-hidden="true" to prune the accessible tree and I'm not comfortable with the idea that aria-hidden="false" creates the tree.

Anyway, ARIA doesn't allow to override native semantics in conflict:

"When a feature in the host language with identical role semantics and values is available, and the author has no compelling reason to avoid using the host language feature, authors SHOULD use the host language features rather than repurpose other elements with WAI-ARIA."

http://www.w3.org/TR/wai-aria/host_languages#host_general_conflict

(In reply to steve faulkner from comment #1)
> Note the mapping for the hidden attribute in HTML5 allows it to be
> overridden by aria-hidden=false:

> Element with a hidden attribute, default mapping = aria-hidden state set to
> "true". If specified by an author, the aria-hidden state may be set to
> "true" or "false". 

It doesn't really say aria-hidden can override hidden attribute, does it? Because it shouldn't come after that aria-hidden may be set to true of false.
Blocks: aria
No longer blocks: treea11y
(In reply to alexander :surkov from comment #2)
> aria-hidden attacks an another wing :) I didn't like an idea to make
> aria-hidden="true" to prune the accessible tree and I'm not comfortable with
> the idea that aria-hidden="false" creates the tree.
> 
> Anyway, ARIA doesn't allow to override native semantics in conflict:
> 
> "When a feature in the host language with identical role semantics and
> values is available, and the author has no compelling reason to avoid using
> the host language feature, authors SHOULD use the host language features
> rather than repurpose other elements with WAI-ARIA."
> 
> http://www.w3.org/TR/wai-aria/host_languages#host_general_conflict
> 
> (In reply to steve faulkner from comment #1)
> > Note the mapping for the hidden attribute in HTML5 allows it to be
> > overridden by aria-hidden=false:
> 
> > Element with a hidden attribute, default mapping = aria-hidden state set to
> > "true". If specified by an author, the aria-hidden state may be set to
> > "true" or "false". 
> 
> It doesn't really say aria-hidden can override hidden attribute, does it?
> Because it shouldn't come after that aria-hidden may be set to true of false.

yes it does



In regards to whether ARIA allows it, suggest looking at this bug. https://www.w3.org/Bugs/Public/show_bug.cgi?id=18574
(In reply to steve faulkner from comment #3)

> > It doesn't really say aria-hidden can override hidden attribute, does it?
> > Because it shouldn't come after that aria-hidden may be set to true of false.
> 
> yes it does

I wish the spec was clearer with no requirements to make conclusions implicitly

> In regards to whether ARIA allows it, suggest looking at this bug.
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=18574

Not sure I've got the idea of the change from that bug. What I see is Leif said that aria-hidden should be moved from strong to weak table (again not sure what it means), James from Apple agreed on weak table issue and gave an example that aria-hidden="false" overrides HTML 5 hidden attribute, you did a change in the spec and Rich said thanks. So it looks like everybody on the same boat but I miss the whole point.

Despite HTML5 spec saying about aria-hidden="false" it'd be quite strange if aria-hidden="true" didn't change the tree but aria-hidden="false" did. Also HTML5 wording is not enough for implementators as it doesn't give any idea how hit testing and boundaries should be implemented for such elements.
(In reply to alexander :surkov from comment #4)

> Despite HTML5 spec saying about aria-hidden="false" it'd be quite strange if
> aria-hidden="true" didn't change the tree but aria-hidden="false" did.

Not sure what you mean here. @aria-hidden should modify the AX tree in both cases if there is a conflict. 

 <div> No conflict: Rendered for all. </div>
 <div hidden> No conflict: Not rendered. </div>
 <div aria-hidden="true"> Conflict resolution: Rendered visually but not to AX APIs. </div>
 <div hidden aria-hidden="false"> Conflict resolution: Exposed to AX APIs, but not rendered visually. </div>

If something is unclear in the spec (ARIA 1.1 ED), please file a bug in the W3C tracker or bugzilla instance.

> Also HTML5 wording is not enough for implementators as it doesn't give any idea
> how hit testing and boundaries should be implemented for such elements.

Non-rendered elements should not convey size and position since there is none. These would only be perceivable through AT via non-spacial navigation (e.g. linear navigation or search, not through pointer hit testing), and operable through AT via direct events like DOMActivate or click. If this causes a conflict in an API or with AT, please raise an issue or file a bug with more specifics. 

Related WebKit bug: 
http://webkit.org/b/98787
(In reply to James Craig from comment #5)
> (In reply to alexander :surkov from comment #4)
> 
> > Despite HTML5 spec saying about aria-hidden="false" it'd be quite strange if
> > aria-hidden="true" didn't change the tree but aria-hidden="false" did.
> 
> Not sure what you mean here. @aria-hidden should modify the AX tree in both
> cases if there is a conflict. 

aria-hidden doesn't change the tree in Gecko, it does in WebKit though, so the web deals with two implementations of aria-hidden (and that is ok with ARIA spec). 

Afaik ARIA spec doesn't say anything about aria-hidden="false" and hidden conflict and all we have:

"Element with a hidden attribute, default mapping = aria-hidden state set to "true". If specified by an author, the aria-hidden state may be set to "true" or "false". " (1)

from HTML5 spec and Steve says to treat it as aria-hidden="false" overrides HTML5 hidden attribute (this wording was not clear with me, I would file a bug against HTML5 spec if I was sure what the behavior should be, hopefully we can figure it out here).

Furthermore, I've been told that ARIA says that aria-hidden behaves as display:none style (please ping Joseph for details), that means

<div aria-hidden="true"><div aria-hidden="false">the text is not visible for AT</div></div> (2)

but the same time HTML5 spec now requires

<div hidden><div aria-hidden="false">HTML5 spec thinks this text should be visible for AT</div></div>

Taking into account that HTML5 spec says (1) then it means it conflicts with (2)
alex: or you can just use the WHATWG spec, which doesn't have these problems (it treats hidden="" as having a strong mapping to aria-hidden="true").
(In reply to James Craig from comment #5)
> (In reply to alexander :surkov from comment #4)
> 
> > Despite HTML5 spec saying about aria-hidden="false" it'd be quite strange if
> > aria-hidden="true" didn't change the tree but aria-hidden="false" did.
> 
> Not sure what you mean here. @aria-hidden should modify the AX tree in both
> cases if there is a conflict. 
> 
>  <div> No conflict: Rendered for all. </div>
>  <div hidden> No conflict: Not rendered. </div>
>  <div aria-hidden="true"> Conflict resolution: Rendered visually but not to
> AX APIs. </div>
>  <div hidden aria-hidden="false"> Conflict resolution: Exposed to AX APIs,
> but not rendered visually. </div>
> 
> If something is unclear in the spec (ARIA 1.1 ED), please file a bug in the
> W3C tracker or bugzilla instance.
> 
> > Also HTML5 wording is not enough for implementators as it doesn't give any idea
> > how hit testing and boundaries should be implemented for such elements.
> 
> Non-rendered elements should not convey size and position since there is
> none. These would only be perceivable through AT via non-spacial navigation
> (e.g. linear navigation or search, not through pointer hit testing), and
> operable through AT via direct events like DOMActivate or click. If this
> causes a conflict in an API or with AT, please raise an issue or file a bug
> with more specifics. 
> 
> Related WebKit bug: 
> http://webkit.org/b/98787

Hi James, 

>If something is unclear in the spec (ARIA 1.1 ED), please file a bug in the W3C tracker or bugzilla >instance.

Can we have a w3c bugzilla component for ARIA 1.1 (please) would make it easier...

what is the expected behaviour in the following?

<div hidden> <span  aria-hidden="false">some text</span> some more text </div>

I would expect that the content in the span would not be available in the acc tree as the aria-hidden is on a child element not on same element as hidden.
I would expect that as well as the containing div, which is hidden, rules.
and the same time you want
<div hidden aria-hidden="false">AT visible content</div>

isn't it controversial? If aria-hidden="false" demolishes @hidden on the same node, why it's not supposed to do the same in the hidden subtree?
Hi(In reply to alexander :surkov from comment #10)
> and the same time you want
> <div hidden aria-hidden="false">AT visible content</div>
> 
> isn't it controversial? If aria-hidden="false" demolishes @hidden on the
> same node, why it's not supposed to do the same in the hidden subtree?

Hi Alex, it works the same as display:block

<div hidden style="display:block"> content visible to all</div>

<div hidden> <div style="display:block">content hidden to all </div></div>

example: https://dl.dropboxusercontent.com/u/377471/hidden-block.html
Ok.

I'm curious why WHATWG didn't adopted the change (per comment 7), are there any objections?
Btw, ARIA implementation guide doesn't seem agree with HTML spec (http://www.w3.org/WAI/PF/aria-implementation/#mapping):

"The following elements are not exposed via the accessibility API and user agents MUST NOT include them in the accessibility tree:

Elements, including their descendents, that have host language semantics specifying that the element is not displayed, such as CSS display:none or visibility:hidden or HTML 5 hidden attribute."
true. We have an agenda item on Monday's aria task force meeting to discuss aria-hidden. Any changes would apply to ARIA 1.1. We can certainly write a clarification in the ARIA implementation guide. 

Note: although we mentioned HTML5 hidden in the implementation guide HTML 5 support is specifically targeted for ARIA 1.1
(The WHATWG spec didn't adopt the change in the W3C spec because that part of the W3C spec doesn't make any sense as written, and nobody raised a bug or sent any feedback pointing out a problem in the WHATWG spec.)
Ian, what is confusing in the W3C spec?
It does things like set aria-hidden to its default value, gives requirements redundant with ARIA, etc. But this is probably not the right forum for a detailed critique of the W3C spec.

Fundamentally, though, it doesn't make much sense to mark a section of the document as irrelevant (setting hidden=""), and then making it visible, whether through display:block or aria-hidden="false". The whole point of strong native semantics is to prevent authors from having this kind of internal contradiction. When you use hidden="", you shouldn't have to think about ARIA at all.
I see. There have been situations where some have desired to expose hidden content to assistive technologies and those are in extreme cases. I am not saying that it is something that I am advocating but others have uses cases for this. A use case that people want would be to hide content that would provide additional help information to the assistive technology including the host language semantics contained within the hidden area. 

The argument was what to do if you have <div hidden aria-hidden="false">. Here the author would like to expose the hidden content to an assistive technology. This was the reason for the HTML working group editors making the native host language semantics tie to aria-hidden weak. I don't have any strong feelings either way about the use case but I do understand that if the author were compelled to create markup like this that the author would like to expose the content to the assistive technology.

I am not an HTML editor so I don't know what the agreement is for filing bugs against the whatwg spec. when changes occur in the W3C spec.
(In reply to Rich Schwerdtfeger from comment #18)
> I see. There have been situations where some have desired to expose hidden
> content to assistive technologies and those are in extreme cases. I am not
> saying that it is something that I am advocating but others have uses cases
> for this. A use case that people want would be to hide content that would
> provide additional help information to the assistive technology including
> the host language semantics contained within the hidden area. 
> 
> The argument was what to do if you have <div hidden aria-hidden="false">.
> Here the author would like to expose the hidden content to an assistive
> technology. This was the reason for the HTML working group editors making
> the native host language semantics tie to aria-hidden weak. I don't have any
> strong feelings either way about the use case but I do understand that if
> the author were compelled to create markup like this that the author would
> like to expose the content to the assistive technology.

The use case doesn't seem too unreasonable, and in any case the web seems to want it enough I'm not sure we have a choice other than it happening somehow.

However that's  not an argument for doing this,  and I tend to agree with Alex it has some mesy problems.
The use case of exposing content to screen readers only is a reasonable one, but this isn't the right way to do it. It's a styling issue, so it should be handled at the style level, not the markup level. hidden="" means the content is irrelevant to _everyone_, showing it to screen readers is a violation of the semantics.
(In reply to Hixie (not reading bugmail) from comment #20)
> The use case of exposing content to screen readers only is a reasonable one,
> but this isn't the right way to do it. It's a styling issue, so it should be
> handled at the style level, not the markup level. hidden="" means the
> content is irrelevant to _everyone_, showing it to screen readers is a
> violation of the semantics.

and the semantic is expressed via a styling rule... We use ARIA role,states and properties to override semantics, it's no different in this case. hidden="" means what we agree to it meaning and what is implemented. Currently we have a range of implementations that support the override (chrome/webkit/Talkback/ChromeVox) intentionally, to support a well known use case. So we are still in the process of reaching consensus on how aria-hidden should effect hidden.
(In reply to Hixie (not reading bugmail) from comment #20)
> The use case of exposing content to screen readers only is a reasonable one,
> but this isn't the right way to do it. It's a styling issue, so it should be
> handled at the style level, not the markup level. hidden="" means the
> content is irrelevant to _everyone_, showing it to screen readers is a
> violation of the semantics.

can you please give an example how it could look (like a code snippet if that would ever implemented)? It will help to understand the technique.

(In reply to alexander :surkov from comment #22)
> 
> can you please give an example how it could look (like a code snippet if
> that would ever implemented)? It will help to understand the technique.

alex, there a number of methods used currently [1]:

width:0px;height:0px

text-indent: -10000px;


position: absolute !important;
clip: rect(1px 1px 1px 1px); /* IE6, IE7 */
clip: rect(1px, 1px, 1px, 1px);

.hidden
{position:absolute;
left:-10000px;
top:auto;
width:1px;
height:1px;
overflow:hidden;}


[1] webaim.org/techniques/css/invisiblecontent/
why would the web need aria-hidden="false" then? It sounds like some extra syntax sugar for the web developers.
(In reply to alexander :surkov from comment #24)
> why would the web need aria-hidden="false" then? It sounds like some extra
> syntax sugar for the web developers.

aria-hidden=false like aria-hidden=true provides a simple declarative method to control display of content to AT, the current methods are hacks and cause various issues across browsers and AT.
(In reply to steve faulkner from comment #23)
> 
> (In reply to alexander :surkov from comment #22)
> > 
> > can you please give an example how it could look (like a code snippet if
> > that would ever implemented)? It will help to understand the technique.
> 
> alex, there a number of methods used currently [1]:
> 
> width:0px;height:0px
> 
> text-indent: -10000px;
> 
> 
> position: absolute !important;
> clip: rect(1px 1px 1px 1px); /* IE6, IE7 */
> clip: rect(1px, 1px, 1px, 1px);
> 
> .hidden
> {position:absolute;
> left:-10000px;
> top:auto;
> width:1px;
> height:1px;
> overflow:hidden;}
> 

These hacks also cause unintended consequences. For example a web developer may put something in negative offsets in an earnest attempt to hide it. Yet screen readers pick it up anyway because it is an accepted hack to provide screen reader users with additional info.

So if there was an accepted, non hacky way to "unhide" content for AT, ATs could start ignoring content that is styled with the methods above. Which would be great.
(In reply to steve faulkner from comment #25)
> (In reply to alexander :surkov from comment #24)
> > why would the web need aria-hidden="false" then? It sounds like some extra
> > syntax sugar for the web developers.
> 
> aria-hidden=false like aria-hidden=true provides a simple declarative method
> to control display of content to AT,

I agree

but 
1) Ian thinks it's not a right way (comment #20), personally I don't have opinion on this
2) It's sort of very hard to implement in Firefox since accessible tree is layout based (nothing rendered - nothing accessible)
3) @aria-hidden="false" @hidden is not really visible to AT since it doesn't have coordinates, size, can't be clicked or activated, so basically it's sort of text representation of the content (like aria-label?)

> the current methods are hacks and cause
> various issues across browsers and AT.

that was why aria-hidden invented for, just to give a hint to AT if the browser has lack of support of styling on accessibility level. Afaik Firefox had a good support of styling mapping to AT so I never bothered about aria-hidden. But later aria-hidden was mutated to remove the accessible tree (aria-hidden="true") and now it grows up to create an accessible tree (aria-hidden=false). I'm curious if browser were consistent in style handling then would aria-hidden need so bad?
(In reply to steve faulkner from comment #21)
> and the semantic is expressed via a styling rule... We use ARIA role,states
> and properties to override semantics, it's no different in this case.

This is a pretty deep misunderstanding of how HTML, CSS, and ARIA work. But that's out of scope for this bug.


(In reply to alexander :surkov from comment #22)
> 
> can you please give an example how it could look (like a code snippet if
> that would ever implemented)? It will help to understand the technique.

Probably the most reasonable way to do it would be a media rule that matched only when a screen reader was active (e.g. "@media reader" or some such). This would be a non-exclusive media rule; a screen UA with an AT would match both 'screen' and 'reader' at the same time. So you'd do something like:

   .detailed-explanation { display: none }
   @media reader { display: block; }

...or some such. (http://www.w3.org/TR/css3-reader/ was a proposal to do that from 2004, it may be time to dust that proposal off and get it implemented. At the time it didn't go anywhere because we were still hoping people would write bi-modal UAs with a speech and visual component at once, but only Opera ever tried that and the approach didn't get adopted by more popular AT developers.)
> (In reply to alexander :surkov from comment #22)
> > 
> > can you please give an example how it could look (like a code snippet if
> > that would ever implemented)? It will help to understand the technique.
> 
> Probably the most reasonable way to do it would be a media rule that matched
> only when a screen reader was active (e.g. "@media reader" or some such).
> This would be a non-exclusive media rule; a screen UA with an AT would match
> both 'screen' and 'reader' at the same time. So you'd do something like:

That seems like it might work but some potential issues include

- I don't really want to make the presence of a screen reader web detectable (maybe I shouldn't care given we expose screen type and such?)

an interesting and related question is if you have a screen reader on should the text then become visible?  In most cases I'd think that would make sense, but then again I'm not really sure how often it is you shouldn't just make the text always visible.

If you say the presence of a screen reader shouldn't make the text visible then what do you do about possition and formating?  I guess the most logical thing to do would be have two frame trees one with the content as it should be exposed to the screen reader and one for on screen but that sounds rather painful.

What do you do about all the things other than screen readers that use accessibility APIs?

> ...or some such. (http://www.w3.org/TR/css3-reader/ was a proposal to do
> that from 2004, it may be time to dust that proposal off and get it
> implemented. At the time it didn't go anywhere because we were still hoping
> people would write bi-modal UAs with a speech and visual component at once,
> but only Opera ever tried that and the approach didn't get adopted by more
> popular AT developers.)

hm, interesting need to take a look at some point I guess.
(In reply to Trevor Saunders (:tbsaunde) from comment #29)
> > (In reply to alexander :surkov from comment #22)
> > > 
> > > can you please give an example how it could look (like a code snippet if
> > > that would ever implemented)? It will help to understand the technique.
> > 
> > Probably the most reasonable way to do it would be a media rule that matched
> > only when a screen reader was active (e.g. "@media reader" or some such).
> > This would be a non-exclusive media rule; a screen UA with an AT would match
> > both 'screen' and 'reader' at the same time. So you'd do something like:
> 
> That seems like it might work but some potential issues include

yep, I think I really like this media thing

> - I don't really want to make the presence of a screen reader web detectable
> (maybe I shouldn't care given we expose screen type and such?)

agree, the browser should ask the user if he wants to use screen reader media styles when it encounters them

> an interesting and related question is if you have a screen reader on should
> the text then become visible?  In most cases I'd think that would make
> sense, but then again I'm not really sure how often it is you shouldn't just
> make the text always visible.

It seems it should be visible (if I read the link right) and it seems that's the whole point.
I filed bug 946370 for reader media type to keep all related discussion there.
(In reply to alexander :surkov from comment #6)
> Afaik ARIA spec doesn't say anything about aria-hidden="false" 

It says: 

"""
Values of aria-hidden
true: Indicates that this section of the document and its children are hidden from the rendered view.
false (default): Indicates that this section of the document is rendered.

Note: Authors are advised to avoid using aria-hidden="false" with styles or attributes that have historically prevented rendering in all modalities, such as display:none or visibility:hidden in CSS, or the hidden attribute in HTML 5. At the time of this writing, aria-hidden="false" is known to work inconsistently when used in conjunction with such features. As future implementations improve, use caution and test thoroughly before relying on this approach.
"""


> Furthermore, I've been told that ARIA says that aria-hidden behaves as
> display:none style (please ping Joseph for details), that means
> 
> <div aria-hidden="true"><div aria-hidden="false">the text is not visible for
> AT</div></div> (2)

That is correct. A descendant node set to aria-hidden="false" will not override a ancestor node's visibility. This shoulld be clarified in ARIA 1.1.

> but the same time HTML5 spec now requires
> 
> <div hidden><div aria-hidden="false">HTML5 spec thinks this text should be
> visible for AT</div></div>

That's an error in the spec then. Could probably be solved with some explanatory text.
(In reply to Hixie (not reading bugmail) from comment #20)
> The use case of exposing content to screen readers only is a reasonable one,
> but this isn't the right way to do it. It's a styling issue, so it should be
> handled at the style level, not the markup level. hidden="" means the
> content is irrelevant to _everyone_, showing it to screen readers is a
> violation of the semantics.

Perhaps the approach should be to separate two bugs covering the following scenarios:

<div aria-hidden="false" hidden>foo</div>
<div aria-hidden="false" style="display:none">bar</div>

The first has some semantic baggage that we could debate til the end of time. The second is a more clear use case.

The fact that hidden is just implemented as display:none is an implementation detail with other implications. For example, a user can set the following rule in their user style sheet and effectively disable @hidden. 

  [hidden] {
    display: block !important;
  }

If Hixie wants to argue that this should change, it's a general browser issue unrelated to this accessibility-specific bug.
(In reply to Hixie (not reading bugmail) from comment #7)
> alex: or you can just use the WHATWG spec which doesn't have these problems

You make your disdain for the W3C spec process apparent every chance you get, but that doesn't mean the WHATWG spec is right.

> (it treats hidden="" as having a strong mapping to aria-hidden="true").

Case in point.
(In reply to steve faulkner from comment #8)

> Can we have a W3C bugzilla component for ARIA 1.1 (please) would make it
> easier...

I've requested moving the member-only ARIA tracker to Bugzilla, too. It's not up to me; need to convince Michael or Janina. Pile on here: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23803
(In reply to James Craig from comment #34)
> (In reply to Hixie (not reading bugmail) from comment #7)
> > alex: or you can just use the WHATWG spec which doesn't have these problems
> 
> You make your disdain for the W3C spec process apparent every chance you
> get, but that doesn't mean the WHATWG spec is right.

Ian, I apologize for being catty in this response. I should have maintained a cooler head. 

That said, it's a frequent annoyance to many that you actively attempt to circumvent the W3C process, including off-list emails to people telling them to ignore the W3C spec, and various comments like this in numerous bug trackers. Kindly stop it. We're all aware of your opinion on the matter.

While you may not agree with all aspects of the process, the W3C defines the Web Platform, and the deliberation and formal process is in place for many reasons. One such reason is so that the needs of a subset of users cannot be tabled, buried, or otherwise effectively ignored on the decision of any one particular individual.
This isn't the place to debate that. Feel free to e-mail me if you want to talk about that.

Having hidden="" be a strong ARIA mapping to aria-hidden="true" is correct behaviour. It would be a layering violation to have the hidden="" attribute specified but the aria-hidden="" attribute overridden to false. If you disagree with that, I encourage you to post on the WHATWG list (or e-mail me directly). Having the W3C just fork the WHATWG's work isn't the way to fix that kind of thing though.
(In reply to Hixie (not reading bugmail) from comment #37)

> This isn't the place to debate that. 

Then we agree that you should not have raised that topic here.


Five sentences later Hixie wrote:

> Having the W3C just fork the WHATWG's work isn't the way to fix that...

Language like "fork" is a nice way to imply that you do all the work, but we agreed this what not the right forum.
Back to work:

(In reply to Hixie (not reading bugmail) from comment #37)

> Having hidden="" be a strong ARIA mapping to aria-hidden="true" is correct
> behaviour. 

I don't agree, but mentioning both @hidden and display:none in this bug is conflating two related but different issues.

It's clearly the correct behavior to have aria-hidden="false" override display:none. The fact that @hidden is implemented via display:none in most browsers is just and implementation detail, which is why I suggested tackling the two concepts separately.
> (In reply to Hixie (not reading bugmail) from comment #37)
> 
> > Having hidden="" be a strong ARIA mapping to aria-hidden="true" is correct
> > behaviour. 
> 
> I don't agree, but mentioning both @hidden and display:none in this bug is
> conflating two related but different issues.

In so far as aria-hidden isn't a total mess I think hixi is right to say hidden implies aria-hidden=true and combining hidden with aria-hidden=false is an author error that makes no sense.

> It's clearly the correct behavior to have aria-hidden="false" override
> display:none. The fact that @hidden is implemented via display:none in most
> browsers is just and implementation detail, which is why I suggested
> tackling the two concepts separately.

that's an... interesting definition of clear you have there, I'd probably say its not the correct thing to do and again an author error.
(In reply to Trevor Saunders (:tbsaunde) from comment #40)
> that's an... interesting definition of clear you have there, I'd probably
> say its not the correct thing to do and again an author error.

Would you prefer authors continue using offscreen positioning hacks like this to render invisible content to screen readers?

<h2 class="offscreen">Messages list</h2>

h2.offscreen {
  position: absolute;
  left: -9999px;
}
On the other matter can we have a bunch of examples where display:none aria-hidden="false" can be useful and if there are some reasonable alternatives to it?
(In reply to James Craig from comment #41)

> Would you prefer authors continue using offscreen positioning hacks like
> this to render invisible content to screen readers?
> 
> <h2 class="offscreen">Messages list</h2>
> 
> h2.offscreen {
>   position: absolute;
>   left: -9999px;
> }

as long as it works I don't see anything bad in it. Nicer alternative to it would be CSS media types.
(In reply to alexander :surkov from comment #42)
> On the other matter can we have a bunch of examples where display:none
> aria-hidden="false" can be useful 

Here are a few:

1. Listed offscreen headings above. This is useful when the visual layout clearly communicates the context, but the DOM does not provide an easily navigable/understandable structure. For example, web mail clients are usually designed to look similar to desktop clients, and visually displayed headings for "Mailboxes", "Messages", and "Preview Pane" sections would be redundant to a sighted user, but incredibly useful to the screen reader user.

2. Sometimes I see people add clarifying text to short links/buttons that would be ambiguous without it. For example: 

<a href="">Learn more <span class="a11y">about product X</span></a>
<button>Delete <span class="a11y">John Doe</span></button>


> and if there are some reasonable
> alternatives to it?

Most are CSS workarounds like the ".offscreen" class defined above. Steve Faulkner mentioned several more in comment 23. None of these are as elegant as just declaring that the element should be in the accessibility tree like aria-hidden="false" does.
(In reply to alexander :surkov from comment #43)
> (In reply to James Craig from comment #41)
> 
> > Would you prefer authors continue using offscreen positioning hacks like
> > this to render invisible content to screen readers?
> > 
> > <h2 class="offscreen">Messages list</h2>
> > 
> > h2.offscreen {
> >   position: absolute;
> >   left: -9999px;
> > }
> 
> as long as it works I don't see anything bad in it. Nicer alternative to it
> would be CSS media types.

See Eitan's counterpoint in comment #26 above:

> > > These hacks also cause unintended consequences. For example a web developer 
> > > may put something in negative offsets in an earnest attempt to hide it. Yet 
> > > screen readers pick it up anyway because it is an accepted hack to provide 
> > > screen reader users with additional info.
> > > 
> > > So if there was an accepted, non hacky way to "unhide" content for AT, ATs 
> > > could start ignoring content that is styled with the methods above. Which 
> > > would be great.
(In reply to James Craig from comment #44)
> 
> 1. Listed offscreen headings above. This is useful when the visual layout
> clearly communicates the context, but the DOM does not provide an easily
> navigable/understandable structure. [...]
> 
> 2. Sometimes I see people add clarifying text to short links/buttons that
> would be ambiguous without it. [...]

These are great examples of things that are entirely in the realm of style, IMHO. For example, if you had a regular speech browser or a line-by-line text browser, you'd want to have these labels visible, even if it wasn't an AT browser (i.e. even if ARIA was ignored).

The issue of whether display:none and aria-hidden="false" can be combined is out of scope of the HTML spec, though, so I'll leave that to others to debate. My concern is more about hidden="" + aria-hidden="false". I think it would be (mildly) harmful to support that, since it would encourage using hidden="" for primarily presentational needs ("this is relevant but don't show it to visual users") rather than for its intended semantic sense ("this is irrelevant, show it to nobody"). As I noted above, it would be a layering violation.

It would also be quite an ugly authoring style, almost as bad as the positioning hacks. A more direct solution like the 'reader' media type that was proposed a while back at the W3C would IMHO be far superior all around.
(In reply to Hixie (not reading bugmail) from comment #37)
> This isn't the place to debate that. Feel free to e-mail me if you want to
> talk about that.
> 
> Having hidden="" be a strong ARIA mapping to aria-hidden="true" is correct
> behaviour. It would be a layering violation to have the hidden="" attribute
> specified but the aria-hidden="" attribute overridden to false. If you
> disagree with that, I encourage you to post on the WHATWG list (or e-mail me
> directly). Having the W3C just fork the WHATWG's work isn't the way to fix
> that kind of thing though.

HTML was and continues to be developed and defined in multiple venues, not an ideal situation, but as we don't have consensus on where and who, its the best we have got. Denying that reality is not helpful to moving the web forward. I would be more than happy to work on a more collegiate collaboration, but yes not in scope of this bug...
(In reply to James Craig from comment #39)
> Back to work:
> 
> (In reply to Hixie (not reading bugmail) from comment #37)
> 
> > Having hidden="" be a strong ARIA mapping to aria-hidden="true" is correct
> > behaviour. 
> 
> I don't agree, but mentioning both @hidden and display:none in this bug is
> conflating two related but different issues.
> 
> It's clearly the correct behavior to have aria-hidden="false" override
> display:none. The fact that @hidden is implemented via display:none in most
> browsers is just and implementation detail, which is why I suggested
> tackling the two concepts separately.

interesting, so are you saying that aria-hidden=false should always override display:none? or only when the hidden attribute is not present?
(In reply to Hixie (not reading bugmail) from comment #37)
> This isn't the place to debate that. Feel free to e-mail me if you want to
> talk about that.
> 
> Having hidden="" be a strong ARIA mapping to aria-hidden="true" is correct
> behaviour. It would be a layering violation to have the hidden="" attribute
> specified but the aria-hidden="" attribute overridden to false. 

do you have a reference to a definition of "layering violation"? i see this term from time to time offered as an argument, but can't find a clear definition and how it relates to HTML/ARIA etc.
(In reply to steve faulkner from comment #49)

> do you have a reference to a definition of "layering violation"? i see this
> term from time to time offered as an argument, but can't find a clear
> definition and how it relates to HTML/ARIA etc.

This is more commonly known as separation of content from presentation. The layers are CSS for style, markup for content, and JavaScript for functionality. Ian uses the term "violations" but that doesn’t mean there are formal rules other than best practice conventions.

He’s implying here that using aria-hidden to override a style is a layering "violation" but the markup aria-hidden=false just means that this is relevant to accessibility APIs, regardless of the style. As such, it is clean, semantic markup. As such, it is not a layering violation.
(In reply to James Craig from comment #44)

> 1. Listed offscreen headings above. This is useful when the visual layout
> clearly communicates the context, but the DOM does not provide an easily
> navigable/understandable structure. For example, web mail clients are
> usually designed to look similar to desktop clients, and visually displayed
> headings for "Mailboxes", "Messages", and "Preview Pane" sections would be
> redundant to a sighted user, but incredibly useful to the screen reader user.

It'd be great to have some code snippet

> 2. Sometimes I see people add clarifying text to short links/buttons that
> would be ambiguous without it. For example: 
> 
> <a href="">Learn more <span class="a11y">about product X</span></a>
> <button>Delete <span class="a11y">John Doe</span></button>

they can do instead

<a href="" aria-label="Learn more about product X">Learn more</a>

or if somebody wants fancy stuff

<span class="a11y" id="span">about product X</span>
<a href="" id="a" aria-labelledby="a span">John Doe </a>

so not really necessary to have one more way to do this

(In reply to James Craig from comment #45)
> See Eitan's counterpoint in comment #26 above:

I hope we will figure out offscreen mess in bug 946226
Some summary as I see it

1) aria-hidden="false" on @hidden (and possibly on display:none element) may be considered as not conforming to HTML ideas (comment #46) and ARIA ideas (comment #2).
2) I still don't have an use case where aria-hidden="false" will be necessary (alternative techniques exists), comment 44 and comment 51. Moreover there's CSS media rules spec what should be a good alternative to aria-hidden when implemented (bug 946370).
3) aria-hidden="false" as presented in HTML spec is not clearly stated for implementation (comment #4) and moreover it contradicts to existing ARIA impl guidelines  (comment #13) (however James suggested to treat it as ARIA spec bug comment #32), see also ARIA impl guide says that aria-hidden="false" is not mapped (http://www.w3.org/WAI/PF/aria-implementation/#mapping_state-property_table), note, recently we fixed bug 838407 in Firefox to pass ARIA test suite

I would suggest to wontfix this bug and pull the change out the HTML spec, at least until the feature is clarified, agreed and doesn't contradict to ARIA spec. I simply don't want the spec be in hurry to put disputable features into the law.
(In reply to alexander :surkov from comment #52)
>pull the change out the HTML spec,
> at least until the feature is clarified, agreed and doesn't contradict to
> ARIA spec. I simply don't want the spec be in hurry to put disputable
> features into the law.

Hi Surkov, please comment on the HTML spec bug if you want a change: https://www.w3.org/Bugs/Public/show_bug.cgi?id=18574
(In reply to steve faulkner from comment #53)
> (In reply to alexander :surkov from comment #52)

> Hi Surkov, please comment on the HTML spec bug if you want a change:
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=18574

done
A layering violation is when you have a system designed in layers -- for example, the network hardware layer and the IP layer in a network stack -- and one layer interferes with a different layer -- for example, if the network hardware layer checks whether an IP packet is a TCP packet or a UDP packet, and handles them differently. In this case, the layers are HTML (defines semantics), CSS (defines presentation), and ARIA (defines how ATs work), and a layering violation occurs when one layer interferes with another (e.g. the ARIA layer allowing authors to make the AT act contrary to the semantics given by the HTML layer).
> I would suggest to wontfix this bug and pull the change out the HTML spec,
> at least until the feature is clarified, agreed and doesn't contradict to
> ARIA spec. I simply don't want the spec be in hurry to put disputable
> features into the law.

or we can follow the whatwg spec like the DOM people tend to and say the spec is already fine ;)


(In reply to James Craig from comment #50)
> (In reply to steve faulkner from comment #49)
> 
> > do you have a reference to a definition of "layering violation"? i see this
> > term from time to time offered as an argument, but can't find a clear
> > definition and how it relates to HTML/ARIA etc.
> 
> This is more commonly known as separation of content from presentation. The
> layers are CSS for style, markup for content, and JavaScript for
> functionality. Ian uses the term "violations" but that doesn’t mean there
> are formal rules other than best practice conventions.

they're violations because they're something that shouldn't happen in well designed systems, not because anyone wants to make something look bad.

> He’s implying here that using aria-hidden to override a style is a layering
> "violation" but the markup aria-hidden=false just means that this is
> relevant to accessibility APIs, regardless of the style. As such, it is
> clean, semantic markup. As such, it is not a layering violation.

accept that the css has clearly stated that this information should not be displayed and aria is blocking that.

(In reply to James Craig from comment #41)
> (In reply to Trevor Saunders (:tbsaunde) from comment #40)
> > that's an... interesting definition of clear you have there, I'd probably
> > say its not the correct thing to do and again an author error.
> 
> Would you prefer authors continue using offscreen positioning hacks like
> this to render invisible content to screen readers?
> 
> <h2 class="offscreen">Messages list</h2>
> 
> h2.offscreen {
>   position: absolute;
>   left: -9999px;
> }

Well the first thing to notice is that things with aria-hidden=false that are display: none should probably have STATE_OFFSCREEN and STATE_INVISIBLE set because well they are pretty clearly that way.  In addition they don't have bounds you can't hit test them you don't really know about text attributes because display: none means you can't ask layout about text attributes etc.

So I'm not in a hurry to mass change positioning stuff to aria-hidden=false, because both aprroaches have problems and neither seems substantially better.  If someone cares about solving this problem they should come up with an actually better proposal.
(In reply to Trevor Saunders (:tbsaunde) from comment #56)
> > I would suggest to wontfix this bug and pull the change out the HTML spec,
> > at least until the feature is clarified, agreed and doesn't contradict to
> > ARIA spec. I simply don't want the spec be in hurry to put disputable
> > features into the law.
> 
> or we can follow the whatwg spec like the DOM people tend to and say the
> spec is already fine ;)

I think the reasons why we don't are provided by James in Comment 36 ;-)

"While you may not agree with all aspects of the process, the W3C defines the Web Platform, and the deliberation and formal process is in place for many reasons. One such reason is so that the needs of a subset of users cannot be tabled, buried, or otherwise effectively ignored on the decision of any one particular individual."
(In reply to Trevor Saunders (:tbsaunde) from comment #56)

> > He’s implying here that using aria-hidden to override a style is a layering
> > "violation" but the markup aria-hidden=false just means that this is
> > relevant to accessibility APIs, regardless of the style. As such, it is
> > clean, semantic markup. As such, it is not a layering violation.
> 
> accept that the css has clearly stated that this information should not be
> displayed and aria is blocking that.

The ARIA attributes define a way to declare that this is relevant to accessibility APIs, regardless of the visual display. Yes, in a perfect world, there would be no reason to do this, but ARIA works for the imperfect world where web developers do things like styling a links background image and hiding its text contents:

  <a href="#"><span style="display:none">text</span></a>

Many web developers now know to avoid this pattern, but that doesn't stop it from happening, because there is no unambiguous way to declare that a particular style is relevant for APIs despite it being hidden from visual renderings. Many times the developers fixing the accessibility problems are not the original authors of the poorly designed web page or application, so the ability to retrofit without gutting an existing application is just one of many benefits to ARIA.

Even if you took the media query approach (of which there are multiple proposals) the reader and screen type are not mutually exclusive, so in Ian and Alex's proposed solution to use @media reader:

  .foo { display: none; }
  @media reader ( .foo { display: block; } }

Let's disambiguate. Does this mean that it's display block on-screen when a screen reader is running, or does this mean it's style display:none on the screen, but screen readers users can detect the element? 

I think the answer is currently ambiguous, but my reading is that "@media reader" is identical to "@media screen and reader" (hence the term "screen"-reader) and therefore the element would display on-screen, possibly blowing out a layout, and potentially causing other problems in web pages. @aria-hidden does not have this problem because ARIA does not affect the mainstream user interface, including visual styles. ARIA only declares override semantics relevant to accessibility APIs.
(In reply to steve faulkner from comment #57)
> (In reply to Trevor Saunders (:tbsaunde) from comment #56)
> > > I would suggest to wontfix this bug and pull the change out the HTML spec,
> > > at least until the feature is clarified, agreed and doesn't contradict to
> > > ARIA spec. I simply don't want the spec be in hurry to put disputable
> > > features into the law.
> > 
> > or we can follow the whatwg spec like the DOM people tend to and say the
> > spec is already fine ;)
> 
> I think the reasons why we don't are provided by James in Comment 36 ;-)

this isn't the place to argue that, feel free to do it on mail lists or whatever if you like, and yes maybe it would have been better if I said what I said someplace else too.

(In reply to James Craig from comment #58)
> (In reply to Trevor Saunders (:tbsaunde) from comment #56)
> 
> > > He’s implying here that using aria-hidden to override a style is a layering
> > > "violation" but the markup aria-hidden=false just means that this is
> > > relevant to accessibility APIs, regardless of the style. As such, it is
> > > clean, semantic markup. As such, it is not a layering violation.
> > 
> > accept that the css has clearly stated that this information should not be
> > displayed and aria is blocking that.
> 
> The ARIA attributes define a way to declare that this is relevant to
> accessibility APIs, regardless of the visual display. Yes, in a perfect

so basically you agree this is a layering violation, but think this is better than any alternative?

> world, there would be no reason to do this, but ARIA works for the imperfect
> world where web developers do things like styling a links background image
> and hiding its text contents:
> 
>   <a href="#"><span style="display:none">text</span></a>
> 
> Many web developers now know to avoid this pattern, but that doesn't stop it
> from happening, because there is no unambiguous way to declare that a
> particular style is relevant for APIs despite it being hidden from visual

I suspect most if not all ways you could do that are doomed to have things like broken bounds and visibility states.

really what you want to fix that case is aria-label or aria-name though

> Even if you took the media query approach (of which there are multiple
> proposals) the reader and screen type are not mutually exclusive, so in Ian
> and Alex's proposed solution to use @media reader:
> 
>   .foo { display: none; }
>   @media reader ( .foo { display: block; } }
> 
> Let's disambiguate. Does this mean that it's display block on-screen when a
> screen reader is running, or does this mean it's style display:none on the
> screen, but screen readers users can detect the element? 

I think its pretty clearly display: block on screen and imho that's correct because otherwise it suffers from the exact same problem as aria-hidden.
Is there some other way, perhaps in some not-yet-defined ARIA, to handle this?

* The use cases that led to the desire to expose hidden content are, I am guessing, specific to screen readers. But it's changing the accessible tree for all assistive technologies potentially adding unwanted elements for, say, a speech input solution.

* There are, I assume, different use cases even just for screen readers. Static instructions/helpful hints/etc. versus text which changes depending on the circumstances, subsequent input, whathaveyou. The first time you visit foo.com, those instructions might be really useful; the 10th time, they might be an annoyance you have to skip over. But you might always want the context-sensitive/dynamic messages on foo.com. If a screen reader knows why something is there (i.e. *how* it is "relevant to accessibility APIs"), the screen reader user can determine if that hidden text is indeed desired for presentation.

* Let's say I read some helpful hidden instructions and then navigate to the content where those instructions are needed. Then I realize that I forgot part of the instructions. Now I have to leave the element where the instructions apply to navigate back to the hidden element where the instructions are so that I can re-read them and then navigate back to where I was. I'd much prefer staying put and giving my screen reader the "give me the helpful text for this input field" command.

* Given a browser with decent caret navigation and emitting the appropriate accessibility signals, it is possible for a screen reader to allow the user to navigate directly in the browser (rather than an off-screen copy, virtual buffer, whathaveyou). Information exposed through hidden accessible objects will never be encountered in that situation. (Yes, I realize that content creators have been shoving stuff way off screen, etc. for years. But given that this bug is here and discussion taking place, I'd love a solution that also works when using a screen reader in conjunction with native navigation in the browser.)

If the existing ARIA element attributes don't apply, is there a potentially new one (or several) that might?
"Is there some other way, perhaps in some not-yet-defined ARIA, to handle this?"

I feel that a solution is needed sooner than waiting for new ARIA.

* The use cases that led to the desire to expose hidden content are, I am guessing, specific to screen readers. But it's changing the accessible tree for all assistive technologies potentially adding unwanted elements for, say, a speech input solution.

It is not possible to get information that is not provided. If the assistive technology knows that an element has aria-hidden="false" and style="display:none", could that technology not just ignore that element if it wanted to?

* There are, I assume, different use cases even just for screen readers. Static instructions/helpful hints/etc. versus text which changes depending on the circumstances, subsequent input, whathaveyou. The first time you visit foo.com, those instructions might be really useful; the 10th time, they might be an annoyance you have to skip over. But you
might always want the context-sensitive/dynamic messages on foo.com. If a screen reader knows why something is there (i.e. *how* it is "relevant to accessibility APIs"), the screen reader user can determine if that hidden text is indeed desired for presentation.

True, but that does not completely cover the use cases for aria-hidden="false".

* Let's say I read some helpful hidden instructions and then navigate to the content where those instructions are needed. Then I realize that I forgot part of the instructions. Now I have to leave the element where the instructions apply to navigate back to the hidden element where the instructions are so that I can re-read them and then navigate back
to where I was. I'd much prefer staying put and giving my screen reader the "give me the helpful text for this input field" command.

See comment on previous point.

* Given a browser with decent caret navigation and emitting the appropriate accessibility signals, it is possible for a screen reader to allow the user to navigate directly in the browser (rather than an off-screen copy, virtual buffer, whathaveyou). Information exposed through hidden accessible objects will never be encountered in that situation. (Yes,
I realize that content creators have been shoving stuff way off screen, etc. for years. But given that this bug is here and discussion taking place, I'd love a solution that also works when using a screen reader in conjunction with native navigation in the browser.)

Unless browsers implement all of the quick key navigation functionality that is available in screen readers like JAWS, most users are not going to stop using the virtual buffer.

If the existing ARIA element attributes don't apply, is there a potentially new one (or several) that might?
I am both a screen reader (JAWS) user and a developer who works on accessibility in main stream websites who uses ARIA almost daily. I would like to add my two cents to this conversation.
First and foremost, as has already been pointed out in an earlier comment, this is not a perfect world. I feel that many of the situations and solutions that have been discussed here would apply in a perfect world, but not apply as well as needed in an imperfect world.
Second, it is my understanding that ARIA is for:
1. Communicating information to the screen reader and ultimately the user that is conveyed via CSS, such as the state of an element--checked, selected, expanded, disabled, etc--and positioning of an element--the menu that is physically located at the end of the DOM is attached to the menubutton somewhere else on the page
2. To provide information to the screen reader and ultimately the user that is different from that shown of the screen for the purpose of improving the experience for the user (e.g., aria-label, aria-labelledby, aria-describedby), which may including omitting irrelevant information (aria-hidden="true") or including information that is not visible to the sighted user (aria-hidden="false" style="display: none")

To answer the question of why display:none should be used, because it works across browsers as apposed to other CSS hacks that do not work uniformly across browsers, and if my memory serves me, occasionally cause problems with screen readers.

I also feel that it is important to support aria-hidden="false" because it is included in the ARIA spec. Okay, so maybe it was a bad idea, but, IMO, that is irrelevant at this point because it is out there and developers expect it to work. This is not a realm where it is okay to not play by the rules because they seem to be wrong.
If aria-hidden="false" is not going to be supported, then this needs to be documented in a clear and concise way and an alternative provided that works across all browsers and screen readers.
Finally, I find it very disturbing that it has been so long since this bug has been updated.
As of now this has marginal implementation support, and does not look as though it will gain more support in the future.
http://stevefaulkner.github.io/HTML5accessibility/tests/hidden-2016.html 

NOTE: support for exposing content in the <div hidden aria-hidden=false> case in browsers/AT is marked a FAIL in results as the purpose of the testing is to provide guidiance to devs on robust methods to manipulate the display of content to AT and 

I suggest that it would be helpful if the Moz engineers made a decision on whether they are going to implement it. So either way we can make progress firming up spec/implementation issues.
Flags: needinfo?(surkov.alexander)
Flags: needinfo?(mzehe)
I do not see this getting worked on from our end, considering that there is no demand for it. There are also other, better, methods to provide AT-specific text that don't involve aria-hidden and thus should be preferred. Closing as WONTFIX. Please reopen if you strongly disagree.
Status: NEW → RESOLVED
Closed: 8 years ago
Flags: needinfo?(mzehe)
Resolution: --- → WONTFIX
I tend to agree
Flags: needinfo?(surkov.alexander)
As many will know, I'm pretty cynical about aria-hidden in general and believe it was one of the less well thought out parts of the spec. I also tend to believe there is rarely a good reason for AT specific text that isn't a label, description, etc. That said:

(In reply to Marco Zehe (:MarcoZ) from comment #64)
> There are also other, better, methods to provide
> AT-specific text that don't involve aria-hidden and thus should be
> preferred.

The primary way to provide AT-specific text that isn't a label, description, etc. is to use off-screen text. I'd argue off-screen text is a far bigger hack than aria-hidden="false". At least the latter is clearly defined as being for AT, whereas the former is an esoteric magic "trick of the trade" that is far from intuitive and very probably wasn't designed for that purpose. As far as I'm aware, there's certainly no spec which tells you how to do off-screen text just for AT; you have to go read articles on the web.
I agree that there should be a more elegant way to make what off-screen hacks serves for, but if I understand correctly aria-hidden="false" doesn't cover all use cases of off-screen technique, for example, aria-hidden="false" cannot be navigated by keyboard. Also off-screen hacks is something that just work, while aria-hidden="false" requires us to make changes in the architecture of Gecko engine, plus it has to affect negatively on performance, since now we just ignore hidden subtrees.
You need to log in before you can comment on or make changes to this bug.