WCAG 1.1.1

Non-Text Content

1.1.1 Non-Text Content is a Level A criterion. (What does Level A mean?)

You may want to read the official WCAG Guidelines for 1.1.1, but I recommend you come back here as this guide is much easier to understand!

Introduction

This criterion is all about the content on your website that isn't text-based, like images, videos and even form fields.

Most of the work to be done here is providing text alternatives for all that media, and making it clear which media element the text relates to.

Why text alternatives? They can be represented in some form to everyone. Text can be read out by a text-to-speech program, or sent to a braille display.

Who Benefits?

An icon image of a young woman wearing dark glasses

Sandra has very poor eyesight, so she uses a screen reader. This is a program that reads out the content of a website, following the user's keyboard instructions.

When developers provide a text alternative for an image, Sandra can still understand what it is showing. She also benefits from audio descriptions of video content to understand what is happening on screen.

An icon image of a man in a shirt and tie

Deepak is deaf and so he can't fully understand any video without captions or a text alternative. He'd also need a transcript of any audio-only content, like podcasts.

An icon image of a man in glasses

Henry doesn't have any issues browsing the web. He's here because all the additional text content on a fully accessible site boosts the search ranking.

All of the above users will be more likely to find and use your site if it's accessible so another person that benefits is you!

There's a lot of things to cover, this is probably the biggest criterion of the bunch, so let's start with...

Images

Alt Text

Probably the most well-known accessibility technique there is, images need "alt text" to explain what they are to non-sighted users.

What that means in practice is that the <img> tag has an alt attribute to contain the text:

<img src="fish.jpg" alt="A goldfish" />

Remember the purpose of the alt text is to explain what the image is. That means it should contain any text that is shown in the image, and give a general idea of the purpose.

Some examples of alt text are shown here:

Four examples of alt text, including a logo, image with text, product image and a photo

One thing to watch out for is that CMS systems and other content editors tend to just add images without asking you for alt text, or worse, use something irrelevant like the file name. Users don't want to encounter "931381-large.jpg" as alt text!

If you are using some kind of rich content editor, make sure it allows you to add alt text, and educate users on how to add it in too.

Decorative Images

Sometimes an image is present on the page purely to make it look good, and it isn’t there to convey any information at all. These are decorative images. 

Three examples of images that are just decorative, and don't add any meaning to the text next to them

An image is not decorative if the user would struggle to understand the page without it, like if it contains some text or a chart. If the image is a button or performs some other function, it is not decorative, as it is serving a purpose on the page.

There are also images and iframes that are used for adverts, or some other third-party tracking tool. These may or may not be shown to the user.

Just because an image contains text doesn't necessarily mean it's non-decorative. If the text is repeated as plain text in close proximity to the image, the image is not really adding anything, so it's decorative. Consider the whole context of the page.  

I would say that all of the images below are non-decorative. There is information being conveyed with each.

Examples of non-decorative images, including buttons, product images, logos and a data chart

What we’re trying to determine here is whether the image would need explaining in some way to a non-sighted user, or whether they can just ignore the fact that it is there completely. 

If an image is decorative, ensure that you don't have alternative text set on it. For a decorative image, you would include the alt attribute but leave it as blank. Removing the alt attribute completely would still cause the assistive technology to announce that there was an image, but by setting it to blank, it is explicit that there is no text alternative.

<img src="decorative.jpg" alt="" />

For other media that is decorative, ensure that you're not setting aria-label or aria-labelledby on the element, or associating a label element with it.

You can also tell assistive technologies to ignore media by setting the role attribute to presentation.

<img src="decorative.jpg" role="presentation" />

CSS Backgrounds

When an image is included using CSS, it cannot be detected by assistive technologies like screen readers. Non-decorative images should be included as image tags in the markup, as they can then have alternative text that is read out.

Including images with CSS alone can also be an issue for users who use alternative backgrounds to make text easier to read, as the image could be lost. 

Complex media

Most images can be easily described, like "Mc Donalds logo", or "Search". Sometimes, it conveys too much information for a couple of sentences of description to explain it, like an infographic, or data chart.

A complex line chart of data about pets

For this kind of media that cannot have a short text alternative, a full text alternative still needs to be provided. It doesn’t necessarily have to be next to the media or even on the same page of the website.

The full text alternative must convey all the information that the media does, in a text format.

For charts like the above, a full text alternative would describe the general trends that can be seen, along with a table of the data values presented. If there were too many data values to be understood from a table, a full discussion of the trends and conclusions from the data would be sufficient.

The accessible text on the element itself should be used to give an idea of what the media is. For example, “Line chart showing number of purchases per month in 2017”, or “Interview with the developer of the app”, and should also state where the full text alternative is, if this is not clear.

Can't Write Alt Text?

There are some types of content that can't have a full text alternative. They should still have accessible text that describes generally what the media is though.

Some tests or exercises have to be completed using non-text content. For example, there is no point in providing a text alternative for an online hearing test, or a spelling test.

Also, certain content cannot be adequately represented in text because the aim is to provide a specific sensory experience. For example, a music track or work of art.

In those situations, you should still provide alt text so that the user knows what it is, like the name of a painting or "Question 2".

Image Checklist

Add a text alternative for an image by using the alt attribute.

Make sure that the text alternative fully explains what the image is showing.

If an image is decorative, use an empty alt attribute. No alt attribute at all is not valid.

Only use CSS backgrounds to include decorative images, not those with a purpose.

Complex media like data charts still need a full text alternative, but it may be elsewhere on the page, as long as the alt text explains where.

Only tests/exercises or specific sensory experiences don't need a full alternative. They still need a name in the alt attribute.

Audio / Video Content

There are other criteria that address audio and video content specifically.

For WCAG 1.1.1, it is sufficient that the audio/video content is given accessible text that explains what it is. You can use the aria-label attribute for this.

<audio src="applause.wav" aria-label="Applause"></audio>

Audio / Video Checklist

Ensure that all audio/video content has an aria-label attribute that explains what it is.

Form Fields

Form fields are also non-text content. Our task here is to ensure that all of our form fields are labelled correctly.

I'm going to run through some useful techniques for form field labelling. One thing to bear in mind throughout is that the label text has to be clear. You can have the HTML markup spot on and still fail the WCAG because the label did not accurately describe what the form field is.

The Label Element

There are a number of form elements that can have explicit labels:

  • input type="checkbox / color / date / datetime-local / email / file / month / number / password / radio / range / search / tel / text / time / url / week"
  • textarea
  • select

If there is a <label> element for the control, add a for attribute to the label. The value should be the ID of the form control that you're labelling. This tells the browser that this label is specifically associated with the form control.

Text input box next to a label that reads “Name”
<label for="txtName">Name</label> 
<input type="text" id="txtName" />

It is also possible to place a control within a label element to indicate the relationship between the two. This is a perfectly valid method as well and can be useful if you don't want to assign IDs to all your inputs.

<label>Name <input type="text" /></label>

ARIA Labels

Your design might not have specific, visible labels for each form control. There may not need to be one for sighted users if the context is clear.

It's clear to sighted users that this is a close button:

A small button with a cross in it

In this situation you can just specify what the label is by adding the aria-label attribute to the control.

<button aria-label="Close">X</button>

It's also pretty easy to see that this text box is where a search term would go:

Text input box next to a Search button

A screen reader user would just encounter it as an unlabelled box, so it needs to be labelled somehow.

The text that actually identifies this input is in the Search button that follows.

If the text that identifies what the control is for 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.

<input type="text" aria-labelledby="btnSearch" />
<button id="btnSearch">Search</button>

Now a screen reader user would know that this text box relates to Search.

Some controls have their own way to specify a label.

Buttons

The text alternative for a button is just its content. This may be direct text content, or via the alt attribute of an image within the button. Both are valid methods.

<button>Submit</button> 

<button><img src="next.jpg" alt="Next" /></button>

Aria-label attributes also work, as shown before.

Input type="button/submit/reset"

For inputs of type button, submit or reset, the button text and therefore the label for the control is provided in the value attribute.

<input type="button" value="Next" />

Links

Links are similar to buttons, where the text alternative is taken from the content.

<a href='/about'>About Us</a> 

<a href='/home'><img src="back.jpg" alt="Back to Home" /></a>

Placeholders don't count!

You might have a placeholder attribute on the input control, which tells a sighted user what it's for

 A text box with a placeholder that reads Email Address

This doesn't count as an accessible name as it disappears when the user clicks into the box. If you don't want to add separate visible labels to your design, add the text into the aria-label attribute to ensure that non-sighted users can understand what it is for.

<input type="text" aria-label="Email Address"
    placeholder="Email Address" />

Form Field Checklist

Ensure that any label text clearly describes what the form field is.

Most form controls can have an associated <label> element. Make sure you either use the for attribute or place the form control inside the label so that they are linked.

If you don't want to add a visible label, add an aria-label attribute to the form control to contain the label text.

If a button or link just contains an image, make sure the image has alt text, or add an aria-label attribute to it.

CAPTCHAs

Yes, the lovely CAPTCHA fits under this criterion too.

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

Screenshot of a captcha with the instruction text: “Type the two words”.

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.

A Captcha asking the user to type characters from an image, with an audio button, “Speak the Captcha code”

The fact that an alternative mode is possible and how to switch to it must be explained to the user.

Most importantly, consider whether a CAPTCHA is actually needed 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.

CAPTCHA Checklist

Consider whether you actually need a CAPTCHA or if you risk driving users away from the site.

Ensure that there is instruction text to explain how to use the CAPTCHA.

The CAPTCHA must have two different modes for completing it, such as a visual task to read text and an audio task.

Both task modes must be clearly explained to the user.