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

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

This article offers a simplified explanation and practical demonstration of WCAG implementation on a document using 3 passing examples and 3 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 document 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, maps, or audio on a document.
"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 Document

How To Run Automated Test for Word, Spreadsheets, Presentations, & PDF Documents

To run an automated test for Success Criterion 1.1.1 on a Word document, spreadsheet, and presentation, we will use the Microsoft Accessibility Checker built into these applications.

While there are many automated testing tools available, for convenience and simplicity, we will use the built-in Microsoft Accessibility Checker for this test.

For PDFs, we will use a different tool to run an automated test.

Automated Test For Word Document

Follow these steps to run an automated test for your Word document:

Start the Microsoft Word application.
Open the document you want to test in Microsoft Word. (Latest version recommended)
Click the 'Review' tab located on the ribbon.
Select the 'Check Accessibility' tab.
View the result on the 'Accessibility' side pane.

The page passes for WCAG success criterion 1.1.1 if:

The result shows 'zero errors' and 'zero warnings' OR
No alternate text issues are detected for any non-text content on the page.

The page fails if:

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

Automated Test For Excel Document

Follow these steps to run an automated test for your spreadsheet document:

Start the Microsoft Excel application.
Open the document you want to test in Microsoft Excel. (Latest version recommended)
Click the 'Review' tab located on the ribbon.
Select the 'Accessibility' tab.
View the result on the 'Accessibility' side pane.

The spreadsheet passes for WCAG success criterion 1.1.1 if:

The result shows 'zero errors' and 'zero warnings' OR
No alternate text issues are detected for any non-text content on the page.

The spreadsheet fails if:

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

Automated Test For PowerPoint Document

Follow these steps to run an automated test for your presentation:

Start the Microsoft PowerPoint application.
Open the document you want to test in Microsoft PowerPoint. (Latest version recommended)
Click the 'Review' tab located on the ribbon.
Select the 'Check Accessibility' tab.
View the result on the 'Accessibility' side pane.

The presentation passes for WCAG success criterion 1.1.1 if:

The result shows 'zero errors' and 'zero warnings' OR
No alternate text issues are detected for any non-text content on the page.

The presentation fails if:

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

Automated Test For PDF Document

The PDF Accessibility Checker (PAC 3) is a free tool designed specifically for checking PDF accessibility against PDF/UA and WCAG standards.

Follow these steps to run an automated test for your PDF using this tool:

Download and run the PDF Accessibility Checker (PAC 3)
On the app window, click the upload button to upload the PDF you want to test.
Navigate to the location of your PDF, and select it.
The tool will automatically run a check to display the results summary.
Click the "WCAG" tab to view the result summary.
Click "Results in Detail" >> "WCAG" >> "Perceivable" >> "Text Alternatives" tabs to view the details.

The PDF passes for WCAG success criterion 1.1.1 if:

The PDF is 100% accessible based on the WCAG result OR
The result shows green tick and an error count of "0" specifically for "Text Alternatives".

The page fails if:

The result shows a red tick and an error count of "1 or any real number" specifically for "Text Alternatives".

How To Run A Manual Test for Word, Spreadsheets, Presentations, & PDF Documents

You can conduct manual checks using various tools. However, to keep things simple, we will manually test all non-text content in a document using a screen reader called NVDA (Non-Visual Desktop Access).

Launch your screen reader. for example, NonVisual Desktop Access (NVDA).
Open the document you want to test using any authoring tool such as Microsoft Office or Adobe acrobat DC.
Use your pointer device to click on each non-text content on the page one after the other.
Listen to the screen reader's voice output.

The word, sheet, presentation, or PDF document passes for WCAG SC 1.1.1 if the voice output of the screen reader accurately describes the non-text content when pointed with the pointer device (mouse).

The word, sheet, presentation, or PDF document fails if there's no voice output or if the voice output does not correctly identify the non-text content.

Examples

Passing Example 1

A lab assistant was instructed to prepare a thesis report in Latin, in a Word document format. The document includes an image demonstrating one of the steps involved in the experiment. The image was properly added with alt text, so when a screen reader focuses on it, it reads: "hands putting something on a microscope slide."

A document being edited in a microsoft word application and showing a pass for accessibility test.

This image is non-text content, and it passes because when a screen reader navigates to it, it outputs a sound that accurately describes the image content.

Failing Example 1

Mr. Andree Rocher is applying for a job at a Japanese company. He prepared his resume and included a passport photograph. However, he forgot to add an alt text attribute to the image.

Andree Rocher Resume open in microsoft word.

The image does not conform to WCAG SC 1.1.1 because it lacks a text alternative. When the screen reader focuses on it, it produces a generic output of "Image," leaving users unsure about the image's content. You can also see from the image that the result generated by the automated tool indicates a missing alt text attribute.

Passing Example 2

A spreadsheet is used to display the income and profit of each product of a company. The document contains a pie chart with relevant information to enhance understanding. Since this pie chart is non-text content, we need to test it for SC 1.1.1 conformance.

A pie chart and a bar chart show the income and profit of a company's products.

This chart meets the success criterion because it is properly associated with alternative text that displays in a tooltip and is read aloud by a screen reader.

Failing Example 2

An XYZ company displays their expenses in a bar chart. However, the bar chart was not properly identified with a text alternative.

This chart fails to meet the success criterion because it is not properly associated with alternative text, and outputs "Chart: Blank". leaving users in the dark.

Passing Example 3

A presentation slide was used to deliver a speech at a university. The only image on the slide outputs "a man standing in front of a whiteboard" when accessed by a screen reader.

A presentation document is displayed in Microsoft PowerPoint.

This image meets our criteria because the screenreader identified and outputs its content in a loud voice.

Failing Example 3

A training presentation displays slide 1 with the organization's details. However, the company logo on this slide outputs "Group object with 12 shapes" when accessed by a screen reader.

A presentation document is displayed in Microsoft PowerPoint.

This non-text content fails to meet this success criterion because the logo was not identified as the official logo of the company featured on the page.

How To Fix Failing Examples

All failing examples can be resolved by simply assigning a descriptive alt text attribute or by assigning a descriptive tooltip through the document editing tools.

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 with your documents? 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, software, or documents?

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 - @ 20:34

Tags: document, sc-1-1-1, wcag