When good accessibility advice is dumbed down to the point it becomes bad advice

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

Table 1: Comparative race statistics, red team and blue team
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.)

Table 2: Statement of financial position as at year-end, £’000
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.


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.