RE: Two efforts to kill longdesc

Laura Carlson wrote:
> The writing is on the wall.


With all due respect, I think you are reading more into this than there is.

Seeking to improve and clarify how browsers should implement ARIA is *NOT* 
an attempt to kill off @longdesc, and suggesting anything of that kind is 
simply wrong and divisive. Suggestions of conspiracy plots certainly doesn't 
help garner wider community support for retaining @longdesc. I've long ago 
accused our detractors of using FUD, and I would be terribly saddened if we 
stooped to that level ourselves.

The Accessibility Task Force *and* PFWG have already lent their support to 
advocating (and fighting) to ensure @longdesc remains in HTML5. Silvia, 
Janina and others have spent time and effort helping to ensure that the 
Change Proposal is as tight as it can be going forward. Rumor and 
scuttlebutt has it that a significant amount of discussion time at the AC 
Reps Face-to-Face was dedicated to the @longdesc "situation", and at this 
time I would be extremely surprised if @longdesc did not return to HTML5.

I often use automobiles as analogies in my presentations and talks, and I 
will again here: I don't want to instantly outlaw gasoline burning 
automobiles tomorrow, but I am totally in support of advancing electric 
automobiles as a sane and scalable solution moving forward. These are not 
mutually exclusive positions.

> Accessibility Task Force ACTION: Janina to carry to PF the request to
> clarify that ARIA Described-by text can include markup, and that any
> such markup needs to be exposed to a11y apis

FWIW, we *NEED* this if we are to achieve a means of describing both a media 
asset and an image asset in <video> properly (see: & - a 
proposal BTW that many have already agreed is both useful and elegant. But 
it won't work if aria-describedby continues to be wrongly implemented by 
browsers. FWIW, it was *me* who pushed Janina to record this as an Actual 
Item in the minutes, as we need to get this fixed - it's important.

I for one would fight tooth and nail if we were in a situation where 
preserving @longdesc meant that we could not continue to improve and 
innovate on ARIA (or even just seek to ensure that browsers are reading and 
implementing the spec correctly), and I think you would be hard pressed to 
find anyone who would disagree with that statement. Retaining @longdesc 
needs to stand on its own merits (of which there are many, many, many), but 
not as a default concession simply because browsers aren't getting ARIA (and 
specifically aria-describedby) right today. That to me is an extremely 
hollow victory.

> Silvia to Jonas in "Re: ISSUE-30 longdesc - Chairs Solicit Alternate
> Proposals or Counter-Proposals" thread:
> "I suggest your change proposal should also include that browsers need
> to expose the markup of the html snippet(s) that aria-describedby
> points to to accessibility APIs."

Ya? So what? Are you suggesting that this is wrong? That instead the 
browsers implementation of aria-describedby today is "perfect", and that 
they've gotten it 100% completely right? 

If Jonas wants to put forth a proposal that, to implement, means that he 
must also convince his browser company (employer) *and other browsers* about 
the need to fix how they currently treat aria-describedby, then I see that 
as a win. Conversely if he cannot succeed in that task, then his proposal 
fails (as does the proposal for describing the media and image assets, which 
harms accessibility in another way), as it is not technically supported. So 
if he succeeds what we end up with is more ways of ensuring accessibility of 
a wide range of needs. If he fails, we lose: the current proposal for 
poster-alt certainly loses.

No matter what, aria-describedby as a sole replacement for @longdesc will 
not meet all of the other user-requirements (including the need for 
backwards compatibility, or access to all users & not just AAPI users), so I 
am unclear why you are so concerned here.

If *moving forward* we can evolve an authoring-language-agnostic but 
functional equivalent to @longdesc that meets future needs, as well as 
current needs (something that the ARIA folks are already discussing), then I 
say bring it on. (The reverse being that we remain stuck exclusively with 
1990's solutions that do not scale to future needs - @longdesc does not 
solve the poster-alt problem for example).

Do not confuse reasoned and well-crafted, consensus driven progress with 
some kind of Machiavellian plot to kill off @longdesc. There is no doubt in 
my mind that @longdesc needs to remain in the author's tool-box (and in that 
I have not wavered one iota in the 3+ years I too have waged this battle), 
but if newer and more robust solutions arrive that allows @longdesc to 
gracefully sunset (as opposed to the current situation of being strung out 
to die, with *NO* functional replacement) then that is the evolution of the 
web - and evolution is a fact of life.

We can lead, or we can chase behind: which do you think better supports 


Received on Thursday, 2 June 2011 01:29:09 UTC