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

On Wed, Aug 15, 2012 at 2:30 AM, Leif Halvard Silli
<xn--mlform-iua@xn--mlform-iua.no> wrote:
> 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.

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?

--
Benjamin Hawkes-Lewis

Received on Wednesday, 15 August 2012 07:51:18 UTC