Comic Update: Alone In The Pitch Black Dark

August 16, 2010

Today’s comic features the chairs of the W3C HTML WG, Sam Ruby, Maciej Stachowiak and Paul Cotton as they and the Squirrel try to deal with the dangers of a cave monster in the dark. You’ll have to take my word for it, however, unless you follow the instructions on the comic to read the transcript. In a reversal of what is the norm, my sighted readers will have to take some extra effort to experience the joke; my visually impaired readers should be able to access the transcript like normal through the longdesc attribute on the comic.

Recently, these three personages made a Working Group decision about the fate of the longdesc attribute which you can read over here. The summary is this: the longdesc attribute, which is a method of serving detailed alternate text for complex images to visually impaired web users, is now obsolete and not a part of HTML5.

So much for backwards compatibility.

Almost a full year ago I addressed the issue of blind web users, encountering the topic on a personal level when I found that my commentary CAPTCHA at the time was challenging for a reader of mine because he was blind. A reader, at a web comic, who couldn’t even see the comics that my commentary accompany. I made a change to the site, setting up transcripts for every comic starting with that one, which can be accessed via either the longdesc attribute or an aria-describedby attribute, both attached to the comic’s image. I’ve been uneven at times in keeping the transcripts synchronized, but every comic since then has that alternate text so you don’t need operational eyes to be in on the joke.

I’m a bit confused to why it’s an issue for non-experts in the accessibility field to constantly be pushing against the presence of accessibility features that pre-exist HTML5 like longdesc. The most common arguments are that it’s largely unused. I know this is true. But that doesn’t seem like a reason to throw validator warnings for those sites that correctly use it for their users (like myself.)

Here’s the validator results for my comic page in HTML5 mode. Mind you, the page isn’t HTML5 yet (I’m really behind on a site redesign), but the one warning that shouldn’t be present is the last one: “The longdesc attribute on the img element is obsolete. Use a regular a element to link to the description.”

Excuse me?

Since when does a validator need to tell me how to design my site? The premise of a link on an a element is plausible (I’ve heard it a million times by now), but it seems to disregard the consequences for sighted users in some design experiences. In the case of the current comic page, I could wrap the comic in a link to the transcript, I suppose. That won’t work in the future design of the page due to interactions that I’ll be adding, however. Furthermore, for many sites, complicated images often have other functionality attached to a link around the image, like loading a larger version of the image or popping open a lightbox gallery. The only alternative at that point is add a separate link by putting an additional element on the page, aka, modify the design based on validation needs.

The fact is, most sighted users don’t want to click on an image description for alt text, because they can see the image. And non-sighted users have access to the accessibility features like longdesc. If a web developer is going to be providing alternative text for complex imagery to the point that he or she would actually create a description hyperlink, why wouldn’t this same person go an extra three inches and just use the longdesc attribute? The premise that a simple hyperlink is somehow more likely to be used is false: lazy people will be lazy no matter what.

I don’t expect this decision to somehow change. Not because I think it shouldn’t. I think it’s an incredibly stupid choice made to please punditry who largely don’t use any sort of alternate text for their sites whatsoever. I just think the issue’s been fought over for so long that those in the position to have the final say will gladly sit on the wrong decision just to move forward.

As a website owner who does make use of accessibility features for my actual blind users, I’ll take my validation error. The code was valid, it does work, and I don’t see any reason to clutter the visual design to implement a less elegant solution.

Respond To This Post

Share This Post With Others: |

Category: Comic | Tags: , , , , , , ,

29 Responses to “Comic Update: Alone In The Pitch Black Dark”

  1. > “like loading a larger version of the image”

    A larger image on an explicitly linked page, with a transcript, is an ideal solution, accessible to all. Would also help users find a particular comic via SE’s when they can only remember a piece of dialogue. Everyone benefits.

    > “or popping open a lightbox gallery”

    May(?) also interact with longdesc. Jaws uses enter key to activate longdesc

    > “And non-sighted users have access to the accessibility features like longdesc”

    NVDA doesn’t support longdesc http://www.nvda-project.org/ticket/809

    > “an incredibly stupid choice made to please punditry who largely don’t use any sort of alternate text”

    WAI CG also recommended obsoleting longdesc http://www.w3.org/2009/06/Text-Alternatives-in-HTML5.html

    For further reading see Tantek’s notes:
    http://wiki.whatwg.org/wiki/Change_Proposal_for_not_including_longdesc

    or the RNIB’s Rise and Fall of Longdesc
    http://www.rnib.org.uk/professionals/webaccessibility/wacblog/Lists/Posts/Post.aspx?id=23

  2. Bravo, sir. Almost felt like I was reading XKCD for a minute there while I figured out how to get to the transcript.

    I love how your comic keeps me aware of happenings like this that I’d otherwise likely miss. I’m sure the WG chairs had their reasons for doing as they did, but I agree, it seems a bit heavy-handed when the only proposed alternative is a nonstarter.

  3. Firefox 3.x; “Image Info”: displays the value of “Long Description”. Unfortunately not as hyperlink, but still.

  4. @Julian – Thanks for that bit of Firefox advice! I didn’t actually know that. *starts right clicking on dozens of images*

  5. There’s also a Firefox plugin you can install that adds a right click menu item to images that have a longdesc attribute.

    https://addons.mozilla.org/en-US/firefox/addon/273/

    Just installed it myself, so can’t vouch for it’s security or stability, but it appears to function as expected.

    As for the HTML5 WG decision to make longdesc obsolete (or whatever they’re calling that now), it’s disappointing, but that’s typical of the sort of nonsense I’ve come to expect from that group. It’ll just get added to my list of “features” to ignore in HTML5.

  6. OK, maybe it’ll help me understand this better if you (or someone) tells me why the ARIA-describedby attribute isn’t a satisfactory way of handling it. As I understand the decision, the near-complete lack of existing examples of longdesc weighed against it in the decision, as dropping it in favor of the ARIA approach would inconvenience very few people.

    This rationale has been used before, in many groups not just the HTML one. If there’s a stronger argument against dropping it that wasn’t made, I guess that underlines the need for more people to speak up *during* the process, rather than doing nothing and complaining afterwards.

  7. Of course you’re familiar with the longdesc lottery?

    http://blog.whatwg.org/the-longdesc-lottery

  8. @we (the coward with no name) Of course you’re also familiar with those that disagree with a collection of sighted 20-somethings too. One of those fan-boys had the nerve to *BRAG* to me this weekend that he’s never used @longdesc, like it’s some kind of badge of honor to go out of your way to exclude the blind. Ya, right, WHAT WG has it all figured out…

    @arlen Let’s not also forget that ARIA *BY DEFINITION* is/was designed to be a bridging solution until a native semantic arrived… you know, like the native @longdesc (which has 1 semantic meaning, and 1 semantic function). So, hey, ya, let’s move backwards to the bridging solution, and bridge a problem that was addressed in 1997. Paving cowpaths indeed.

    At any rate, the first of likely many appeals has been filed: http://www.w3.org/Bugs/Public/show_bug.cgi?id=10017 Read the ground of the appeal here: http://www.malform.no/messages/appeal-issue-30.html (Note: Leif’s English is likely far superior to your Norwegian, but reading though can be a tad tricky if you are unfamiliar with my buddy’s writings. Just go slowly)

    Kyle, thanks for your continued support, and for putting your money where your squirrel is.

  9. I appreciate your point, and I most certainly disagree with the idea of removing accessibility features from HTML5 (even ones that are almost completely unsupported by most assistive technologies), but what about a user who is sighted but physically disabled? Having to type in that URL could be a real barrier to viewing the transcript for somebody who has to blow or suck on a straw to navigate the web and whose assistive technology doesn’t support longdesc because they don’t need it, because they’re physically impaired, not visually impaired.

    Too often “accessibility” is equated with “what blind people need” – this is very far from the truth. Stephen Hawking, if he’s a regular reader, probably won’t bother with this one, which kind of negates the point.

    Sorry if I sound snarky, but there’s a lot more to accessibility than longdesc, and blindness isn’t the only disability that can make the web a hard place to be.

  10. @Arlen, aria-describedby works with fragment identifiers on the same page. @longdesc takes an ID or an URL. Say for example you’ve got a stock chart on a home page. Through longdesc it can refer to another page where that graph is explained in text form (not that unusual to protocol things happening in the life of a public company). A link might be inappropriate or confusing for your sighted users. So longdesc was the only accessible method of pointing to a text on a different page.

  11. @ Nick F.

    …even ones that are almost completely unsupported by most assistive technologies

    Pardon? Many screen-readers today support the longdesc attribute including JAWs, WindowEyes, SuperNove/Hal and others – please be sure of your facts before making such blanket statements. Other assistive technologies (head mice, sip-and-puff switches, etc.) *could* also interact with longdesc if browsers bothered to support longdesc, as those technologies interact with the browsers.

    The longdesc attribute is primarily for non-sighted users, but for sighted users who want to take advantage of longdesc (when authored – more on that in a second) then it is native feature in Opera, and can be made available in Firefox via the longdesc plug-in (https://addons.mozilla.org/en-US/firefox/addon/273/) and has been available since Firefox 1.5

    Of course web accessibility is about more than blind users, and no-one has suggested otherwise. Kyle’s cartoon is pointedly making a point, but no sophisticated image that would require a long description would normally also include the URL of that long description as part of the image. Yes, he *could* have made the link a hyperlink in the page, but for design considerations he didn’t. One of his points is that forcing content authors to conform to a specific series of author choices simply to meet some-one else’s idea of the best way to provide accessibility is wrong: he CHOOSES to use a perfectly valid 10 year old HTML attribute that works exactly the way it was designed to work in user-agents that bother to actually deliver on that spec.

    The problem with longdesc has been fueled by author apathy re-enforced by browsers that have NEVER PROVIDED NATIVE SUPPORT TO THE ATTRIBUTE. Turning that tide is a huge effort, but shrugging and giving up because of years of non-support is simply wrong. Want to blame someone for poor adoption of longdesc, blame the browsers who routinely launch ‘features’ (like, say ) that have no accessibility support, while at the same time ignoring trivial-to-implement support to existing accessibility constructs.

    Stephen Hawking, if he’s a regular reader, probably won’t bother with this one, which kind of negates the point.

    If Mr. Hawking is a regular reader, and is using Opera, Firefox + the plug-in, or a tool like SupreNova, he could access the link in other ways other than typing in the URL. By the same token, if Stevland Judkins (a.k.a Stevie Wonder) was also a regular reader, then he too could access both this cartoon, and all the others that Kyle has bothered to make universally accessible. (And I ask you, how many cartoons on the web today do you think are accessible to the non-sighted? Focus on the bigger picture and not this one cartoon which was consciously made to be less accessible to all but the blind to make a point!)

  12. Oops..

    …who routinely launch ‘features’ (like, say <canvas>) that have no accessibility support, …

  13. Love it :-)

  14. I can understand that a tiny minority of “accessibility advocates” may have a self-interest case for wanting to keep accessibility as a special sauce that only they can provide.

    But let’s be completely clear on this: if you want to provide good accessibility for all, the best approach is universal design, accessible by default, for everyone without requiring special moves or training. You need a damn good reason to not use this approach.

    If OTOH you’re not too bothered about providing good accessibility, but would like to to impress your friends by sprinkling arcane accessibility talismans of questionable practicality through your code, then longdesc is the ideal solution for you. But that’s not accessibility, it’s accessibility theatre.

    Everyone knows how to use a link. Hardly anyone knows how to use the longdesc attribute. So you use longdesc?! Come on.

  15. @Nick – With the exception of this most recent comic, all the comics are made for sighted users and navigable via the previous/next links below the comic. Those links are targetable by the sort of technology a physically-disabled person would use to navigate most links.

    The issue at hand was directed at a piece of technology made for non-sighted users, however, so this comic provided an exception to deal with that specific experience.

    @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.

    Also, are we going to pretend that using longdesc is difficult? Yes, people may use it wrong without some correction, but simply saying “Hey, put a URL there,” is not complex at all, and most of longdesc’s non-use is a lack of awareness or caring (most non-longdesc websites simply don’t offer alt text at all.)

  16. It truly is sad that people like @mattur (who proudly confirms he’s NEVER provided a long description) continue to spread false information and pretend to have *the word* (at the same time simply parroting the WHAT WG party line without spending 2 seconds thinking it through). Mattur claims that everyone knows how to use a link, so let’s go see what the HTML 4 specification says about @longdesc shall we? Follow the link: http://www.w3.org/TR/html4/index/attributes.html

    Name: longdesc
    Related Elements: IMG
    Type:%URI;
    Default: #IMPLIED
    Comment: link to long description (complements alt)

    Yes, that’s right, a LINK to a long description. If you are going to try and inform people, try being sure that what you are informing folks of is accurate. If you use a screen reader like JAWS, SuperNova/Hal or WindowEyes, the longdesc attribute is announce and ‘operated’ exactly like a link. Use a Standards compliant browser like Opera, ‘right-click’ over Squirrel’s cartoon and *gasp* a link is exposed to the long textual description. The real problem is that the majority of browsers can’t be bothered supporting this ten year old attribute – I don’t know why, ask the browser developers why not. But even if those browsers don’t have a native support mechanism for sighted users to access @longdesc, the value of the @longdesc attribute is still in the DOM as a link value, exposed to adaptive technology and any tool that cares to access the link (like, oh say, search engines). But of course Mattur either already knows that and doesn’t want you to know it, or he doesn’t know it, but is happy to continue spreading false information on the web as he makes it his mission to inform people of the wonderful “theater” he has come across.

    Speaking of which, I’m really glad that Mattur is amused by all of this, calling this Accessibility Theater. Am I the only one who finds this cavalier attitude and self-righteous comment highly offensive? 20 years ago, librarians said that they didn’t understand why they need to widen the aisles between their book-shelves, as no-one in wheel chairs ever came to their library (without ever questioning why not). I’m sure Mattur would have supported their point of view back then too.

  17. In Opera (for whom I work, etc) right click on an image and choose “long description” to follow the link. Or use Shift f10 (on Mac it is Cmd Shift m)

  18. Kyle: I posted a comment with some counterpoints and links on Monday, but it still seems to be stuck in your spam queue. Could you release? It’s got links to Tantek Celik’s wiki page objecting to longdesc, NVDA’s lack of support for longdesc, and the RNIB’s article The Rise and Fall of Longdesc.

    > “my upcoming design already has functionality mapped to clicking the comic”

    You will need to make sure that doesn’t disable or otherwise conflict with the way (some) AT users can access longdesc. Jaws users press enter to activate the longdesc link iirc(?)

  19. John Foliot:

    > “who proudly confirms he’s NEVER provided a long description”

    I’ve never had to use a longdesc attribute to make a website accessible. Neither have you, AFAICT – I’ve asked you repeatedly to explain how often you use longdesc at Stanford(?)

    We cannot rely on using longdesc to provide accessible long descriptions, at least at the current time, due to poor AT and browser support. But you told Kyle to use it on CssQuirrel. That was very poor advice.

  20. Everyone knows how to use a link.

    Everyone knows how to add a link, too. But as has been pointed out a number of times above, often the image is already a link. And often other aspects of the author’s design concept would be undermined by making the image a link.
    Classic case: A thumbnail that links to a larger image. Where should I expect to find the description of that image &mdash from the larger image only? Then how is a blind person supposed to know which of the perhaps dozens of thumbnails on the original page they should click to get the correct larger image? Obviously, there are ways of making this work, but each is more complicated than simply adding a longdesc attribute to the thumbnail.

    Hardly anyone knows how to use the longdesc attribute.

    True. And, truth be told, hardly anyone knows how to use the alt attribute. So let's get rid of both.
    There are long-running debates about what constitutes appropriate alt text. Some people want to hear a description of each photo or gravatar associated with the comments in a discussion. Other people say they don’t care what each comment’s author or the author’s gravatar looks like, so they don’t want their screenreader to add that noise to the background.
    According to the specification for html5, the value of the alt attribute “must be an appropriate replacement for the image.” That requirement by itself will not end this long-running debate. Experts might be able to agree as to what constitutes “appropriate replacement,” but clearly people who rely on html to reveal information to them through their screen readers don’t. So, whatever position we take, how can the rest of us be sure we’re right?

    OK, maybe it’ll help me understand this better if you (or someone) tells me why the ARIA-describedby attribute isn’t a satisfactory way of handling it.

    I have a very simple, self-centered reason for not wanting to relegate the role of longdesc to ARIA-describedby. In our CMS-based website, I am one of three people who review content before it is posted. Because the authors of our content are experts on the subject matter, their mastery of authoring tools, languages, and strategies is about fifteenth on the list of “other duties as described” in their job descriptions. It takes a lot of work to get them to learn the basics of html, but in most cases we can manage to accomplish that. Getting them to also learn ARIA would be impossible.
    In some of the comments above, I see the suggestion that people who don’t use longdesc are lazy. Maybe some are. But many, probably most, are simply poorly informed. Adding ARIA to the list of things they need to learn is not going to help them improve the accessibility of their content.
    I realize I’m the only one out here who uses a content management system with which scores, if not hundreds, of different individuals need to be able to develop the website’s content. So let me approach this issue from another direction: Without longdesc, html5 fails to coherently address the proper choices for describing images.
    In other words, consider again the case of the gravatar or photo of the author above each comment in a discussion forum. With longdesc and these instructions, html5 could in and of itself resolve the now-endless debate:

    For the alt attribute, enter the meaning you expect a sighted person to understand from this image. For example, a gravatar or photo of a person next to their name does not add meaning to the text. In this case, use alt="".
    For the longdesc attribute, enter a relevant description of the image itself. For example, for a photo of Cliff, longdesc="tall, strong, stunningly handsome man" is a relevant description. ;)

    Notice how this distinction changes the relationship of alt to longdesc:

    In xhtml and html4, the main differences between alt and longdesc are length and level of detail. Neither of these properties has clear boundaries. As a result, the Web abounds with musings on how one would know when they have entered too much alt text.
    With this approach, html5 would call for each of these attributes to present two different types of information:

    For alt, the focus is meaning: What does this image add to the message for those who can see it?
    For longdesc, the focus is detail: What are the significant qualities of this image? “Significant” does depend on context, so longdesc can be either completely independent of alt or an elaboration on alt.

    So restoring longdesc and giving stronger examples of its purpose will make html5 an adequate and complete tool for making images accessible.
    Authors would be able to rely on knowing html, and html alone, for making static content accessible.
    Developers of user agents would have a better sense of what features would be valuable to add to their products.
    People who rely on screen readers would have clearer options for revealing information about images to them.
    And even people who can see would often benefit. Whenever an author uses a graph to support a position, the alt text would reveal what that author believes the graph means, and longdesc would reveal much about how that author has processed the raw data to come up with that graph.
    Better accessibility inevitably improves the experience for everyone. Keeping longdesc and supporting its proper use will lead to better accessibility.

  21. @mattur – I am not a web *developer* at Stanford (a decentralized publishing environment with hundreds of web developers), so I don’t write code for Stanford. I continue to advocate and instruct content authors on the appropriate ways of ensuring accessibility, including how to meet WCAG 2 requirements by using approved W3C techniques and technologies. (http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/H45) I am not however the accessibility cop, and I have no mandate to force anyone to do anything.

    Besides, I am abundantly clear in all of my writings that I do not speak for Stanford, their policies or practices, and so I am unclear what point you are actually trying to make. You are welcome to maintain your ill-informed opinions on how to ensure accessible content, but the advice I gave Kyle was both correct, appropriate and useful, and being a free-thinking person who uses reason rather than rhetoric to make his decisions, he concurs. If you don’t want to provide long descriptions to your sophisticated images, don’t. It’s already clear that you’ve drunk your brand of Koolaid, and others are free to agree with you or not.

    Shoe on the other foot, where exactly are examples of *your* proposed technique of ensuring complex images are explained to non-sighted users?

    Re: the RNIB’s Rise and Fall of Longdesc: http://www.rnib.org.uk/professionals/webaccessibility/wacblog/Lists/Posts/Post.aspx?id=23, the author (expressing his personal opinion, not RNIB Policy or Position) wrote:

    Seven sites used LONGDESC, either correctly or as in one of the ways above, but on linked images. This just can’t work.

    The problem with the last technique is that the same keystroke, (Enter key), is used to launch both the LONGDESC page and the destination of the link. It shouldn’t happen, but it does. W3C warned about this in the HTML4 specification: “Since an IMG element may be within the content of an A element, the user agent’s mechanism in the user interface for accessing the “longdesc” resource of the former must be different than the mechanism for accessing the href resource of the latter.”

    (Hey’ isn’t that what Mattur is recommending? Note as well that the author neither mentions *which* browser nor *which* Adaptive Technology they were using, but DOES state that the problem is with the implementation, not the attribute itself.)

    Comments from that same blog post:
    “We have an attribute where people don’t know how to use it properly. Also we have faulty browser implementations that lead people to misuse the attribute. Is that reason enough to remove it from the specification, or shouldn’t we rather educate developers and build pressure on browser and screenreader vendors? …I would rather tell screenreader vendors to fix that behavior according to the specs than removing a reasonable element.” – Martin Kliehm
    (Blogger’s Response: “Martin: I do so agree! It would be wonderful if we could get all user agents to implement the specifications for all elements and attributes correctly. But how soon is it going to happen? When did complaints about IE rendering of the ALT attribute begin? I believe that we should keep trying, but am suggesting what I hope are workable alternatives, “until user agents …”. I was being deliberately controversial in suggesting that LONGDESC is removed from the web authors accessibility toolbox, hoping for a comment like yours. We put pressure on where we can, but the web community at large has to get behind calls for adherence to standards.”)

    “Abandoning longdesc and using text links is similar to CSS hacks, to my mind. It means abandoning the purpose-built feature designed specifically to provide this, then putting something similar together using features which weren’t designed for it.” – Ben ‘Cerbera’ Millard

  22. Wow! What a lot of energy people have available to attack such a little thing. If only the same amount of effort were spent on workng out how to make canvas-based apps accessible, I think we would have solved that by now, and be seriously working on something intelligent to support mouseless browsing in a way that doesn’t make authors’ life misery and users’ life such a lottery.

    I have begun to change my mind about longdesc. I used to accept that it wasn’t particularly smart design. It clearly has a bunch of problems, like being “dark metadata”, so is more likely to work when people are careful about making content and more likely to break if people do a slap-dash amateur job. But the only credible alternatives I have seen (like Kyle, things that impose constraints on design generally strike me as not really credible) are a suggestion to replace it with another attribute. With a new name. That does. THE. SAME. THING.

    So if we (the collective genius who produce HTML5 and all its alternates) can’t come up with any better ideas in a decade, maybe we’re just not that clever when faced with complex problems in accessibility. Or maybe longdesc isn’t that bad after all.

    Anyway, Kyle, I really appreciate your effort to provide descriptions of your comics. Occasionally it means I happily pass them to blind folks from time to time. But probably on a personal level I appreciate it more often because it’s a good way to find out who the characters are. The squirrel is bit of a give-away, and John Foliot wasn’t hard to pick. But I like to know who is there, and see what I understand, before I read the associated blog.

  23. Cliff Tyllick – excellent, real-world comment; thank you. It’s helping me weigh up the pros and cons of longdesc in html5.

    I’ve long disliked longdesc, feeling that it’s like table summary: if it’s needed for some users, it should be exposed for all. But the use case that you describe, and the fact that it points to a URL rather than just a fragment identifier on the same page, is moving me over to the “keep longdesc” camp.

    Of course, I’ll oscillate wildly. And my opinion isn’t that of Opera.

  24. Cliff Tyllick, Bruce:

    The longdesc attribute in HTML4/XHTML1 is for a URL pointing to a long description, not for the long description itself. This (understandable) confusion amongst authors is part of the problem:

    http://wiki.whatwg.org/wiki/Change_Proposal_for_not_including_longdesc

  25. As a number of folks pointed out kindly, I goofed: make that longdesc the URI of an anchor down the page where folks can find out how stunningly handsome I am.

    Or, more useful in the case of gravatars, make it the URI of an external page where I can update longdesc for all instances of my gravatar with one edit.

    Happy to have been able to contribute to the discussion.

  26. Bruce, why couldn’t browsers expose table summary for all on request? Makes sense to me, much along the same lines as my argument for longdesc: It could give more insight into the author’s interpretation of the data, leading to clearer discussion when interpretation of the data is at issue.

  27. @John Foliot: my apologies, I was getting confused over the lack of support for @longdesc in browsers as opposed to that in ATs. I stand corrected.

  28. For a podcast on this subject, go to Web Axe Podcast #83: Fate of Longdesc in HTML5.

  29. Longdesc was incorrectly used in 100% of cases on our old web site. In migrating to our new site I automatically removed every longdesc attribute, and now we’ve started using the feature properly.

    For example on this page http://www.antarctica.gov.au/dome-a where we have a weather graph, the longdesc is the URL of a page that contains the same data in an HTML table.

    This seems to be an ideal use for longdesc… we don’t want this data on the page itself, and it can’t be in the image alt attribute. Because we’re generating the graph and the ‘accessible’ page from the same data, it’ll never be out-of-sync.

    Using Opera, if I right-click on the graph there’s a menu item “Long Description” that opens the longdesc URL in a new window. Overall it’s unobtrusive and easy.

    Why does this have to be hard? Our web content management system (Squiz Matrix) supports longdesc. The Opera web browser supports longdesc. Couldn’t other browsers support similar right-click longdesc access? Couldn’t other authoring tools support it?

    I’m disappointed after all these years to finally be implementing longdesc properly, and now there’s a plan to remove it from HTML5 … to be replaced with, what? Nothing-in-particular … or nothing that’s better than longdesc.

    I think the modern generation of application-driven web sites are in a far better position to support longdesc than past generations of static HTML sites were (with web authors having to update pages by hand and not understanding what longdesc meant, and getting it wrong…) It seems like not a good time to be taking longdesc out of the standard.