Alt text matters to users. When an image is not visible, due either to a user’s own visual or cognitive disability, or their use of a low-bandwidth or intermittent connection to the web, @alt is there to provide the necessary, missing semantics. This is a good thing. So good, in fact, that @alt is a required attribute in HTML 4.01 and all flavors of XHTML. If you omit alt text, your code is not valid HTML.
However, as of today, alt is not a required attribute for the img element in HTML5. Despite claims that this is neutral or even beneficial to accessibility, this is a bad idea, made worse by adversarial relations between participants in the HTML Working Group and accessibility advocates, including those in the W3C/WAI Protocols and Formats Working Group, of which I am a participant.
Much of the discussion around this rather tense standoff has centered around what I call the Flickr Defense. It goes like this:
Sites like Flickr depend on user-generated content in the form of uploaded images. (Of course Flickr now accepts video, something that has also been added to HTML5, and which may have even bigger problems than the issue at hand. But that’s for another time.) Flickr doesn’t know what to communicate as meaningful alt text. But if we want them to adopt HTML5, they wouldn’t be able to create valid documents without that @alt. So in this very limited case, Flickr should be able to have an img element without @alt.
This argument is bogus on numerous counts.
First, let’s dispense with the very limited case for making @alt optional. Once an attribute like @alt is optional anywhere, it’s optional everywhere. One could make the argument that the specification limits the scope of acceptable use of missing @alt to only where it’s not possible for it to be meaningful. But that’s just one image out of 65 on the average Flickr photo page. And if it’s an optional attribute, we could strip the alt text from all of those other images, and an HTML5 validator could do nothing but assert that it remains valid. That’s a huge step backward for users as well as accessibility evaluation tools, which interpret missing alt as an error. But more on that later.
Second, Flickr could, in fact, require that meaningful alt text accompany images that are uploaded. Other sites, such as Smugmug, actually do offer the ability to do that, either as they’re uploaded, or as a batch job after the fact. The Authoring Tool Accessibility Guidelines 2.0, which apply explicitly to sites like Flickr, require that such sites prompt users for that content. If they prompted for and stored that content from the user, they’d be able to insert meaningful alt text where it is required. There’s no need to give them a pass.
(Although that’s exactly what the Web Content Accessibility Guidelines 2.0 does. Flickr could make a partial conformance claim stating exactly why they can’t produce alt text. They could still insert generic alt text like “user-uploaded image” and satisfy the requirements of users with disabilities to some extent.)
Third, Flickr image pages have over 80 validity errors, and that’s just HTML 4.01 Transitional. Why should the HTML specification make supposedly narrow exceptions to the spec to be more lax about validation when the sites themselves aren’t even trying today?
How it works today
There are three conditions for alt text that are currently determinable:
- This image has meaningful alt text. (alt=”foo”)
- This image is decorative, and needs no text equivalent. (alt=””)
The third is determinable now, but would not be in HTML5 as proposed:
- The author has not entered alt text for this image. (missing @alt)
This is critical because assistive technology looks for repair data (including filename, etc.) when @alt is missing. We need to know whether @alt is null due to conscious effort, or that it has been ignored, in order to know what to do next.
The Flickr Defense is a fourth state:
- The author asserts that s/he cannot provide alt text.
It is the wrong solution to take away the semantics from the third state to indicate the fourth. There would be far more missing @alt attribs due to inattentiveness on the part of the author than conscientious statements that @alt is not possible.
The clearest indicator that this is an awful idea is that same Flickr image page. All of the images with missing alt attributes on the Flickr image page could have meaningful data. In fact, most of them do. It’s just sitting in the title attribute instead.
So what do we do, smart guy?
I don’t want to propose a solution to the problem when I think the status quo in HTML 4.01 doesn’t need to be mucked with. But, okay, you read a big long accessibility article, so here’s a thought experiment.
Add an attribute. Call it @usergenerated. When a UA encounters this attrib, it indicates that the author has stated alt cannot be provided programmatically.
It would be even better if other users could detect that attrib and annotate the attached image. If you could get around the spam potential, this could be a real winner. Crowd-sourced @alt. That’s actual accessibility progress, measurable today.
If you can’t do that much, leave @alt alone.
Gez Lemon’s analysis of the subject got me wound up enough to write about it. If you don’t like what I had to say, blame him.
(Note: This isn’t meant as a critique of Flickr per se. It just happens to be a site that’s being held up by third parties as the reason to backtrack on @alt as a required attribute.)