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

Re: example spec text for longdesc

From: Laura Carlson <laura.lee.carlson@gmail.com>
Date: Fri, 25 Mar 2011 20:57:24 -0500
Message-ID: <AANLkTi=APerB9n2mWo0WvCrZMRv9X9YobMYgkC94aQDx@mail.gmail.com>
To: Jonas Sicking <jonas@sicking.cc>
Cc: Henri Sivonen <hsivonen@iki.fi>, HTMLWG WG <public-html@w3.org>
Hi Jonas,

Thank you very much for your email and comments. I really appreciate it.

>> What are appropriate way to solve the formal use cases?
>> http://www.d.umn.edu/~lcarlson/research/ld.html#uc
> I would love it if we could actually talk about it this way,

Me too.

> so I'll just take this invitation and run with it.

Thank you.

> First of all it has always surprised me that the list of use cases
> only list discusses adding accessibility information to images. Is
> there a reason things like tables, SVG (and portions thereof), figures
> and forms are left out?

Do you mean that tables, SVG (and portions thereof), figures and forms
are left out as they do not have mechanisms for providing a long

Would it be possible to make longdesc a global attribute? What would
be the pros and cons?

> Also, ease of use seems to be missing from that page. This isn't
> really a use case but rather a requirement.

Longdesc is a link so it is simple in that regard. Ease of use and
simplicity are pretty evident in the formal use case scenarios. For


> However since the page
> seems to be lacking a section for requirements maybe it would be ok to
> list under use cases.
> Would it be ok for me to go add these requirements to the wiki?

Requirements are linked:

But I can flesh that out and add ease of use, etc.

> Once you include these use cases and requirements it seems much less
> that longdesc is a proper solution.
> It's only available on <img>ages
> (this missing all other ways even for including images such as
> <canvas> and <object>).

Yes. Images are what we have been talking about.

> It isn't very user friendly. Lots of people
> seem to misunderstand it to include the actual describing text rather
> than a link to it.

That's where better conformance tool and authoring tool checking along
with more implementation would come in.

> Not only that, but since it is url based, rather
> than id based, it encourages people to put the description in an
> external resource, which more often than not is not what you want to
> do.

Being an external resource is very important in many situations. For
examples visit:

Describing a Logo

Describing an Email Banner

Describing Illustrations

Facilitating etext Image Descriptions Describing etext Images

> It turns out that ARIA already have a attribute that almost fits the
> bill, and this is aria-describedby. As is pointed out on the wiki
> page, the problem is that the ARIA specification only allows exposing
> text content to the user, rather than arbitrary content, such as
> links.
> This problem can be fixed though by changing the ARIA specification.
> By changing ARIA to say that aria-describedby can point to arbitrary
> content, rather than just refer to the textual contents of it, we
> solve multiple problems in one go.
> This would first of all allow aria-describedby to solve all the use
> cases in the wiki, as well as the ones pointed out in this message. It
> also seems to fulfill the ease of use requirement better as people so
> far seems to put an id in aria-describedby rather than the actual
> text.

aria-describedat has been discussed. There are quite a few reasons
that it does not seem workable.

Sean Hayes just wrote up  "Configuring Internet Explorer to Handle
Longdesc" It adds a context menu entry to extract the longdesc
attribute value and have the page navigate to its content.

Jonas, is something like that doable natively in FireFox?

Thanks again.

Best Regards,
Laura L. Carlson
Received on Saturday, 26 March 2011 01:57:56 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:16:11 UTC