Accessible annual report financial tables

Usability and accessibility design problems and solutions

As another annual report season comes to a close, two key PDF accessibility themes come once more to mind:

• PDF accessibility is about so much more than tagging and technical accessibility: the content also has to be right.
• PDF accessibility professionals should not just be passive recipients of whatever content they are supplied with. We have a key role to play in feeding back to clients the many ways documents can and should be improved at source.

Accordingly, the following sets out some of the most common design and layout problems found in annual report financial tables, as well as tips on how to fix them.

Unlabelled subtotals

Perhaps the most common design error in many annual report financial tables is the inclusion of unlabelled subtotals, as in Figure 1 below. In the absence of an appropriate row header, the reader is assumed to be able to figure out that these are subtotals by visual means only, in this case because of the physical location of the text in question, and because it is in bold.

This is a clear violation of WCAG 2.1, 1.3.3 (sensory characteristics)—”instructions provided for understanding and operating content do not rely solely on sensory characteristics of components such as shape, color, size, visual location,” etc.

A partial solution

For screen reader users there is a possible workaround for this, which is to use an Actual Text attribute to replace, behind the scenes, the contents of a table cell with itself, plus an appropriate label.

However, this level of editing across a whole document can be very time consuming. It also won’t solve a general usability problem: will a reader be able to tell at a glance whether £417,034 is a subtotal of the five rows above it, or just the three immediately above? Adding a row header, as in Figure 2 below, will instantly clarify, and thus improve the usability of the table for all readers.

You can test the difference

You can test the difference in performance between the layouts in Figures 1 and 2 (without the highlighting, of course) by recording the time it takes different people to answer a question such as: “What were the total current assets in 2016-17”. Almost always, people will retrieve the required information significantly faster from Figure 2.

Headers, yes please; headings, no thanks

A second structural problem with this table is the inclusion of headings doing the job of headers. What I mean by this is that the top row of cells, containing “Notes”, “2017-18, £’000” and “Restated 2016-17, £’000”, are defined here as column headers because each relates to all the content in the column below it, all the way to the bottom of the table. By contrast, “Non-current assets” and “Current assets” are headings and not headers, as they relate to only some of their respective columns’ content.

IDs and headers

The problem with headings in tables is that they will require significant editing work to explicitly associate each one with its related cells, using IDs and headers. For example, the cell containing “Non-current assets” will need to be assigned an ID. Then, at a minimum, the cells containing “Intangible fixed assets” and “Property, plant and equipment” will need to be assigned headers attributes that explicitly associate them with “Non-current assets” (via its ID). This will effectively make “Non-current assets” into a column header for these two rows of the table.

A second column of row headers

This approach will work tolerably well for screen reader users, but is still far from ideal, for several reasons which we will examine shortly. However, a far better design would be to lose the headings altogether by converting them to row headers. To do so, simply create a new column of row headers and move the headings into it, as in Figure 3 below. These will now be headers because they relate to all of the content in the row or rows that they head (all the way to the end of the row).

Once these cells have been assigned <TH> tags and row span attributes as appropriate, there will be no need for any IDs and headers. Hence, this approach can dramatically cut down the amount of post-production tagging work required. But that is by no means the only advantage.

Better for screen reader users

In table designs which oblige you to use IDs and headers, unless you add IDs to all of the table’s headers/headings, and then add headers attributes to every single data cell throughout the table, the data cells will not be explicitly associated with all of their related headers.

However, if you convert all headings to headers as described above, all of the data cells will be explicitly associated automatically with their respective headers, and a potentially substantial amount of editing work will be avoided.

Better for screen magnifier users

The above approach will also benefit screen magnifier users as it will cut down the physical distance between the contents of a row header cell and a data cell. Looking at an A4 size page of which Figure 2 is a screenshot, and using ZoomText with a magnification setting of just ×5 (on a 17″ screen), I can already see a whole screen’s width of white space between the end of the row header “Intangible fixed assets” and the “4” in the Notes column. This makes it difficult to read and understand the table at this level of magnification.

However, with the layout in Figure 3, I can zoom to ×16 and still not get a whole screen width of white space between the row header and the next cell to its right. A very considerable improvement. (To put this in perspective, ZoomText, MAGic and SuperNova all allow magnification up to ×36).

Of course, adding row and column borders or perhaps alternating background colours for each row would also help in this respect. But either way, the reduction in excessive empty space between cells is likely to aid readability for everyone, but particularly for screen magnifier users. 

The problem with £’000 (redundancy)

There is one further small amendment to this table that I would recommend in order to reduce both redundancy and editing time, as well as make the content more screen reader accessible. Notice that both main data columns include “£’000”, indicating that the figures are in thousands of pounds. This kind of abbreviation can often be found in multiple columns but it actually need only appear once, in the caption or heading, as shown in Figure 4 below.

Making this change will de-clutter the column headers and thus reduce cognitive load for all readers. And, as screen readers don’t interpret “£’000” particularly consistently or meaningfully, it will be helpful to replace it with an Actual Text attribute of “thousands of pounds”. And once again, of course, it will cut editing time to have to do this only once per table.

Notes

Lastly, there is a problem with the usability and accessibility of notes referenced from a table in the way this one does. In a PDF it is possible, although quite labour-intensive, to link from each note reference to the note itself. It is not at all straightforward to provide back-links that will work reliably for screen reader users (it’s very fiddly and time-consuming, and the results are generally not great, especially when a note is referenced multiple times from different tables. In such a case, back-links can effectively be dismissed as an option).

Pop-ups revisited

A better result can be achieved by making each note available via a JavaScript-driven pop-up. I set out elsewhere in this blog the techniques for doing this in the context of accessible PDF footnotes and endnotes and so will not repeat it here.

However, it is important to note that this level of refinement doesn’t come cheaply. Even an experienced PDF editor can expect to spend 5 minutes or more per note reference when employing this technique. Doing so could easily add a couple of hours or more to the time it would take to make a typical annual report accessible.

Conclusion

As stated at the outset, the table design problems set out above need to be addressed at source as there are only limited or time-consuming retrospective workarounds available for them, if at all. But theses kinds of problems and their solutions may not be obvious to those who don’t regularly test PDFs for accessibility. For these reasons, there needs to be ongoing dialogue between document producers and accessibility specialists.

Training

We also cover this topic in detail our Accessible PDFs from InDesign and Accessible PDFs from Word training courses.

Further information

For more on this topic, and a detailed study of the wider topic of making accessible PDF tables, please check out my ebook Design and build accessible PDF tables”. (It’s a few years old now, but still as relevant as ever.)