Longdesc – Where are the alternatives?

Non-text Content is “any content that is not a sequence of characters that can be programmatically determined or where the sequence is not expressing something in human language”. Mostly what comes to mind when discussing non-text content are audio/ video content, images, or other graphical content not necessarily image-based. WCAG 1.1.1 Calls for alternatives for non-text content. For basic images, presented in the <img> element, the ‘alt’ attribute is the most-frequent means of providing an alternative. The content you place in the ‘alt’ attribute may vary depending on the image and context but generally “…the general consensus is that if the text alternative is longer than 75-100 characters (1 to 2 sentences), it should not be considered a short text alternative and should not be presented using the alt attribute or the figcaption element…”. In the vast majority of cases, that amount of text should cover you rather well in providing a good, clear, and concise alternative for the image. But what if the image is complex? What if the information portrayed in the image can’t be described effectively in 75-100 characters? One suggestion is to use the longdesc attribute.

Historically, support for longdesc has been rather spotty. Back in 2000, WCAG 1.0 recommended using longdesc, but also acknowledged the lack of browser support and also recommended the use of what was called a D link. In practice, the D link probably saw more popularity than longdesc and its recommendation was pretty pervasive.

Over time longdesc support among user agents has improved, having been added to Opera, IE, and Firefox. Movement toward supporting longdesc has been made by Chrome’s dev team. Screen readers such as JAWS, Window-Eyes, NVDA, and Orca support it, as do many authoring tools. That hasn’t stopped the pushback on longdesc and Apple has stated they have no plans to implement longdesc.

longdesc (as implemented) is a poor solution to a real problem

There should be no argument in anyone’s mind that there’s a real issue that needs to be addressed: effective and informative alternatives to complex and/ or detailed non-text content. There are loads and loads of images on the web which convey things like charts, graphs, and diagrams. How do you describe, in 75-100 words, the components and operation of a 4-stroke engine?

Example complex image: cutaway of 4-stroke engine

Easy. You can’t. There may be other ways to describe this, such as in the same page as the image. Try getting that one past the content people. But longdesc – in its current form – is a crappy way to do this. See, the problem with longdesc is that it is basically only useful for screen reader users. Longdesc essentially locks out sighted users entirely. The image with longdesc isn’t placed in the tab order and there’s no visual affordance provided to indicate the existence of longdesc. Firefox’s implementation provides access to the long description via the context menu which is great if you knew the image has a long description, which you likely won’t if you’re not a screen reader user. As it stands, longdesc is wholly useless to people with cognitive disorders, which is another population that could seriously benefit from long descriptions.

Where are the alternatives?

Ultimately, I have to agree with many of the criticisms of longdesc. But that doesn’t mean I agree with the notion of just doing nothing, either. The fact remains that some images require longer descriptions than the 75-100 characters available to the alt attribute and despite the protestations of longdesc’s detractors, there don’t appear to be any proposed alternatives for implementing a mechanism of supplying long descriptions for non-text content, beyond saying “Fuck it, leave it to the web authors to figure that out”.

Two ideas

Unfortunately, that’s where we are right now if we want a viable means of supplying long descriptions. With Safari/ VO support out of the picture, we can’t rely on partially supported features. Or can we?

See here’s the thing about HTML: You can actually put whatever you want in your markup. You can make up your own elements or attributes, you can even add bogus values in attributes. That doesn’t mean it’ll do anything, but you can put it there. For instance, you can add the old <blink> tag to your page, but it won’t actually blink anymore in any major browser. Similarly, you can still add longdesc to your images. The attribute will still be in the attributes node of the image object. Because it is in the DOM you, the developer, can do something useful with it. Here are two possible ideas:

Dirk Ginader’s longdesc plugin places an unobtrusive icon over the image which represents a link to the long description. Activating the link replaces the image with the long description. Dirk hasn’t done much continued development on the plugin, but its a great starting point and I like the concept.

Today, I created a new Polymer-based Web Component called image-longdesc. It is basically just a different approach to my image-caption component. It places a link to the long description under the image. Remember my 4-stroke engine example? Here it is with a caption and longdesc link:

Screenshot: Prior engine example as a web component with caption and longdesc link under the image

Are these ideas perfect? I don’t know. What I do know is that we’ve yet to see longdesc’s detractors come up with any viable alternatives that address the very real need for suitable alternatives to complex non-text content.

If you are interested in learning about the next generation in Web Accessibility Testing, give Tenon.io a try.
If you or your organization need help with accessibility consulting, strategy, or accessible web development, email me directly at karl@karlgroves.com or call me at +1 443-875-7343. Download Resume [MS Word]


  • Posted August 27, 2014 at 10:55 am   Permalink

    Alright Karl, here we go.

    First, some background and history. One of the key use-case requirements is the “no visual encumbrance” requirement, which essentially says that there are circumstances and times when providing the “link” visually will not meet the design requirements of the client. Karl, you’ve consulted to large companies and organizations in the past, you know how much pull the Designers have, and you also know that the explanation “…you *HAVE TO* for accessibility reasons…” is both the kiss of death, and a sure-fire way of not getting invited to the next planning meeting. Pretending otherwise is fooling only yourself.

    So we have this design requirement that restricts us from placing a visible link on the page – oh yes, you and I and everyone else who works in the accessibility field know that this is the best solution, the “universal design” solution, the one that benefits all users, not just screen reader users… yes, we all know that. But the Design team aren’t interested, it interferes with the wire-frame comps, the business owners don’t get it – they want to see the ROI, and the Project manager doesn’t think people with cognitive disabilities will be looking at this anyway… we’ve all been there.

    So what can we do?

    Well, first, lets insure that at least the core target audience is addressed. Let’s say it out loud: Blind people. They can’t see the image, they *NEED* the freaking description, it’s not a nice-to-have, it’s critical. We need to address that problem first. I hate that we aren’t addressing the needs of those other users who could benefit from the longer text description, but I can’t leave *everyone* out in the cold simply because I can’t accommodate everyone – we have to do *something*. Fortunately, many of the modern screen readers *do* do something with @longdesc: we have support in JAWs, WindowEyes, NVDA, and recently Orca. These tools inform the blind end-user that, when available, the critical longer text description is indeed there for you.

    Now, it’s great that you’ve come up with your Polymer-based Web Component (which isn’t working in my version of Firefox 31 BTW) – Steve Faulkner has also come up with a similar strategy, but again, the problem is the forced visual encumbrance. Likewise with Joe Dolson’s addition of support for @longdesc: all of these alternative solutions fail to address this critical requirement – they “force” the link onto all of the users, and as such they eliminate CHOICE.

    And frankly, that’s what the real problem is all about – choice. We need a solution that affords choice, not only to the authors of the content, but also the end users. It is my argument that done right, @longdesc can provide that choice, because it supports one of the fundamental axioms of real Universal Design (WRT web design): author proposes, user disposes. By providing a programmatically determinable attribute, user-agents *should* be able to afford the end user the ability to use or dispose. We have plenty of examples of this: users can enable or disable JavaScript (yes, problematic today, but THEY CAN!), they can use user-supplied style-sheets, they can configure their browser to always use a specific font face, font-size and link colors. They can (in some user-agents) choose high-contrast mode, zoom to 200, 300, 400% – in short, the end user can take whatever the Designer offers up, and turn it completely inside out if that is what is required and “works” for them, and each and every one of us accessibility experts are nodding our heads and saying “yes… that’s right”.

    Except for when it comes to the alternative solutions to @longdesc – there, each alternative solution I’ve seen insists on changing the design at the author level, not the user level. And that’s the problem there!

    You mention Dirk’s jQuery plugin (which BTW, was created by Dirk for me as a proof of concept – I paid the man a bottle of Port 🙂 ) – but are you aware that Dirk has now taken that code and created a series of browser extensions? (Video here)

    This isn’t the first time a browser extension to support @longdesc showed up either: Chaals McCathienevile’s “TellMeMore” is another example of a browser extension that supports @longdesc, by placing a notification in the browser chrome. What is (I believe) critically important about these examples however is that they are end-user solutions, not author solutions. Because, you see, if you – an individual, sighted user – want to access long descriptions when provided by the author, then you, as end user can install/activate the support to do so. At that point, you, as end-user, have accepted that to have that support, *you* will be changing the Design offered by the Designer – not them. It’s no different than over-riding the lovely Helvetica Neue specific in the style-sheet with your CHOICE to see everything in MS Comic Sans.

    The solution then, the long-term solution for @longdesc, is to look at the interaction patterns that are emerging (and based upon Dirks’ 4-year-old implementation of my idea, and Steve Faulkerner’s web component example, and James Craig’s iframe example, I’d suggest that a pattern is emerging) and then build the functionality into the browser as a user-configurable setting: if you – Mr. or Ms. End User – want to enable the ‘visual encumbrance’ then you have that CHOICE, just like you have the choice to over-ride other author supplied Design proposals and instead choose to view all of your sites in 22 pt MS Comic Cans – because that is what works FOR YOU.

    The solution is pretty simple, the barrier is the browser vendors today.

  • karlgroves
    Posted August 27, 2014 at 11:17 am   Permalink


    This is a great comment and I don’t take it as a rebuttal at all. I agree that it would be great if there was a user-configurable setting to somehow expose a notice of some kind that an image has longdesc. Unfortunately the fact is that doesn’t currently exist. Browser extensions could close this gap and there are a number out there. But that requires that the user has such an extension. As a developer who is conscious of the need for a suitable text alternative, I don’t want to rely on that. That’s why I’d rather have the control myself, via something like Dirk’s plugin or my web component.

    I agree though, that the best approach is something available in the browser natively. What’s in the browser natively *right now* sucks, though.

    The one thing I do disagree with, however, is that the core audience for longdesc is blind people. The blind-centric nature of the accessibility field is bothersome to me. Sure, blind people who can’t see images surely need text-based alternatives. But the population size of people with cognitive impairments out-numbers blind, low-vision, hard of hearing, and motor impaired users combined. Further, the fact that current longdesc implementations don’t add the longdesc to the tab order means that sighted keyboard-only or voice dictation users can’t access it, locking out people with motor impairments.

    So, ultimately I’m saying:
    1. longdesc, as it is today, sucks. 2. It would be great if browsers implemented longdesc in a more universally usable manner. 3. They haven’t and I need a solution for my users that works today.

  • Posted August 27, 2014 at 11:48 am   Permalink

    As a developer who is conscious of the need for a suitable text alternative, I don’t want to rely on that. That’s why I’d rather have the control myself, via something like Dirk’s plugin or my web component.

    Great, if you have final say on the design, but we both know that isn’t the case in large orgs – the accessibility types aren’t the only ones at the table (if they get invited to the table at all).

    With regard to “core audience” I too am mindful of the numbers, and those other user-groups, but when it comes to @longdesc, I stand by my statement: the textual equivalent for the image has the greatest impact on non-sighted users: not that this diminishes the other user-group’s needs, but when it comes to graphics such as this (Infographic) the text is there for all of those other groups as “burned in” text, but the non-sighted user gets <img alt=”infographic”>.

    So I would modify your comment slightly:

    1. longdesc (*browser support*), as it is today, sucks.

    2. It would be great if browsers *It is critical that browsers* implemented longdesc in a more universally usable manner.

    3. They haven’t and I need a solution for my users that works today.
    [JF: then use the polyfill solutions out there today, and fight to have the Designers accept them as well, while remaining prepared to not win that battle every time. When that day arrives, let me know – because that will be the day that @longdesc will be the partial solution.]

Post a Comment