Short note on alt in HTML

Sarah Horton says:

Thanks for the article, Steve. I’m confused about why the two specifications would diverge. What’s the advantage of not using the alt attribute, or using aria-label instead? Doesn’t that cause issues for people who don’t load images? And what about search engines, do they read and index aria-label? As you point out, there are lots of use cases where people who don’t have access to aria-label would not have access to a text alternative. What’s the benefit to accessibility, not requiring the alt attribute?

Alastair Campbell says:

Hi Steve,

Thanks, it’s good to have a clear point about this published! A couple of points:

1) From an external point of view (i.e. developers / content authors who don’t know the specs that well), it does seem odd to have this divergence. No matter how valid the technical reasons, it seems reasonably for WCAG to make some account of usability as well, although I understand the scope is strictly accessibility. If anything, you wouldn’t expect the HTML spec to account for usability!

2) I missed the core discussions on alt last year (and it’s a nightmare to try and review historically), but it does seem that for img, an alt is fundamentally different from title or aria-labelledby.

I.e. an alt is aimed at people who cannot see the image, so only labelling it with visible text means there will be missing information.

It is the same thought-process I went through on the figcaption, an alternative for someone who cannot perceive the image should be different from the visible label you would give that image.

Alastair Campbell says:

I guess the questions to be answered are then:

– How do we modify WCAG materials so that harmonises with the usability (or universal design) aspects of HTML?

– How do we modify WCAG materials so that providing a visible caption that doesn’t describe the image fails?

IMHO it is fine from an HTML point of view to have that situation where a text-alternative has not or cannot be provided, but that doesn’t mean it should “pass” from an accessibility point of view (as per SC 1.1.1).

Of course, if I could make more time for the WCAG calls I would be in a better position to actually contribute :-/

Sarah Horton says:

aria-label is a generic method to provide an accessible name, while alt is a special case for images. Developers have difficulty coping with using different attributes for different elements.

So we are modifying accessibility guidelines for developers, because it’s difficult to keep track of different attributes? What about all the work we have been doing to get people to understand and use the alt attribute?

And doesn’t this undermine the “accessibility is good for everyone” perspective since, in this case, complying with accessibility may actually impair usability in general?

Stomme poes says:

We’re kinda screwed either way:
alt would usually the the easy choice, except with how most browsers (except the Gecko ones) break alt when image dimensions are smaller than the alt text.

aria-anything is pretty useless for everyone who doesn’t happen to have a screen reader. I could agree with it being an option in WCAG where it lists possible techniques, but never a sole option. “This fulfills the Success Criteria so long as all users have a secret decoder ring!”

We simply have to fight vendor implementations to make some things work, and the user experience is completely dependent on how much extra time the developer can put in: if they’re relying on WCAG they may be putting in more time than if they’re relying on the HTML validator.
Just like with title. Or modal dialog windows. Or skip links in any Blink browser…

Stomme poes says:

@Devarshi
quote: “I am sure screen readers would voice the title attribute on an image if they don’t detect the alt text.”
That depends on the reader and also you can choose settings in many of them. But to avoid Java hell er, title+alt verbosity (since “for SEO reasons” many CMSes have had the habit of adding both, on everything, back in the day), the ones I’ve used usually voice just one or the other (I couldn’t even find the setting in JAWS that let me hear both– it was a radio button choice menu). What you don’t want is users backing up and hunting around for another attribute if one is not available.
More of a problem than sighted keyboarders just don’t get access to title.

If it’s in an anchor, what you could do that should work for most everyone is a fake tooltip, but not a title. Or use title as a handy data-storage unit for Javascript…

[ a href=”wherever” ][ a hidden span via negative margins or so ]tooltip text[ /span ]
link text visible by default for everyone [ /a ]

You could (with Javascript) make that hidden span appear when keyboarders focus on it, using CSS to style it like a tooltip. Because the span is just a normal child who isn’t display:none, it’s available to a11y APIs as well.

Images get harder all the way around: not natively focusable, and as EMPTY elements can’t have that handy span inside. You could have Javascript construct a box to go around the image, and a span with the alt data inside it and append to the DOM, and manually add in tabindex for keyboarder focusability… but now you’ve added a focusable graphic and that may be confusing to people since they’re not normally so. Plus messing with each image in the DOM onLoad won’t be pretty on slow CPUs and battery-dependent devices.