Tables Have Unique Accessibility Requirements

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

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.)

Portion of a table that displays staff from a school showing the person's name, ID, and email address.

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.

Sample of a portion of a table that combines multiple elements into single cells with a line break.  While visually this technique may make sense, the visually impaired may be confused by it.

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

Table Properties dialog uses the Alt Text tab to add the Title and Description to a table.

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.

Table captions can be added using the dropdown menu when you right click on the table selection box in the upper left corner.

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

The Caption dialog shows there are various formatting options for captions.

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.

See My Voice, Hear My Images

Video and Sound Have Rules Too!

If you post video or podcast files to your website, you should consider the following accessibility requirements that most people are not aware of. It does not take special tools or skills for the ‘accessibility police’ to check your web pages to see if you were aware of them. So let us talk about video first.

Video accessibility Issues

If you post a video file, there are several questions that you must answer. I will examine these in no particular order. Just know that you should consider each as a separate issue.

  1. Will the video stream when accessed?

    There are two fundamental ways that a video can play from your website. One is that it must first be fully downloaded before it can begin to play. The second, referred to as streaming, allows the video to begin playing as soon as some has downloaded even while the rest of the video is still being downloaded. Thus, a streamed video often begins almost immediately while a downloaded video may take several seconds or even minutes before it begins. The negative impact of this later method is that the download delay may seem exceptionally long causing the user to question whether the site or link are broken and encouraging them to move on to something else, something faster. If the video is about a product you are selling, you may have just lost the sale. This is often the result of posting the video within another directory of your website. To avoid this, you want videos to stream. If you post your videos to YouTube or other similar services, they will stream by default.

  2. Does the video have sound, specifically spoken words?

    Whether the video is being narrated by someone offscreen or by people in the video itself, you must consider that some viewers may have hearing impairments. Therefore, it is necessary to include either a transcript of the text or add closed captioning with the video. Some applications can generate a closed caption file for the spoken words in a video. The Streams app from Microsoft and Youtube are two platforms that come to mind. However, no platform can perfectly generate text to go along with voice. Differences in the rate of speaking, local accents, and misinterpreting similarly sounding words all lead to errors in the generated text. Therefore, it is vital to review and correct the text generated. Along with the generates text, the appearance of that text must be synchronized with the actual spoken word in the video. Test this by playing the video with the sound turned off. What does the video say to you?

  3. Videos should not auto-start

    A video reference on a page should never auto-start. There should be an obvious control/button to start the video if and when the viewer decides they want to hear it. The reason they may not want the video to auto-start might be because they have been on the page before and have previously watched the video. Another common reason is that they are in an open environment with other people and having the video auto-start may be distracting and even annoying to others. Similarly, there should be a way to stop a video from playing. These video controls must not only exist, but they must be accessible not only by clicking a mouse on the screen, but also they must be available through the keyboard. If they are not, people with hand movement control issues who do not use a mouse may experience problems.

  4. Audio Description

    Audio description (AD) is a form of narration used to provide information surrounding key visual elements in a media work (such as a video or training program, or theatrical performance) for the benefit of blind and visually impaired consumers. These narrations are typically placed during natural pauses in the audio, and sometimes during dialogue if deemed necessary. Here is an example from Subaru.

    Subaru commercial

    I have also seen a video that takes the site visitor on a virtual tour of their newest facility. Unfortunately, for the vision impaired guest that virtual tour was worthless without a corresponding audio description file of what was being shown. Here is a test. Close your eyes while the video is playing. Do you get the same information?

Podcast Accessibility Rules

As you might expect, some of the rules for podcasts mirror those for videos.

  1. Media controls

    As with videos, podcasts should not automatically start upon displaying a page. Rather they should have clearly identifiable start and stop buttons that can also be accessed from the keyboard

  2. Captioning

    Remember that hearing impairments affect the sound from podcasts just as much as videos. Therefore, you should have either captions that display while the podcast plays or a separate transcript of the podcast.

  3. Navigation

    Can a user enter or exit focus of an embedded media file whether it is a podcast or video from the keyboard without using a mouse? What if they can tab into the media file but have no way to exit when the media file has ended back to the rest of the page?

In the News

Before I end this week’s post, I want to mention an editorial in our local paper from this week written by Ohad Gal of Lighthouse Works. He started off by stating that while the internet has become more central to most of our lives, that there are more than half a million Floridians who are blind or have substantial vision impairments. (Florida has a population of about 26.5 million so a half million is about 2%.)

Remember that this is just vision impairments. There are other types of impairments that affect as much as 6% of the population. If you think that none of what I’ve been talking about affects you or your web pages, Mr. Gal stated that according to a survey by WebAIM that 97% of the top million web pages have some type of accessibility issue. In addition, the number of web accessibility cases filed from 2017 to 2020 has doubled with 10% of those cases filed right here in Florida. Think about that!