Re: Screen-reader behaviour

On Mon, 10 Sep 2007 22:42:26 +0200, Maciej Stachowiak <mjs@apple.com>  
wrote:

> 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>

>>> 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>
>>>>> Sure, but what does authoring HTML (with universality and  
>>>>> accessibility in mind) have to do with OSs' accessibility APIs?

>>>> 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.

We work towards the same APIs on Mac (and by the way working with  
VoiceOver has been relatively nice) but as I understand it, the APIs on  
Windows are different, so we need to support the Windows APIs as well.

>> 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.

Yes. But the original question is why system APIs are important to the  
HTML group, and the answer is because, although there is some special  
casing for web browsers (which is not much fun to have or do) browsers  
basically hook into system APIs in order to make screen readers work. (So  
it seems to me that we actually agree here).

Cheers

Chaals



-- 
   Charles McCathieNevile, Opera Software: Standards Group
   hablo español  -  je parle français  -  jeg lærer norsk
chaals@opera.com   http://snapshot.opera.com - Kestrel (9.5α1)

Received on Tuesday, 11 September 2007 04:12:20 UTC