The WHATWG Blog

Please leave your sense of logic at the door, thanks!

The longdesc lottery

by Mark Pilgrim, Google in Elements

Let's talk about the longdesc attribute. In HTML 4, it's defined as a pointer to a long description for a complex image. Anyone can learn how to write a good long description. There's only one problem: virtually no one bothers, and virtually everyone who does bother gets it wrong.

Let's quantify that. In August 2007, Ian Hickson analyzed a sample of 1 billion <img> elements in Google's index. Approximately 1.3 million (0.13%) had a longdesc attribute. That's OK, you say, not every image needs a longdesc attribute. And you would be right. But regardless of whether it's needed or not, it's not being used that often: just over one in a thousand images.

Now let's look at how often the longdesc attribute is actually used correctly. Of course this is a more subjective question, but we can spot some obvious errors. Out of those 1.3 million images with a longdesc attribute, let's subtract the ones where the longdesc attribute...

That knocks out a whopping 1.25 million (about 96%) right off the bat. That's not 96% of all the images on the web; that's 96% of the 0.13% of images that included a longdesc attribute in the first place. And when you take a closer look at the remaining 50,000 (4% of 1.3 million), the results get even worse: links to other images, links gone 404, links to one-line text descriptions identical to the alt attribute, and links to pages that describe the image size but not its contents (Wikipedia, I'm looking at you). Extrapolating back to 1.3 million, that 50,000 shrinks to about 10,000. That means that less than 1% of images that provide a longdesc attribute are actually useful. No more than one in a hundred get it right, of one in a thousand that even try.

Meanwhile, the very people advocating for keeping the longdesc attribute have recently conducted some user testing. That is, testing how well an actual blind person with an actual screen reader can read actual web pages. It turned out that the test subject didn't know that longdesc even existed before the tester told him about it. Can you blame him? 99.87% of the images he'd ever encountered had no longdesc attribute at all. Even if he had known about it, and he had actually stumbled across one, he would still be up against 99 to 1 odds that following it would be worth his time. He has a better chance of winning the lottery.

I'm not saying there isn't a real problem to be solved here. There is. People can publish complex images that require complex text alternatives. Charts, graphs, detailed photographs. Whatever. "A picture is worth 1000 words," and all that. The longdesc attribute is, theoretically, a solution to this problem. But that doesn't mean it's a good solution, and it's certainly not the only solution. We've been living with longdesc for 10 years now, and let me tell you, it's not working out. So can we please get past the grandstanding and start talking about a better solution?

↔

40 Responses to “The longdesc lottery”

  1. Can you give us a glimpse of another solution ? As I understand it, the causes of the problem are :
    – webdesigners don’t care about accessibility.
    – most web designers are not professionnals.
    You can jump on your head and invent any spec you want. Against these, the only solution I can think about is education.

  2. You’re mostly right. But the fact that the longdesc attribute is rarely used (correctly) is not the killer argument against the longdesc attribute. It still can be useful. There are 2 things to say to that theme.

    1. For making the longdesc attribute useful (and known), there needs to be an addition in css. You need a consistend and reliable way to create links out of attributes. So let’s take a virtual example:
    img[longdesc]:after {
    content: url(attr(longdesc),”D”);
    }
    That would do the trick. Of course currently that does not work. But if it would, it would make that attribute useful, and that would still keep the separation of content into html and presentation in css. The content is the url and it is still in the html. The presentation (if or how that content is presented) is in the css. So reworking this aspect is nothing about html but all about css.

    2. There already is a solution for that problem. It is standardized since long time now. Unfortunately it is not supported by the IE. The solution is the object element. According to specification it is not only a replacement for the old embed to embed Java applications, but a general method for including any multimedia content. It is explicitely mentioned that these multimedia content also include images. And the object element offers a standardized way to include any type of alternate content, including other objects including more objects including other objects including…
    So with object you may include the alternate textual (resp. html) content directly or include an external html page or include another object containing another format for the same content or whatever you want. This would completely solve all of the accessibility problems regarding images. Unfortunately the IE is not capable of including images via object. But that is not a problem of a web standardisation organisation, but a problem of the software company producing the browser.

    Summary: There is no need to rework anything here in html. Maybe some reworking in css, and definitely reworking the IE.

  3. While I agree that the longdesc attribute has not been successful in providing a solution to the problem, it has been removed from the draft spec without the spec providing an alternative mechanism. In the spec it is not acknowledged that there is a real problem to be solved. It should at least be stated in the spec that there is a need for a mechanism to explicitly associate an extended description of an image. whether that be the longdesc or some other mechanism is open for debate.

    The use of the phrase “the very people” is misleading as it implies that all the people that are on the html4all mailing list are of the same mind on issues such as the longdesc, which is far from the case.

    “That is, testing how well an actual blind person with an actual screen reader can read actual web pages.”

    love the tone, what’s the point? Individuals (some of whom are on the html4all mailing list) who are making cases for mechanisms to be provided within HTML 5 are providing testing and research to inform their cases.

    It appears that you are implying that these “very people” are arguing from a position of ignorance, when i think that in many cases the opposite is true, for a start a number of them are visually impaired screen reader users, and others that I know of work professionally in web accessibility. I myself worked for 5 years, up until last year, for a blind and low vision service and interacted with professionally and socially and observed visually impaired people using the internet on a daily basis, so in that respect I do have some idea about the issues that these users face. But at the same time do not consider myself to be a “self styled accessibility expert” as has been the derogatory and mocking term used by some to refer to people who are arguing the case for accessibility on the HTML WG.

    Where is the research (apart from the ubiquitous google stats) performed with “actual users” prior to the decisions were made about dropping/changing attributes?

    “It turned out that the test subject didn’t know that longdesc even existed before the tester told him about it”

    Making a case on one persons experience is pretty shaky don’t you think? Besides, where is the requirement that users must know and understand the elements and attributes in HTML in order to access content?

    “So can we please get past the grandstanding and start talking about a better solution?”

    I don’t see how the person you are referring to is “grandstanding” His tone is overly emotive perhaps. I don’t know the person or his organisation or the greater context in which this was written.

    As far as a classic example of grandstanding is concerned it is hard to go past your own remark on this blog from a few weeks ago:

    “Hi, I’m Troy McClure. You may remember me from such classics as “Dive Into Accessibility”

    So taking up your last point to “start talking about a better solution?” why didn’t you avoid the rant and start this post with that premise and provide some examples of possible solutions?

  4. You should also filter out the results from tutorials which talk about the proper usage of logdesc – this will further reduce the .13% figure.

  5. Obviously, longdesc sets the barrier for the web authors too high: 1 of 100,000 is a crushing vote. I suppose it would be easier if longdesc an image could be in the same page, but delivering two alternative descriptions is simply not what you want to do as a web author. The best solution I ever heard is that of XHTML2: Take an element – say, <p> -, add an src attribute and the alternative text including the usual child elements goes into the content.

  6. The statistics you cite a just a mess. Before even collecting or analyzing statistics such as these its important to also understand how browsers work. Many browsers do not provide a mechanism for users to traverse or load the document fragment pointed to by the lonagdesc attribute. This means that any conscientious web designer will typically need to provide a link to the longdesc as a fallback mechanism until one day when browsers actually implement this piece of HTML 4.01 from 1999.

    So this means eliminating the cases where the longdesc URI “is the same as a parent link’s href attribute (i.e. the longdesc is redundant because you could just follow the image link instead)” is misguided at best. This is not necessarily an error. It would be an error if all browsers supported longdesc, but they do not.

    Also eliminating longdesc that “points to the page you’re already on” is very strange, especially considering problems the current HTML5 attempted to address with changes to the ‘alt’ attribute. One of the issues recently addressed by the draft was that many images are illustrative of the text content within a document. The draft strangely decides the way to deal with that is to remove the alt attribute from an IMG element. However, a longdesc pointing to the page the image is contained in could very well be authors attempts to address the same issue. Sure it’s not an approved method of saying an image is illustrative of the page’s text content, but it’s much more reasonable
    than the proposal in the current HTML5 draft to omit the alt attribute to send that message.

    Finally, the very idea that this attribute should be eliminated because it hasn’t been used much or hasn’t been used correctly is just bizarre. There may be many reasons a facility in the language isn’t used much. Many authors will simply ignore the elements and attribute they have no use for and so maintaining something as important as accessibility features even though many authors aren’t using them is an easy and costless thing to do. Also if authors do not understand how to use a feature of HTML, it may mean the feature is too complicated. In this case it is much more likely that it is because it isn’t easy or even possible to test how the feature works in existing browsers. Once that issue was fixed we should revisit the issue with HTML6 and see how longdesc is doing then.

  7. Rob, there’s still several more years until HTML5 reaches CR and even begins getting widely used. So you still have plenty of time to try and get browsers to implement it in a way you think would be useful and demonstrate that authors can and will use it properly. Until such time, there is little point retaining an existing feature that doesn’t work in practice under the misguided assumption that it will eventually.

  8. I also thought it was really interesting that during the user tests for @longdesc my friend and colleague Stuart (who is the star of the tests) made that comment about @longdesc, that he didn’t find it useful. But just for a sense of perspective, that was his subjective opinion based on his experience of using the web.

    I agree that @longdesc is not ideal, but it currently works well and is supported by the most popular screen readers, like JAWS. I guess, when a better solution comes along we can go for that by all means. However, that is what I would like to see, a better solution that has broad user agent support that is easy to use for blind and visually impaired people, or even others who may get some use out of this functionality.

    BTW Stuart also commented as the tests went on that in many contexts @longdesc would be very useful. My concern, is that @longdesc is potentially being dropped from the HTML 5 specification on the basis of spurious statistical analysis and the argument that it is an edge case attribute.

    In truth though there may be only a relatively small percentage of web users who find it useful certain aspects of the web would be far more inaccessible without it.

  9. Lachlan Hunt writes:
    “Until such time, there is little point retaining an existing feature that doesn’t work in practice under the misguided assumption that it will eventually.”

    Part of what HTML5 seeks to do is provide more explicit guidance to implementors of browsers and other UAs. If HTML5 does so, I see no reason why this feature wouldn’t work as expected.

    What assumptions or logic are you using that lead you to the conclusion that this feature cannot work. I just don’t see it being a problem. So I’m not sure why you would want to make any misguided assumptions, one way or the other. What evidence is there that this feature wouldn’t work to associate a document fragment with a long description with a void image element?

  10. Rob, I didn’t say it wouldn’t work. I said it currently doesn’t work in practice and it’s wrong to simply assume that it will eventually. It is theoretically possible that it can work, and we’re looking for evidence to show that it either can or does work, but the current evidence suggests otherwise.

  11. The problem, as I see it, is that img is an empty element. Had it not been, both longdesc and alt could be replaced with inline content, as advanced as anyone could ever grok their HTML to be. But since img is an empty element and probably always will be, the best solution is to ditch it alltogether and move over to object or something similar that allows for inlining replacement content that degrades gracefully and can be as complex as the author wants.

  12. First of all thanks to Hixie for providing the stats – unfortunately (and predictably) this approach leads to the usual counter-claims that these are just data without any real implications for users of screen readers. Unfortunately (and predictably) the opponents don’t (can’t?) supply any data on the benefits of longdesc either (where »It’s in the spec. so we must use it« does not constitute a benefit), so I’d like to provide you with some real world data.

    Let me first give you some background info: I am working on a site http://www.einfach-fuer-alle.de/ run by a large german charity, Aktion Mensch. The site has been around since ca. ’99/2000, the main topic is obviously web accessibility, tutorials, lobbying / awareness-buildig and such. Aktion Mensch is also hosting a yearly high-profile competition, called the BIENE awards for the last 5 years. I am also working on the advisory council for the awards, where we developped and refined an immensly complex ste of accessibility. So, without grandstanding, I can safely establish that I know what I am doing. Also, we can safely assume that the sites I am working on have an above average audience with some form of handicap or another, since they are run by a charity that actively tries to engage PwD in the discussion concerning all matters related to web accessibility.

    At »Einfach für Alle« we have been using the longdesc-attribute since the very beginning on select images such as charts, other graphical representations of data and on complex images such as screenshots in the tutorials. And yes, we’ve been using them properly (e.g. longdesc=”foo.txt” or longdesc=”bar.html”). When checking the server logs, we found that these longdescriptions recieved very, very little to no measurable traffic (based on traffic data from the last 7+ years).

    So we decided to test this a couple of years ago (I would have to dig through the backup tapes, but IIRC it was around ’03/’04) and replaced the descriptive texts with some generic message. This message basically said something like »You came here via the longdesc-attribute of an image. We’d like to hear from you if you find this way of supplying alternative textuseful and if you usse it on a regular basis on sites that employ those attributes. Please send an e-mail to…«. Feedback: none.

    Next we collected all the longdesc attributes and changed their value to one single URI, so that they are all pointing to http://www.einfach-fuer-alle.de/longdesc/generic.txt
    In all those years the client recieved one single e-mail based on this text. Again: one. single. e-mail. And this even came from a blind visitor who does accessibility testing for a living (it said something like »Heh, gotcha!«). We check the stats on a regular basis and (filtering out bots) the traffic on those longdescriptions is essentially: zero.

    If this isn’t enough to convince the audience: the BIENE awards test is widely considered as the industry standard for checking the accessibiliy of large web sites here in Germany. It consists of four different stages (automated testing, expert evaluation, user testing, jury) with a strong emphasis on user testing. Since 2003, a total of 1,100 web sites were entered into the competition. Out of these 1,100, ca. 100 sites made it to the stage where they were tested by real users with just about any form of disability you can think of.

    Most of these sites were not simple WordPress installation with the default theme, but extra-large sites like state portals and parliaments, health insurances, the upper chamber of the federal parliament, the german federal reserve bank, the german Bundeswehr, Postbank Online-Banking (the largest bank here in .de and so on (see http://www.einfach-fuer-alle.de/award2006/preistraeger/ for a complete listing of awarded sites).

    Quite a few of these sites do use longdesc on select images. During user testing (again, not limited to, but including the proverbial »blind user with JAWS«) we could not find a single instance where a user followed a longdesc (or a D-link for that matter). There were instances where the evaluators pointed users to a longdesc and asked them to explore these, but we can draw the safe assumption that the very users who would supposedly benefit the most do not use longdesc.

    Conclusion: I’m sorry folks, but I’m afraid you will have to come up with something else other than longdesc.

    (I’m not a HTML WG participant, so if anyone wants to copy this to the appropriate lists, please do)

  13. lachaln wrote:
    “we’re looking for evidence to show that it either can or does work, but the current evidence suggests otherwise.”

    It does work for the major screen reading software, it has not been used well by authors in the majority of known cases. Modifying it to be more useful in UA’s other than screen readers is a possible solution.

    Many new elements and attributes have been added in HTML 5 as well as current ones being changed. I presume that not all of these have been implemented in a UA? And the evidence that they either can or will work as proposed is not yet available. If so why can’t current attributes such as longdesc be kept in the spec with proposed improvements. If they are part of the spec it is much more likely that will be implemented by UA vendors and consequently have a chance at being used.

  15. Hi Lachlan, yes just read that, a pretty compelling piece of evidence about the failure of longdesc in its current form to provide useful information to users who may need it. But that does not take away from the need for a mechanism to provide extended descriptions of images for those that cannot understand the information contained within a complex image, as mark states:

    “I’m not saying there isn’t a real problem to be solved here. There is”

    So why not clearly provide an indication of this in the spec, it is provided for many other issues. And why not start from the basis of providing improvement to the current implementaion as has been done in other cases such as the menu element.

  16. Steve, the spec already states:

    Big Issue: There has been some suggestion that the longdesc attribute from HTML4, or some other mechanism that is more powerful than alt=””, should be included. This has not yet been considered.

    What more does it need to say? There are several alternative solutions for providing alternative content documented in the wiki and discussed on the list. e.g. rel=longdesc, using <object> with alternative content nested within, the proposed <alt> element, etc.

  17. It is nearly impossible to get any traffic out of the longdesc attribute. No user Agent supports it. So the attribute and its value are simply sitting around without any benefit for the user.

    But that is not a problem of the attribute itself. It is a problem of _presenting_ the attribute value in some way to the user. The only known (to me) method of adding some kind of presentation for that attribute is via the longdesc extension for the firefox. But even then you actively have to try (right-click on the image, see, if there is a longdesc attribute, and if yes, klick). So if you do not have Firefox _and_ this extension _and_ actively search for that attribute you won’t ever notice its presence. So why is anyone surprised that this attribute is virtually unknown? You won’t ever notice what you cant see/feel/smell/taste/whatever. Make it usable by the user and it will be known.

    But presenting whatever is not the task of hml, this is the task of css. Just keep in mind the separation of content and presentation.

    Just to give an example: If you include an empty link on a web page, it would not be recognized, would not be clickable and thus not be usable until you make it somehow visible (via css). Would you then think that the a element is obsolete because it’s not usable?

  18. Yes Lachlan I am aware of this. It clearly indicates that before removing the longdesc that an alternative mechanism or how to improve the longdesc to make it do the job it was intitially meant to do, was not considered.

    While it states that there has been “some suggestion” that a mechanism “should be included” it does not state that there is a real problem that needs to be solved and that a solution will be provided. The wording is equivocal to say the least. The use of the term “some suggestion” clearly implies that the idea lacks merit in the authors view.

    It is interesting to note that the only times the phrase “some suggestion” or indeed the word “suggestion” has been used within all of the “Big issues” in the spec is in reference to the longdesc and headers issues…

  19. Siegfried, the longdesc attribute is supported by assistive technology, such as JAWS.

    Steve, I think you’re trying to read between the lines too much. There are lots of issues and suggestions that have not yet been considered and most of them don’t even have big red boxes pointing them out in the spec. Some are listed within comments in the source code of the spec, many listed in the issues list and/or on the HTMLWG wiki.

  21. Thank you Troy McClure for outlining the problem. Thanks as well for some constructive suggestions on how to improve the current situation… oh, wait, sorry, I take that back.

    Repeatedly, the HTML5 WG have said that what we need to do is state the problem, and then find the solution, rather than pretend that existing solutions are the end-all and be-all. Fair enough.

    Problem: Many content creating entities are mandated, by law, by social responsibility, or by desire (believe it!) to ensure that all users are delivered equal or equivalent (if different) access to information. They may be governments, they may be educational institutions, they might be non-government organizations that service specific communities, they might be large multi-national companies who have either gotten the religion, or are simply trying to ensure that they remain competitive in a market place that is now starting to come to the realization that “accessibility” has some commercial currency; they, like their constituents, are varied and diverse.

    These organizations will invariably be using sophisticated images as part of their overall online presence. Because of this, there is a requirement to ensure that “the picture that is worth the 1,000 words” has, in fact, those 1,000 words. Because of this, we require a means to supply this: ideally this means would be seamless, transparent and scalable – it must also be unobtrusive when not needed, but readily available *when* needed. (The “D-Link” was doomed from the onset because it interfered with the acknowledged need of graphic design needs… it was, frankly, ugly.)

    This then, in basic, non-technical terms, is the problem. What is the solution?

    So far, what we have is an HTML attribute called LONGDESC. That it is poorly used, certainly mis-understood, and until recently had poor to little support even from within the Adaptive Technology sector is a serious problem. That even the community it seeks to most significantly benefit (the visually impaired) are uninformed and unaware of the enhanced accessibility it affords them is sad as well – this too is a problem. However, is that the fault of the attribute itself, or does the blame lie somewhere else?

    Most importantly however is the fact that in light of current problems, the apparent solution is to simply abolish LONGDESC. Advocates within the accessibility community are waiting to hear what, exactly, will be used to replace it? There is a problem (stated above), but to date no concrete alternative solution has been put forward… instead what we have is a giant void – a gapping vacuum where there was once an imperfect solution. To many, this is a regressive step and hardly a progressive move forward for the next generation authoring language.

    Much electronic ink has been spilled over the past months concerning the “paving of cowpaths”. There exists today, a statistically small but none-the-less existent “cowpath” of appropriate usage of LONGDESC. To be sure, the path is faint, but it is there. Until such time as a better solution can be put forward, the argument for paving and better promoting the LONGDESC path should be kept in place within the Draft Specification. Failing to do so is potentially criminal and could very well stand in the path of universal adoption of HTML5 upon its release.

    And so the problem remains, as does the question: if not LONGDESC, what?

  22. > Thank you Troy McClure for outlining the problem.

    > instead what we have is a giant void – a gapping vacuum where there was once an imperfect solution

    > Failing to do so is potentially criminal

    You asked us to do research, and we have done research. You asked us to provide current statistics on longdesc usage, and we have provided statistics. You have responded with name-calling, grandstanding, and hyperbole.

    I can not begin to tell you how much you are hurting the very people you claim to represent.

  23. tomas, is that a failing of longdesc, or a failing of user agents who don’t notifiy/present the presence of longesc in a sensible enough way?

  24. A question and a comment:
    You count a longdesc pointing to a URL with a 404 to be a FAIL and an example of how difficult longdescs are to get right — are you first removing all data with a 404 on the image src as well? It seems like it would be a bit unfair if you were including pages in your sample that are so unmaintained that even the images pointed to are broken. But I’m bad at statistics, so maybe doing so is actually more representative of the web-at-large.

    Also, correct me if I’m wrong, but “points to the image itself” and “the same URL as the src attribute” are not the same thing at all, considering Content Negotiation may be at play. The sample data should only be disqualified if the first part (“points to the image itself”) is true, which you can guess at but not be certain about from the second part (“the same URL as the src attribute”), not without re-requesting the URL as textual data.

    That is, you must go back and ask for the image again with a “Accept: text/*” header, or at least remember that it didn’t include a “Vary: accept” header the first time you got the image data (though I’m guessing your test didn’t involve fetching the 1 million images contained in the src attributes and recording the full headers for each).

    I was just playing with this idea recently: a page has an inline img (src=”/images/lion” longdesc=”/images/lion”). If you go to “/images/lion” in your web browser, you get an HTML page with the image (src=”.”) and a description of said image (humorous firefox bug: Firefox tells servers it would much prefer an image/png than a text/html if both are available — after all, rendering HTML is so much work!).

    Tools just don’t really support this very well, though. Servers are hard to configure with correct mime-types (but in their defense, so are filesystems), and also hard to configure when there is a disconnect between a URL and a filename (Apache’s type-map handler lets you do this easily), clients are hard to coerce into requesting an acceptable mime-type (e.g. how would you use wget to download a copy of the lion picture, and would you get an image/jpg or a text/html file?), and what elements support a type attribute in HTML usually get ignored by browsers and always get ignored when constructing the accept header in a request. In the case of OBJECT, on Firefox at least, type is actually better left out — if an object declares its type to be, say, image/jpg, firefox will request the data URL from the server, telling it any type at all will be acceptable, but then refuse to render it if the server returns anything except an image/jpg — allowing the situation where the server has an image/jpg available but is misled by firefox into thinking an image/png would be just as good if not better, and then firefox rejects the entire object.

    Academic of course, since I imagine the chances that any of the 1 million URLs chosen have multiple types behind them is even less than the overall chances that a longdesc is useful. Still, it’s an interesting idea and I hate to see it discounted out of hand and without comment.

  25. John Foliot writes:

    Advocates within the accessibility community are waiting to hear what, exactly, will be used to replace [longdesc]?

    The same technique that is currently recommended by experts within the accessibility community: describing the image in the page text, or linking to a description.

    We recommend providing a text description on the page itself, as this will be useful for all users and not just those with access technology.

    Alt Text, RNIB

    The most straightforward way of making long descriptions accessible is to make them obvious and available to everyone, whether they have a disability or not.

    Creating Accessible Images, WebAIM

  26. Yeah, sorry to be the wet blanket here, but I’m pretty sure the reason why longdesc is scarcely ever used is that it is never needed. WCAG 1.0 mistakenly assumed that you can take an image and treat it like a suitcase you can unpack and repack with more and more words until you get something equivalent to the image. In reality, you just can’t. The true accessibility method for a complex image may be a tactile graphic. (Yes.)

    And besides, I have people complaining that *my* alt texts are too long. Imagine what would happen if I wrote long(desc).

  27. John, it would really help if you spent more time focussing on developing a better solution than complaining about the omission of a broken solution.

    Patrick, it’s easy to speculate about who or what is to blame for the misuse of longdesc. Regardless of whether it’s due to poor implementation, lack of author education, broken by design or whatever else; it doesn’t change the fact that the attribute doesn’t work in practice and it’s not showing any signs of getting better.

    IMHO, for the rare cases that a long description is actually useful, using an ordinary link to the description, or simply including that description in the surrounding prose, is sufficient. The link could be something like “Read our textual description” as used on The Webcredibles or make the image itself a link. I am not suggesting using D-links.

  28. Meanwhile, the very people advocating for keeping the longdesc attribute have recently conducted some user testing.

    That is a bit harsh, and perhaps criticism unfairly pointed at, what looks to be, a newly formed group. This group is badly needed for accessibility to be handled properly in the HTML5 Working Group in some sort of cohesive fashion. Up to now, accessibility issues look to be dealt with by grandstanding, leaving the working group in a huff (only to rejoin), incite flamewars via cross-group posting, and insisting on an ‘expert opinion’ without a factual or scientific justification.

    This group has the chance to rally around real practical experts like Steve Faulkner, Gez Lemon and Patrick Lauke, and start to concentrate on qualitative analysis and researched arguments. Hopefully collaboration can help temper some of the attitudes that seem so prevalent in and around the accessibility issues.

    Good standards are not based on mud-slinging. The Atom Protocol is a great example of that – once the mudslinging had ceased, and the real rational work got started (actual implementations over endless religious debates), and what’s coming out there is real quality. WHAT WG seemed to be the same type of set-up – and its a pity seeing that work being ground down in an HTML5 Working Group.

    Either way, give this new group a chance to prove or disprove itself.

    Now everyone in the HTML 5 Working Group – you are there because you are supposed to be experts of some kind. Could we see more demonstrated expertise and research from this group and less tin-foil hats, please?

  29. Perhaps the W3C Web Accessibility Initiative Working Group and User Agent Working Group could be consulted in an effort to find a solution? Those folks may have insights that would be helpful.

    To ensure that accessibility requirements are addressed and improved and not bypassed and abandoned, don’t hesitate to ask for guidance.

    The HTML 5 WG’s charter says:

    “The HTML Working Group will cooperate with the Web Accessibility Initiative to ensure that the deliverables will satisfy accessibility requirements. Coordination with WAI will be primarily conducted through the Protocol and Formats Working Group, but direct coordination with other WAI groups, such as Web Content Accessibility Guidelines Working Group and User Agent Accessibility Guidelines Working Group, will also be done when appropriate.”
    http://www.w3.org/2007/03/HTML-WG-charter.html#wai

  30. lachaln wrote:
    »By the way, Eric Eggert has provided some more very useful information about the usability of longdesc«

    Please don’t blame Eric for this, all he did is post this info as per my request, since I’m not subscribed to the HTML-WG list.

    steve faulkner wrote:
    Charles McCathieNevile has provided an interesting perspective on the info

    No, he hasn’t. The only thing he did was to misquote what I said. He claims that I said, that nobody (nobody would have been me, since I’m the one doing the markup) ever used longdesc on the site I was talking about. Quite the opposite is true: we do in fact use longdesc on various images, we measured the outcome and found no usage whatsoever for years and years.

    Then he claims that the site doesn’t use any images which would need a long description. Again, quite the opposite is true, as can been seen in a recent tutorial I wrote: http://www.einfach-fuer-alle.de/artikel/barrierefreie-formulare-mit-html-css-und-javascript/formular-design/ . Most of the examples in the section on labels could use some sort of long description since the alt-attribute in this case isn’t the proper place to describe the graphics in detail (too long, no structural elements allowed etc.). Most of the graphics do have some description of their contents in the surrounding text, but as we all know there is no reliable way of »programatically determining« the relation between the two. Simply using longdesc to point to a fragment identifier in the page doesn’t cut it either, since we have enough evidence to prove that no screen reader user ever used longdesc on this particular site.

    Furthermore, he ignores the evidence I had given from hundreds of tests with real users showing that none of them ever bothered to explore the longdescriptions provided by the sites that were tested during the Biene awards.

  32. I did find a good use of the longdesc attribute in my implementation of the Lightbox.js-script. (Sorry, my site is only in Dutch, but the sourcecode isn’t. 😉

    In short it works like this:

    1. The following propercode is used in a post:
    <a href="{photo_src}" title="{photo_title}" rel="nofollow"></a>

    2. The lightbox-script takes care of pointing to the source-page while viewing the bigger image.

  34. Very interesting stats, I have certainly only rarely seen longdesc used, and it has always struck me as a slightly odd solution to the problem. In my experience, much of the data in complex images is graphical and can be presented in a more accessible way through correctly marked up data tables.

  36. Hmmm. Most countries have statutes against littering. Yet litter persists. Do we then recommend removing all the anti-littering laws, on the grounds that no-one obeys them? (I could have used “murder” here but then people accuse you of getting emotional)

    As others have said, education is the answer, as it was for getting people to use CSS (not finished yet!) instead of tables for layout.

  37. Mark Harris, we’re not removing the ability for authors to provide long descriptions of images when necessary, but the longdesc attribute is not the right solution to that problem. It doesn’t work in practice. It’s better to replace it with something better that will.

  38. Lachlan, I’d advise getting the replacement organised before losing something that currently exists and that some people are using, even if you feel it doesn’t work. It is a specified known method for doing a specific thing which, if used properly, will provide a known result. Encouraging the world and his dog to do their own thing runs the risk of making accessibility harder.

  39. Looks like our work here is done. Frontpage and dreamweaver brings the power of web to 90% the people who can press the start button. We can shut up shop and go home.

  40. Just a tiny sidenote: Dreamweaver — even the newest version CS3 — brings up a dialog box looking for an image when you try to insert longdesc. You can still point to an HTML or text file, of course, but I’m willing to bet that this little problem is responsible for a tiny part of the longdesc misuse. Education of authoring tool makers in addition to authors and browser makers is definitely needed.