Tables & Lists

Tables

Tables are typically used in two ways within course content:

• First to display numerical data or data that can be described with a matrix layout efficiently (columns and rows).
• Second to provide visual organization for all types of information often in a condensed way. Tables can be used frequently just to give more “space” around items so they show up on the page in a clearer fashion.

Screen readers can identify tables within your content and read it back. However in the process of navigating through a table a screen reader needs to provide a lot of extra verbal instructions to provide user with location information often at the expense of the data that is shown in tables.

For this reason there are some best practices around tables.

1. Decide if it absolutely necessary to put content into a table or will a list also work. Lists are much easier to understand in an auditory manner.

2. Table should have a clear title. This will allow someone using a screen reader to understand what type of information will be translated for them.

3. Table should have a header row which identifies every column. Within your editor you should be able to identify the top row as a header row.

4. Table should have no blank cells. If there is no data in a cell then the screen reader will have nothing to read and this can cause confusion for the listener.

5. Table should have no merged cells. Again a screen reader reads each row cell by cell and if there is a change of format then it will be hard to interpret as your listener will presume the top row describes each column.

Lists

As a best practice lists should always be built using the list tool in your editor. This attaches code that a screen reader can recognize.

A screen reader can pick out nested lists so you can use lists within lists to help convey information.

One method to provide greater accessibility is to present content in both table and list format giving the reader a choice.