Table Accessibility
Table Accessibility
A good way to ascertain if you should be using a table or not is to ask yourself two questions:
If you read the data in a data cell, do you need other information to explain how it relates to other data in the cells? If so, it’s a data table.
Does the material consist of information that is sequential or self-explanatory? If so, it’s a layout table and it should be formatted another way such as a list.
For layout tables within Microsoft, headers should not be used which means there is no identification which column someone is in when using a screen reader.
Formatting, such as headers, that a sighted reader uses is read out loud to help someone with visual differences. Headers are used in data tables to notify the screen reader user:
What column they’re in
What the name of the column is, and
Information that is in the cell
Whereas, files created in Google Drive, still identify where the user is within the table even when header rows and/or columns are not identified.
Screen readers essentially ignore the fact that the content is inside of a table. The screen reader just reads the content in the literal order, left to right, top to bottom.
According to WebAIM, in reality, layout tables do not pose inherent accessibility issues. There are certainly many worse things that you could do in terms of accessibility. People with all kinds of disabilities can easily access layout tables, as long as the tables are designed with accessibility in mind - ensuring proper linearized reading order, content scaling, etc.
When you hear alternative text, you probably don’t think of tables. However, any table used for data requires alternative text for context. Tables used for layout should never have alternative text because the content is read linearly and provides the context itself.
This is the case for documents created in Microsoft or Google Drive, but if adding a table within your LMS, alternative text is not always an available option. You may be able to add a caption or title for your table.
When using table headers, you should do the following:
Always mark the first row and/or column as the header. A screen reader moves horizontally along a row and reads the contents of the column header. This allows a user to view the title of the column without having to navigate back up to the first row to remember what column they were on. It allows the user to remember how the table is organized.
Mark the first column as the header if its content is needed for emphasis/context for the rest of the row. When a user navigates a column vertically, the screen reader will read the row header if it is appropriate. If a student is reviewing a course schedule for the semester, having the first column read first which dictates the week of the semester, is helpful for a screen reader user. Headers are meant to orientate the user with the table.
Ensure that every cell has data, especially in the header row and/or column as a screen reader needs to provide the individual with the context.
A table should never be an image, screenshot, or scan of a textbook. These images are completely inaccessible to a screen reader. Even with alternative text, tables that are images are impossible to follow as keyboard navigation is not available.
While you should really never use an image for a table for the reasons just stated, if you absolutely cannot avoid it, it's imperative you describe what should be interpreted from the table as the user cannot navigate to understand the data. Additionally, you need to provide enough information while not overwhelming someone. Remember that the screen reader will break up the flow of information to read the table/image (if you’re using a screenshot of a table), and if there is too much alternative text for the table, the individual reviewing the information may lose key details if too much information is provided as they will not be able to navigate the cells of the table since the table is an image. If the explanation would be deemed overwhelming for someone, the table should be broken up into multiple simple tables so that the information can be digested. If it cannot be described concisely in a sentence or two in alternative text, information should be added in your document (before, after, or next to the table).
If you are using images of tables from a publisher that you have copyright permissions for, you can check with the company to verify if they have any alternative text that can be used.
While we are stressing making tables accessible for students using assistive technology, it’s also important to consider how tables impact your typically abled students (electronic mobility is a form of accessibility). Many students are using mobile technology (e.g., smartphones and tablets) to complete coursework. While an image of a large table may be aesthetically pleasing and be easier to present to students, it is difficult for students using mobile technology to access.
Avoid Merging or Splitting Cells: Assistive technology doesn’t identify why cells are skipped, and it may even block the screen reader form navigating the table. This makes it difficult for someone using a screen reader to understand the table. There is a high likelihood that the content will become difficult or impossible to follow.
Avoid Abbreviations: When you abbreviate things, the screen reader reads the abbreviation. This is difficult for someone who is listening to the table being read to understand
For months spell out the month
For ranges use “to” instead of a dash
Ultimately, when it comes to tables, simple is best. All users with and without a screen reader are more likely to struggle with a table that is too large or contains too much information.
Complex Tables: Microsoft and Google products are not well equipped to handle complex tables. A complex table is one where there are two rows of headers that must be referenced to understand the relevance of the corresponding data cells. Tagging a complex table often takes additional hours of work, and they are rarely tagged properly. It is often substantially easier/faster to break the table up into several simple tables than it is to attempt to tag the complex table in a more appropriate software such as PDF.
Complex Tables in PDFs (Wright State University)
Creating Accessible Content: Tables (Portland Community College)
Creating Accessible Tables (WebAIM)
How can data tables be made accessible? (Washington Do-It Center)
Mysteries of Accessibility: Constructing and Using Tables (Hawkes Learning YouTube)
Webinar Handouts: Constructing and Using Tables (Google Drive folder)
Specific Guidelines – Tables (Diagram Center)
Tables (University of Minnesota)
Tables Accessible U (University of Minnesota)
Table Accessibility with a Screen Reader (University of Colorado Boulder)
Tables: Simple Tables vs. Complex Tables (Penn State)
Tables Tips and Tricks (W3C)
Tips and Tricks (W3C)
When to Use Tables and How to Make Them Accessible to Screen Reader Users (University of Colorado Boulder)
Add Alt Text to Charts (Microsoft Support)
Create Accessible Tables in PowerPoint (Microsoft Support)
Create Accessible Tables in Word (Microsoft Support)
Creating Accessible Presentations in Microsoft PowerPoint – Tables Section (University of Washington)
Creating Accessible Documents in Microsoft Word – Use Tables Wisely Section (University of Washington)
How to Add a Table in Microsoft PowerPoint (Microsoft Support)
How to Add a Table in Microsoft Word (Microsoft Support)
PDF Accessibility: Lists (MSFTEnable YouTube)
PDF Accessibility: Tables (MSFTEnable YouTube)
Use Table Headers (Microsoft Support)
Add and Edit Tables (Google Help)
Google Use Tables for Data Not Formatting (Google Help)
Grackle for Google Docs: How it Works (Grackle Docs)
Other Accessibility Checks (Grackle Docs)
Installation (Grackle Docs)
GrackleDocs Demo (Grackle Docs Inc YouTube)