- From: Charles Pritchard <chuck@jumis.com>
- Date: Tue, 07 Feb 2012 12:40:35 -0800
- 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