Tables

Tables are useful for communicating relationships between data, especially when those relationships can be best expressed in a matrix of rows and columns. Tables should not be used to control layout. Authoring tools have other means of doing this, including organizing content into columns.

If your data is best presented in a table, try to keep the table simple. If the table is complex, consider whether you could divide it into multiple smaller tables with a heading above each.

A key to making data tables accessible to screen reader users is to clearly identify column and row headers.

Tables should be used for presenting rows and columns of data, not for layout, and column and row headers should be explicitly identified.

Techniques using HTML

Simple Table

A simple table has a single header at the top of each column, and optionally a single header in the first column of each row. It has no nested columns or rows. To make a simple table accessible, apply the following techniques:

• Markup all column headers or row headers as table headers using the <th> element.
• Define the scope of each <th> using the scope attribute (the value of scope can be either “col” or “row”)

Complex table

A complex table is any table that is not a simple table, as defined in the preceding section. There might be nested rows or columns, or headers might be located in places other than the first row or column. These sorts of tables can be very challenging for screen reader users to understand. If possible, try to organize the information using multiple simple tables, with HTML headings above each. If a complex table is ultimately necessary, additional markup may be needed in order to ensure its accessibility for screen reader users.

• Markup all column headers or row headers as table headers using the <th> element.
• Add a unique id attribute to each <th> element.
• For every table data cell (<td>), add a headers attribute that lists the id’s of all headers that apply to that particular cell. If more than one header applies to a cell, separate id’s with a space.

Interactive tables

If table cells contain content that is intended to be interacted with (e.g., pop-up menus, editable form fields), these are technically considered “grids”, and will require additional considerations for accessibility, including the use of Accessible Rich Internet Applications (ARIA) markup. For additional information, see our ARIA on websites page.

Techniques using a rich content editor

Some rich content editors within web pages include a button on their toolbar for adding tables. If they support this functionality, they may or may not also support the features necessary to make the tables accessible to screen reader users (e.g., identifying which cells in a table are table headers).

The screen shot below shows CKEditor 5, which includes toggle buttons for identifying Header rows and columns.

If your rich content editor does not support adding tables or identifying column or row headers via the toolbar, you will need to edit the HTML code directly, as described above in the Techniques using HTML section.

Resources

Creating Accessible Tables (from WebAIM)

 

Tables should be used for presenting rows and columns of data, not for layout, and column and row headers should be explicitly identified.

Techniques for Word

Word has limitations when it comes to making tables accessible. For a simple table with one row of column headers and no nested rows or columns, these applications are up to the task. However, more complex tables can only be made accessible within HTML or Adobe PDF (accessible table markup can be added to the PDF using Adobe Acrobat Pro DC).

Often complex tables can be simplified by breaking them into multiple simple tables with a heading above each.

For simple tables, the only step necessary for accessibility is to identify which row contains the column headers. The specific technique for doing this varies depending on which version of Word you’re using. Try either of the following methods:

Method 1

Select the table row that contains the headers (Table > Select > Row), then right-click the row and select “Table Properties.” This brings up the Table Properties dialog. In this dialog, click the Row tab, and check the checkbox that says “Repeat as header row at the top of each page.”  This feature was designed for long tables that span multiple printed pages, but since it results in table header rows being explicitly identified, screen readers have long supported it as an accessibility solution.

Method 2

When a table is added to a document in Word, two new tabs will appear in the ribbon, “Table Design” and “Layout.” Selecting the “Table Design” tab (which is sometimes abbreviated as “Design”) will reveal the Table Style Options group where you can define your Header Row.

See the following Microsoft support pages for additional information:

• Repeat table header on subsequent pages
• Create accessible tables in Word (video)

Techniques for PDF

To get the best results for an accessible table in PDF, use the application that created the document to add headers then save your document as an accessible PDF. If the source document is not available, or to check and refine the tables in the PDF, use Adobe Acrobat Pro DC.

Using the “Autotag Document” feature for remediation should produce a properly-recognized table. However, further investigation of the table will be necessary to determine if the content has been properly structured.

Use the Table Editor to check and correct table tags, and to determine if column and row headers have been identified accurately. To launch the Table Editor in Adobe Acrobat Pro DC, follow these steps:

1. From the Accessibility Panel, launch the Reading Order tool
2. Right click anywhere in the table and select ‘Table Editor’ from the context menu
3. Right click in each cell and review the Table Cell Properties to ensure tag type, scope, and span are properly assigned

NOTE: Modifying PDFs can have unpredictable results. Save often! (Saving multiple versions is recommended.)

Techniques using Google Docs

Google Docs does not currently provide a means of identifying column or row headers in tables.  If you’re authoring a document that includes tables, you should avoid doing so using Google Docs.

 

Tables should be used for presenting rows and columns of data, not for layout, and column and row headers should be explicitly identified.

Techniques

To make tables accessible in a D2L page, following the following two steps.

Step 1.  Identify the header row.

• In the D2L page editor, click on (or arrow to) the table that you want to edit.
• From the menu bar in the rich content editor, select Table > Row > Row Properties.

• In the Row Properties dialog, select “Header” as the Row type.

• Save.

This has the effect of wrapping the header row in a <tbody> element in HTML.

 

 

Step 2.  Identify each individual header cell

• In the D2L page editor, click on (or arrow to) a column header or row header.
• From the menu bar in the rich content editor, select Table > Cell > Cell Properties.

• In the Cell Properties dialog, select “Header” as the Cell type.

• In the same dialog, select “Column” or “Row” as the Scope. The dialog also provides “Column Group” and “Row Group” as options; select either of these options if the header cell spans multiple rows or columns.

• Save.

This has the effect of tagging the table cell as a <th> element in HTML, with a scope attribute.