[Bug 23370] Strong Native Semantics table appears to imply @hidden trumps @aria-hidden

https://www.w3.org/Bugs/Public/show_bug.cgi?id=23370

--- Comment #6 from Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no> ---
(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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Received on Thursday, 26 September 2013 23:50:41 UTC