PEAT Blog

Implementing Accessible Workplace Tech: Website Tables

As the digital gateway to your company or organization, your company’s website is an ideal place to start when implementing accessible technology practices. But how do you actually get started? In this multi-part series, Gian Wild of AccessibilityOz shares essential tips for ensuring that your eRecruiting materials and other website content are accessible to as many people as possible.

If you’ve got a website, you may be relying on tables to convey information. When presented meaningfully, tabular content is of benefit to many users and can increase a person’s cognitive ability to understand complex information. And when tables are used in an accessible manner, they can also support and add meaning to page content. But if those tables are not created correctly, they can create a real mess for employees and job seekers trying to access the information they need, particularly people who are blind, people with low vision, and people with cognitive disabilities. To learn what makes a good table—and the pitfalls of bad ones!—please read on.

The basics

There are two types of tables used on websites: data tables and layout tables.

  • Data tables are to present data. They cannot be interpreted properly without referring to the headings of a particular column or row. They usually have visible borders.
  • Layout tables are used to space out content on a page and do not have headings at all. Most of the time, the borders are hidden.

Example of a data table

This data table, taken from the CDC, illustrates the Prevalence of Disability and Disability Type Among U.S. Adults, 2013.

  Vision Cognition Mobility Self-care Independent living
Alabama 7.5% 16.3% 20.6% 5.3% 10.1%
Alaska 3.1% 7.7% 10.3% 3.1% 4.4%
Arizona 4.8% 10.9% 12.4% 3.7% 6.9%
Arkansas 7.2% 16.8% 18.0% 5.3% 9.1%
California 5.4% 9.8% 11.4% 3.4% 5.6%

When you look at the second column and the fourth row (handily highlighted above), it only makes sense if you know that “Arkansas” is the row heading and “Cognition” is the column heading. From this, you know that 16.8% of all people in Arkansas have some kind of cognitive disability.

What would a screen reader read?

An accessible website needs to be usable by everyone—not just people using the most common setup of a screen, keyboard, and mouse. In this example, we’ll consider the needs of screen reader users, who access digital information by having their device read text aloud.

If the above table was not coded well, a screen reader would read:

“Empty cell, Vision Cognition Mobility Self-care Independent living Alabama 7.5% 16.3% 20.6% 5.3% 10.1% Alaska 3.1% 7.7% 10.3% 3.1% 4.4% Arizona 4.8% 10.9% 12.4% 3.7% 6.9% Arkansas 7.2% 16.8% 18.0% 5.3% 9.1% California 5.4% 9.8% 11.4% 3.4% 5.6%”

Now, could you tell me how many people in Arkansas have cognitive disabilities? It’s pretty much impossible—particularly when you remember that this information is being read aloud.

But if the table was coded correctly, a screen reader would read:

Alabama Vision 7.5% Alabama Cognition 16.3% Alabama Mobility 20.6% Alabama Self-care 5.3% Alabama Independent living 10.1% Alaska Vision 3.1% Alaska Cognition 7.7% Alaska Mobility 10.3% Alaska Self-care 3.1% Alaska Independent living 4.4% Arizona Vision 4.8% Arizona Cognition 10.9% Arizona Mobility 12.4% Arizona Self-care 3.7% Arizona Independent living 6.9% Arkansas Vision 7.2% Arkansas Cognition 16.8% Arkansas Mobility 18.0% Arkansas Self-care 5.3% Arkansas Independent living 9.1% California Vision 5.4% California Cognition 9.8% California Mobility 11.4% California Self-care 3.4% California Independent living 5.6%

Example of a layout table

The majority of websites use style sheets to layout content, but tables are also used for this purpose. In this example, based on a table at SF.gov, the table has been used to force space between two sections.

Screenshot of a layout table providing contact information Left cell: Address: Office of Contract Administration City and County of San Francisco 1 Dr. Carlton B Goodlett Place Room 430 San Francisco, CA 94102;  Middle cell: blank; Right cell: Office Hours Monday-Friday (excluding holidays) 8:00 am to 5:00 pm  Phone/Email (415) 554-6743 oca@sfgov.org

There are three things to notice here:

  1. there are no headings;
  2. the content only makes sense when it is read cell-by-cell, left-to-right; and
  3. there are no borders (the red borders were added so you could see the table – they aren’t visible in the web site).

What would a screen reader read?

A screen reader would read this one entire cell at a time, left-to-right and top-to-bottom:

Address: Office of Contract Administration City and County of San Francisco 1 Dr. Carlton B. Goodlett Place Room 430 San Francisco, CA  94102 Office Hours: Monday Friday (excluding holidays) 8:00 a.m. to 5:00 p.m. Phone Email (415) 554-6743 oca@sfgov.org

What makes a good table?

A lot of the time a good table is not a table.

In the majority of situations, you’d be better off using style sheets, text, a graph, or a chart (though important to note: complex images like charts will require text alternatives).

If you’ve weighed the options and have decided that you must use a table, first determine whether it is a layout or data table, and then apply some simple rules.

How do I know what table is what?

Data tables:

  • Often have visible borders;
  • Only make sense if you know the heading of the row or column;
  • Cannot be understood when read cell-by-cell, left-to-right, top-to-bottom; and
  • Are usually used for presenting complex information.

Layout tables:

  • Often do not have visible borders;
  • Often do not have headings for the row or column;
  • Can be understood when read cell-by-cell, left-to-right, top-to-bottom; and
  • Often make sense if you read the cells in any order (for example, in the SF.gov table, if you read the right-hand cell first followed by the left-hand cell the contents would still make sense).

Accessibility rules for tables

Data tables:

  • Must have coded table headings for rows and / or columns
  • Must use the SUMMARY attribute to provide a summary of the table
  • Must use the CAPTION element to name the table

The rules for layout tables are the exact opposite of the rules for data tables:

  • Must not have coded table headings for rows and / or columns
  • Must not use the SUMMARY attribute to provide a summary of the table
  • Must not use the CAPTION element to name the table
  • Should not consist of a single cell

The Next Steps

Ready to learn more? Please be sure to join PEAT on November 9 for an instructional webinar on accessible tables. I’ll provide a hands-on demonstration with code examples and will be available to take your questions so that you can leave ready to create accessible tables on your own. In addition, PEAT has also added a new factsheet on accessible tables that compiles the information you need in one convenient place.

And of course, perhaps the most critical component of an accessible technology initiative is sharing what you learn with your staff and colleagues. Please be sure to check out PEAT’s tips and resources on training staff in accessible technology, and also how staff training fits into the overall process of ensuring that your employment process and workplaces are accessible to everyone.

About the Author

Gian Wild headshot

Gian Wild

Gian Wild is the CEO of AccessibilityOz. She has worked in accessibility industry since 1998. She spent six years contributing to the W3C Web Content Accessibility Guidelines, Version 2.0 and spoke at the United Nations Conference of State Parties on the importance of web accessibility.