It’s not just about screen reader users
I have recently come across two sources advocating techniques (one in MS Word, the other in InDesign) for hiding tables behind graphs or charts for the benefit of screen reader users. Unfortunately, doing so is not a good idea, as it will create serious accessibility problems for literacy software users.
The purpose of tables
The starting point for understanding why hiding a table will cause a problem is to appreciate the fundamental purpose of the table itself. The whole point of a table is to describe relationships between rows and columns of data.
Sighted readers will perceive the relationships between the rows and columns via visual cues offered by the physical layout of a table. However others, particularly screen reader users (who for our purposes here are assumed to not be able to see the page at all) will perceive those relationships through the structural relationships built into a properly tagged table in the form of headers, scope, and column and row span attributes, etc. These cues are read out loud by screen readers.
This is why, of course, it is so important to make sure that tables are always tagged correctly. If they are not, screen reader users will have difficulty in understanding the relationships between the rows and columns and will not be able to access the data effectively.
The problem of hidden tables
The problem with a table hidden behind a graphic is that literacy software such as Read&Write Gold (principally used by people with dyslexia) will read out loud the contents of such a table, and will also display areas of colour on top of the graphic where the data cells should be, even though the table itself is invisible.
Invisible content being read out loud to a sighted person will of course be confusing. But even more seriously, literacy software, unlike a screen reader, does not read out loud any structural cues built into the table. It only reads out the data. This is because it assumes that the user can see the page and therefore doesn’t need the same audible cues that a screen reader user needs. Hence, literacy software users (who, by the way, vastly outnumber screen reader users) will get neither the visual cues about the relationships between the rows and columns nor any structural cues.
By hiding a table in this way you are effectively doing to people with dyslexia what you would be doing to screen reader users if you didn’t tag the table properly, which I’m sure no serious accessibility practitioner would even consider for a moment.
Ideally you should provide a (visible) table as well as a graphical representation of your data. However, for many graphs it is not sufficient to provide only a table as an accessible alternative to a graph because tables are not good at conveying trends, patterns, proportions, relationships or anomalies within the data in the way that graphs do.
Enter William Playfair
It was precisely because tables are not good at conveying information on trends etc, that in 1786 Scottish engineer William Playfair invented line, area and bar charts, and in 1801, pie charts and circle graphs.
In order to provide an equivalent experience to a non-sighted user that a graph provides to a sighted reader, you need the summary of trends as well as the data table. The summary can be placed on the page or can be part of the graph’s alt text.
Table summary example
For each year the values of A in each pair were below the values of B. The highest percentages for both A and B were in 2023.
As stated above, the trends and patterns in the data are available at a glance from the graphic but not so obvious from the table. This is why you need both the summary and the table.
A summary of trends in a data set can be hidden behind a graph as alt text, although it is preferable to make it visible on the page if at all possible. However, the table cannot be. Doing so will exclude your largest target audience, namely people with dyslexia and other cognitive disabilities.