W3C home > Mailing lists > Public > public-html-a11y@w3.org > August 2012

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

From: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
Date: Wed, 15 Aug 2012 12:19:46 +0200
To: Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com>
Cc: Maciej Stachowiak <mjs@apple.com>, Janina Sajka <janina@rednote.net>, John Foliot <john@foliot.ca>, Sam Ruby <rubys@intertwingly.net>, public-html@w3.org, HTML Accessibility Task Force <public-html-a11y@w3.org>
Message-ID: <20120815121946452040.1d95c1ed@xn--mlform-iua.no>
Benjamin Hawkes-Lewis, Wed, 15 Aug 2012 08:50:30 +0100:
> On Wed, Aug 15, 2012 at 2:30 AM, Leif Halvard Silli:
>> Maciej Stachowiak, Tue, 14 Aug 2012 13:03:34 -0700:

>> 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.
> 
> Finding the above hard to follow, but just because an HTML "native"
> feature implies some ARIA mappings does not mean that it has to behave
> precisely the same way as some ARIA annotations that have the same
> mappings. Was that your concern?

The 'HTML to Platform Accessibility APIs Implementation Guide' has not 
documented *any* correspondence between the hidden attribute and 
WAI-ARIA *or* with any accessibility APIs.[1] But the HTML5 spec, OTOH, 
says, in the table over strong native ARIA semantics:[2]
   Element with a hidden attribute | The aria-hidden state set to "true"

Note that Maciej said 'invisible' and not 'hidden': "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!"

If we compare with aria-hidden=true, then it is a feature of WAI-ARIA 
that it is *possible* - for a no-AT user - to tab into an 
aria-hidden=true area. Just do this CSS:
   element[aria-hidden=true]{display:block}

What the decision makes possible, then, is the opposite: that some AT 
users could tab into a hidden area.

Now, is it a bug in implementations that the hidden attribute does not 
cause the aria-hidden state to be set to true? Or is it a feature and 
thus a bug in the HTML5 spec?

It seems to me that the bug - the false shortcut - is in HTML5. Why? 
Because we are discussing making it possible for AT to jump around 
inside a [hidden]{display:none} section. Because the same thing - for 
an AT to jump around inside a section that has aria-hidden set to 
'true', is not possible. And no one plans to make it possible. Am I 
wrong?

Clearing this up will at least not hurt the current debate.

[1] 
http://dvcs.w3.org/hg/html-api-map/raw-file/default/Overview.html#att-22
[2] http://dev.w3.org/html5/spec/wai-aria.html#table-aria-strong
-- 
leif halvard silli
Received on Wednesday, 15 August 2012 10:20:24 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 15 August 2012 10:20:24 GMT