By Kim Wee, Minnesota IT Services Partnering with the Department of Education

When displaying data for web, the code you write builds the Document Object Model (DOM) structure and accessibility tree. It is crucial to verify we are presenting the relationship between the cell contents, and the row and column headers in a programmatic way. Remember the POUR principles: Perceivable, Operable, Understandable and Robust. If we forget about semantics, roles, and relationships, all kinds of things can go wrong.

This article will not cover a lot of details about fixing the accessibility tree. But, as a developer, sometimes you get into problems if you pick a framework that automatically creates the code. And sometimes, you can go in and fix it. Sarah Higley does a great job describing some possibilities for fixing the accessibility tree in her Roles and relationships article. However, fixing is something done after you begin to build. If you consider accessibility first when you choose whether to use a table or a grid, it will improve the accessibility of your solution and reduce the number of issues you will find when testing.

But how do you know which to use? Visually, tables and grids may look similar. Where they often differ is in the level of interactivity. Interactions include editing cell content or selecting or deselecting a cell. If most or all cells require some sort of interaction, it may be best to use a grid. If the primary goal is to read the data, stick with a data table.

Grids also have the benefit of including one stop in the tab order. This can make keyboard navigation much easier and more efficient.

Disclaimer: My goal for this article is to focus on data display options. I have not included options for page layout and grids on purpose.

Data Grids (more specifically, ARIA grids)

Have you heard the saying…the first rule of ARIA - don't use ARIA? I tend to agree. However, in this case, the ARIA grid solution is pretty slick and robust! 

Consider using an ARIA grid when you have data you want to present in a tabular format, and you have any of the following: 

• A lot of data.
• Keyboard interaction.
• You want column and row headers to be automatically read by a screen reader. 

In many cases, creating a grid can be easy, by adding role="grid" to the <table>. Take a look at the examples listed on the ARIA Authoring Practices Guide, Data Grid Examples page.

By adding both role="grid" to the table and tabindex="-1" to each <td> the screen reader user now has one tab stop - to the first interactive element in the grid. Then, by using the keyboard arrow keys, they can: 

• Navigate the other data cells.
• Have the row and column header information read.
• Use the space or enter key to interact with the other elements.

Tables (Data Tables)

You can read more detail about the semantics of data, layout, and presentation tables in last month’s article Easy Read that will Demystify Tables, Reflow, and Magnification. Watne and Shoemaker state: "Use (data) tables for two-dimensional information." I would add: and if the primary purpose is to read through the data in order to consume and understand it. Even if there are a few actions included in the data cells, your best bet is to stick with the use of a HTML table. Remember, the first rule of ARIA! At this time, ARIA supports people using screen readers. There are other functional needs your readers may have which ARIA does not support.

In summary

When displaying tabular data, begin by asking yourself two questions. First, how do you want people to take in and interact with the data? Next, which criteria below applies best?

Use a table when:

• Reading the data is the primary use.
• There is little to no interaction.

Consider a grid when:

• Interacting with the data is the primary use.
• Interactions include the ability to select rows and/or has form elements.

And always remember to test the accessibility of your page!