Articles Archives - Accessmeter Consulting

Category: Articles

Uncover a rich trove of articles exploring accessibility, QA, along with a spectrum of testing topics.
Delve into detailed analyses, practical guidance, and the latest industry insights in our articles category. Gain valuable resources to stay informed and inspired amidst the evolving landscape of digital accessibility, usability testing, security testing, and more.

E-commerce: Accessible Data Tables

Posted on by Samuel Enyi

E-commerce: Accessible Data Tables

<p>We evaluated several e-commerce sites and found that most of them feature data tables. This is likely because data tables effectively organize and present large amounts of information clearly.</p>

Notably, over 80% of these data tables were not properly implemented using accessible coding best practices.

Learn more about accessible data tables and how to address prevalent data table issues, which can potentially resolve up to 90% of the challenges commonly encountered by these platforms.

<p>If you need custom support for your accessibility project, we are experts ready to help.</p>
        <a href="/contact" target="_self" rel="noopener">
                        Get Support
        </a>
<h3>What is a data table?</h3>

To keep it simple, A data table is a structured arrangement of data in rows and columns that makes it easier to view, organize, and analyze information.

Broadly speaking, there are two types of tables:

  • Presentation tables: Used purely to arrange page elements visually. These tables are not intended to convey structured data but rather to help with the layout and design of a webpage. They often involve merging cells or adding styles to achieve a desired appearance.
  • Data tables: Used to present data in a logical and organized way. These tables are designed to display structured information, making it easy for users to read, compare, and analyze data.

In the context of e-commerce sites, data tables are often used to display product lists, customer information, order details, stock prices, financial records, and other relevant data in a systematic way. Each row typically represents a different item or entry, while each column represents a different attribute or piece of information about those entries.

Data tables allow users to quickly scan and compare different pieces of data, and they also facilitate various operations like sorting, filtering, and searching within the table.

Proper implementation of data tables includes ensuring accessibility features, such as using appropriate semantic HTML tags (<table>, <tr>, <th>, <td>) and providing descriptive headers and captions, to ensure that the information is accessible to all users, including those using assistive technologies.

Wrongly implemented data tables pose a significant challenge to users with disabilities. This is because assistive technologies may not be able to properly associate each piece of data within the table with its appropriate column and/or row headers.

<h3>Types of data tables</h3>

In the context of accessibility testing, we recognize three simple types of data tables, which are:

  1. Tables with column headers only: These tables have headers at the top of each column, providing context for the data in that column. Each cell in the table is associated with a column header, but there are no row headers.
  2. Tables with row headers only: These tables have headers at the beginning of each row, giving context for the data in that row. Each cell in the table is associated with a row header, but there are no column headers.
  3. Tables with both column and row headers: These tables have headers for both columns and rows, offering a comprehensive context for each cell by providing relevant information from both dimensions. This type of table is particularly useful for displaying complex data where understanding the relationship between rows and columns is important.

Building Accessible Data Tables: Best Practices

Posted on by Samuel Enyi

E-commerce: Accessible Data Tables

We evaluated several e-commerce sites and found that most of them feature data tables. This is likely because data tables effectively organize and present large amounts of information clearly.

Notably, over 80% of these data tables were not properly implemented using accessible coding best practices.

Learn more about accessible data tables and how to address prevalent data table issues, which can potentially resolve up to 90% of the challenges commonly encountered by these platforms.

If you need custom support for your accessibility project, we are experts ready to help.

Get Support

What is a data table?

To keep it simple, A data table is a structured arrangement of data in rows and columns that makes it easier to view, organize, and analyze information.

Broadly speaking, there are two types of tables:

  • Presentation tables: Used purely to arrange page elements visually. These tables are not intended to convey structured data but rather to help with the layout and design of a webpage. They often involve merging cells or adding styles to achieve a desired appearance.
  • Data tables: Used to present data in a logical and organized way. These tables are designed to display structured information, making it easy for users to read, compare, and analyze data.

In the context of e-commerce sites, data tables are often used to display product lists, customer information, order details, stock prices, financial records, and other relevant data in a systematic way. Each row typically represents a different item or entry, while each column represents a different attribute or piece of information about those entries.

Data tables allow users to quickly scan and compare different pieces of data, and they also facilitate various operations like sorting, filtering, and searching within the table.

Proper implementation of data tables includes ensuring accessibility features, such as using appropriate semantic HTML tags (<table>, <tr>, <th>, <td>) and providing descriptive headers and captions, to ensure that the information is accessible to all users, including those using assistive technologies.

Wrongly implemented data tables pose a significant challenge to users with disabilities. This is because assistive technologies may not be able to properly associate each piece of data within the table with its appropriate column and/or row headers.

Types of data tables

In the context of accessibility testing, we recognize three simple types of data tables, which are:

  1. Tables with column headers only: These tables have headers at the top of each column, providing context for the data in that column. Each cell in the table is associated with a column header, but there are no row headers.
  2. Tables with row headers only: These tables have headers at the beginning of each row, giving context for the data in that row. Each cell in the table is associated with a row header, but there are no column headers.
  3. Tables with both column and row headers: These tables have headers for both columns and rows, offering a comprehensive context for each cell by providing relevant information from both dimensions. This type of table is particularly useful for displaying complex data where understanding the relationship between rows and columns is important.

Why creating accessible data tables is important

Creating accessible data tables is important because it ensures that all users, including those with disabilities, can access and understand the information presented. According to the Web Content Accessibility Guideline (WCAG), Success Criterion 1.3.1-Info and Relationships. Information, structure, and relationships conveyed through presentation should be programmatically determinable or available in text.

This implies that:

  • Data tables should allow screen readers and other assistive technologies to correctly interpret and convey the data to users, ensuring that those who rely on these tools can navigate and comprehend the table’s content.
  • Providing accessible data tables promotes equal access to information for everyone, regardless of their abilities. This is essential for inclusivity and non-discrimination.
  • Well-structured, accessible tables enhance usability for all users by making data easier to read, understand, and interact with. This leads to a better user experience overall.

Alright, enough of the background stuff. Let’s dive into passing examples and failing examples for each type of data table.

Tables with column headers only

Failing Example:

Code:
The following code snippet shows a failing data table with only column headers: <table> <caption>Quarterly Sales Data</caption> <tr> <td>1st Quarter</td> <td>2nd Quarter</td> <td>3rd Quarter</td> <td>4th Quarter</td> </tr> <tr> <td>100</td> <td>120</td> <td>80</td> <td>90</td> </tr> <tr> <td>150</td> <td>130</td> <td>95</td> <td>110</td> </tr> <tr> <td>80</td> <td>100</td> <td>70</td> <td>85</td> </tr> <tr> <td>200</td> <td>180</td> <td>150</td> <td>160</td> </tr> <tr> <td>530</td> <td>530</td> <td>395</td> <td>445</td> </tr> </table>
Result:
Quarterly Sales Data
1st Quarter 2nd Quarter 3rd Quarter 4th Quarter
100 120 80 90
150 130 95 110
80 100 70 85
200 180 150 160
530 530 395 445

This table is a failing example because it lacks a <th> element to define the column headers and a <tbody> element to define the table body. Screen readers will struggle to associate the data cells with their appropriate headers, leading to confusion for users relying on assistive technologies.

Passing Example

Code:
The following code snippet shows a passing data table with only column headers: <table> <caption>Quarterly Sales Data</caption> <thead> <tr> <th>1st Quarter</th> <th>2nd Quarter</th> <th>3rd Quarter</th> <th>4th Quarter</th> </tr> </thead> <tbody> <tr> <td>100</td> <td>120</td> <td>80</td> <td>90</td> </tr> <tr> <td>150</td> <td>130</td> <td>95</td> <td>110</td> </tr> <tr> <td>80</td> <td>100</td> <td>70</td> <td>85</td> </tr> <tr> <td>200</td> <td>180</td> <td>150</td> <td>160</td> </tr> <tr> <td>530</td> <td>530</td> <td>395</td> <td>445</td> </tr> </tbody> </table>
Result:

 

Quarterly Sales Data
1st Quarter 2nd Quarter 3rd Quarter 4th Quarter
100 120 80 90
150 130 95 110
80 100 70 85
200 180 150 160
530 530 395 445

This table is a passing example because there is a <thead> element to define the column headers and a <tbody> element to define the table body. Screen readers will properly associate the data cells with their appropriate headers.

Tables with Row headers only

Failing Example:

Code:
The following code snippet shows a data table with only row headers: <table> <caption>Quarterly Sales Data</caption> <tr> <td>1st Quarter</td> </tr> <tr> <td>2nd Quarter</td> </tr> <tr> <td>3rd Quarter</td> </tr> <tr> <td>4th Quarter</td> </tr> <tr> <td>100</td> </tr> <tr> <td>120</td> </tr> <tr> <td>80</td> </tr> <tr> <td>90</td> </tr> <tr> <td>150</td> </tr> <tr> <td>130</td> </tr> <tr> <td>95</td> </tr> <tr> <td>110</td> </tr> <tr> <td>80</td> </tr> <tr> <td>100</td> </tr> <tr> <td>70</td> </tr> <tr> <td>85</td> </tr> <tr> <td>200</td> </tr> <tr> <td>180</td> </tr> <tr> <td>150</td> </tr> <tr> <td>160</td> </tr> <tr> <td>530</td> </tr> <tr> <td>530</td> </tr> <tr> <td>395</td> </tr> <tr> <td>445</td> </tr> </table>
Result:
Quarterly Sales Data
1st Quarter 100 150 80 200 530
2nd Quarter 120 130 100 180 530
3rd Quarter 80 95 70 150 395
4th Quarter 90 110 85 160 445

This table is a failing example because there is no <th> element to define the table headers. Screen readers will not properly associate the data cells with their appropriate row headers.

Passing Example

Code:
The following code snippet shows a data table with only row headers: <table width="548"> <caption>Quarterly Sales Data</caption> <tbody> <tr> <th scope="row">1st Quarter</th> <td>100</td> <td>150</td> <td>80</td> <td>200</td> <td>530</td> </tr> <tr> <th scope="row">2nd Quarter</th> <td>120</td> <td>130</td> <td>100</td> <td>180</td> <td>530</td> </tr> <tr> <th scope="row">3rd Quarter</th> <td>80</td> <td>95</td> <td>70</td> <td>150</td> <td>395</td> </tr> <tr> <th scope="row">4th Quarter</th> <td>90</td> <td>110</td> <td>85</td> <td>160</td> <td>445</td> </tr> </tbody> </table>
Result:

 

Quarterly Sales Data
1st Quarter 100 150 80 200 530
2nd Quarter 120 130 100 180 530
3rd Quarter 80 95 70 150 395
4th Quarter 90 110 85 160 445

This table is a passing example because there is a <th> element to define the row headers and a <tbody> element to define the table body. Screen readers will properly associate the data cells with their appropriate row headers.

Tables with Both Column & Row headers

Failing Example:

Code:
The following code snippet shows a data table with both row and column headers: <table style="height: 238px;" width="548"> <caption>Quarterly Sales Data</caption> <thead> <tr> <th></th> <th>Week 1</th> <th>Week 2</th> <th>Week 3</th> <th>Week 4</th> <th>Week 5</th> </tr> </thead> <tbody> <tr> <td scope="row">1st Quarter</td> <td>100</td> <td>150</td> <td>80</td> <td>200</td> <td>530</td> </tr> <tr> <td scope="row">2nd Quarter</td> <td>120</td> <td>130</td> <td>100</td> <td>180</td> <td>530</td> </tr> <tr> <td scope="row">3rd Quarter</td> <td>80</td> <td>95</td> <td>70</td> <td>150</td> <td>395</td> </tr> <tr> <td scope="row">4th Quarter</td> <td>90</td> <td>110</td> <td>85</td> <td>160</td> <td>445</td> </tr> </tbody> </table>
Result:
Quarterly Sales Data
Week 1 Week 2 Week 3 Week 4 Week 5
1st Quarter 100 150 80 200 530
2nd Quarter 120 130 100 180 530
3rd Quarter 80 95 70 150 395
4th Quarter 90 110 85 160 445

This table is a failing example because it lacks <th> elements to define the row headers. While screen readers will correctly associate each data cell with its column headers, they will not properly associate the data cells with their corresponding row headers.

Passing Example

Code:
The following code snippet shows a data table with both row and column headers: <table style="height: 238px;" width="548"> <caption>Quarterly Sales Data</caption> <thead> <tr> <th></th> <th>Week 1</th> <th>Week 2</th> <th>Week 3</th> <th>Week 4</th> <th>Week 5</th> </tr> </thead> <tbody> <tr> <th scope="row">1st Quarter</th> <td>100</td> <td>150</td> <td>80</td> <td>200</td> <td>530</td> </tr> <tr> <th scope="row">2nd Quarter</th> <td>120</td> <td>130</td> <td>100</td> <td>180</td> <td>530</td> </tr> <tr> <th scope="row">3rd Quarter</th> <td>80</td> <td>95</td> <td>70</td> <td>150</td> <td>395</td> </tr> <tr> <th scope="row">4th Quarter</th> <td>90</td> <td>110</td> <td>85</td> <td>160</td> <td>445</td> </tr> </tbody> </table>
Result:

 

Quarterly Sales Data
Week 1 Week 2 Week 3 Week 4 Week 5
1st Quarter 100 150 80 200 530
2nd Quarter 120 130 100 180 530
3rd Quarter 80 95 70 150 395
4th Quarter 90 110 85 160 445

This table is a passing example because there is a <th> element to define the row and column headers and a <tbody> element to define the table body. Screen readers will properly associate each data cell with its appropriate row and column headers.

Let’s Wrap It Up

The most common errors we often find when testing websites featuring data tables are improper associations of each cell with their corresponding column and row headers. Users with disabilities may find these kinds of tables difficult to comprehend.

Since most charts and graphs used to convey data on e-commerce sites can be made accessible by providing text alternatives in the form of data tables, it becomes very necessary to make these tables accessible.

Start Building Accessible Solutions Today

We are an agency that knows our onions. Let us transform your rigid websites into highly accessible fortresses.

HIRE US

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

Posted on by Samuel Enyi

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:

  1. “Non-text content” refers to information presented in a non-text format like images, charts, graphs, carousels, videos, maps, or audio on a document.
  2. “Text alternative” means there is some text-based description or explanation provided to represent the non-text content.
  3. 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.
  4. 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:

  1. Start the Microsoft Word application.
  2. Open the document you want to test in Microsoft Word. (Latest version recommended)
  3. Click the ‘Review’ tab located on the ribbon.
  4. Select the ‘Check Accessibility’ tab.
  5. 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:

  1. Start the Microsoft Excel application.
  2. Open the document you want to test in Microsoft Excel. (Latest version recommended)
  3. Click the ‘Review’ tab located on the ribbon.
  4. Select the ‘Accessibility’ tab.
  5. 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:

  1. Start the Microsoft PowerPoint application.
  2. Open the document you want to test in Microsoft PowerPoint. (Latest version recommended)
  3. Click the ‘Review’ tab located on the ribbon.
  4. Select the ‘Check Accessibility’ tab.
  5. 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:

  1. Download and run the PDF Accessibility Checker (PAC 3)
  2. On the app window, click the upload button to upload the PDF you want to test.
  3. Navigate to the location of your PDF, and select it.
  4. The tool will automatically run a check to display the results summary.
  5. Click the “WCAG” tab to view the result summary.
  6. 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”.

 

The following content is video alternative to text showing how to run automated test for WCAG SC 1.1.1 on a Word, Excel, Powerpoint, and PDF document

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

  1. Launch your screen reader. for example, NonVisual Desktop Access (NVDA).
  2. Open the document you want to test using any authoring tool such as Microsoft Office or Adobe acrobat DC.
  3. Use your pointer device to click on each non-text content on the page one after the other.
  4. 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.

 

The following content is video alternative to text showing how to manually test a document for WCAG SC 1.1.1 compliance

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.

A bar chart displaying a company's expenses.

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

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

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

Posted on by Samuel Enyi

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:

  1. “Non-text content” refers to information presented in a non-text format like images, charts, graphs, carousels, videos, or audio on a webpage.
  2. “Text alternative” means there is some text-based description or explanation provided to represent the non-text content.
  3. 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.
  4. 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

The following content is video alternative to text showing how to run automated test for WCAG SC 1.1.1

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:

  1. Open the webpage you want to test for SC 1.1.1 conformance.
  2. Click the ‘Extensions’ icon located on the toolbar of your browser.
  3. Select the ‘Lighthouse’ extension.
  4. Click the ‘Generate report’ button and wait for the page to be analyzed.
  5. 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.
The following content is video alternative to text showing how to run manual test for WCAG SC 1.1.1

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

  1. Open the webpage you want to test.
  2. Launch ANDI by clicking its tab in the bookmarks bar.
  3. Select the “focusable elements” module from the menu options after ANDI launches.
  4. 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.)
  5. Observe the ANDI output (for non-text content only).
  6. Repeat step 3, but this time, select the “graphics/images” module from the menu options.
  7. Use your mouse pointer or the “Next” and “Previous” buttons to navigate from one highlighted graphic/image to the next.
  8. 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:

  1. Launch your screen reader. for example, NonVisual Desktop Access (NVDA).
  2. Open the page you want to test.
  3. Use your pointer device to point all non-text content on the page one after the other.
  4. 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" 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

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