31 July 2020 | Ted Page
I often hear from organisations who have been advised, for accessibility reasons, to avoid merging cells in tables in PDFs. This advice needs a fair bit of qualification. Taking it at face value could do more harm than good.
The required formatting
When navigating around a correctly formatted table, a screen reader user will hear the appropriate column or row headers being read out before the data value for any given cell. “Correctly formatted” in this context means that a header cell must:
- be tagged with a
<TH>tag - have an appropriate scope attribute (column or row)
- (in the case of merged cells) have an appropriate column span or row span attribute
Column and row span attributes
For a merged header cell to “know”, for example, that it spans two columns, it must have a ColSpan (column span) attribute with a value of 2. Without this, the wrong headers are liable to be read out before each data cell, thus rendering the content unintelligible.
Merged header cells in MS Word—need repair
Unfortunately, MS Word doesn’t do a great job of generating column span or row span attributes. Although Word 2003 used to get merged cells right (sort of), all subsequent versions don’t. (The shortcomings of MS Word in this respect are perhaps the source of people’s concerns about PDF data tables). Such cells will need to be fixed after the document has been exported to PDF, along with headers and scope which are both likely to need fixing in all but the simplest of tables.
Merged header cells in InDesign—no problem
By contrast, header cells that are merged in InDesign will cause no problems at all. They automatically get the correct column or row span attributes when exported to PDF (although row headers and scope attributes will need editing).
How to fix the problems
There are plenty of guides around on how to tag tables in Acrobat, so I won’t reproduce the information here (these include https://blogs.wright.edu/learn/accessibility/pdf-documents/complex-tables-in-pdf/, or my ageing but still relevant ebook Design and build accessible PDF tables). Suffice it to say that it’s a relatively simple and straightforward process, once you are familiar with it.
Why does it matter?
In order to dispense with merged cells you will be forced to break tables into multiple smaller units. For example, the table below would have to be divided in to four separate tables: one for Red team 2020, one for Blue team 2020, one for Red team 2019, and one for Blue team 2019.
| 2020 | 2019 | ||||
|---|---|---|---|---|---|
| Appearances | Wins | Appearances | Wins | ||
| Red team | Sue | 15 | 4 | 12 | 5 |
| Bob | 12 | 3 | 13 | 6 | |
| Blue team | Harry | 13 | 4 | 10 | 4 |
| Beth | 18 | 2 | 16 | 3 | |
But forcing readers to navigate between multiple tables will make it more difficult to make comparisons between different categories of data (in this case teams and years), thus rendering the content less usable and less accessible.
In a PDF, the above table (and more complex ones besides), if formatted correctly, will work fine in both JAWS and NVDA. Yes it’s true that complex Word-authored tables are a problem, out of the box. But fixing them in Acrobat is quick and easy (once you are familiar with the process) so there really is no need to avoid merging cells when you need to. On the contrary, you are liable to make your content less accessible if you do.