Re: Screen-reader behaviour

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