This document:Public document·Annotated document·View comments·Search comments·Add a new comment·Send replies to comments·Disposition of Comments·
Nearby:HTML Accessibility Task Force
Other specs in this tool
Quick access to LC-2786
There are 5 comments (sorted by their types, and the section they are about).
Forwarding to HTML A11Y TF per Chaals's suggestion.
Group Product Manager, Accessibility
From: Charles McCathie Nevile [mailto:email@example.com]
Sent: Thursday, August 22, 2013 6:00 AM
To: Andrew Kirkpatrick
Subject: Re: longdesc extension question
(this is a good question, and I would love to have it in public - feel free to forward my response...)
On Wed, 21 Aug 2013 00:57:54 +0500, Andrew Kirkpatrick <firstname.lastname@example.org> wrote:
> Hi Chaals,
> I'm looking at the longdesc extension and also a couple of the WCAG
> techniques and have a question. It seems that a key problem with the
> implementations of longdesc today (well, at least JAWS and NVDA) is
> that when you activate the longdesc feature for an image they load the
> page with the longdesc and start reading at the required place. As
> some people are advocating for same-page references or many longdesc
> descriptions on a single separate page this is a problem because JAWS
> and NVDA don't know where the longdesc stops, just where it starts. As
> a result, a user listening to the longdesc for all three images in the
> following example would hear information about "a" once, "b" twice,
> and "c" three times.
> So the question is: Is there anything in the spec that requires that
> user agents read only the content contained within the HTML object
> with the matching id reference?
No, but there is a "should" requirement on authors:
'Authors should put descriptions within an element which is the target of a fragment link (e.g. longdesc="example.html#description") if a description is only part of the target document.'
which is intended to allow for such behaviour.
In general the spec tries to go lightly on requirements for user agents - it was somewhat controversial to require that they actually make the longdesc available to users in the first place ;(
> <img alt="a" longdesc="descs.html#a">
> <img alt="b" longdesc="descs.html#b">
> <img alt="c" longdesc="descs.html#c">
> <div id="a"><p>This is my longdesc for a</p></div> <div id="b"><p>This
> is my longdesc for b</p></div> <div id="c"><p>This is my longdesc for
> Andrew Kirkpatrick
> Group Product Manager, Accessibility
> Adobe Systems
Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex
email@example.com Find more at http://yandex.com
I have an additional suggestion that I believe would help the acceptance of this document within the general working group. Add an informative section detailing several of the many cases where it is inappropriate to use @longdesc. For example…
1. @longdesc is inappropriate when an EPUB footnote is sufficient.
2. @longdesc is inappropriate for Math. Use MathML instead.
3. @longdesc is inappropriate for SVG graphics. Make the SVG DOM accessible instead.
4. @longdesc is inappropriate for graphics of tabular data. Use an accessible table instead.
More examples at http://cookiecrook.com/longdesc/
These should probably be added to the WCAG 2.0 Techniques documents as well.
I'd also add:
5. @longdesc is inappropriate when a normal link is sufficient. Example:
<a href="descrip"><img src="pic" alt="*the purpose of the link*"></a>
In my opinion, 3.0.3 User Agents (UAs) is deficient. While it requires
UAs to make the link available, it arguably does not require anything
more than access to the source code.
My rational is that access to the source code is a regular user
interface. Access to source code is provided in most if not all UAs. The
word 'available' does not specify what we can do with the link or how we
As a result of using the word 'available', I feel there is nothing in
3.0.3 that would compel UAs to make easy access to longdesc links
possible. I feel it needs to be more prescriptive to UAs that everyone
should benefit from longdescs.
I am suggesting a change or addition:
"If the longdesc value is valid, User agents must make the link
actionable or able to be activated to all users through the regular user
interface(s) similar to regular links."
Choose the wording the best describes how a regular link is activated.
A Non-normative example: Add to the context menu of the image a 'Go to
long description' menu item.
I hope my opinion is clear and my goal is entice UAs to make longdesc
readily available to all users. I also hope that you agree with me.
Nice work. I just have a few suggestions:
1. Double-check the consistency of capitalization in "Requirements for an Image Description functionality". Some items have each word capitalized while others do not and then some have different capitalization in different places ("Simple Return" ). My preference is usually for less capitalization.
2. re: the section referencing ATAG 2.0 that is marked with " ISSUE: This doesn't seem a great reference - is there anything better? This is tracked in bug 21501 and its dependent bugs. Unless a proposal for improvement is made and accepted this bug will simply be closed after Last Call."
Right now it points to:
" Implementing PRINCIPLE B.3: Authors must be supported in improving the accessibility of existing content " (http://www.w3.org/TR/ATAG20-TECHS/#principle_b3)
...which is probably too general.
There are other anchors in "Implementing ATAG 2.0" that provide more specific information. This is probably the most specific:
Also, these two sections that explain how checking and repair can range from manual to fully-automated also include relevant descriptive text examples: http://www.w3.org/TR/ATAG20-TECHS/#checking-types
Add a comment.