Some comments just to clarify that we are on the same page:

The consequence of @hidden being in the strong native semantics table is that it would be forbidden to set its aria-hidden state to _false_:

    <foo hidden="" aria-hidden="false">

But the this would still be allowed - but redundant:

    <foo hidden="" aria-hidden="true">

If @hidden was placed in the ”weak” table, it would not be forbidden to “override” it with a aria-hidden="false".

But your focus i aria-hidden="true" - not aria-hidden="false". And in that regard, then is a piece of cake to make elements with @hidden *visible*:

    [hidden]{display:block})

As such, it would per my understanding be possible to solve your usecase (visible elements that should be hidden to AT users) the following way:

    <div style="display:block" hidden="">
      Visual clutter that should be hidden from AT
    </div>

But of course, it could be simpler to skip both the @style and the @hidden and just use aria-hidden. And in my view, @hidden in the strong table does not prevet aria-hidden="true" from being applied to elements without @hidden.

Thus I don't see the problem that you see - one of us is probably reading something wrong ... :-)

(In reply to Leif Halvard Silli from comment #1)
> Some comments just to clarify that we are on the same page:
> 
> The consequence of @hidden being in the strong native semantics table is
> that it would be forbidden to set its aria-hidden state to _false_:
> 
>     <foo hidden="" aria-hidden="false">

This is one of the problems with this row in the table, but not my main point. 

> But the this would still be allowed - but redundant:
> 
>     <foo hidden="" aria-hidden="true">
> 
> If @hidden was placed in the ”weak” table, it would not be forbidden to
> “override” it with a aria-hidden="false".

Moving this row to the "weak" table would work for me.

> But your focus i aria-hidden="true" - not aria-hidden="false". 

Not necessarily. That's tangential to my point, but WebKit exposes the following to the AX API. Other UAs don't, but they should.

    <div hidden aria-hidden="false">Only AT gets this text</div>

> And in that
> regard, then is a piece of cake to make elements with @hidden *visible*:
> 
>     [hidden]{display:block})
> 
> As such, it would per my understanding be possible to solve your usecase
> (visible elements that should be hidden to AT users) the following way:
> 
>     <div style="display:block" hidden="">
>       Visual clutter that should be hidden from AT
>     </div>

That does work, but it's hacky since it forces an overwrite of the default style for @hidden.

> But of course, it could be simpler to skip both the @style and the @hidden
> and just use aria-hidden. And in my view, @hidden in the strong table does
> not prevet aria-hidden="true" from being applied to elements without @hidden.
> 
> Thus I don't see the problem that you see - one of us is probably reading
> something wrong ... :-)

You're suggesting this, which I agree is the right approach, but the spec is written to disallow this use due to the strong native semantics of @hidden.

<div aria-hidden="true">
  Visual clutter that should be hidden from AT
</div>

The problem is that @hidden is a boolean attribute, so its absence indicates that the element is *not* hidden, and therefore aria-hidden="true" would be in conflict with the host language attribute.

ARIA defines conflict resolution here:
http://www.w3.org/WAI/PF/aria/complete#host_general_conflict

"When a host language declares a WAI-ARIA attribute to be in direct semantic conflict with a native attribute for a given element, user agents MUST ignore the WAI-ARIA attribute and instead use the host language attribute with the same implicit semantic."

Therefore, because this "strong native semantics" table is conflating @hidden and @aria-hidden, and the HTML spec allows @hidden on all elements, it is explicitly declaring that @aria-hidden has no effect in HTML5, which is obviously problematic, because the user agents MUST ignore aria-hidden and use the host language attribute on the following element (missing @hidden implicitly means "not hidden", even to API):

<div aria-hidden="true">
  Visual clutter that should be hidden from AT
</div>

I propose the change be to remove that line from the "strong" table (and possibly add it to the "weak" table) because the @hidden and @aria-hidden actually mean different things:

@hidden indicates the element is not rendered in any modality unless:
 - visually overridden with @style.
 - semantically overridden with @aria-hidden for accessibility APIs.

@aria-hidden is an explicit override for any display property that only affects accessibility APIs, and always trumps other display settings or attributes for the output to said APIs.

(In reply to Leif Halvard Silli from comment #1)

> If @hidden was placed in the ”weak” table, it would not be forbidden to
> “override” it with a aria-hidden="false".

Can you post a link to the "weak" table? Does it exist or would it be a new table?

Related to bug 23376

(In reply to James Craig from comment #3)
> (In reply to Leif Halvard Silli from comment #1)
> 
> > If @hidden was placed in the ”weak” table, it would not be forbidden to
> > “override” it with a aria-hidden="false".
> 
> Can you post a link to the "weak" table? Does it exist or would it be a new
> table?

Nevermind. I preseume you're talking about the "Implicit ARIA Semantics" table.

(In reply to James Craig from comment #5)
> (In reply to James Craig from comment #3)
> > (In reply to Leif Halvard Silli from comment #1)
> > 
> > > If @hidden was placed in the ”weak” table, it would not be forbidden to
> > > “override” it with a aria-hidden="false".
> > 
> > Can you post a link to the "weak" table? Does it exist or would it be a new
> > table?
> 
> Nevermind. I preseume you're talking about the "Implicit ARIA Semantics"
> table.

It has an @id attribute which says "weak". At least it used to have.

(In reply to James Craig from comment #2)
> (In reply to Leif Halvard Silli from comment #1)

> > If @hidden was placed in the ”weak” table, it would not be forbidden to
> > “override” it with a aria-hidden="false".
> 
> Moving this row to the "weak" table would work for me.

I think that would be an acceptable solution as well.

> > But your focus i aria-hidden="true" - not aria-hidden="false". 
> 
> Not necessarily. That's tangential to my point, but WebKit exposes the
> following to the AX API. Other UAs don't, but they should.
> 
>     <div hidden aria-hidden="false">Only AT gets this text</div>

One question then becomes: Should the Strong/Weak tables be use to direct what *authors* are allowed to do, based on what is implemented? Or should one use other means for that? Probably one should place @hidden in the table where it should be, and deal with advice to authors regarding what is implemented, separately.

As for how AT *should* behave, then I believe HTML5 already makes it clear that - as ARIA says - aria-labelledby might point to a <div hidden>section</div>. (We also had a big debate about whether aria-describedby could do the same - and in all the fuss, I forgot what the conclusion was …)

But I guess what you defend is that aria-hidden="false" should affect the flow of text - from AT’s side - which is a slightly different thing than aria-labelledby/-describedby. (But, then again, linking is also interesting - as e.g. activating a link to a <div id="hidden" hidden> section could, via CSS, make it visible.)

> > And in my view, @hidden in the strong table does
> > not prevet aria-hidden="true" from being applied to elements without @hidden.
> > 
> > Thus I don't see the problem that you see - one of us is probably reading
> > something wrong ... :-)
> 
> You're suggesting this, which I agree is the right approach, but the spec is
> written to disallow this use due to the strong native semantics of @hidden.
> 
> <div aria-hidden="true">
>   Visual clutter that should be hidden from AT
> </div>

This might be a possible reading of the spec. But to the extent that the NU validator does anything with @aria-* elements at all, the above example *does* pass as conforming. If your reading is the intended one, then I am on the same page as you - it is wrong.

From my perspective it is obvious that it is wrong to place the <head> in the strong table with aria-hidden="true". Why? For two reasons:

1) It is possible to make the head element visible - all it takes is CSS. For instance, it is possible to make the <title> element - a child of <head> (and my understanding is that the aria-hidden state is inherited) - visible. May be it is *anyhow* (that is: even when made visible) best that it defaults to being aria-hidden="true". But why is it correct that it should be a strong semantics?

2) The other reason is the thing that <title> is child of <head> - would it then even be correct to render the title of the page to AT users? Yes, you could argue that the title is displayed to visual users in the chrome of the browser and not via the visually rendered canvas. But still. Would it not be better to apply the aria-hidden-ness to selected children of <head>? (In practice, to any child of <head> - except <title>.) Some of the elements that goes into <head> are already hidden by default - such as <script> and <style> - anyway.

In my view, it would be best to place all elements that by default are hidden in the weak table, or else the spec is kind of sending the message that it is *forbidden* to make them visible. In all these years - before ARIA was included in HTML - it has been permitted to make e.g. <script> visible – and it did not lead to any problems. Hence I don't understand the business with the strong aria-hidden semantics. Weak would be enough. Or may be - as you hinted - one should find another way (than the strong/weak tables system) to categorize these things.

> The problem is that @hidden is a boolean attribute, so its absence indicates
> that the element is *not* hidden, and therefore aria-hidden="true" would be
> in conflict with the host language attribute.

If so, then the spec is in conflict with itself when it defines that a number of elements which do *not* use the @hidden attribute (such as <script> and <head>) have a strong semantics of aria-hidden="true".

> ARIA defines conflict resolution here:
> http://www.w3.org/WAI/PF/aria/complete#host_general_conflict
> 
> "When a host language declares a WAI-ARIA attribute to be in direct semantic
> conflict with a native attribute for a given element, user agents MUST
> ignore the WAI-ARIA attribute and instead use the host language attribute
> with the same implicit semantic."

WAI-ARIA should have provided examples of what this means. For instance, I guess that @alt on <img> is an attribute that is in direct conflict with @aria-label. Not?

> Therefore, because this "strong native semantics" table is conflating
> @hidden and @aria-hidden, and the HTML spec allows @hidden on all elements,
> it is explicitly declaring that @aria-hidden has no effect in HTML5, which
> is obviously problematic, because the user agents MUST ignore aria-hidden
> and use the host language attribute on the following element (missing
> @hidden implicitly means "not hidden", even to API):
> 
> <div aria-hidden="true">
>   Visual clutter that should be hidden from AT
> </div>

My impression is that Steve considers it author friendly to promote @hidden and suppress @aria-hidden. (Or aria-hidden="true".) And I agree that it is a bit unfortunate to mix them together.

But note that WAI-ARIA also has the *opposite* problem: I always thought it strange that WAI-ARIA says that it is not enough to just hide elements via CSS - one should *in addition* use aria-hidden. 

I feel that you are putting it on an edge, though. Even if @hidden is boolean, it is a matter of fact that applying - or removing - @hidden on e.g. <script>, has no effect what so ever.

> I propose the change be to remove that line from the "strong" table (and
> possibly add it to the "weak" table) because the @hidden and @aria-hidden
> actually mean different things:
> 
> @hidden indicates the element is not rendered in any modality unless:
>  - visually overridden with @style.
>  - semantically overridden with @aria-hidden for accessibility APIs.
> 
> @aria-hidden is an explicit override for any display property that only
> affects accessibility APIs, and always trumps other display settings or
> attributes for the output to said APIs.

I concur with your proposal.

> I propose the change be to remove that line from the "strong" table (and
> possibly add it to the "weak" table) because the @hidden and @aria-hidden
> actually mean different things:
>
> @hidden indicates the element is not rendered in any modality unless:
>  - visually overridden with @style.
>  - semantically overridden with @aria-hidden for accessibility APIs.
>
> @aria-hidden is an explicit override for any display property that only
> affects accessibility APIs, and always trumps other display settings or
> attributes for the output to said APIs.

Let me also discuss what you are *not* proposing:

In theory, we could have have removed the aria-hidden="true" semantics from @hidden. Then all conflicts with ARIA would be solved. From AT users’ point of view (or at least: from their user experience’ point of view),  the *only* thing we *win* by linking @hidden to aria-hidden="true" is that we can do this, which you described above as a hack:

   <div hidden style="display:block">AT don't see me!</div>

Or does AT see <script> different from <script hidden="">? Would it change *anything*, in the real world, if <p style="display:none"> and <p hidden=""> become 100% synonymous? (THus: that hidden just became an alias for display:none [except that @hidden is also supposed to be implemented even if the UA does not support CSS].) 

Some of the arguments in defense of "getting as much @aria-hidden=true as possible" (which is how you could see the linking of @aria-hidden=true to @hidden) seems to be focused on the AT equipment, namely the fact that aria-hidden="true" does *more* than simply CSS-hiding the content [namely, it removes stuff from the accessibility tree]. It clutters up the debate because, from users’ point of view (AT users, that is), there is no difference (right?) between the following variants:

 <p aria-hidden="true">
 <p style="display:none">
 <p hidden="">

(In reply to Leif Halvard Silli from comment #6)
> (But, then again, linking is also interesting - as e.g. activating a link to a <div id="hidden" hidden> section could, via CSS, make it visible.)

Interesting, though seems tricky in practice. :focus would not work by itself because there is no displayed target to move focus to. :target could display the element just before :focus, but chances are that this would be futile and hide the element again after the onblur of the link, but before the onfocus of the target.

(In reply to Leif Halvard Silli from comment #6)
> (In reply to James Craig from comment #5)
> > ARIA defines conflict resolution here:
> > http://www.w3.org/WAI/PF/aria/complete#host_general_conflict
> > 
> > "When a host language declares a WAI-ARIA attribute to be in direct semantic
> > conflict with a native attribute for a given element, user agents MUST
> > ignore the WAI-ARIA attribute and instead use the host language attribute
> > with the same implicit semantic."
> 
> WAI-ARIA should have provided examples of what this means.

Bug 23383 is a less controversial example. @value, @min, and @max on <input type="range" are identical to @aria-valuenow, @aria-valuemin, and @aria-valuemax on role="slider"

> For instance, I
> guess that @alt on <img> is an attribute that is in direct conflict with
> @aria-label. No?

No. Labels are a special case. See the text alternative computation for more examples of why.

http://www.w3.org/WAI/PF/aria/complete#textalternativecomputation

> I feel that you are putting it on an edge, though. Even if @hidden is
> boolean, it is a matter of fact that applying - or removing - @hidden on
> e.g. <script>, has no effect what so ever.

What? Does that mean it has no effect in browser X? In WebKit, adding @hidden hides the element from the visual display and the accessibility tree. The implementation detail is that the UA style sheet now includes:

[hidden]{display:none;}

> > I propose the change be to remove that line from the "strong" table (and
> > possibly add it to the "weak" table)
> 
> I concur with your proposal.

Steve, do you concur too?

(In reply to James Craig from comment #8)

It is very simple. Given this CSS:

<style>*[hidden]:target{display:block;}</style>

then it only requires that you activate the link/url to the #hidden fragment. Either via a link:

   <a href="#hidden">link</a>

or by typing it direclty.

(In reply to James Craig from comment #9)
> (In reply to Leif Halvard Silli from comment #6)


> > I feel that you are putting it on an edge, though. Even if @hidden is
> > boolean, it is a matter of fact that applying - or removing - @hidden on
> > e.g. <script>, has no effect what so ever.
> 
> What? Does that mean it has no effect in browser X? In WebKit, adding
> @hidden hides the element from the visual display and the accessibility
> tree. The implementation detail is that the UA style sheet now includes:
> 
> [hidden]{display:none;}

Yes, of course. But UAs already implements

script{display:none}

So applying @hidden to <script> does not add something that wasn't there.

(In reply to James Craig from comment #9)

> > > I propose the change be to remove that line from the "strong" table (and
> > > possibly add it to the "weak" table)
> > 
> > I concur with your proposal.
> 
> Steve, do you concur too?

It seems he has chosen another way to solve the problem, see bug 23371:

https://www.w3.org/Bugs/Public/show_bug.cgi?id=23371#c1

(In reply to Leif Halvard Silli from comment #12)
> (In reply to James Craig from comment #9)
> 
> > > > I propose the change be to remove that line from the "strong" table (and
> > > > possibly add it to the "weak" table)
> > > 
> > > I concur with your proposal.
> > 
> > Steve, do you concur too?
> 
> It seems he has chosen another way to solve the problem, see bug 23371:
> 
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=23371#c1

I have made a proposal through an edit to the spec, I have left the bug open for further discussion.

Leif Halvard Silli wrote:
> > > Even if @hidden is boolean, it is a matter of fact that applying - or removing - @hidden on e.g. <script>, has no effect what so ever.

and:
> UAs already implement
> script{display:none}
> 
> So applying @hidden to <script> does not add something that wasn't there.

We're getting somewhat academic, but it has an effect in that it adds another rule to be considered in the cascade. In this case, it hidden because of either rule, or both. I understand your point about the Boolean state though. Seems like in order to correct this HTML, could disallow @hidden on elements that were not rendered by default, but mentioning that also seems like pointless spec bloat.

Duping this one out to the clone.

*** This bug has been marked as a duplicate of bug 23371 ***