CTL Blog

A Beginner's Guide to Authoring Universally Accessible Materials, Part 6: Tables

March 15, 2021 | 8 Minute Read

This guest post is by Celine Greene, Senior Instructional Technologist in the Center for Teaching and Learning.

In this series of posts on Authoring Universally Accessible Materials, you've been introduced to the "why we care" and the "how do we get there" for being more inclusive, more professional, and more conscientious in our digital communications. And – bonus! – if you've been embracing the recommended practices, you are closer to aligning your resources with Web Content Accessibility Guidelines (WCAG). So now it's time to discuss one specific, very common part of many documents: the table. At first glance, the table seems basic in its creation; but when taken through the lens of digital accessibility, we learn editing the table is so much more than making a grid of columns and rows.

Rules for Every Table

The most very basic rule of a table is only insert a table when you want to sort or organize data. The next rule of every table is always identify the header row, making sure to programmatically repeat the header row when we know a table might span across multiple pages. Another rule is always format the borders of a table's cells to be visible. And then there are the recommended practices to avoid empty, split, and merged cells and to provide alternative text and/or a caption for complex tables. Additionally, don't forget what you learned in an earlier post regarding color and contrast ratios: the contrast between the text of a cell and its background (the cell's "fill") must be sufficient: at least 4.5 to 1.

Only Insert a Table to Sort or Organize Data

If someone using an assistive technology (AT) comes across a table "behind the scenes" (where a table is inserted and thus programmed into a document), they are expecting that the next thing being presented to them will be categorized data. If instead a table has been inserted simply as an easy way to control the document's visible layout – for instance, aligning blocks of text, images, or elements in a form – there might already be confusion. Not only is the basic expectation of organized data being thrown for a loop, but there is added complexity in making sure the "convenient layout" matches the intended reading order (part of document structure). In addition, should the resolution of the digital resource be altered, the desired appearance can unintentionally change. If you want to control your document's layout, you should avoid using a table and instead adopt formatting techniques, such as column and section breaks, to maintain the correct reading order while adhering as closely as possible to the desired display.

Identify a Table's Header Row (and Repeat the Header Row)

A table is typically read left-to-right and top-to-bottom, but it truly depends on the common habits – specifically the default text directionality – of the person reading the resource. For many of us, we take for granted that the top-most row will be read left-to-right and is the one that identifies what's being sorted in the rows and columns underneath. But that misperception is based on both our ability to visibly discern a table and on our presumption that it should be read in a manner that is familiar to our own cultural norms.

When you identify the header row, you remove the presumptions and provide important information about the organized data in your table. Assistive technologies use this information to provide context to an end user, so the relationship between the data elements can be understood. It also ensures that the table will be read, or translated, in a logical order.

Additionally, when a table is displayed in a resource we need to make certain the organization of its data is obvious to everyone. This includes not just identifying the header row but making sure that the header row is repeated should a table continue onto another page; for example, when a document is in print preview. Since a table will never automatically continue beyond a single slide in Microsoft PowerPoint, there is no reason to format it so a header row is repeated. However, in Microsoft Word and Excel, this designation should always be made even if the table seems to "fit" on a single page when we create it. For instance, the person visually discerning our digital document may be doing so after increasing the font size, so all of the sudden the table extends to a second page when in print layout. Or the table may change placement or grow in its dimensions when our resource is edited in the future.

In newer versions of Microsoft Office, header rows are automatically added to tables. However, it still is worthwhile to make certain the correct row is identified – especially if the document's language and script isn't English. In addition, you still need to format a table to repeat its header row in the print layout for Word and Excel.

Format the Borders of a Table's Cells to be Visible

While a table's contents are programmatically organized in its columns and rows, understanding the organization visually is dependent upon looking at the table as a whole. Visible cell borders add clarity to a table. When there are no visible borders, determining the top and bottom, or left and right, edges of a cell can become difficult especially if the whole table is not displayed. For instance, if a person uses a screen or document magnifier, their visual discernment is based only on the portion of a table displayed at that magnification; they may not know where one column stops and the next begins. Additionally, even when the entire table is displayed, especially if there are many rows or many columns in the table, visible cell borders or banded rows (alternating shaded backgrounds) can be helpful in visually discerning the organized data.

Avoid Empty, Split, and Merged Cells

There are times when we can't provide data for every category and item in a table. However, instead of leaving a cell empty – which can lead to confusion for a person reading the table with a screen reader, document magnifier, or other AT – the better practice is to always put something inside the cell. What's entered in the cell may simply be an em-dash, "N/A", "TBD" or other simple designation that best translates that the data isn't there.

Similarly, merged and split cells also can lead to confusion for someone dependent on an AT. If the data being presented in a table isn't organized according to the identified header row, or normative in its display of expected columns and rows, it is very difficult for both the technology and the individual dependent on that AT to make sense of the table.

If you have empty, merged, or split cells in a table, chances are that with some editing, the information could be organized or displayed differently. Sometimes a row with an empty cell signifies incomplete data collection; the better option might be to make a statement adjacent to the table and not include that row. And sometimes merged or split cells actually define what could be entirely separate tables. Each situation will be unique. Regardless, do your best to use the simplest table configuration possible and avoid empty, split and merged cells in a table.

Provide Alternative Text and/or Captions for a Table

Any object in a digital resource that isn't decorative or simply text is deserving of alternative text (alt text) or a caption. These objects include the organized data displayed in a table. (The caption should appear right before or right after the object.) When a user dependent on AT comes across a table without alt text or a caption, it's usually impossible to grasp what's in the table without having its entire contents read or otherwise translated. In further support of providing captions and/or alternative text for tables – especially complex ones – we all benefit when the extraneous cognitive load is diminished in comprehending any communication.

Why Must We Have All These Rules?

The guidelines for editing a table all stem from the perceivable, operable, understandable, and robust principles of digital accessibility. We want everyone to have as close to the same experience as possible, no matter how they might be accessing our table. This means the content in an accessible table will be clearly identified, easily navigated, and consistently communicated across different individuals and technologies. Adhering to the rules above, which are really just a set of best practices, gives us the desired result.