Simplified Guide to WCAG SC 1.1.1: Non-text Content for Web Accessibility

WCAG Success Criterion 1.1.1: Non-Text Content: Web Accessibility

This article offers a simplified explanation and practical demonstrations of WCAG implementation on the web using 5 passing examples and 5 failing examples.

If you need additional technical support for your WCAG projects, don't hesitate to reach out to us.

Get Technical Support

Definition

1.1.1 Non-text Content (Level A)

All non-text content that is presented to the user has a text alternative that serves the equivalent purpose, except for the situations listed below.

Controls, Input: If non-text content is a control or accepts user input, then it has a name that describes its purpose. (Refer to Guideline 4.1 for additional requirements for controls and content that accepts user input.)
Time-Based Media: If non-text content is time-based media, then text alternatives at least provide descriptive identification of the non-text content. (Refer to Guideline 1.2 for additional requirements for media.)
Test: If non-text content is a test or exercise that would be invalid if presented in text, then text alternatives at least provide descriptive identification of the non-text content.
Sensory: If non-text content is primarily intended to create a specific sensory experience, then text alternatives at least provide descriptive identification of the non-text content.
CAPTCHA: If the purpose of non-text content is to confirm that content is being accessed by a person rather than a computer, then text alternatives that identify and describe the purpose of the non-text content are provided, and alternative forms of CAPTCHA using output modes for different types of sensory perception are provided to accommodate different disabilities.
Decoration, Formatting, Invisible: If non-text content is pure decoration, is used only for visual formatting, or is not presented to users, then it is implemented in a way that it can be ignored by assistive technology.

Explanation

This simply means making sure that any piece of content on a webpage that is not in written form has a short or long descriptive text attached to it programmatically to explain what it is for people who can't see it.

Making it clearer:

"Non-text content" refers to information presented in a non-text format like images, charts, graphs, carousels, videos, or audio on a webpage.
"Text alternative" means there is some text-based description or explanation provided to represent the non-text content.
This text alternative must fulfill the same purpose as the non-text content. For example, if there's an image showing a graph, the text alternative should describe the graph's information.
This rule ensures that all users, including those who can't see or access non-text content (like people with visual impairments using screen readers), can still understand the content.

When to Include Alternative Text Descriptions:

Short Description Needed: If there's already text near the non-text content (like an image or chart) that explains its meaning, then a brief description as alt text will suffice. This short description should simply rephrase the nearby text for users who can't see the image itself.
Detailed Description Needed: If there's no text nearby that explains the non-text content, you'll need to provide a more detailed description as alt text. This detailed description should comprehensively explain the information conveyed by the non-text content, ensuring users who rely on screen readers or other assistive technologies can understand it.

In simpler terms:

Text Nearby? Short Alt Text. If there's already text explaining the image, audio, chart, or any non-text content, just write a short version of that text for the alt text.
No Text Nearby? Long Alt Text. If there's no explanation for the image, audio, chart, or any non-text content, write a longer description that explains what it means.

How To Test For Compliance On A Web Page

How To Run Automated Test

To run an automated test for success criterion 1.1.1, we would use the Google Lighthouse tool. There are many tools to simulate automated testing for this success criterion; however, in this test, we will be using the Lighthouse tool for its simplicity.

If you haven't installed the Google Lighthouse Chrome extension, do so.

Follow these steps to run automated testing:

Open the webpage you want to test for SC 1.1.1 conformance.
Click the 'Extensions' icon located on the toolbar of your browser.
Select the 'Lighthouse' extension.
Click the 'Generate report' button and wait for the page to be analyzed.
Scroll down briefly to the accessibility section and observe the result.

The page passes for WCAG success criterion 1.1.1 if:

The report shows 100% for accessibility, OR
No alternate text issues are detected on the page.

The page fails if:

Alternate text issues for any one or more page components are detected and reported by the tool.

How To Run A Manual Test

You can run manual checks using various tools, including screen readers. On this page, we will manually check all non-text content found on a page using the Accessible Name and Description Inspector (ANDI).

If you have not installed ANDI, follow this guide

Open the webpage you want to test.
Launch ANDI by clicking its tab in the bookmarks bar.
Select the "focusable elements" module from the menu options after ANDI launches.
Use your mouse pointer or the "Next" and "Previous" buttons on the ANDI interface to navigate from one highlighted element to the next. (Please note that not all focusable elements are non-text content.)
Observe the ANDI output (for non-text content only).
Repeat step 3, but this time, select the "graphics/images" module from the menu options.
Use your mouse pointer or the "Next" and "Previous" buttons to navigate from one highlighted graphic/image to the next.
Observe the ANDI output.

A non-text content on the page passes if the following points are true:

ANDI output is not blank, AND
ANDI output is a meaningful piece of text that accurately describes the non-text content.

A non-text content on the page fails if any of the following points are true:

ANDI output is blank, OR
ANDI output is not meaningful.

Please note that a piece of non-text content may be hidden in an Iframe on the page. In this case, you will have to select the "iframes" module from ANDI menu and analyze the content similarly. If you do not see the "iframes" option, then no iframes were used on the page.

Please note that you can also use screen reader to conduct manual testing for this success criterion. Follow these easy steps to do that:

Launch your screen reader. for example, NonVisual Desktop Access (NVDA).
Open the page you want to test.
Use your pointer device to point all non-text content on the page one after the other.
Listen to the screen reader's voice output.

A non-text content passes if the voice output of the screen reader accurately describes the content when pointed with the pointer device (mouse).

A non-text content fails if there's no voice output, or if the voice output does not make sense.

Examples

Passing Example 1

An image of a red-eyed frog presented in an article on the National Geographic website titled: 13 Gorgeous Pictures Remind Us Why Frogs Need Our Help

This image is non-text content, and it passes because when a screen reader navigates to it, it outputs a sound that says "red-eyed tree frog.".

Failing Example 1

An image of an Agama lizard was presented to users in an article on the XYZ website titled "How Tropical Agama Survives.". The image of Agama does not output any sound when a screen reader navigates to it.

This image does not conform to WCAG SC 1.1.1 because it lacks a text alternative. When the screen reader focused on it, there was no audible description provided.

Passing Example 2

A YouTube video is embedded in an article titled Simplified Guide to WCAG SC 1.1.1: Non-text Content for Web Accessibility

This video meets the success criterion because the embedded iframe has a descriptive title: "Youtube Video Player Showing How To Run a Manual Test". When the video is focused, a screen reader will announce this title, effectively providing a short text alternative to the video. Please note that the video is an alternative to the surrounding text that describes the content of the video.

Failing Example 2

A video is embedded in an article on the XYZ website, that discusses "Zombies". This video is embedded within an untitled iframe.

This video does not meet the accessibility criterion because the iframe lacks a title. When focused, the screen reader only announces "iframe", providing no context about the content within the iframe. This omission leaves screen reader users unaware of the content contained in the iframe.

Passing Example 3

A US government website features a chart on a page titled: Federal Reserve Board - Recent balance sheet trends,

The chart is not accessible, but a nearby link directs users to a page where the same data is presented in text format. This approach aligns with the requirements of this success criterion, and this is a good passing example.

Failing Example 3

A non-image chart is displayed on an XYZ website, the chart is dynamic, complex, and inaccessible. However, no alternate version (in text) that presents the same data was implemented.

This non-text content fails to meet this success criterion because the chart itself is inaccessible, and there's no textual alternative available to present the same data.

Passing Example 4

A banking website displays a CAPTCHA challenge to prevent bots from automatically signing up, the website implemented a linked text nearby that reads: "Prove you are a real human by taking the audio version of CAPTCHA"

This CAPTCHA provides a text alternative that guides users to access the audio version of the information presented in the CAPTCHA.

It's important to note that the CAPTCHA value itself cannot be provided in text format to maintain the challenge's integrity. Instead, the text alternative serves to describe and redirect users to alternative formats of the same challenge.

Failing Example 4

An XYZ website implemented a security check using CAPTCHA. However, it lacks audio or other safe alternative versions of the CAPTCHA, and there's no text alternative to describe and direct users to these versions.

This CAPTCHA challenge fails because it lacks a text alternative that describes and directs users to another accessible version of the same challenge. When a screen reader focuses on it, it either outputs nothing or simply says "CAPTCHA," providing no useful information to users with disabilities.

Passing Example 5

Accessmeter.com displays a Google map (in an iframe) showing the location of one of its offices on the Contact Us page.

This map is accessible because the iframe has been correctly labeled as "Office Location of Accessmeter.com on Google Maps." When the map receives focus, a screen reader will read out this descriptive text. Additionally, it's important to know that the location details shown on the map are also provided in nearby text.

Failing Example 5

The contact page of XYZ website features a Google map (in an iframe) showing the location of their head office.

This content fails to conform to WCAG SC 1.1.1 because the iframe is not titled, and when focused, screen readers will not output any sound.

How To Fix Failing Examples

How To Fix Failing Example 1

Failing example 1 can be easily corrected by adding an "alt" attribute to the image tag. This attribute should contain a brief or detailed description of the image's content, as demonstrated in the provided code snippet.

The following code snippet shows how to include an alt text in an image:


<!-- Your HTML code snippet here -->
<img src="example.jpg" alt="A red-headed Agama Lizard">

How To Fix Failing Example 2

To fix Example 2, adjust the title attribute of the YouTube embed code. Replace the generic "YouTube video player" with a descriptive title that accurately reflects the video content.

In the "Before" example, the title attribute of the embedded YouTube video player is by default set to a generic value, "YouTube video player."

In the "After" example, the title attribute is updated to provide a more descriptive title that reflects the content of the video being embedded.

The title can be brief if there is surrounding text that talks about the video, If there is no related surrounding text, consider creating a whole alternative to the video.

The following code snippets show how to embed YouTube videos in an HTML document with descriptive titles:


<!-- Embed a YouTube video with a generic title -->
<iframe src="https://www.youtube.com/embed/VIDEO_ID" title="Youtube video player"></iframe>

<!-- Embed a YouTube video with a more descriptive title -->
<iframe src="https://www.youtube.com/embed/VIDEO_ID" title="Something more descriptive of the video content"></iframe>

How To Fix Failing Example 3

You can resolve failing example 3 by creating an alternative table that displays the same data as the chart. Then, you can label either the chart as an alternative to the table or the table as an alternative to the chart. Alternatively, you can provide a link to another page hosting the same data in tabulated text format.

Ensure that the table you create is accessible.

How To Fix Failing Example 4

To fix the failing example 4, you can assign an ARIA label to the CAPTCHA image, indicating its purpose. Then, link the image to an alternate version of the same CAPTCHA content, with a label clarifying that clicking the image will lead to the alternate version. Alternatively, provide a separate link to the alternate version, clearly labeled with text that explains its purpose.

The following code snippets show how to provide an alternate audio CAPTCHA for users who cannot see the CAPTCHA image:


<a href="alternate_captcha_sound.html" aria-label="CAPTCHA: Click to listen to the sound alternate version">
  <img src="captcha_image.jpg" alt="CAPTCHA Image">
</a>

<p>Can't see the CAPTCHA image? <a href="alternate_captcha_sound.html">Click here</a> to listen to the sound alternate version.</p>

How To Fix Failing Example 5

To fix failing example 5, you need to do two things. First, add a descriptive title or an ARIA label to the iframe that embeds the map. Second, create a text version that describes the same office address as shown in the map.

The following code snippets show how to embed a Google Map and include a text version of the address:


<!-- Google Maps Embed -->
<iframe src="https://www.google.com/maps/embed?pb=!1m18!1m12!1m3!1d156698.079922076!2d-122.49040297311342!3d37.75776279928813!2m3!1f0!2f0!3f0!3m2!1i1024!2i768!4f13.1!3m3!1m2!1s0x808f80d70dd47f47%3A0xe1e7b02fcf0cbdc!2sGolden%20Gate%20Bridge!5e0!3m2!1sen!2sus!4v1622128359771!5m2!1sen!2sus" width="600" height="450" style="border:0;" allowfullscreen="" loading="lazy" aria-label="Google Map showing Golden Gate Bridge"></iframe>

<!-- Text version of the address -->
<p>123 Main Street, City, State, ZIP</p>

FAQs

Non-text content refers to any information on a webpage or digital interface that is not in text form. Examples include videos, audio, charts, graphs, maps, and captchas, ETC.

No, buttons, icons, and separators are not considered content under WCAG success criterion 1.1.1. Here, "content" specifically refers to useful information conveyed to the user. Elements like buttons, icons, and lines are considered enhancements, and their accessibility is covered by other success criteria.

It depends. If the information conveyed by the non-text content is also available in text format elsewhere on the page, you can safely hide the non-text content using the [aria-hidden="true"] attribute. However, if this information is completely or partially missing in text form, you must ensure the non-text content is accessible to assistive technologies.

Need help? Book a call at a time to suit your schedule

Do you need professional accessibility testing, custom reports, and ongoing collaboration with your developers to fix issues on your site?

Book Appointment

Written by:

Samuel Enyi

Sammi is a seasoned accessibility expert with over a decade of experience. He holds several professional certifications in web development, a Trusted Tester certification from the U.S. Department of Homeland Security, and a Bachelor's degree in Electrical-Electronics Engineering. Sammi excels at managing client accessibility needs across multiple platforms and enjoys simplifying complex problems.

Olivera Peter

Olivera is a meticulous proofreader and editor with a bachelor's degree in linguistics. She ensures our blog remains error-free with her keen eye for detail. Outside of work, she enjoys traveling and playing tennis.

Ramib Abeeb

Ramib is a Computer Science graduate who brings a wealth of experience to the table. He is passionate about supporting individuals with disabilities, dedicating his expertise to making their work environments more accessible and user-friendly.

Filed under: Articles - @ 21:23

Tags: sc-1-1-1, wcag, web