- From: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
- Date: Wed, 15 Aug 2012 03:30:14 +0200
- To: Maciej Stachowiak <mjs@apple.com>
- Cc: Janina Sajka <janina@rednote.net>, Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com>, John Foliot <john@foliot.ca>, Sam Ruby <rubys@intertwingly.net>, public-html@w3.org, HTML Accessibility Task Force <public-html-a11y@w3.org>
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:54 UTC