Rebuilding The Web

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?