Skip to content
tally learning

Layout Tables

4 minute read

Last updated:

Summary

Section titled “Summary”

Websites should only use tables to display data. Sometimes, however, websites must use tables to control the appearance of content on a page. These tables are called layout tables. When websites use layout tables, developers must code them so that assistive technologies can distinguish them from data tables.

Overview

Section titled “Overview”

Avoid using layout tables when possible. Websites should only use tables to display data, not for layout purposes.

In the early stages of web development, content was often arranged on a page using tables. However, developers now use Cascading Style Sheets (CSS) to control page layout. It is unusual to find layout tables in modern websites, but they are sometimes still used.

When layout tables are used, developers must code them so that assistive technologies ignore the fact that a table exists and only pay attention to its contents. This avoids confusion for people relying on assistive technology to understand the page’s content and structure.

Who is Helped

Section titled “Who is Helped”

People who use assistive technologies, especially screen readers, expect tables to contain data and have a structure composed of table headings and data cells. Screen readers announcing a table and table cells that contain regular page content rather than data can lead to confusion. Correctly coded layout tables avoid this problem.

Guidelines

Section titled “Guidelines”

When websites must use layout tables, the table’s code, but not its content, must be programmatically hidden (hidden via code) from screen readers.

  • The table must not have any header rows.
  • The table must use an ARIA role to hide the fact that it is a table.

Use ARIA to override the semantics of the table (to hide the fact that this element is a table) by including the ARIA role of “presentation” or “none” within the table tag. ARIA (Accessible Rich Internet Applications) is a set of roles and attributes used in coding websites that makes web content more accessible for people using assistive technology.

The example below shows a simple layout table used to control the layout of an image next to text. This example is only used to show the correct coding for a layout table. Note that CSS can easily manage the placement of these elements; in reality, a layout table is not needed.

A picture of a sleeping dog is placed next to text about sleeping dogs. The text is quoted in the code example.
Figure 1: Layout Table Containing Image and Text
Code Example for Figure 1
<table width="400" role="presentation">
    <tr>
        <td width="150">
          <img src=”sleeping-dog.png” alt=”sleeping dog” />
        </td>
        <td width="250">
          <a href=”sleeping-dogs.html” class=”article-title”>Why do dogs sleep so much?</a>
          <p>Did you know that dogs spend over 50% of their day sleeping? Read on to find out more about your favorite friend’s sleepy habits.</p>
        </td>
    </tr>
</table>

The presentation role hides the presence of the table in this example from assistive technologies. Screen reader users encountering this content do not know it is located within a table; only the image and text are announced. Using role=”none” has the same effect.

These roles remove the semantics from the table element so that assistive technologies do not announce the presence of the table or its structure, but the content is still available. For more information about the presentation role, refer to ARIA: presentation role (MDN).

How to Test

Section titled “How to Test”

Testers can check layout tables using either an automated accessibility test tool or a screen reader.

Test Using an Automated Test Tool

Section titled “Test Using an Automated Test Tool”

You can use accessibility test tools like the ANDI bookmarklet or a tables bookmarklet to test layout tables. See ANDI (Ta11y) for more information on using this tool.

To test layout tables using ANDI:

  • Identify any layout tables used on the page.
  • Open the ANDI bookmarklet.
  • Go to the “Tables” module. ANDI lists all tables on the web page on the right side of the ANDI interface. Correctly coded layout tables are identified in this list. (Note: The list of tables at the end of the reading order is helpful for testers using a screen reader.)
  • Select each of the layout tables. Verify that each table is correctly coded.
    • Check that the layout table has role=”presentation” or role=”none”.
    • Check that table headers are not marked up in the code.
  • Navigate through all tables on the page with ANDI to verify that there are no incorrectly coded layout tables hidden on the page.
Screenshot of ANDI’s Test Results for a layout table. The following text has the full description.
Figure 2: ANDI Test Results for a Layout Table

In this example, an ARIA role is added to a table to identify it as a layout table. The ANDI test tool:

  • Identifies the table as a presentation table.
  • Indicates the presence of role=”presentation” in the table element’s code.
  • Does not identify any table headers or other table markup in the table’s code.

Test Using a Screen Reader

Section titled “Test Using a Screen Reader”

Identify any layout tables that are used on the page. Listen to tables with a screen reader. Screen readers should not mention the table’s presence if layout tables are correctly coded. They should only announce the table’s content.

References

Section titled “References”