Rebuilding The Web

Articles, advocacy, discussion and debate about the many problems of the Web and the challenges of rebuilding it.

An offer to the HTML5 team to save longdesc

To the dismay of many accessibility experts and advocates, the longdesc attribute has been dropped from the HTML5 spec because this feature is not popular. Despite its lack of use, this feature has the potential to improve Web accessibility if used and used correctly. So in the interest of making the Web more accessible, I would like to make an offer to the HTML5 team to save longdesc.

Why is the longdesc attribute unpopular?

The longdesc attribute is not used as intended because the longdesc attribute and the related alt attribute are poorly defined in the HTML specification. Consequently, derivative works such as articles, references and tutorials propagate the incorrect use of these features. Influenced by such works, browser and tool vendors then implement these features improperly and inconsistently.

As an example of this, the following screen shot shows the lackluster support that we at XStandard have given longdesc by allocating to it a text field with a label that few content authors understand how to use. This approach simply does not make sense to content authors, who will not want to write two image descriptions if the only difference between the descriptions is their length. Other tool vendors have presented longdesc in the same way. This approach is clearly inadequate and will do nothing to encourage content authors to use longdesc correctly.

Screen shot of an image properties dialog box containing a single line text field control with a label 'Long description URL'.

What are the choices available to authoring tool vendors?

1. Do nothing. Leave the longdesc user interface as is - labeled according to past specs/guidelines and consequently meaningless to content authors.

2. Comply with the HTML5 spec and remove the longdesc from user interfaces.

3. Ignore the spec and build interfaces based on what each vendor thinks the function of longdesc is and how it should be presented.

What is our offer?

You, the HTML5 team, claim to develop features that vendors promise to implement. So here is our pledge, as a tool vendor, to the HTML5 team:

  • if you reinstate the longdesc attribute
  • if you define the content that appears in the alt attribute as "textual substitute" for an image, and content appearing in the longdesc as a "description" of the image
  • we at XStandard will build a user interface for longdesc that will actually encourage content authors to use this feature and use it correctly.

What might this interface look like? It might look as shown in mock screen shots below. Note that the longdesc user interface does not have to be limited to a single line text field. In the first screen shot below, content authors can create / edit a document that the longdesc points to. The authoring tool can interface with back-end systems to read / save the content entered by the author and save the appropriate URL into the longdesc attribute.

Dialog box labeled 'Image properties' contains an image of a graph, a drop down list box labeled 'Description location' with the value 'Below' and a WYSIWYG editor control labeled 'Describe what is in the image' containing a table.

Alternatively, the content author can select to manually enter a location (URL) where the longdesc can be found:

Dialog box labeled 'Image properties' contains an image of a graph, a drop down list box labeled 'Description location' with the value 'A document on the Web' and a single line text field labeled 'URL' containing a URL.

Or the content author can select or browse for files that contain the image description in a repository such as the file system or a library managed by a CMS.

Dialog box labeled 'Image properties' contains an image of a graph, a drop down list box labeled 'Description location' with the value 'Library' and data grid control labeled 'File containing image description' containing selected file.

In cases where the image description resides within the document being edited, the content author can select the section heading under which the image description is to be found.

Dialog box labeled 'Image properties' contains an image of a graph, a drop down list box labeled 'Description location' with the value 'Within this document' and a listbox control labeled 'Document section'.

The screen shot mockups above are just a few examples of how user interface design can be applied to make the longdesc attribute meaningful, and appealing to content authors.

Will you join us?

I am calling on other authoring tool vendors to join us in pledging to make the necessary effort required to extract the obvious potential of longdesc, to make it meaningful to content authors, and easy to use. So let's hear from Dreamweaver, Expression Web, KompoZer, CKEditor, TinyMCE, and all the rest.

I also call upon accessibility experts and advocates not to take the dropping of longdesc lying down, but to pledge that, if the HTML5 team will reinstate and fix the definitions of alt and longdesc in the spec, you will educate, promote and do your best to make sure these features are used as the spec intended.

Conclusion

Through better user interfaces and education, tool vendors and accessibility experts/advocates can together make the longdesc attribute fulfill its potential and make the Web more accessible. The HTML5 team must reinstate the longdesc attribute, define content that appears in the alt attribute as "textual substitute" for an image, and content appearing in longdesc as a "description" of the image. The vendors of XStandard will then build a user interface for longdesc that will actually encourage content authors to use this feature and use it correctly.

To the HTML5 team I say: Let's work together with tool vendors and the accessibility community to make the Web more accessible.

Public comments

1. Posted by Leif Halvard Silli
on Thursday 2010-09-30 at 16:01:16 PST

I agree that it is smart to see the @alt as "textual substitute", but I'm not sure if it is smart to link the willingness to support @longdesc to that specific interpretation. I like "textual substitute" primarily because that interpretation allows both a useful and flexible interpretation of what @alt should be.

2. Posted by mattur
on Thursday 2010-09-30 at 16:59:58 PST

> "..the longdesc attribute has been dropped from the HTML5 spec because this feature is not popular..."

I don't think that statement is entirely accurate. The Working Group Decision on longdesc [1] provided a full explanation of how the decision was reached:

--begin quote--
[...] a number of proponents for various proposals did so after stating a number of concessions:
# relevant only to a fraction of images
# use, even among those pages, is relatively limited
[...]
None of these are decisive. There are people who strongly support each of these proposals even after taking these facts into consideration.
[...]
The strongest argument against inclusion was the lack of use cases that clearly and directly support this specific feature of the language. The fact that longdesc has little observable uptake amongst users reinforces this: all the evidence indicates that users don't see this feature to be compelling, and the lack of user demand has been noticed by implementors.
--end quote--

[1] http://lists.w3.org/Archives/Public/public-html/2010Aug/att-0112/issue-30-decision.html

3. Posted by Web Axe
on Thursday 2010-09-30 at 17:35:00 PST

Great article, and thanks for taking the lead on the part of HTML tool vendors. In addition to awareness, a major reason why longdesc is barely used is lack of proper support by HTML development tools, as you point out. I agree that longdesc needs to remain in HTML5 until a similar, programmatic solution is in place.

4. Posted by John Foliot
on Thursday 2010-09-30 at 18:18:44 PST

Hi Vlad,

I am glad to see you challenging the HTML WG to re-instate @longdesc into the spec, however I concur with Leif that linking willingness to support @longdesc to a specific interpretation of @alt can be counter productive. These issues, while related, should be dealt with separately. It might also be too late (but still worth a try).

I find it interesting that @mattur (Matthew Turvey) judiciously edits the chairs response to the @longdesc Straw Poll by only inserting the facts he wants people to know. I also find it interesting that despite being eligible to participate in that Straw Poll, he did not bother to: http://www.w3.org/2002/09/wbs/40318/issue-30-objection-poll/results - see #261 in the list of non-respondents. For all his alleged expertise on this topic, when it came to actually participating in the process he remained remarkably silent. What he also fails to mention is that numerous use-cases have in fact been presented, as well as examples of usage and implementation in the wild since this decision was made. He also avoids noting that there is at least one Formal Objection at the W3C (with likely 1 or 2 more on their way) - the net effect being that the current status of @longdesc today rests with the director of the W3C - Tim Berners-Lee. He can continue to run around spreading his brand of WHATWG propaganda and FUD, but those most closely associated to this contentious issue are aware of the actual facts, and generally dismiss the FUD for what it is.

Mr. Berners-Lee is now the final arbitrator (as per W3C Policy) of @longdes's fate and I believe he is smart enough to weigh up all the facts and make an informed decision; he does not require Mr. Turvey's interpretive skills to reach that conclusion.

5. Posted by mattur
on Friday 2010-10-01 at 03:47:56 PST

No one is that stupid, John. Come on. It's Sir Tim Berners-Lee, not Mr.

Also, a link to these "numerous use-cases" that clearly and directly support the longdesc attribute would be great! You can find out what a use case is here: http://en.wikipedia.org/wiki/Use_case

Example usage of the longdesc attribute is not sufficient, because more accessible ways of providing a link to a long description already exist, as the W3C demonstrate here: http://www.w3.org/Consortium/facts#history

6. Posted by Cliff Tyllick
on Friday 2010-10-01 at 07:11:15 PST

In a nutshell, Mr. Turley, the many use cases stem from this: Images carry three kinds of information, and not everyone needs all three kinds. People who can see the images can quickly, and almost unconsciously, decide which of those types of information they wish to process. Without alternative sources of the same information, people who cannot see the image can't even tell what information it's conveying. And if we provide alternative means for conveying that information, people who must rely on those means need a way to tune in to the information they want and tune out the information they don't want.

The three kinds of information conveyed by an image are:

- Meaning. Many people want to know only this information about an image. To me, the best place to state the meaning of the image is in the image's alt attribute. This gives the alt attribute a purpose somewhat more refined than "textual substitute." It should go without saying that if an image conveys a meaning, anyone who cannot see the image should be able to get access to its meaning.

- Role. What is that image doing on the page? People with moderate low vision tell me this is important to them. They can almost see an image, but they can't make it out. Is it important to spend time enlarging and examining the image until they can figure that out? If they could quickly check and see whether the image is a bullet, a logo, a decoration, or a mood-setting device or if the image has yet some other purpose, they could quickly decide how much or how little time they should devote to it.

- Description. How would a person who can see this image describe it? The use cases for needing to know only the description of the image are many. Perhaps the person with limited sight is participating in a discussion with people who can see, and needs to know which photo on the page shows a woman in a striped shirt because that's the reference point that was just mentioned. To accommodate this need requires a single, unambiguous method for saying, "This is what this image looks like."

And yes, there are many different ways these needs could be met — but not a clear, single way so I can be confident that, regardless of the page I'm on, and regardless of who coded or designed it, if they used HTML5 as it was intended, I can rely on doing one specific action to get the information I need.

And the use case for needing this to be inherent to HTML5 is simply this: Many people who put content on the Web have training in nothing more than html. If you call any technique by a different name — whether it's Java, AJAX, or ARIA — they will not learn it. So if the means for attaching this information to an image is not within html, they won't use it.

For the people who need to retrieve it and the user agents that will programmatically help them to retrieve that information, there must be an unambiguous way to convey all the information an image may carry.

For the people who haven't the time or inclination to learn more than html, that way must be intrinsic to html.

Oh, one other thing: The method cannot interfere with a designer's needs, either. Many of your proposals do this by suggesting that the image itself become a link to its description. That obviously can't always work, because many times the role of the image is to link to other information.

For those reasons, every alternative you've proposed in discussions with me fails. And it's shocking to me that anyone involved in meeting the needs of people to communicate electronically would describe a good-faith effort to meet a real need as "incredible," as you did in your tweet linking to this article.

7. Posted by skeptical
on Friday 2010-10-01 at 10:25:52 PST

> Mr. Berners-Lee is now the final arbitrator (as per W3C Policy)
> of @longdes's fate and I believe he is smart enough to weigh up
> all the facts and make an informed decision;

He is smart enough to make a good political decision. Perhaps it will go like this:

Opening: Accessibility is our highest priority.

Bad news: @longdesc is out.

Empty promises: Resources to be dedicated to find better alternative solutions in the future.

Closing: We are all on the same team. And W3C is the best place to develop standards. And accessibility is our highest priority.

8. Posted by mattur
on Saturday 2010-10-02 at 15:01:26 PST

Cliff:

> "And the use case for needing this to be inherent to HTML5 is simply this: Many people who put content on the Web have training in nothing more than html.

That's an argument for making HTML features accessible-by-default, wherever possible.

> "If you call any technique by a different name — whether it's Java, AJAX, or ARIA — they will not learn it. So if the means for attaching this information to an image is not within html, they won't use it."

That's not a use case. It's an assertion (which may well be true, or not). But we know that even people that do have the time and inclination to learn HTML often end up using longdesc wrongly [1] or not at all, even though it is "within" the HTML4 spec and has been for 13 years.

So imho your point applies to AT-specific markup generally, rather than being dependent on which particular technical document the markup is defined in, or what it's called.

> "[A link on the image] obviously can't always work, because many times the role of the image is to link to other information."

imho putting 2 links on one element is an anti-pattern that immediately introduces ambiguity and confuses users (and authors). The W3C PFWG should have stopped recommending it [2] years ago.

> "The method cannot interfere with a designer's needs, either."

Accessibility requirements impose constraints on "designer's needs" (you mean preferences) e.g. use of colour [3] Good designers work within those constraints.

[1] http://www.w3.org/html/wg/wiki/ChangeProposals/LongdescConformingWithWarning#Longdesc_shows_many_signs_of_being_problematic_in_practice

[2] http://www.w3.org/WAI/GL/WCAG20-TECHS/H45.html

[3] http://www.w3.org/WAI/WCAG20/quickref/#qr-visual-audio-contrast-without-color

9. Posted by John Foliot
on Sunday 2010-10-03 at 00:50:47 PST

@mattur
Use Cases:
Overview: "Use cases describe system behavior from an actor's point of view as scenario-driven threads through the functional requirements."
- http://en.wikipedia.org/wiki/Use_case

Actor: Web Design and User Interface team

System Behaviour: Provide a longer description / textual description of a complex graphic. The visual design of the containing page cannot repeat the text contained in the image, nor any other text or redundant links due to design and/or marketing requirements.

Scenario: "@Mattur – I have no qualms with other people using hyperlinks where they desire to provide alternate text. However, as a designer, I object to being told I must use those links myself. As you’ve pointed out on Twitter, the current design of the comic page would certainly support a hyperlink wrapping around the comic. However, my upcoming design already has functionality mapped to clicking the comic, and won’t have space for a large “transcript here” hyperlink sitting around in plain sight (which would be distracting for the 99% of my users that are sighted). In that scenario, longdesc can and does serve my needs." - http://www.cssquirrel.com/2010/08/16/comic-update-alone-in-the-pitch-black-dark/#comment-32126

Mr. Turley can continue to pretend that he doesn't know, understand or acknowledge that some authors need a means to provide a link to a long description that is NOT a visual link, is not an IDREF to text on the same page, and cannot be linked by wrapping an ANCHOR link around the image, but he's been told, shown, and had it explained to him on numerous occasions. However, he steadfastly remains nothing more than a propagandist for the WHATWG editor, who has decreed that LONGDESC is "harmful" (despite the overwhelming contradiction of the majority of web accessibility professionals), and as we've recently discovered, the WHATWG editor still has no clue as to the real needs of users with disabilities: http://www.w3.org/Bugs/Public/show_bug.cgi?id=10642#c7

LONGDESC is being used properly today, is a valid HTML 4 attribute, is a viable choice (amongst many) that is supported by the majority of screen reading software, and, when used properly, provides a needed and useful solution to a real problem. Removing this option for providing extended text associated to complex images does not 'improve' accessibility, it simply reduces the number of options available to content authors. How can that be a good thing?

10. Posted by mattur
on Sunday 2010-10-03 at 09:36:58 PST

> "...some authors need a means to provide a link to a long description that is *NOT* a visual link..."

Text alternatives should also be available to people who are not visually impaired/using screen readers. See WCAG2 SC 1.1.1 "Text alternatives may help some people who have difficulty understanding the meaning of photographs, drawings, and other images" [1]

And CsSquirrel *already* provides a non-visual text link (hidden by CSS) using aria-describedby in addition to the longdesc on each comic page (check the source).

AIUI, what Kyle is proposing for his redesign will conflict with Jaws' method of accessing the longdesc link [2], so he can't rely on using longdesc to provide accessibility in this scenario anyway.

> "LONGDESC [...] is supported by the majority of screen reading software

But not all screen reading software [3],[4],[5] and not all browsers [6] so that's an accessibility problem. And not everyone who could benefit from a long description knows who to access the longdesc, so that's another accessibility problem [7]

Longdesc is harmful because some folks will use it without an explicit link, thereby locking out people with/without disabilities [8]. Accessibility techniques are supposed to remove barriers to access, not introduce new barriers.

[1] http://www.w3.org/TR/UNDERSTANDING-WCAG20/text-equiv-all.html#text-equiv-all-5-head
[2] http://www.rnib.org.uk/professionals/webaccessibility/wacblog/Lists/Posts/Post.aspx?id=23
[3] http://www.nvda-project.org/ticket/809
[4] http://twitter.com/#!/jcsteh/status/22837891244
[5] http://twitter.com/#!/jcsteh/status/22846777780
[6] http://twitter.com/#!/HTML_longdesc/status/20988570180
[7] http://twitter.com/#!/ezufelt/status/21354331282
[8] http://twitter.com/#!/jared_w_smith/status/20896884330

11. Posted by Rob
on Sunday 2010-10-03 at 11:34:36 PST

>current status of @longdesc today rests with the director of the W3C

Does anyone know when Tim Berners-Lee is expected to rule on the fate of LONGDESC?

> But not all screen reading software [3],[4],[5] and not all browsers [6] so that's an accessibility problem. And not everyone who could benefit from a long description knows who to access the longdesc, so that's another accessibility problem [7]

Matthew (@mattur), I'm trying to understand your argument. Are you saying that lack of support and know-how for LONGDESC is an accessibility problem and therefore LONGDESC should be removed from HTML? If this is what you are saying, then this is a flawed argument. Applying this logic, new elements and attributes should not be introduced because lack of support and know-how. Many more existing elements and attributes should be removed because of lack of support and know-how. Take elements like DFN, VAR, KBD, CITE and SAMP that suffer the same problems as LONGDESC. How about Q and BLOCKQUOTE? I bet less then 0.1% of all web pages use DL - should this element be removed as well? I think people use EM and STRONG when they really intend to use I and B - should those elements be removed as well?

12. Posted by Laura
on Sunday 2010-10-03 at 12:10:18 PST

Matthew (@mattur), do you support the value of the alt attribute being displayed visually by default in browsers?

Comments are closed for this article.

Main menu

Check out the a11y bugs project that aims to help browser / tool vendors fix accessibility bugs.