Accessibility: Re: Path to Last Call (was closing various issues)

> Are we really saying something
> like "have mercy on the poor beleaguered developers for being imposed upon
> by being "required" to do something "just for accessibility"?

> "Oh, why must we *force* authors to do alt-text well, it's just for
> accessibility, isn't it? Perhaps if we can show some 'business case' for it,
> we can get it done."

I think a better description would be:

Authors *are* lazy.  Anything strictly for accessibility *will*
usually be done very badly.  The actual state of things is so bad that
even getting authors to ignore accessibility hooks (as opposed to
putting in false information) can be a minor win.  We *can't* force
them to do a better job, or at least no one has yet come up with a
method that actually works to force them.

The disagreement is on what to do about that.

To a programmer, it sounds like the Accessibility folks are saying
"More of the Same!  Just Try Harder!", and the programmers hear "Keep
beating your head against the wall!".

The programmers prefer a solution like "Automate the accessibility, so
that it works despite lazy authors!".  Unfortunately, this sounds to
accessibility advocates like "We can probably fix that in the next
version, so don't worry."  And they're used to broken promises...

If the gap isn't breached, then the programmers get discouraged and
settle for saying the problem isn't solvable (and isn't new), and the
advocates feel disrespected.

To bridge the gap:

    Programmers have to come up with some viable proposals first.

    Accessibility Advocates have to evaluate these proposals seriously.

    Someone (product managers?) has to make a public commitment that
these improved solutions will actually get in to the products, once
there is agreement.

My admittedly biased perspective is that the programmers have taken
some first steps, but the "meeting halfway" part was a missed
connection.  I assume some advocates see it differently, but please
don't hesitate to repeat yourselves -- I doubt I was the only one who
missed the responses.

Specific Examples:

(1)
The proposals to autogenerate summary were genuine offers.  There were
questions about what *should* go in a summary, so that it could be
done right, or at least no worse than what is out there today.

The advocates expressed some interest, but there was never a clear
enough explanation of what *should* go in the summary.  There was
never an explanation of what Assisted Technology already filters out.
(It filters out some bad summaries, but which ones?  Does it already
go out and get Table Headers on its own, for sensibly authored
tables?)

Nor was there specific feedback saying "This algorithm is good enough"
or "This is missing X, Y, and Z".  I even tried posting modifications
to the summary for the specific example table, but no one ever said
"This particular automatic summary would/would not be sufficient."

(2)  To programmers, aria looks like a good solution.  It should
supersede some of the bolted-on accessibility.  But the details of how
to integrate it seemed to be a minefield of hurt feelings.  (Do you
still need "alt" even if you have aria-labelled-by and
aria-described-by?  I *think* the answer is "yes", because the label
assumes you can see the image too, but described-by text is likely to
be too long, but this is still only an assumption -- and it wasn't my
first understanding.)

I have seen at least two attempts to integrate aria with html
(Hsivonen and Ian Hixie); in neither case did I see feedback specific
enough to drive it to completion.  I have heard of another done by the
PFWG, but since I can't see it ... it isn't useful to me.

I understand that the PFWG works much more formally (and therefore
much more slowly), but ... it isn't always clear how long to wait.

-jJ

Received on Monday, 31 August 2009 16:49:07 UTC