WCAG 1.1.1 Non-Text Content (Level A)
When there is non-text content, like images on a page, there should be a suitable text alternative.
This is because information conveyed in text can be provided to the user by different methods, like audio or braille. A person that cannot see an image can listen to audio describing it, and a person that can't hear a video can read a transcript, or captions.
Sound simple enough? There are lots of different complications and edge cases that need thinking about. What if a short text description simply cannot explain the media content? What about CAPTCHAs, where a text alternative would defeat the object? This section explains what we can do in these scenarios.
A Captcha is used to determine whether a form is actually being completed by a human.
This is to protect against things like automated spam bots.
Captchas ask the user to complete a task. There must be some text on the page that explains to the user what they have to do.
For example, if a Captcha shows an obscured image, there should be an instruction such as "Type the words in the image".
There may be cases where a user with a disability can't complete the Captcha task, such as a blind user being asked what is in an obscured image.
It must be possible for the user to complete an alternative Captcha task that uses a different mode of test. For example, a visual task of typing words in an image, with the option of an audio task of typing the letters spoken in an audio file.
The fact that an alternative mode is possible and how to switch to it must be explained to the user.
Ensure that there are clear instructions for how to complete a CAPTCHA.
Switch to a different CAPTCHA provider if it doesn't offer a different mode of test, like both a visual and an audio task.
If you're looking for an alternative, Google's reCAPTCHA is probably the best one out there.
Alternatively, consider whether a CAPTCHA is actually needed on this page at all. Even CAPTCHAs that pass the WCAG can still be pretty confusing for some people and they may give up trying. Try to judge what is best for your users.
Some users cannot see images well, or hear audio. By providing text that conveys the same information, they do not miss out on content. For example, a user that is blind may have the page read out to them by a screen reader. When they encounter an image on the page, they need to know what the image is.
The accessible text should be a full text alternative for the media. This includes any text included in images and/or a general explanation of what is shown.
Some examples of accessible text are shown here:
You need to set the accessible text on the element, and ensure that it accurately describes the media.
For images, use the alt attribute to set the accessible text:
<img src="roses.jpg" alt="12 red roses" / >
For other media, you can use the ARIA attributes for setting accessible text.
If the text that identifies what the media is is already present in another element, you can add the aria-labelledby attribute to the control, and set it to the ID of the element with the appropriate text.
<h2 id="success">Success! </h2> <audio src="success.wav" aria-labelledby="success"></audio>
Sometimes, the appropriate text is not present in a separate element for you to reference. In this case you can just specify what the text is by adding the aria-label attribute to the control.
<audio src="applause.wav" aria-label="Applause"></audio>
WCAG 1.2.1 Audio-only and Video-only (Prerecorded) (Level A)
WCAG 1.2.2 Captions (Prerecorded) (Level A)
This set of tests ensures that videos with an accompanying audio track include captions, which are used by people with hearing loss to access the audio information. The text is overlaid onto the video.
You don’t have to include captions if a full text transcript is suitable for the media and made available.
People who are deaf or have a hearing loss can use captions to access the audio information in the video. The text is overlaid onto the video.
Captions can be open or closed. Open captions are always present and closed captions can be switched on or off.
I personally find captions useful myself when I'm in the office. Some users may not be able to hear the audio because of a noisy environment, or not want to disturb others so this is a general benefit that should result in more people consuming your content.
Captions have to include all of the audio content, such as laughter and sound effects, not just the spoken word.
Open captions are always present and closed captions can be switched on or off. It doesn’t matter which kind of captions are used; both are acceptable.
YouTube does some of the job for you, as it has an automatic captioning feature. Note that I say some of the job. The automatic captioning is not perfect and so it's important to review it and make amendments where YouTube gets confused. Saying that, I find it quite quick and easy to have YouTube do the auto captioning and then I tweak things as it's pretty accurate.
When you upload a video to YouTube, it will automatically add the captions for you, it's not a feature that you have to enable, but it does take a while for the captions to show up after the video is published.
On the video screen, click on the "Subtitles / CC" menu item.
Then select the "English (Automatic)" captions option, which will be present if YouTube has finished captioning it.
You then see your video with the snippets of text associated with a few seconds of video content.
There's an Edit button in the top right, which allows you to edit the text snippets as you play through the video.
You can then publish the changes.
If you’re not using YouTube, you’re going to need to produce captions in a format called WebVTT.
This is a text format that basically contains the text to show alongside the time in the video to display them.
A typical WebVTT file has a .vtt file extension and looks like this:
WEBVTT 1 00:00:22.230 --> 00:00:24.606 This is some text for the first caption. 2 00:00:30.739 --> 00:00:34.074 A later caption.
You can specify some more advanced options like styling, positioning and person speaking. This is a pretty good guide to the format:
This isn’t something you’re going to want to produce yourself, unless you have a big content production team. Instead, you can easily find an agency that can produce .vtt files for your videos, or hire a freelancer on a service like Upwork.
If you're displaying a video using a <video> element in the HTML, you just have to reference the .vtt file.
To do this, include a <track> element. This should reference your source file, state that it is the captions and also specify the language that the captions are written in.
<video controls> <source src="video/short.mp4" type="video/mp4"> <track kind="captions" srclang="en" src="captions/en.vtt"> </video>
If you’re hosting your video on Vimeo, they allow you to upload the .vtt file containing captions for the video, under the Advanced menu.
Captions are arguably more useful for the end user as they synchronize the text with the video. If the video content is such that it could be explained with a full text transcript, this is an acceptable alternative.
This won’t apply in all scenarios – you wouldn’t want to read a text transcript alongside a movie! But if the video is short and is just explaining one simple concept, for example, a transcript will work.
A full transcript must include all relevant sounds from the video, such as sound effects or laughter.
WCAG 1.2.3 Audio Description or Media Alternative (Prerecorded) (Level A)