W3C home > Mailing lists > Public > public-html@w3.org > September 2007

Getting input from AT developers (was Re: Screen-reader behaviour)

From: Sander Tekelenburg <st@isoc.nl>
Date: Mon, 3 Sep 2007 14:38:09 +0200
Message-Id: <p0624066ac301a0add4ad@[192.168.0.101]>
To: <public-html@w3.org>, <wai-xtech@w3.org>

["AT" as in "Assitive Technology", not authoring tools]

At 04:27 +0200 UTC, on 2007-09-03, Charles McCathieNevile wrote:

> cc- wai-xtech. They know this stuff.

OK.

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

[...]

>> Why would a HTML UA be unwilling to contribute to HTML5?
>
> Because is it expensive (very expensive to try and deal with this group

What expense are you referring to? The time it takes to track
<public-html@w3.org>? I can sympathise with that (but only up to a point --
many of this WG's members are donating their time). But, unless they have no
interest in a more accessible Web, they'll need to figure out some way of
participating. A simple form could be that this WG's members jointly, through
the wiki, write up specific questions for them. That way they'll only need to
deal with that document. But for us to bother, we should know that AT
developers would be willing to (try to) answer those questions (and
preferably hand us their 'wish list').

(I suppose it could be done even more officially, by delegating a few members
of this group; setting up a dedicated subgroup. But committeeing itself is
expensive. A simple question and answer through the wiki would be easier on
everybody.)

> I know of several HTML UAs where nobody is interested in participating.

Sure, but we're not talking about specific individual parties missing from
this WG, but about the entire AT industry. Considering the emphasis W3C puts
on "accessibility", that is strange, to say the least.

[...]

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

What is unreal about authors abusing @alt, suppressing it with empty @titles,
finding it too hard to provide @headers, not providing @longdesc, @summary,
@scope, avoiding <link> and <object>, abusing <table>, ignoring @rel, etc?

Very simple example: I sat down with a Jaws user once to find out what
problems he might have with accessing a site I built. To my dismay, he
complained about all the abbreviations in the text not being explained,
despite their being marked up with <abbre title=>. It turned out that for
some reason his set-up ignored that, thus making things less accessible to
him. Exactly why @title was ignored wasn't clear. Possibly due to IE's lack
of support for <abbr>; possibly due to some default setting in Jaws (settings
which themselves weren't accessble at all). This is a real world problem --
how can HTML be improved, or how should authors author, to serve such users
better?

Other real world questions that have come up here are
- what help could HTML provide to AT to recognise that a table is abused for
lay-out
- to what extent is it important for users, and possible for UAs, to present
equivalents simultaneously
- is it generally easier for AT to support (new) elements, or (new)
attributes (compare <alt> vs @role.)
- etc.

> , the way to present information to assistive technology
> is via OS accessibility APIs.

If you're saying that AT aren't HTML UAs, that suggests we shouldn't be
targeting these question at AT deveopers, but at accessibility API
developers. Or do I misunderstand you?

[...]

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

Understood. But these aren't HTML issues, so not relevant for the HTML WG.
(And it applies to screen readers only.)

[...]

> WAI-ARIA is designed to solve the class of problems that arises with
> bleeding edge development [...]

Exactly.

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

Right.

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

Which "people"? "Faster" than what?


-- 
Sander Tekelenburg
The Web Repair Initiative: <http://webrepair.org/>
Received on Monday, 3 September 2007 12:39:34 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:38:49 UTC