Re: Screen-reader behaviour

cc- wai-xtech. They know this stuff.

On Sun, 02 Sep 2007 18:27:42 +0200, Sander Tekelenburg <st@isoc.nl> wrote:

> At 10:48 -0400 UTC, on 2007-09-02, Al Gilman wrote:
>> To: public-html@w3.org, wai-xtech@w3.org
>> At 3:58 AM +0200 31 08 2007, Sander Tekelenburg wrote:

>>> At 13:18 -0400 UTC, on 2007-08-30, Al Gilman wrote:
>>> Are you saying you have input from real actual flesh and blood  
>>> developers of
>>> Jaws and such?
...
>>> Can you get them to participate in the HTML WG?
>>
>> I seriously doubt it.
>
> Why? Why would a HTML UA be unwilling to contribute to HTML5?

Because is it expensive (very expensive to try and deal with this group -  
I know of several HTML UAs where nobody is interested in participating.  
How many of the major phone browsers are represented here?

>>> The theory is
>>> important, but without input from the practice side, we aren't going  
>>> to get anywhere.
>>
>> I'm sorry, 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.

> [...]

> that I very much want to know *why* that is; what obstacles developers of
> such tools run into, so that we can start to try to remove such obstacles
> from HTML5.

Changing practice is a major one...

Some issues:
+ Screen readers have to lay their functionality (and interface for it) on  
top of the user interfaces for the applications they support. This is  
generally very hard.
+ They are supporting a range of applications - everything you use, not  
just web browsers.

...
>> 3) We not only have AT vendors talking to us, we have them
>> implementing WAI-ARIA so that very-lightly-improved coding practice
>> in Web Applications will create function available through AT which
>> is presently outright unavailable.  This is our response to "solve
>> real problems."
>
> And WAI-ARIA looks, at first glance, real useful. But from what I've  
> read of it, it appears to be only about intentionally javascript-
> dependant sites (or "DHTML, Ajax, Web 2.0", if you prefer fancier
> terminology). In the mean time,
> we're still stuck with much more basic problems like @alt, @longdesc,
> @summary, @headers, @scope, <img>, <object>, <embed>, aural CSS, etc.

WAI-ARIA is designed to solve the class of problems that arises with  
bleeding edge development - the fact that support for it won't, a priori,  
be built into anything. While it seems good enough for a developer to just  
write a bit of javascript and provide keyboard shortcuts to their new Web  
2 application, it is rare to find that they considered how that would  
impact existing use of the keyboard, and how it would work on devices with  
no keyboard, or a numeric keypad, ...

In fact ARIA *could* be used to deal with the problems currently being  
solved by @alt, @longdesc, etc. But I think there is general agreement  
that where you have a standard built into browsers and the language it is  
more useful than relying on the kind of magic that ARIA does. So you  
*shouldn't* reinvent wheels like @alt without some pretty good reason to  
believe that people will implement the new version faster and replace the  
old version.

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 02:27:23 UTC