bestkungfu weblog

@alt and the Flickr Defense

Filed in: accessibility, Web, Thu, May 1 2008 18:09 PT

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

18 responses to “@alt and the Flickr Defense”

  1. Mike D. says:

    I still don’t see how alt=”” and no alt at all are any different from each other in practice. The only argument I buy (which is a valid one, I suppose) is that by telling developers they can omit the alt attribute altogether, you’re pushing accessibility one step further out of sight, and thus one step further out of mind. Decent argument, but not a showstopper either way for me.

  2. Matt says:

    @alt=”” is at least an action indicating the author has determined that there shouldn’t be alt text. Missing alt could mean anything, and we can’t infer anything from it. It’s just missing. And in HTML 4.01, that’s a validation error.

    Now, remove that constraint, and any image with missing alt could be purposeful, or not. We’ll never know. And what’s already out there on the web tells us that more often than not, it’s going to be omitted accidentally.

    Why would we take an error that already exists all over the web, and then apply semantics to it? How many authors do you think would be aware of that change? More to the point, what sense does it make to propose the omission of an attribute as valid semantics?

  3. Mike D. says:

    I guess I just see plenty of problems even *with* the requirement of the alt attribute, so it doesn’t feel like a giant step backwards to me, except with regard to my comment above. Specifically:

    1. Plenty of tools already automatically insert alt=”” for you and developers just leave it that way. In this case, it’s really the same as not being there. In other words, we don’t know the intent… it could still be laziness.

    2. Plenty of people insert the *wrong* sorts of things into alt attributes which doesn’t help the situation.

    3. Plenty of people and tools insert alt text where there shouldn’t be any at all. In fact, I would argue that at least in my experience, *most* images should not have any alt text whatsoever. Navigation images? Sure. But those aren’t in very wide use anymore. At least with the types of sites I work on, most images deserve to simply be treated as “not there” if the visitor can see them.

    4. I’ve never understood why the absence of an alt value causes any program (screenreader or other) to do anything other than just ignore the image. Didn’t screenreaders used to even read the URL of the image ALOUD if there wasn’t an alt value? Clearly I’m ignorant about this issue but how is that possibly the right thing to do?

  4. @Mike D.:

    One quick thing regarding:

    I’ve never understood why the absence of an alt value causes any program (screenreader or other) to do anything other than just ignore the image. Didn’t screenreaders used to even read the URL of the image ALOUD if there wasn’t an alt value? Clearly I’m ignorant about this issue but how is that possibly the right thing to do?

    Yes, a screenreader will read the src attribute of an image aloud that doesn’t have an alt attribute — mostly a requirement when the image is part of a link. If it is a link, the screen reader has to read out *something* to the user, otherwise it would just say “link” and nothing else. Maybe eventually we’ll get something better, but for now, we still need it, and I’m actually very surprised at how many sites we look at that have no @alt on an image that is a link. It is shocking, to be honest…

  5. Jake Archibald says:

    Surely flickr should write empty alt attributes to all user uploaded images as the title and description are nearby in the html.

    For images where the title isn’t nearby the img (such as some thumbnail views), the title should be the alt.

  6. Matt says:

    That’s not necessarily true, Jake. Not the first part, anyway. The image itself is the most important content of the page. To set @alt=”” on it means assistive technology would ignore it. But, what if a blind user wants to select the image and copy it into an email? (Blind users do have sighted friends, after all. In fact, I know at least two who have digital SLRs.) Without @alt, how are they going to get to the image, when it’s never read to them?

  7. Mike D. says:

    Derek: Yep… I’ve definitely heard that that’s what some screenreaders do, but I guess I’m just saying I think it’s patently stupid. I just can’t see how reading the URL of an image aloud is ever useful to anybody. I suppose one could make the argument that if all people named their images like “big-grizzly-bear.jpg”, it could provide *some* information, but that seems of little use in practice.

  8. Jake Archibald says:

    Interesting… what should the @alt be in this case then? Repeating the title / description would be pointless, should @alt be set to something like “full image”? That seems wrong, but what else would it be?

  9. Kim Sullivan says:

    If Flickr really prompted the user who is uploading the pictures for the mandatory meaningful alt text – how many users are actually going to provide *meaningful* text? Who is going to check if the text is meaningful, will images have to be moderated? How many people are going to push the “whatever” button just to get that stupid form to be submitted?

    Even in this very article, the example meaningful text is “foo”… And that was written by someone who actually cares about alt texts! How many pictures are going to have that or a similar nonsensical description (DSCN4567)? And if it’s really mandatory and not easy to circumvent (no “whatever” button, meaningfulnes verified by editor/moderator), won’t people just move to a different site that’s less accessible and not valid, but which just lets them upload pictures without hassle?

  10. Matt says:

    First, be reasonable. I wrote alt=”foo” because I’m not describing any image at all. It hardly negates the rest of the argument.

    We do not expect that all authors are going to be conscientious about adding meaningful alt text. But the guidance from W3C/WAI for 8 years now has been that we’re better off from an accessibility standpoint for authoring tools to at least ask for it. If the authors decide not to add alt when prompted, then they don’t get to be valid. That’s their call. If, on the other hand, they insert garbage, then even by the reasoning of the validation advocates in this debate, they’re not really valid because they’re acting counter to the spec. Making it optional, then, doesn’t do anything to help them, since they don’t care either way. All it does is make it harder to coax alt text in any form out of other authors.

    And it should be noted that many if not most Flickr users _do_ provide alt-like titles of their own accord. One step might be to apply the title text as the @alt value, or failing that, some placeholder like “full image”. That’s not the best alt text, but it’s better than nothing.

    Finally, Mike, yes, guessing at the meaning of an image from its filename or other identifying details is a shot in the dark. But it’s not per spec, it’s a repair technique. If we can’t rely on the presence of @alt, this is the kind of scavenging that assistive technology is reduced to. We like good alt text, but even the promise of crappy or sometimes misleading alt text is better than none at all.

  11. Kim Sullivan says:

    You’re right, sorry about the “foo”.

    As for the other point – I think I side with Henri Sivonen, who says that “validity” should be something that is machine verifiable. Inserting garbage alt text would make the page not valid, but there would be no way to verify it’s validity. I like the idea of @usergenerated, but I’d probalby still prefer it in combination with the possiblity of a missing @alt Come to think of it, this is what you propose, isn’t it?

    alt=”meaningful description by website author”
    alt=”hopefully meaningful description by user” usergenerated
    alt=”” usergenerated

    Requiring the alt attribute leads to 2 states
    alt=”some kind of description, maybe meaningful, maybe not”

  12. Kim Sullivan says:

    One mor time, but this time not using HTML comments…

    alt=”meaningful description by website author”
    alt=”” !–decorative image as specified by website author —
    alt=”hopefully meaningful description by user” usergenerated
    alt=”” usergenerated !– is this combination meaningful? How many sites actually allow users to insert purely decorative images? Probably invalid —
    usergenerated !– not a decorative image, but user has not deemed it worthy of description, website author cares about accessibility–
    !– if both @alt and @usergenerated are missing, the page is invalid

  13. This is a very difficult area and I can see both sides of the arguments. I do find it slightly irritating and unneccessary that I need to add alt=”” for a purely decorative image in order to make it accessible (or at least pass the validation test). It does cause some confusion because a decorative image that does not have an alt attribute only fails the WAI guidelines at priority level 2, and not priority level 1. I can however also see the point that asking for a description is better than not, even if the resulting description may not give enough meaning.
    It becomes even more subjective when you consider that an image of a leaf (which for example appears on my own website as a purely decorative image) probably does need some meaningful alt text if it appears on say Flickr (or where the image actually originated from), and if it was on a site identifying different types of leaves then the text alternative would need to be more descriptive to be useful.
    All this rambling isn’t nailing my colours to the fence so here goes. I think that the alt attribute should be an optional attribute (without taking away the requirement for any information or meaning within an image to have a text equivalent), but image collection sites should probably insist on submitters providing a description (and stating the reasons why this would be helpful to blind users). To turn the argument around slightly, if the alt attribute continues to be obligatory then I think that it should also become obgligatory for CSS background images, because they could convey meaning in some way. Discuss!
    By the way, I love the Kung Fu graphic for this page. Simple but stylish.

  14. Nancy says:

    I have a close friend who is visually impaired. She loves alt tags. Even if the description is a bit off. The reason I think is it helps her to experience the same thing as sighted people experience.

    I would hope that before html 5.0 is finalized that the developers ask the folks who depend on alt tags the most feel about them being mandatory or optional.

  15. Mike says:

    Given that an empty alt atribute is a fudge to get around the rules, I don’t see that it is any great leap to force applications to do something like: alt=”missing” or alt=”No description entered”
    Neither of these are very helpful to the end user, but they are much more useful than it being missing altogether, especially if a specific value is part of the specification, or gains widespread acceptance in the same way that “” has.

  16. @Richard

    In regards to:

    I do find it slightly irritating and unneccessary that I need to add alt=”” for a purely decorative image in order to make it accessible (or at least pass the validation test).

    I’m afraid the irritation you feel pales in comparison to the irritation or frustration that user who is blind feels when they have to listen to “bullet.gif” over and over or “prettyflowerborder_small1.gif” because the null alt value, alt=””, was not included. I understand what you’re saying, but it’s never about US as developers, it’s always about the users. I myself use a wheelchair and when a business owner tells me what a pain it is to have to put in a ramp or accessible bathroom, I responde that they do not know the pain I feel when I tell my kids we can’t go somewhere, because Dad can’t get into the place. Irritation and pain are relative to your circumstance.

    I would also say, in general, that while even with standards, many developers don’t follow the standards (see Flickr, MySpace, Facebook, etc.). That doesn’t mean we get rid of the standard. Just because everyone speeds doesn’t mean we abolish speed limits, eh?


    As you say:

    I would hope that before html 5.0 is finalized that the developers ask the folks who depend on alt tags the most feel about them being mandatory or optional.

    Absolutely. As a person with a disability, I can tell you that too often folks WITHOUT disabilities make decisions on what is “good for” people with disabilities. Medicaid/Medicare, insurance companies, HMOs, government, hospitals, etc. decide for us what we need, where we live, what meds and tools we use. This is wrong and if users with disabilities are not consulted on their development, then these standards are no exception to this paternalistic attitude. Hey, I don’t tell you TABs (Temporarily Able Bodied) how you should walk, right? 🙂

  17. Fully agree with Matt: I think that the main problem is that some HTML5 evangelist don’t know that there are different requirements for Web content and for Web applications, and that Web Apps like flickr (but also like youtube, gmail, google docs, blogging tools) shall follow the future ATAG 2.0.

  18. dani says:

    I’m a ‘disabled images’ user 🙂
    (volume based Internet user)
    alt attibutes are very helpful on my side
    I would be grateful if the site passes WCAG 2.0 and or 508, BITV, Stanca Act

Powered by WordPress (RSS 2.0, Atom)