- From: Maciej Stachowiak <mjs@apple.com>
- Date: Mon, 10 Sep 2007 13:42:26 -0700
- To: Charles McCathieNevile <chaals@opera.com>
- Cc: "public-html@w3.org" <public-html@w3.org>
On Sep 2, 2007, at 11:31 PM, Charles McCathieNevile wrote: > > On Mon, 03 Sep 2007 14:03:43 +0900, Maciej Stachowiak > <mjs@apple.com> wrote: > >> On Sep 2, 2007, at 7:27 PM, Charles McCathieNevile wrote: >>> On Sun, 02 Sep 2007 18:27:42 +0200, Sander Tekelenburg <st@isoc.nl> >>>> At 10:48 -0400 UTC, on 2007-09-02, Al Gilman wrote: >>>>> ... the accessibility APIs are practice >>>> >>>> Sure, but what does authoring HTML (with universality and >>>> accessibility in mind) have to do with OSs' accessibility APIs? >>>> We're trying to >>>> improve HTML such that it becomes easier and more attractive to >>>> authors >>>> to produce content that provides universality and accessibility. >>> >>> In the real world, the way to present information to assistive >>> technology is via OS accessibility APIs. An HTML list, or >>> checkbox, is related to the OS' notion of a checkbox so the AT can >>> figure out what to do with it. Some ATs have special handling for >>> Web browsers, but this makes them much more expensive to produce >>> and maintain, and less likely to be overall compatible with >>> browsers, instead relating to one or two specifically. >> >> I don't know of any screen reader that doesn't special case the >> browser to some extent. > > That doesn't make it a good design principle. Screen readers special- > case certain applications - so VoiceOver might special-case Safari, > but does nothing for Opera, I think it would work for other browsers to use the same accessibility interfaces for their web content area that WebKit uses. The source code for WebKit's VoiceOver integration is all publicly available. > nor iTunes (which until recently was a fairly good demo of the > problems with relying on special casing). iTunes is not a web browser (or an HTML UA of any kind), so I'm not sure what relevance that has. > And it doesn't prove that screen readers make special APIs for > browsers. In general, it makes more sense to provide generic APIs > for system widgets, and that is what screen readers tend to do. My understanding is that most screen readers on Windows use a combination of generic Windows accessibility APIs, application- specific APIs through COM, and literal screen-scraping by hooking into video drivers. They don't tend to provide APIs themselves. VoiceOver gets information through Mac OS X accessibility APIs that could in principle be used by another screen reader. There are some special APIs meant for web browsers that go beyond what normal applications would do. Regards, Maciej
Received on Monday, 10 September 2007 20:42:40 UTC