Re: Call for consensus on longdesc change proposal

Cynthia Shelly 17/5/'11,  22:15
> Sorry I couldn't make the call.  As I've said before, I can live with 
> either decision on longdesc, as I think we can have a path forward with 
> ARIA describedby and describedat.
> On the specific proposal, I have 3 questions:
> 1)
> I don't really understand this:
> "aria-describedby will annotate text in the target id referenced by the 
> idref. This means assistive technology users would not be able to control 
> how they interact with the long description (as they can with longdesc). 
> It is read aloud without any user intervention, forcing the longer 
> description on the user whether they want it or not."
> What is meant by annotate?  Why does this make it impossible for AT 
> developers to create UI for their users that allows them to control how 
> they interact with aria-describedby?  Note that I'm not talking about 
> current AT behavior.  If this argument is about current AT behavior, then 
> it is a very weak argument, as AT can be changed just like any other 
> software.  If the argument is about it being impossible to create this UI, 
> then the reason for that needs to be called out more explicitly.

It is always possible to become more precise.

But it is, from my POV also about ARIA itself, which makes it a MAY whether 
AT presents it as markup. You mentioned the idea about @aria-describedat, 
but even for that attribute it could become a MAY.

As long as it is a MAY, then it is unreliable as a tool for an author who 
wants to provide e.g. a table for a diagram - depending on the AT, it could 
be presented as pure text.

> 2) "As, by definition, a long description is in fact long, 
> aria-describedby is not good solution for a longdesc."
> Because....?

Pointer? (the cp is big and i am on mobile)

But if the content of the long description is just plain text, then it 
probably doesn't matter.
> 3) "It is unlikely that many content creators or developers will learn 
> ARIA (something not native HTML). They already feel like they've learned 
> far more than they should have to know under their job description. And in 
> many cases, their supervisors agree. (reference Cliff Tyllick)"
> Do you really want to go there?  The PF believes pretty strongly in the 
> value of ARIA.   While I'm neutral on longdesc, I would feel very 
> uncomfortable supporting a document with this statement in it.  I suspect 
> there are other members of the TF that would agree.  It's also an appeal 
> to authority (one view), or what some guy on a blog thinks (another view), 
> neither of which carries much weight in this WG.  It seems unlikely to 
> help your case, and likely to harm other work.

We have had many uninformed debates about ARIA in this wg. The most 
important thing to learn has often been how little ARIA provides.

Telling Cliff that he should learn ARIA when ARIA - due to implemention 
status AND do to the MAY - does not support what @longdesc does, seems 
pointless and could even harm ARIA.

>>From a developer standpoint, aria-describedby and longdesc are the same. 
>> They are both extra attributes you have to add.  They're the same amount 
>> of work.  A WYSWYG tool that supports one can be modified to support the 
>> other.  I can even think of ways to do it that would be transparent to 
>> the user.

> -----Original Message-----
> From: 
> [] On Behalf Of Judy Brewer
> Sent: Saturday, May 14, 2011 9:55 AM
> To:
> Subject: Call for consensus on longdesc change proposal
> Dear HTML A11Y TF:
> Please read the longdesc change proposal, which Laura has agreed is now 
> stable:
> A lot of work has been done on this; thanks to Laura and others that have 
> contributed.
> We will discuss consensus on this in the Text Alternatives Sub-Group call 
> on Monday 16 May.
> Thanks,
> - Judy
> --
> Judy Brewer    +1.617.258.9741
> Director, Web Accessibility Initiative (WAI), World Wide Web Consortium

Received on Tuesday, 17 May 2011 21:38:35 UTC