Short note on alt in HTML

It is no longer a WCAG 2.0 conformance failure to have an <img> without an alt attribute, as long as the img element has an accessible name provided using another method such as aria-label.

It is still a conformance error in HTML  to have an <img> without an alt attribute (unless the img has a caption provided using the figure and figcaption elements)

Why are there now divergent requirements?

The HTML conformance requirement takes into account the accessibility and usability needs of users:

4.7.5.1.1 Examples of scenarios where users benefit from text alternatives for images

  • They have a very slow connection and are browsing with images disabled.
  • They have a vision impairment and use text to speech software.
  • They have a cognitive impairment and use text to speech software.
  • They are using a text-only browser.
  • They are listening to the page being read out by a voice Web browser.
  • They have images disabled to save on download costs.
  • They have problems loading images or the source of an image is wrong.

Further reading:

 

Categories: Development
Tags:

About Steve Faulkner

Steve was the Chief Accessibility Officer at TPGi before he left in October 2023. He joined TPGi in 2006 and was previously a Senior Web Accessibility Consultant at vision australia. Steve is a member of several groups, including the W3C Web Platforms Working Group and the W3C ARIA Working Group. He is an editor of several specifications at the W3C including ARIA in HTML and HTML Accessibility API Mappings 1.0. He also develops and maintains HTML5accessibility and the JAWS bug tracker/standards support.

Comments

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?

Steve Faulkner says:

Hi Sarah,

I’m confused about why the two specifications would diverge.

In general, WCAG 2.0 relaxed the requirement to use valid HTML that was in WCAG 1.0. Thus WCAG only requiring parsable HTML. Use of the alt attribute is a HTML requirement not a WCAG requirement, provision of a text alternative is the WCAG requirement, if the text alternative can be acquired from another source then the use of alt is not required.

What’s the advantage of not using the alt attribute, or using aria-label instead?

A reason that I have heard is that 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.

Doesn’t that cause issues for people who don’t load images?

Yes, unlike the alt attribute, the text is not displayed when images are not, but I believe that the display (or lack) of images is not considered an accessibility issue by the WCAG working group.

And what about search engines, do they read and index aria-label?

Not that I know of, but this is not an accessibility issue.

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?

I am unsure about the tangible benefits other than the ‘remove special case’ argument to benefit developers.

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.

Steve Faulkner says:

Hi Alastair,

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…

I cannot but agree.

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.

Agreed, which is why I have worked and continue to work to ensure the HTML spec reflects the differences.

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.

I agree with this, an image with a caption but without an alt is only for cases where a text alternative has not or cannot be provided. The semantics of figcaption unambiguously identify its contents as a caption.

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 :-/

Steve Faulkner says:

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

And that is what the situation is. Use of figure/figcaption with an sans alt is conforming in HTML under very specific conditions. This does not mean that its use conforms to the WCAG 2.0 text alternative guideline.

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

Yeah I know the feeling…

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?

Steve Faulkner says:

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?

It appears so.

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…

Devarshi says:

Hi Steve,
Would a title attribute (tooltip) be considered a reasonable alternative? I understand it may not be the most effective implementation, nevertheless it is mentioned as a possibility in the Text Alternative Computation – 5.2.7.3 – 2D (https://www.w3.org/TR/wai-aria/roles#textalternativecomputation). Furthermore, would a keyboard accessible tooltip be more acceptable in this situation, assuming there is a need to use the title attribute on an image? Sorry – too many questions. I am sure screen readers would voice the title attribute on an image if they don’t detect the alt text.
-Devarshi

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.

Steve Faulkner says:

For AT title works, but the semantics are different to alt, and we should endeavor to avoid conflating them. Also title does not generally get displayed when images are disabled or otherwise unavailable. Furthermore use of title is a slippery slope as it comes with other accessibility/usability deficiencies.