Tables have long been a popular way of displaying related information that would be difficult to read if you provided the same information in paragraph form. Tables imply a structure to the data and thus are inherently visual. Each row of the table represents an instance of whatever you are listing in the table while each column represents a common attribute for each of the rows. (Think of a database or even an Excel spreadsheet.) For example, a table might represent staff at a facility. Each row of the table represents one facility. The columns then represent attributes that describe more information about the facility which in this case might include the facility name, staff person’s name, staff person’s employee ID, and the staff person’s email address.

That table structure makes it very visual and easy to interpret by non-disabled people. It makes it easy to find which staff member works at each facility, who all the staff are at a facility, and how to contact any individual staff member. However, it can make it hard for the visually impaired person to understand the relationships in the data without the help of some accessibility features.

There are three main components to making a table accessible over and above what is required for standard text. I will not discuss here the mandatory requirements of color contrast and font styles which by now you should be familiar. Rather, I will examine these three requirements that are unique to tables no matter where you create them or how you display them. Specifically, I will cover how to implement these requirements in Microsoft Word. Microsoft PowerPoint, and Microsoft Excel have similar features and can be implemented using more or less the same steps.

These three components are:

• Maintain a simple table structure
  
• Use a header row
  
• Include Alt-text and a title for each table
  

Maintain a Simple Table Structure

Maintaining a simple table structure means that you should not use split or merged cells. Screen readers read from left to right, top to bottom. Merged or split cells could be confusing when read by a screen reader it jumps over a cell or reads only the cell contents midway across a row without including the context of where the cell is in the table. Merged and split cells are typically the result of merging or splitting cells vertically. (There are times when you think you need to split or merge cells horizontally too.)

Fixing vertically merged cells may be as simple as not merging the cells in the first place and inserting the same text in each of the additional rows for that column. I have seen some examples in which the repeated text adds the word: ‘cont.’ to the end of the text, but this is not necessary. The following figure shows a portion of a table that displays TSRs (Technical Support Representatives) at each school. Rather than merging the common cells, you might do something like the following since all the column data is unique except for the school/facility name. (Remember, the ‘cont.’ suffix is optional.)

Another way to handle merged/split cells may be to use multiple lines for data as shown in the next example. In this example, the school name appears once in the first column. Then the information for each TSR is combined into a single cell for each column with a comma between each value followed by a line break. Line breaks are generated in Microsoft Word by placing your cursor between the values and pressing ENTER (In Excel to get a line break, you need to press: ALT-ENTER). Note, this is not the same as splitting a cell because it does not create additional cells. The net result is that there is a single row for each school followed by cells with the name of all the TSRs at that school separated by a comma and line break. Most people viewing this table visually will have no problem understanding it. However, depending on the number of items combined, this technique could make it harder for the visually impaired listening to the screen reader read the contents of each cell to understand which attributes belong to which person making the first method preferable.

In a similar manner, you should avoid blank rows or blank columns at all costs. If there is no information for that cell in the table, enter: NA so that it does not look like you skipped over a cell or forgot to enter a value when you really did not have a value for that cell.

Avoid nesting tables. This can be confusing when read by a screen reader in several ways. First, the nested table should have its own set of headers, title and alt-text. Second, the screen reader may not know when it has left the nested table and was back reading cells in the original table. Depending on the complexity of the nested table, this may not be easy to fix without restructuring how you display the information.

Use a Header Row

Screen Readers use the text in the header row to remind the user in what column the text currently being read belongs. Without a header row, the user may not know where in the table they are or what the current cell information means. Header text should be relatively short, and the header row should appear at the top of the table in a webpage and for a PDF, at the top of each page when the table spans multiple pages.

To define a header row, select the row and then select the Table Design tab. In this ribbon, make sure the Header Rows check box is selected. By default, it usually is, even if the text in the first row is not really header text. How would it know? Many pre-defined styles use this information to format the header row different from the rest of the table and is therefore pre-selected. Formatting the header row is obviously only of benefit to those who visually can see and read the table. Therefore, while it is option, you must still obey all color contrast rules discussed in previous posts. You can also access this property by:

• first selecting the first row of the table
  
• then right click anywhere within the row
  
• then selecting Table Properties from the context menu
  
• then opening the Row tab in the Table Properties dialog
  
• finally select: Repeat as header row at the top of each page
  

Why select the option to repeat the header row on the top of each page? First, adding the header row manually at the top of each new page for large tables in a PDF would not be a good choice. Changes in the formatting of the page could cause the table to split at unexpected points in the table causing the manually inserted header to appear randomly. The preferred method is to right-click anywhere in the header row. Then in the Layout ribbon, select: Repeat Header Rows in the Data group. This option ensures that no matter where the table splits between pages, the top row on each page will be a repeat of the header row. Note, you should always do this even if you think your table is short. You never know when a PDF of a document is created where the page breaks might occur. Also, while it is possible to have multiple rows serve as the header, for now I will not recommend that practice.

Alt-Text and Table Titles

You probably remember from our discussion on images how important it is to have alt-text. However, did you know that tables also have alt-text? To add alt-text to a table, right click in any cell in the table and select Table Properties from the dropdown menu. Then in the Table Properties dialog, click the Alt-Text tab. As you can see in an image of the dialog below, there are two fields available. The purpose of the Title field is to give the vision impaired person a short description of the table so they can skip over it if it does not interest them. The Description text should provide a more detailed description of what is in the table including a listing of the fields (columns) that appear in the table. Again, this sets the context of the table for the visually impaired before diving into the data. This text appears with the Summary attribute within the HTML of the table if the table is rendered as HTML

So, that leaves the Table Caption. Notice that in Word, as you move your mouse anywhere over the table, a small box with a ‘+’ within it appears in the upper left corner of the table.

Right click on that box to open the table’s context menu and select Insert Caption that appears in the dropdown menu.

Enter an appropriate Table Caption after the text ‘Table 1:’ and click OK. Is a table caption necessary? I have seen mixed opinions. However, in a large document with multiple tables, having table captions makes it easy to reference different tables from within the document or webpage and makes it easy for the visually impaired person to follow along.

Well, that is how to make tables accessible. You probably are performing many of these steps now. If you convert the Word document to an Adobe PDF file, these accessibility features will be included in the PDF. When published to the web, these features will help visually impaired readers clearly understand your table. In a future post, I will go through the steps of how to create accessible PDFs from Microsoft Word, and Excel documents.

NEVER publish Microsoft source documents (.docx, .xlsx, or .pptx) directly to the web. Most browsers will download the file and then expect your local device to have an application that can open these file types. On the other hand, PDFs can be opened and displayed directly from within most web browsers on most devices.