I’m sure you know about alt
text. It’s the attribute on the image tag that has the important task of describing what that image is for someone who can’t see it for any reason. Please use them.
I don’t want to dimish the please use them message, but some interesting alt-text-related things have come up in my day-to-day lately that are related.
When you don’t
Hidde de Vries wrote You don’t always need alternative text recently:
But when an icon has a word next to it, for example ‘Log out’, the icon itself is decorative and does not need an alternative text:
<button type="button"><img src="close.svg" alt="" /> Close</button>
In this case we can leave the alt attribute empty, as otherwise a screenreader would announce ‘button – close close’.
I would think in a perfect world because that icon is entirely decorative that applying it via CSS would be ideal, but the point stands: if you have to use an image, alt
text hurts more than it helps here.
Can we get it for free?
Computers are pretttttty smart these days. Perhaps they could look at our images and offer up descriptions without us manually having to type them.
🔥 I think I used machine learning to be nice to people! In this proof of concept, I’m creating dynamic alt text for screenreaders with Azure’s Computer Vision API. 💫https://t.co/Y21AHbRT4Y pic.twitter.com/KDfPZ4Sue0
— Sarah Drasner (@sarah_edo) November 13, 2017
Sarah’s demo uses a Computer Vision API to do that.
What about figcaption?
I hate to say it, but I’m not particularly good at writing alt text descriptions for images in blog posts right here on CSS-Tricks. It’s a problem we need to fix with process changes. We do often use <figcaption>
though to add text that’s related to an image. The way that text is often crafted feels like alt text to me. It describes what’s going on in the image.
I was asking around about this, and Zell Liew told me he does the same thing:
I actually have the same question. Most of my figcaptions are used to describe the image so readers understand what the image is about.
In my mind, I figured it would be worse to drop the exact copy from the figcaption into the alt text, as someone who was reading alt text would then essentially read the same description twice.
I also talked to Eric Bailey who had an interesting idea.
<figure> <img src="screenshot.png" alt="Screenshot of Chrome displaying a split view. On the left is a page full of image thumbnails comparing pre and post-optimization filesize. On the right is Chrome developer tools showing paint rasterize duration for the images. With a 6x CPU slowdown, the longest Paint Raster took 0.27ms, AKA 0.00027 seconds."> <figcaption aria-hidden="true"> With a 6x CPU slowdown, the longest Paint Raster took 0.27ms, AKA 0.00027 seconds. </figcaption> </figure>
This:
- Preserves figure styling
- Avoids nulling alt, which can be problematic for some screen readers
- Keeps the description close to the content and communicates point to SR users
- Communicates significant takeaway to visual readers without duplicating reading for SR users
- Uses an aria property designed to be used outside of forms
I’d stress that he considered this just an idea and it hasn’t been heavily vetted by the larger accessibility community. If there are any of you out there reading, what do you think?
Eric’s demo used a more verbose alt text than the figcaption, but it seems like the pattern would be fine even if they were identical.
Little reminder: Twitter has alt text
But you need to enable the feature.
One tricky thing is that there are no hard and fast rules when it comes to accessibility. So much is a judgement call. The specification tells us, “Authoring useful alt attribute content requires the author to carefully consider the context in which the image appears and the function that image may have in that context.” (
https://www.w3.org/TR/html51/semantics-embedded-content.html#alt-text
)I would say that your example is probably more in line with the pie chart example shown on that page. (
https://www.w3.org/TR/html51/semantics-embedded-content.html#graphical-representations-charts-diagrams-graphs-maps-illustrations
) The best way to represent the information you’re trying to convey could be to place the text, “On the left is a page full of image thumbnails comparing pre and post-optimization filesize. On the right is Chrome developer tools showing paint rasterize duration for the images. With a 6x CPU slowdown, the longest Paint Raster took 0.27ms, AKA 0.00027 seconds.” in a paragraph and use as the alt attribute something like, “screenshot described above” with a figcaption providing additional meaning if needed. (Maybe something like, “This represents a change of XXX from our previous experiment.” Again, context is everything.)My reasoning is that the information you’re placing within the alt text is useful to all readers (if perhaps a little redundant for those with perfect sight) and it hides important information from those that have limited sight but don’t use a screen reader. (Someone with glaucoma or macular degeneration, for example.)
Unfortunately terriersT alt text option is not available on their PWA.
There is a pretty nice decision tree to help people decide whether to use alt text and what to describe in it. https://www.w3.org/WAI/tutorials/images/decision-tree/
Also, thanks for sharing the ML backed alt text generator. We are drilling a tunnel from both ends: (1) educate human to write code that is machine readable (2) improve machine to understand code in a human way.
I see lots of hope in (2). Just imagine a screenreader that doesn’t even need to access the DOM!
Not sure why the
<figcaption>
solution needs to use the repeated text and thearia-hidden
. Why not this (which is what I do on my blog)?In VoiceOver it’s read as:
Screenshot of Chrome displaying a split view. On the left is a page full of image thumbnails comparing pre and post-optimization filesize. On the right is Chrome developer tools showing paint rasterize duration for the images., Image
With a 6x CPU slowdown, the longest Paint Raster took 0.27ms, AKA 0.00027 seconds.
It really depends on the image of course, but I find it’s usually easy to draw the line between “describing the image itself” and “providing extra context for the image.”
Did I miss something? When did alt text change from containing any text graphically represented by pixels in the image, to serving as the description? I thought that’s what title was for… O.o
Apparently you aren’t the only one who’s been confused about what title is used for:
https://silktide.com/i-thought-title-text-improved-accessibility-i-was-wrong/
It never changed. Alt text has always been a way to describe an image’s content, in context to what’s important about it relating to the document it has been used in. One way of doing so, is to ensure that any text used in the image is indicated in the alt attribute’s value. So you’re not wrong, but there’s more to it than what you thought :)
The title attribute is not great for accessibility.
Basically, although text should be used to convey the same meaning as the image, and figcaption for extra details. If that text then doesn’t make sense (e.g. duplication of text next to an image as a label, then ask yourself “should this image really be in the html?”. Answer is probably ‘no’.
It’s primarily for screen readers. Always use descriptive alt text where you think it would help accessibility.
Title is not an accessibility feature. Alt Text should contain text as pixels when that is the image, but otherwise describe the image’s function (email vs envelope for an icon) or form (a brief description that makes sense in the image’s context)
Something that’s always rubbed me a bit funny is describing how an image looks visually via alt-text. For example alt-text like “a beautiful sunset” or “a light red car near a dark blue house.” Thesw might not be great examples, but the underlying idea being that if someone is blind, this description offers little useful information, and might even be insensitive (unintentionally, of course).
Applying aria-hidden to figcaption is a problem for users with low vision who use a screen reader to compensate. They may be frustrated to not be able to get their reader to read text that they can tell is on the page. You also have to consider NVDA’s mouse hover mode (default) and iOS VoiceOver’s look-around-by-pointing methods of browsing the page. It’s on the page, so let them hear it. Try to make things as one-to-one as possible, and don’t think of things as existing in the sighted realm vs the non-sighted realm.
aria-hidden (and .sr-only) should be used sparingly.
I use a very useful but also somewhat wonky newsreader that’s great about pulling “read more” text but terrible and pulling images. The result is I probably see way more alt text than the average sighted browser user.
A trend I started noticing maybe a year ago on news and other big-iron content sites has been alt text that uses narrative text instead of expressly describing the image. The result is something more like what Eric Minto describes, above, where the alt text reads more like a callout than a caption.
(Alt text that just duplicates the caption is just tiresome.)
This works great for content, but I’ve started using it in interface elements where it makes sense. For instance using “Return to the [site name] homepage as the alt text for logos instead of leaving it empty or saying something like “[site name] logo.” Describing the logo is more ‘authentically’ descriptive but also uninformative.
I think Evan ( @VamptVo ) is quite right. Repeated text in ALT and Figcaption is definitely not my recommendation as it can be boring to those who use SR. The most important thing is to make the difference between a text that describes an image and a text that adds extra information. On the other hand, the aria-hidden can be useful for design purpose.
So in the end, I think it depends on the image first and the idea of giving the same amount of detailed information for SR users and screen users. One the example Evan gave, this is exactly the issue as if you don’t want to see a small sentence below the image, but you want to give the same information for both types of users… you have to be sure that the hidden figcaption data is placed elsewhere in the page
In case alt and figcaption texts would be the same, you don’t have to repeat yourself. You might give the figcaption an ID and refer to it via aria-labelledby:
I use
alt
strictly to describe the image for the visually impaired, and usefigcaption
to provide more of a comment on the image. I try not to use it to describe the image at all. For example, in a photo of a water slide, I would describe the appearance and the colours of the water slide in thealt
text, but thefigcaption
might be something like, “Looks like a lot of fun!”This, of course, would depend on how I’ve written the copy around the image. Sometimes this
figcaption
may not be necessary at all. That said, with this implementation, I would not usearia-hidden
, so similar to what Evan has said in an earlier comment.In addition to making your website accessible to all users, which is important to ensuring that you are maximizing the value of your traffic, Alt Tags on images can have a positive SEO impact as well. Especially with Google’s rollout of the removal of the “view image”, properly tagging your images for search (meaning using your main keywords in addition to describing what the images are about in your alt tags) can have big impacts on visibility and search rankings.
Alt tags are important for lots of reasons, UX and SEO being just 2 of many.
-Marissa @ VisualFizz http://www.visualfizz.com
WordPress users can leverage the Azure API in this handy plugin too:
https://wordpress.org/plugins/automatic-alternative-text/
We need to keep in mind that “alt” text refers to alternative text that you want to have appear in a browser if for some reason the image it’s associated with can’t show up or to be read out loud; the “alternative” part is important here. I think historically as web developers we were always being told, “Include alt text for your images,” which is… okay… but if you have a decorative image of a family having a picnic and the image can’t display you don’t really need “family having a picnic” showing up in the web page and you don’t need it read out loud by a screen reader.
And there could be some instances where alt text and figcaption text are the same but conceptually they are different.
Of course there’s also the title attribute which is different still. Oh, and wait, there’s also the longdesc attribute… still another thing. Get to know the differences between them all and then use them (or not) appropriately on a case-by-case basis.
Just a few points:
First, The original purpose of the alt attribute is as an alternative to the image. It is only to be used if the image cannot be viewed. This is not limited to visual impairment: text-only browsers, limited bandwidth and a tidy-up gone wrong can also lead to missing images. The alt text should offer a reasonable substitute, rather than just reading off the name of the image.
The alt text was never meant to explain the image. That’s what the title is for, and it is available whether the image is available or not. At one stage IE displayed the alt as a tooltip, but they fixed that. It is only the title which should do that.
Second broadly speaking, you can argue that some images are informational, while some are not (such as those which are purely decorative). The border between the two is not a sharp one. You can then argue that an alt attribute is essential for informational images while not so essential for non-informational images.
Third accessibility tests tend to penalise you for missing alt tags, since they cannot distinguish between informational images and others. That is going to make things complicated if you are trying to implement the advice in this article, which is generally good advice, while trying to pass accessibility tests.
Just saying …