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

Re: Using @aria-describedby for long described image links [Was: Using an image map for long described image links [Was: Revert Request]]

From: Charles Pritchard <chuck@jumis.com>
Date: Tue, 07 Feb 2012 12:40:35 -0800
Message-ID: <4F318C43.7000309@jumis.com>
To: Maciej Stachowiak <mjs@apple.com>
CC: Steve Faulkner <faulkner.steve@gmail.com>, Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com>, John Foliot <john@foliot.ca>, Matthew Turvey <mcturvey@gmail.com>, Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>, Silvia Pfeiffer <silviapfeiffer1@gmail.com>, Laura Carlson <laura.lee.carlson@gmail.com>, Sam Ruby <rubys@intertwingly.net>, Paul Cotton <Paul.Cotton@microsoft.com>, HTML WG <public-html@w3.org>
On 2/6/2012 5:57 PM, Maciej Stachowiak wrote:
>
> On Feb 2, 2012, at 3:14 AM, Steve Faulkner wrote:
>
>> Hi ben,
>>
>> >But that's the very least of the problems here, since the same company
>> >who maintain VoiceOver also maintain the accessibility API and the
>> >main browser on VoiceOver's platform, so they are free to make changes
>> >to the rest of the stack to support VoiceOver.
>>
>> Indeed
>> just didn't want arguments to be based on false assumptions.
>> While it is true they are "free to make changes to the rest of the 
>> stack to support VoiceOver." assuming they will, without clear 
>> indications from them is not useful.
>
> You're both more or less correct about how things work.
>
> All direct querying of the DOM (and also of rendering information) is 
> done by WebKit, which then communicates the info to VoiceOver using 
> the NSAccessibility API. However, we are able to change any or all of 
> those layers as necessary to get a better overall experience, and we 
> try to do better with each release.

I believe it's a very-good-practice to support the DOM, as some ATs will 
be querying the DOM directly.

That's part of the reason why using setAttribute is a preferred method 
when setting ARIA values, though one can set them directly in some UAs.


> I don't think Apple has a strong stance either way on using 
> @aria-describedby to point to @hidden elements, but I believe we could 
> reasonably expose full semantics of hidden content pointed to by 
> aria-describedby, this is more or less the same as the work we'd have 
> to do to expose <canvas> children as an accessible tree.

<canvas><button /></canvas> is not the same as <canvas><button hidden 
/></canvas>.

Elements within the canvas subtree are not hidden, though. It's apples 
to oranges, though both fruits.
"The hidden attribute is a boolean attribute. When specified on an 
element, it indicates that the element is not yet, or is no longer, 
relevant. The hidden attribute must not be used to hide content that 
could legitimately be shown in another presentation."
http://www.w3.org/TR/html5/editing.html#the-hidden-attribute

The issue with Canvas is that implementers did not realize that Canvas 
is in some abstract sense, a form element.
"the best way to fix it is to make [it] more like a form control"
https://bugs.webkit.org/show_bug.cgi?id=50126

In all implementations, fixing Canvas seems to be about changing the 
object it inherits from.
https://bugzilla.mozilla.org/show_bug.cgi?id=495912

Canvas is not <img>, it's <input>.

-Charles
Received on Tuesday, 7 February 2012 20:44:01 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:39:30 UTC