Other problems, @hidden (ISSUE-204 aria-hidden)

Maciej Stachowiak, Tue, 14 Aug 2012 13:03:34 -0700:

> Consider the scenario where aria-describeby on an element points to 
> hidden content, which contains a link.

> It may also be that there are some UAs 
> that would inadvertantly allow tab focus into invisible content, 
> perhaps due to hard implementation constraints. I do not see this as 
> inevitable. I do not believe it would be the case with WebKit.
> 
> It may also be that there are problems with the approach above. But 
> it does not seem to me that tab-focus into invisible content is one 
> of them. If there are other problems, it would be great to know!

One problem: The spec wants us to use the hidden attribute rather than 
aria-hidden=true and my perception has been - for a good while - that 
when one adds the hidden attribute to an element, then on 
simultaneously add aria-hidden=true. I don't know, anymore, whether it 
really *should* be that way. But at any rate: If it had been like that, 
then it would have been congruent with the way the empty alt attribute 
is equivalent to role=presentation.

What has made me uncertain, however, is testing. Take these 2 
paragraphs, where display:block overrules the [hidden]{display:none}:

<p hidden="" style="display:block" >B, b, b!
<p hidden="" aria-hidden="true" style="display:block" >C, c, c!

If @hidden and @aria-hidden=true were truly equal, then there would be 
no difference between the two paragraphs - both of them would be hidden 
from AT users.  However, as a matter of fact: only the first paragraph 
is visible to AT users. (Tested in VoiceOver+Safari, 
VoiceOver+FirefoxNightly, Crome+ChromeVox and Jaws+Firefox.)

How is this related to ISSUE-204? Well, if all @hidden does is that it 
adds display:none to the element where it is used, then it is simple to 
make hidden elements visible to AT users: All it takes is some CSS. (It 
is certainly simpler to use CSS to make a page accessible, compared to 
using JavaScript.)

Questions to the chairs, to John and others: 

(1) Did you, the chairs, consider @hidden from the angle that it merely 
is "semantic" variant of style="display:none"?

(2) Would it make a differences to the objector(s) if the spec pointed 
out that @hidden does not mean the same thing as @hidden?

(3) Would it make sense if the spec said that @hidden is *not* 
semantically equivalent to @aria-hidden? If @hidden is *not* equivalent 
to @aria-hidden=true, then it becomes much simpler to author with: Just 
do e.g. *[hidden]{display:block} and - voila - the content is 
accessible even for ATs that are unable to read inside hidden content.

By contrast, aria-hidden=true requires that one removes it or changes 
it to aria-hidden=false before it becomes visible to AT. Remember that 
ARIA recommends authors to do [aria-hidden=true]{display:none} - and 
that this is for two reasons: a) to think about accessibility from the 
start - make it the cornerstone of the design and b) to - for 
back-compatibility reasons - make sure that aria-hidden sections are 
also visually hidden.
-- 
Leif Halvard Silli

Received on Wednesday, 15 August 2012 01:30:52 UTC