Re: FW: [html] Summary draft

[This email is not Cced to any of the wai lists, but only because I
suspect it would be either out of context or redundant.]

Aryeh Gregor wrote:

> I think a lot of the people who work on accessibility start out
> with the attitude "Let's provide a mechanism that would be
> helpful for accessibility if used correctly".

Yes.

That seems like a pretty low bar, but it is a necessary condition.

In certain walled-garden situations, it may even be sufficient.

The questions are:

(a)  How practical would it be to do even better?
(b)  If a "mostly better" solution came with trade-offs, how many such
walled gardens would be hurt, and how badly?

A fair amount of automated communication uses XML rather than HTML,
because the extra effort of getting it right (for a program) isn't all
that high, and the extra benefits (for automated processing) accrue
quickly.

My personal beliefs regarding summary are that:

(a)  It wouldn't be that hard to do better.  This is largely because
correct @summary usage has been so rare.  (But also because the
automated "even better" options are not as expensive or as unlikely as
the advocates believe, so long as they can be clearly specified and
implemented by the browser vendors instead of AT vendors or individual
page authors.)

(b)  The number of sites (even walled gardens) using @summary
correctly is fairly small, and probably limited to the same
organizations that would be most willing to use an even better
solution if one could be standardized at even the author level, let
alone the browser level.

I freely admit that I don't have any hard data to support those two
beliefs.  But I haven't seen any data to contradict them either, and I
think accessibility advocates may have become too conservative in
their aims.  This leads to a reflexive defense of something that is
less bad than nothing, rather than an exploration of what improvements
are still plausible.

-jJ

Received on Tuesday, 15 September 2009 19:07:07 UTC