Tables

Executive Summary

Tables should be used only for data or information that requires organization with rows and columns, not for layout or lists. Tables should be kept simple such as those with a single row of simple yet meaningful column headings and optionally a single first column of meaningful row headings. Complex tables should be restructured or broken into simpler tables (examples below). A heading or title should appear before the table. Hidden summaries or descriptions intended for screen reader users should be avoided by being provided in the main text for everyone. The takeaway message of the author should appear in the text accompanying the table for the benefit of everyone. Cells should all contain data (e.g., 0 or NA or "blank") rather than simply being left empty and there should be no merged or split cells. Details for proper table accessibility in different document types are available in the tutorial for the document type, e.g., Microsoft Word, HTML

Covered in this Tutorial:

• Introduction
• Things to Consider Before You Begin
• Summary
  • Best Practices
  • Techniques to Avoid Under Most Circumstances
  • Techniques You Should Not Use
• Table Headings or Captions
• Table Description/Summary
• Blank Cells
• Column/Row Headings,
• Table Column and Row Spans
• Table Complexity
  • Simple Tables
  • Complex Tables Should Be Avoided
  • Multi-cell Headings and Subheadings
  • Splitting Tables to Make them Simple
• Examples of Table Techniques to Avoid page

Introduction

Understanding rather than elegance or concise display should be the goal in creating tables of row and column information. This works for the benefit of everyone and not just people with cognitive difficulties or those using assistive technologies such as a screen reader.

Things to Consider Before You Begin

Use tables to present multifaceted data, do not use them for layout or lists. Data tables are used to organize data with a logical relationship in grids. If similar data is being conveyed about multiple items a table is appropriate. For example, information about the top speed, fuel efficiency and horsepower of several brands of cars would be in a table.

Tables are an effective way of presenting data. You should consider using tables when:

• Showing how a single category of information varies when measured at different points (in time or space). For example, a table would be an appropriate way of showing how the category unemployment rate varies between different countries in the European Union (different points in space).
• Displaying things such as financial data, time-tables, pricing, feature comparison, the nutrition facts information panel, bowling scores, and many other tabular data.

Tables should not be used for:

• Layout or design of the visual presentation. For example, a 2 celled table in a syllabus should not be used to achieve a side-by-side layout of instructor and teaching assistant contact information.
• When the table would have only 1 row or 1 column. For example, if the information was all about 1 brand of car a list may be more appropriate.

Summary

Best Practices

• Use tables only for true tabular data.
• Use simple tables, complex tables can be split into multiple simple tables.
• Identify tables by captions or headings that are separate from the table content.
• Provide summaries and takeaways in the surrounding text.
• Have single column and/or single row meaningful and unique headings.
• Do not leave blank cells.

Techniques to Avoid Under Most Circumstances

• Visually hidden summary/description information.
• Blank cells.
• Spanned cells (also known as joined/merged cells).
• Complex tables.

Techniques You Should Not Use:

• Nested tables.
• Layout tables.
• Tables with only 1 row or 1 column of information

Table Headings or Captions

Tables should have an identifying title or caption associated with but outside of the table data itself. In general, the best place is just before the table, so that a screen reader identifies the table before going into the details.

Table Description/Summary

Text in the body of the document should tell what the author desires for the end user to understand from the table if it is not merely a presentation of data. If the structure or use of a table is complex enough that it needs an explanation, it likely is not very accessible and should be simplified. We do not recommend the use of visually hidden description/summary sections, such as alt text, except as needed to support specific assistive technologies as specified in the tutorials for specific document types, e.g., Microsoft Word, HTML.

Blank Cells

Do not leave blank cells for either data or headings. If appropriate values are NA or n/a or 0 or "left blank" use them to help prevent assistive technology users from getting lost.

Column/Row Headings

Column/Row headings indicate the organization of the table, read by screen readers to help users understand the context of the information they are hearing. Without a column or row heading, a screen reader user may hear "one hundred twelve" for "112" and not know if it is the top speed or the horsepower of a vehicle. Column Headings should be as simple and meaningful as possible to their intended/expected audience. The first cell in each row should be a meaningful identifier of the row's content, not a row number.

Table Column and Row Spans

Column and Row Spans (see "Cars" in Table 2) should not be used for either headers or data. It is better for assistive technology users if the column heading or data is repeated. If such spans seem like they are needed, you probably have a complex table.

Table Complexity

Tables can be classified as simple or complex. Simple tables are the easiest for assistive technology to interpret and generally have 1 header for each column, 1 header for each row or both row and column headers. Only simple tables are recommended for proper understanding and accessibility by all.

Simple Tables

Table 1: Car Comparison

Every table should have at least column or row headings, many have both such as Table 1 where the headings have been given distinctive styling on the vertical column and horizontal row that begin with the top left cell containing "Car." When read by a screen reader, the column heading, if present, will normally be re-read each time the user switches columns. Likewise, a row heading, if present, will be re-read each time the users switches rows. (Audio File: NVDA screen reader reading Table 1.)

Complex Tables Should Be Avoided

Complex tables are not recommended. Several common types of complexity will be discussed below and on the Table Techniques to Avoid page along with suggestions on simplification.

Multi-cell Headings and Subheadings

Multi-cell headings (also known as column and row spans) whether done by joining cells horizontally (as in the next example) or vertically (on the Table Techniques to Avoid page) should not be used. Generally it is best to break the table into simple tables.

Table 2: BAD EXAMPLE Multi-cell Subheadings

Splitting Tables to Make them Simple

Most complex tables can be split into multiple tables to make them simple. For instance, Table 2 could be split to display in two simple tables, one for cars (Table 3) and one for SUVs then no multi-cell subheadings are needed.

Table 3: GOOD EXAMPLE Simple Table 1 instead of Complex Table - Cars

Examples of Table Techniques to Avoid page