The table to the left has many issues. At first glance, it may be hard to see what this table even is. Upon further inspection, you can see that it is two lists of first and last names that seem to belong into two categories: "Avengers" and "Justice League". All cells are formatted and structured in the same way, so there is no clear distinction between what may be serving has a header in the table and what could be content.

This table is better, but still not perfect. By defining table headers, you can more easily see the hierarchy and relationships with the data items present. If you glanced at this and the above tables for a second each, you are much more likely to understand the meaning of this table. A screen reader also generally announces the appropriate headers for each column correctly, so a user can know that "Stark" is the "Last Name" of someone in the "Avengers" group.

Admittedly, there is an issue here where the "Justice League" heading is read off by a screen reader as if it is a part of the "Avengers" > "First Name" groupings above it. There likely is a way to correctly structure the headings to make it not do this, and I believe it is the only heading misspoken in the table, but it still is an example of how this is a very hard table to make accessible.

Avengers

Justice League

The "Avengers" and "Justice League" headers made the above table a bit overly complicated. They took considerably more work to assign the appropriate headers for each table cell, and even the example provided doesn't read correctly from a screen reader. We can produce much simpler tables and still achieve our goal by simply splitting this data out into two separate tables.

Avengers

• Tony Stark
• Steve Rogers
• Natasha Romanoff

Justice League

• Clark Kent
• Bruce Wayne
• Diana Prince

The best solution to having an accessible table could simply be having no table at all. Here, the data from our table was fairly simple and standardized: a list of names falling under two categories. We can easily represent that information as two bulleted lists under their own headings, and still produce the same meaning. This is considerably more accessible and often takes less code to create and maintain.

It is a good idea to think about other ways you could represent your data other than a table. Certainly there will be times where a table is the only option, as could be the case if you have many rows and columns of information. On this page, we started with a small table that still had a fairly complex structure. Breaking the table into distinct tables per section helped considerably, but also highlighted that we could go even simpler by just making a list.