- From: Maciej Stachowiak <mjs@apple.com>
- Date: Thu, 19 Jul 2007 20:33:48 -0700
- To: Al Gilman <Alfred.S.Gilman@ieee.org>
- Cc: Robert Burns <rob@robburns.com>, joshue.oconnor@cfit.ie, public-html@w3.org
On Jul 19, 2007, at 8:21 PM, Al Gilman wrote: > > It's no mystery. > > Up until now, browsers have had one processing path to the DOM and > another to the screen with divergent results. > > Authors only test for what is on the screen. AT would prefer > information expose through an API like the DOM, but they can only use > that to serve their customers if it matches what the > site/application's other customers get, i.e. what is on the screen. > So consistency of DOM and rendering is something that belongs in the > UA conformance clauses if you want to advance the state of AT > practice in this area. The DOM can't give you complete information about what is onscreen, since that is partly under the control of CSS and element-specific rendering behaviors. For example, things like CSS :before/:after generated content aren't in the DOM. Neither are the counter values for ordered lists. On Mac OS X, VoiceOver does not use the DOM as the API for accessibility hooks into Safari. Instead, the browser (actually the WebKit engine) fulfills OS-wide accessibility APIs, and the information we present is based primarily on the render tree, but it also looks at the DOM. Overall, I don't think the DOM is the right API for accessibility. Assistive technologies need information that is not appropriate to expose to scripts in the web page. Also, assistive technologies generally work cross-process, which introduces new complexities. And finally, to faithfully represent a web page, you need to include CSS info, and it's better if the AT can ask the browser how it actually rendered things rather than attempting to do its own style resolution. Regards, Maciej
Received on Friday, 20 July 2007 03:34:02 UTC