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

hi Jim,
> 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.

ARIA in the draft spec has been around a little over a week, Ian has also
sent some questions to the PF that are under consideration.
The scope (http://www.w3.org/WAI/PF/charter200612) of the PF work is to
review all specifications that are produced by the W3C as they progress on
the recommendation track. Apart from that the PF has its own specification
currently in last call (WAI ARIA) and are working their through the 100's of
public comments received. So its  not so much about the PF working much more
slowly as about the PF having a lot of work on its plate that is a higher
priority than responding to the ARIA implementation in the HTML5 spec and
also the PF works on consensus model so that responses need to be discussed
and agreed upon rather than decided by an individual, so an immediate
response is not possible.


in my role as a  html  wg member i have taken an action to monitor feedback
from the PF on the text added to the html5 spec on wai aria, and also to
produce a matrix providing author conformance advice for use of aria in
html5.
the matrix is available here
http://www.paciellogroup.com/blog/misc/ARIA/html5-elements1.html, I emailed
public html with the details about 10 days back, so it has been available.

regards
stevef
2009/8/31 Jim Jewett <jimjjewett@gmail.com>

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


-- 
with regards

Steve Faulkner
Technical Director - TPG Europe
Director - Web Accessibility Tools Consortium

www.paciellogroup.com | www.wat-c.org
Web Accessibility Toolbar -
http://www.paciellogroup.com/resources/wat-ie-about.html