Making tables accessible

Make simple tables accessible

Tables are an effective way to organize and present content in accessible forms. When used appropriately, a table’s rows and columns provide a predictable and consistent structure for form content.

For example, when a user navigates into a body row cell, the screen reader specifies the cell location and then reads the cell content. The screen reader specifies the cell location using a combination of row and column headers or row and column numbers.

In addition to providing the location of a cell, screen readers may also specify header information, such as the content of the cell at the top of the column. Because screen readers provide information that orients the user to the location of content in the table, its layout directly affects the table’s accessibility.

Tables with simple layouts are recommended. Simple tables begin with a single header row followed by the body rows.

When designing simple tables for accessibility, remember the following tips:

  • The tabbing order for a table is geographic order, which is the same as for the form itself. Ensure that the table content is organized such that it makes sense when read from left to right and top to bottom.

  • Most screen readers interpret the first row in a table as the header row. When reading the content of a body row cell, these screen readers first read the content of the associated header row cell. Ensure that the content in each header row cell meaningfully describes the column content.

  • Avoid cells that span two or more columns, nested tables, or table sections. Screen readers have difficulty interpreting these features correctly or may not use them. For example, if a cell in a body row spans two columns, screen readers may not reference the correct cell content in the header row when reading the next cell in the row.

Navigate tables in accessible forms

In accessible forms, screen readers speak information about where the cursor is located in the table. As a user moves between the table cells in a form, the screen reader speaks the contents of the cell. When a user moves to a cell containing a nested table, the screen reader speaks the contents of the cell and the nested table.

The editable fields in a nested table are part of the tabbing order in the form. Therefore, users move between editable fields in a nested table by using the arrow keys. As the user moves in and out of a nested table, the beginning and end of the table is spoken.

Note: When using JAWS, the beginning and end of the nested table is not spoken in virtual cursor mode.

Result

Action

The screen reader speaks the current table cell.

Ctrl+Alt+5 (number pad)

Move horizontally between cells.

Ctrl+Alt+Left or Right Arrow

Move vertically between cells.

Ctrl+Alt+Up or Down Arrow

Make complex tables accessible

When designing tables for accessibility, we recommend that you keep the table layout simple, with one header row followed by body rows. However, some content may be best presented in a table format rather than other presentation options, but requires a more complex layout. For example, you may need to use cell spanning or more than one header to effectively convey the content.

You can create complex tables by using the table object or by combining subform objects. The table object lets you use features that are intended to help the design process, such as options for inserting and resizing columns and rows.

Depending on your design experience and preferences, you may choose to create complex tables by combining subform objects. For example, you can create one subform that includes two rows and specify this subform as the header for the table and specify another subform for the table body rows.

When using subform objects instead of table objects to create tables, the following additional steps are required:

  • Set the type for each subform to Positioned. See Subform properties in the Subform tab.

  • In the Accessibility palette, set the appropriate subform role for each subform that makes up the table. For example, assign the role of Header Row to the subform that is used as the table header. See Accessibility properties in the Accessibility palette.

  • For rows that convey information about the table or its content but that are not considered to be part of the table, assign the subform role of None. The screen reader will read the row content.

    The features supported by the screen reader determine the information read for a complex table. For example, assume that a table includes a header row and a section with a header row. When the user navigates into a body row cell in the table section, the screen reader should read the following content, in order:

  • Content from the appropriate cell in the header row for the table

  • Content from the appropriate cell in the header row for the section

  • Content from the selected cell

    Some screen readers may not read cells in both header rows.

// Ethnio survey code removed