W3C home > Mailing lists > Public > public-html-a11y@w3.org > May 2011

Re: Call for consensus on longdesc change proposal

From: Gez Lemon <g.lemon@webprofession.com>
Date: Wed, 18 May 2011 00:04:13 +0100
Message-ID: <BANLkTik13OBhg9JZEkE6qLtBOWTsq4xkDw@mail.gmail.com>
To: Cynthia Shelly <cyns@microsoft.com>
Cc: Judy Brewer <jbrewer@w3.org>, "public-html-a11y@w3.org" <public-html-a11y@w3.org>
Hi Cynthia,

I am an advocate of WAI-ARIA, and I didn't contribute to the longdesc
proposal, but I have a few comments for your questions.

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

When aria-describedby was first explained to me, my understanding was
similar to your understanding; ATs would have a reference to a target
whereby they could provide a means of allowing the user to navigate a
sub-DOM that described the current object.

In practice, the target provided by the idref is concatenated to the
"description" property in the accessibility API, which means AT users
receive that information as a string of text. This is outside of ATs'
control, so they have no choice but to announce it as a string, rather
than allow the user to navigate the content using reading keystrokes
to investigate rich semantics (which was what I was initially led to
believe would be the case).

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

Semantic elements are better for users than having a long stream of
text announced to them; with semantic elements, the user is able to
control how that content is delivered; with text content, it's
delivered as one long stream.

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


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

The longdesc attribute defines a URI with rich semantics, where AT
users can use reading keys to control how the information is provided
to them; aria-describedby is presented as a string, where the user has
no control as to how it is presented to them. If aria-descibedby was
presented how you suggest (not how it is processed by AT, but how it
is conveyed in the accessibility API), then I would agree with you.
It's not a matter of changing the way AT works, but redefining how
aria-describedby should be presented to the accessibility API - either
a string or a URI; at the moment, it's a string.



> -----Original Message-----
> From: public-html-a11y-request@w3.org [mailto:public-html-a11y-request@w3.org] On Behalf Of Judy Brewer
> Sent: Saturday, May 14, 2011 9:55 AM
> To: public-html-a11y@w3.org
> 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:
> http://www.w3.org/html/wg/wiki/ChangeProposals/InstateLongdesc
> 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.
> http://lists.w3.org/Archives/Public/public-html-a11y/2011May/0359.html
> Thanks,
> - Judy
> --
> Judy Brewer    +1.617.258.9741    http://www.w3.org/WAI
> Director, Web Accessibility Initiative (WAI), World Wide Web Consortium (W3C) MIT/CSAIL Building 32-G526
> 32 Vassar Street
> Cambridge, MA,  02139,  USA

Supplement your vitamins
Received on Tuesday, 17 May 2011 23:04:41 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:55:56 UTC