26 March 2021 | Ted Page
Good advice can be over-simplified to the point that it becomes harmful. Unfortunately, in the accessibility world there are many such over-simplifications doing the rounds.
I have written about a few such cases elsewhere in this blog, including on the topics of skipped headings, italics and merged table cells. In future posts I may cover others such as “don’t use click here” or “design doesn’t matter, only functionality counts”.
But here I will return to tables, having recently seen two lots of over-simplified accessibility guidance on this topic published by prominent organisations. I will compare these with WCAG’s guidance on the subject and discuss how each pans out in the real world. I will argue that, in a world of competing claims, WCAG remains the most reliable point of reference.
The over-simplified version
In the case of merged table cells, the over-simplified advice goes something like this: don’t merge table cells. Instead break complex tables down into a number of smaller, simpler tables.
As will be seen, this can be good advice. But sometimes it isn’t, and sometimes it would be impossible to follow, even if it were desirable.
What WCAG has to say on merged table cells
By contrast, in Technique H63, WCAG states the following (emphasis added):
- Some users may find it easier to work with several simple tables than one more complex table.
- Authors may wish to consider whether they can convert complex tables to one or more simple tables.
Furthermore, in Technique PDF6, WCAG states:
- Cells that span two or more rows or columns should use the RowSpan or ColSpan attribute.
Summary of the WCAG position
The WCAG position on merged table cells can be summarised as follows: some people may find tables easier to use if they are broken down into smaller units, but there is no requirement to do so. There is also a clear recognition that some tables cannot be split. So, when you do merge cells, make sure to mark up their column span and row span attributes correctly.
Problems of the over-simplified advice
If the answer a reader is looking for from a table is just the contents of a single cell (as it may be, for example, in a bus timetable), then that information may be more easily retrieved if complex tables are split. However, if the question the user is seeking to answer requires the extraction of trends, patterns, relationships, proportions or anomalies from the data, then it is quite likely that keeping the data in a single complex table will be better.
Example 1
| 2020 | 2019 | ||||
|---|---|---|---|---|---|
| Entered | Completed | Entered | Completed | ||
| Red team | Harry | 10 | 8 | 5 | 5 |
| Tom | 12 | 7 | 6 | 6 | |
| Beth | 15 | 15 | 3 | 3 | |
| Blue team | Sue | 16 | 15 | 9 | 8 |
| Sam | 13 | 13 | 4 | 2 | |
| Bill | 14 | 14 | 7 | 3 | |
In the above example, to avoid merged cells, the table would have to be broken down into four separate tables (one each for red team 2020, red team 2019, blue team 2020, and blue team 2019). If the user then wants to know, for example, how many races red team’s Harry entered in 2020, finding the relevant table and the contents of the appropriate cell should be relatively straightforward.
However, if the user wants to make comparisons, for example, between teams or between years, it is likely to be considerably easier to do so in the larger complex table rather than having to jump between four separate tables to extract the required information.
Example 2
Secondly, as stated previously, some tables can’t be split and therefore must contain merged cells. Below is just such an example. (It can’t be split as it contains overall totals in the final row.)
| Note | 2020 | 2019 | ||
|---|---|---|---|---|
| Non-current assets | Intangible assets | 12 | 5,095 | 6,342 |
| Property, plant and equipment | 9 | 152,098 | 144,702 | |
| Receivables | 6 | 909 | 480 | |
| Total non-current assets | 158,102 | 151,524 | ||
| Current assets | Inventories | 14 | 8,175 | 8,133 |
| Receivables | 10 | 5,223 | 18,380 | |
| Cash and cash equivalents | 1 | 9,692 | 8,156 | |
| Total current assets | 43,090 | 34,669 | ||
| Current liabilities | Trade and other payables | 3 | −37,327 | −29,937 |
| Borrowings | 8 | −17,956 | −7,686 | |
| Provisions | 16 | −381 | −412 | |
| Other liabilities | 7 | −3,948 | −5,506 | |
| Total current liabilities | −59,612 | −43,541 | ||
| Total assets less current liabilities | 141,580 | 142,652 | ||
| Non-current liabilities | Borrowings | 12 | −46,481 | −47,476 |
| Provisions | 22 | −4,110 | −4,302 | |
| Other liabilities | 26 | −1,056 | −1,584 | |
| Total non-current liabilities | −51,647 | −53,362 | ||
| Total assets employed | 89,933 | 89,290 | ||
I am aware, by the way, that entries in financial tables such as “Non-current assets” above often appear on separate rows rather than in a first column of merged cells.
However, doing so is not good design, accessibility-wise nor otherwise, as it breaks the relationships between rows and columns of data—the defining characteristic of what a table is and what it is for. Nor does it solve the problem as such cells would have to be merged horizontally in any case.
Conclusion
Beware of over-prescriptive accessibility advice on complex versus simple tables. As with skipped headings, italics, “click here” and many other examples, WCAG provides sensible, practical and well thought-through guidance. Unnecessarily limiting your options can make your content less accessible, not more so.