brhfl.com

One of the stranger accessibility myths that I often run into is that merged cells in tables are to be avoided at all costs. This is entirely antithetical to semantic structuring of data and really points to a larger issue: often, folks who are doing and talking about accessibility have no concept of tabular structure, data relationships, and the importance of context. This goes both ways – often, folks that I receive documents from will have put multiple pieces of data in a single cell, either because they don’t know how to make the cell border invisible, or because they’re afraid to merge a cell that spans all the pieces of data.

To start, examples:

Here are four tables that exemplify this. I’m leaving my default table styles intact for the first three, which colors odd and even rows differently. This helps to show what I’m demonstrating in each issue, but if you imagine them styled differently (as in the fourth), they could all very well look the same – but the accessibility of the data varies dramatically. Example one is the correct solution: three people all belong to one office. There are seven pieces of data: the one office that they belong to, their three respective cube numbers, and their three respective names:

In example two, the user wants the office to visually span all three people, but has been told they can’t merge cells, so structurally Jan and Lisa don’t belong to any office. Note that according to my default style, the ‘Office of Fancy Folks’ cell is not shaded as an even row because it’s a table header cell.

Example three only has one row worth of data. All three cube numbers are treated as a single piece of data; all three names are treated as a single piece of data.

Example four is structurally identical to example one (the correct one), but visually it has been restyled to mimic the desired visual effect of example three. This is easily done in Microsoft Word, but the unfortunate reality in my experience is simply that people are insufficiently trained¹.

Why does this matter?

So, what does all of this mean as far as accessibility? When we’re focusing on these invisible structural issues, it’s generally because they cause a discrepancy between the visual experience and the experience afforded a blind user using a screen reader. Tabular data is, at its core, a two-dimensional system of data relationships: a piece of data is somehow related to those in the same column, and those in the same row. Visually, if we’re looking for data in a table, we identify header rows and/or columns, and we scan for the information we know so that we can find the related information we need to know. Screen readers allow users to navigate tables in both dimensions, one cell at a time. Changing rows or columns reads off any necessary header information as well as the cell data.

In example two, as mentioned, Jan and Lisa have no relationship to an office. The two empty cells aren’t actually intended to contain null data, they’re supposed to reflect that Jan and Lisa are members of the Office of Fancy Folks. Without that data there, there’s simply no way for a screen reader user to associate that office with those two names. Example three is slightly less of a problem – in theory, a user could relate all of the data. In practice, all of ‘101A 203J 419B’ will be read off together. If the user is trying to figure out who works in 419B, they need to count entries as that list is being read off, and then remember that they’re listening for the third one in the next cell. While my tables are small for demonstration purposes, this becomes increasingly implausible as more and more individual pieces of data are improperly crammed into a single cell. It completely falls apart if there’s null data – an empty cell will still exist and be appropriately navigable whereas a mere line break is ignored.

Beyond sight, and a fifth example:

Even though visual impairment is seemingly the most oft-discussed accessibility issue, cognitive differences also need to be considered. To this end, I would say that the visual decision made in examples three and four is still less accessible than example one. Borders are incredibly helpful visual aids. This, again, is less obvious on my tiny table, but becomes a larger problem the more data is being presented. There is a fifth possibility which avoids merged cells and ensures absolute clarity from cell-to-cell:

Accessibility for users with varying cognitive needs is not a terribly well-discussed or formalized area². To that end, I’m not entirely sure how the redundant/repeated information and the resulting visual busyness in example five would affect certain users. I’m inclined to believe that it’s a universally clean solution (also, it’s guaranteed to filter/sort cleanly even in poorly-designed systems), but this is just a hunch based on the fact that there’s a perfect 1:1 relationship across all of the data. Perhaps this is what people mean when they say not to merge cells, but they never explain this, and the result is a ton of ‘example twos’ out in the wild.

Ultimately, the key isn’t to never merge cells, nor is it to merge cells indiscriminately. The key is to ensure every piece of data has its own cell, and that cells which are left empty are truly null data³. Tools for structuring tables (that is, creating rows and columns, and merging cells) exist for a reason, and misusing tabular structure has real implications as far as navigation is concerned. Suggestions to avoid merging cells seemingly never come with explanations of what to actually do with that data, nor do they ever ask of the user why they’re merging in the first place.