RE: Revert request

Charles Pritchard wrote:
> 
> The PFWG is outside of my purview: yes, there is work on an ARIA
> semantic with etymological roots in longdesc.
> And it will be glorious. And it'll come out of ARIA1.1 or ARIA2. And
> I'm
> more likely to see it in ARIA2, given that 1.1 will probably be an
> errata-style document covering issues of accessibility that were not
> covered in 1.0. That is, 1.1 will fix things that don't exist. ARIA2
> would further enhance things that do exist.
> 
> That's my guesstimate.

And a reasonable guesstimate it seems to be.


> 
> In the meantime: where are we with closing the case on HTML5 @longdesc?

The Issue is sitting with the Chairs who seem paralyzed to do anything, instead hoping some magical solution will fall from the sky. It won't, but they (apparently) remain hopeful.


> 
> I understand there is an active issue to improve aria-describedby via
> changes to @hidden. It's really far out there

I have filed a Counter Proposal to Issue 204 that addresses this:
http://www.w3.org/html/wg/wiki/ChangeProposals/ARIA_Can_Only_Refer_To_Hidden_Content_With_Specific_Restrictions

It is actually based on a presumption that is untenable, as any hidden text will be (per ARIA and the Accessibility APIs) string text only. It will not - nea cannot - support richer HTML text, a point that I have actively clarified through Richard Schwerdtfeger, IBM (and will surface more clearly articulated in the ARIA Implementation Guide, based on feedback - Date TBC, but soon). 

Rich is in a real position to both understand and know the answer, as over the life-cycle of ARIA to date he has served as Editor of the WAI-ARIA 1.0 W3C Candidate Recommendation, Editor of the WAI-ARIA 1.0 Authoring Practices Working Draft, Editor of the Roadmap for Accessible Rich Internet Applications, and the former and current Editor of the WAI-ARIA 1.0 User Agent Implementation Guide were/are IBM employees who report to Rich.



> and even if it worked
> perfectly; which it would spec-wise if implemented between <canvas>
> tags; and even if it were implemented perfectly (canvas isn't; we're
> just now seeing focus events working, and they are bug-ridden); even if
> all of that happened, @longdesc would still have its use.

Yes, because even if we triumphantly arrive at a great ARIA-mapped equivalent to @longdesc (in ARIA 1.1 or ARIA 2.0), there is a whole raft of implementation issues that will need to be addressed, including (most importantly), adoption/support by Screen Readers. And while at least one of the Chairs believes that should an ARIA solution emerge tomorrow we will have a solution to the Issue 30 log-jam, he is, uhm, mistaken, as that alone would not be sufficient to Obsolete @longdesc, as attaining any amount of usable, dependable support across browsers and screen readers will take a significant amount of time - time measured in years, not months or weeks - and we require a solution now.

We have also pretty clearly articulated a need for the browsers themselves to *do something* besides hand it off to other tools to do something useful with.  All of that will take time, and in the interim we will need a functional option that addressed the needs. Despite its alleged or apparent shortcomings, @longdesc is the best we've got, if for no other reason than we have some support today - support that screen reader users today count on.


> 
> So we're looking at new aria semantics that would work to supersede
> @longdesc; and as I said in my reply, that's great, but that doesn't
> mean that HTML @longdesc should be deprecated. It simply means it'll
> have an ARIA mapping in the future.

Exactly. And to be extremely clear, it is not "deprecation" that @longdesc currently faces, but rather full-on obsolescence of the attribute. More than anything else, it is this jarring and abrupt "ripping out" of the @longdesc attribute that is most infuriating.

JF

Received on Wednesday, 14 March 2012 06:18:45 UTC