- From: Charles McCathieNevile <chaals@opera.com>
- Date: Mon, 03 Sep 2007 15:31:51 +0900
- To: "Maciej Stachowiak" <mjs@apple.com>
- Cc: "public-html@w3.org" <public-html@w3.org>
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, nor iTunes (which until recently was a fairly good demo of the problems with relying on special casing). 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. cheers chaals -- Charles McCathieNevile, Opera Software: Standards Group hablo español - je parle français - jeg lærer norsk chaals@opera.com Catch up: Speed Dial http://opera.com
Received on Monday, 3 September 2007 06:32:18 UTC