Re: the market hasn't spoken - it hasn't bothered to listened [was Re: fear of "invisible metadata"]

On Jun 25, 2007, at 21:33, John Foliot wrote:

> Henri Sivonen wrote:
>>
>> I wasn't referring to any particular language feature. I was saying
>> that we should be informed and even be swayed by how markup gets used
>> in practice even if you consider the usage "poor". It would be
>> foolish to ignore actual usage.
>
> Based upon this thinking, automobiles 25 (or so) years ago should  
> never have
> installed seat belts... 'cause even when they were installed,  
> hardly anyone
> used them.  This is a "rump-forward" way of thinking: just because  
> current
> usage is poor is not a reason to continue to advocate and support
> accessibility enhancements.

No, based on this thinking of observing actual usage, the design of a  
door in a high-traffic public building has failed if it can be  
observed that most people don't know whether to push or pull when  
they walk up to the door. Educating people by adding a sign "Push" or  
"Pull" (around here often in three languages!) doesn't fix the basic  
design failure. Putting a pullable-looking handle on the pull side  
and putting a slab you can only push on the push side is a much  
better solution.

>> If we apply the curb-cut analogy to HTML, the conclusion I draw is
>> that we should move to markup with built-in accessibility roles as
>> part of the routine authoring process instead of advocating after- 
>> the-
>> fact chiseling with role=''. That is, we should push <progress>
>> instead of a bunch of divs and spans with role='wairole:progressbar'.
>
> But what is the difference really?

No offense intended, but I think we're going to have even more cases  
of people talking past each other in this WG if you really don't see  
the difference.

The difference is that when you make a progress bar using <progress>  
in a world where UAs implement HTML5 and properly communicate with  
AT, the author gets AT support for the progress bar for free when she  
uses the simplest markup for getting a visual scriptable progress  
bar. With role='' and similar afterthought annotations, enabling AT  
support requires another authoring pass over the markup specifically  
for the purpose of enabling AT support.

It should be a no-brainer that the way that makes things Just Work is  
more likely to result in an overall improvement of accessibility than  
the way that requires authors to jump through extra annotation hoops— 
particularly if they don't see if they jumped through them correctly.

> Adding a whole slew of new elements (with the learning curve  
> involved there),

The usage of <progess> is really not that hard for authors once it is  
implemented and authors are aware of it. It is much simpler to author  
than a bunch of divs and spans annotated with role='' and tested to  
see that the role='' was on the right div or span to actually work  
with AT in the intended way.

> or adding a universal attribute
> such as @role, that can be incorporated into many of the basic  
> elements
> already being used (the notorious paved cow paths)?

The "could" isn't the problem. The extra authoring work suggests that  
the "would" is in danger *on the Web scale*.

> WYSIWYG editors then
> can expose the ability to enter the appropriate role perhaps from  
> either a
> dropdown list of standard roles, or with the added ability to "custom"
> create.  We currently have *today* (on my cow path of life) WYSIWYG  
> editors
> that allow similar functionality with CSS.

I still find it curious how accessibility experts have faith in  
authoring software gaining all manner of features while at the same  
time assuming explicitly or implicitly that AT will be more or less  
frozen to its current state.

>> I'm not making market *share* arguments. I'm arguing that we should
>> be informed and potentially swayed by how markup features are used in
>> practice. That is, how they are doing in the "market". Pretending
>> that the design accessibility features cannot fail when exposed to
>> the people out there (i.e. the market) makes no sense.
>
> Neither does *not* including the ability to do so, simply due to  
> poor usage.
> This is where the fundamental difference lies between the two  
> "camps":  Many
> of the HTML WG contributors are talking in terms of lowest common
> denominator, where-as the accessibility advocates are pleading to  
> reach for
> the sky.

That depends on what constitutes reaching for the sky. I think  
settling for afterthought band-aid like role='' isn't reaching for  
the sky. Elements with built-in accessibility roles and DHTML  
fanciness moved to XBL is a more ambitious way of addressing the  
problem for the long term by shifting the burden to a handful of UAs  
than settling for a short-term solution that puts the burden on  
countless authors who don't have the competence to deal with the burden.

> What I cannot understand is how the camp that pushes for new and  
> advanced
> HTML code such as <canvas>, (which is currently experimental or  
> proprietary
> at best) see no issue with pushing these advances forward (even  
> though their
> current usage is, shall we say, poor at best); yet when the  
> accessibility
> camp asks for the same types of considerations, they are constantly  
> argued
> down due to either "complexity" or lack of general usage today.

Roughly the same "camp" that is pushing for <canvas> is also pushing  
for new elements with built-in accessibility roles. It isn't like the  
"camp" was anti-accessibility or anything. It's just that people  
disagree about the technical solutions for addressing use cases.

> Nobody is forcing anyone to use @role,

Actually, those identifying themselves as accessibility experts are  
rather quick to flash the scare of the legal stick. Even you did in  
the message I am now replying to: "and many laws in many lands say  
just that."

> *you* might want <canvas> for your perceived needs, I want @role  
> for my perceived needs.  Why should my
> needs have any less sway than yours?

People aren't really disagreeing on the needs on the use case level.  
For example, the need of blind users to query a table cell for its  
headers has not been disputed. However, the accessibility expert  
clique and the WHATWG clique have different views on what kind of  
technical solutions best address the use cases. The general pattern  
is that the accessibility expert clique goes for explicit  
accessibility annotations that put the maximal burden on authors and  
the minimal burden on UAs and the WHATWG clique goes for extracting  
accessibility information from markup that has other purposes as well  
while trying to shift the burden away from authors.

In a technical working group we should be able to discuss different  
technical solutions for the same use cases without knee-jerk  
implications that someone is anti-accessibility (and, therefore,  
immoral) for questioning a technical solution.

-- 
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/

Received on Tuesday, 26 June 2007 08:06:32 UTC