Make simple tables accessibleTables 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 formsIn 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 accessibleWhen 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.
|
|
|