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

hi leif,

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]
>

it is not the place of the 'HTML to Platform Accessibility APIs
Implementation Guide' to document ARIA mappings to HTML, that should be in
the aria implementation guide, which it is for aria-hidden [1] Any
reference to ARIA in the HTML guide is there for informative purposes only.

as to @hidden, the 'HTML to Platform Accessibility APIs Implementation
Guide' has not *yet* documented the mappings

regards
SteveF

[1] http://www.w3.org/WAI/PF/aria-implementation/#mapping_state-property


On 15 August 2012 11:19, Leif Halvard Silli <
xn--mlform-iua@xn--mlform-iua.no> wrote:

> 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
>
>


-- 
with regards

Steve Faulkner
Technical Director - TPG

www.paciellogroup.com | www.HTML5accessibility.com |
www.twitter.com/stevefaulkner
HTML5: Techniques for providing useful text alternatives -
dev.w3.org/html5/alt-techniques/
Web Accessibility Toolbar - www.paciellogroup.com/resources/wat-ie-about.html