Accessibility myths: The misguided war on merged cells

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:

Example one
OfficeCube numberName
Office of Fancy Folks101AJan "Fancypants" Binelli
203JSam "the fancy one" Sammy
419BLisa "Fancy-tastic" Glass

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 two
OfficeCube numberName
101AJan “Fancypants” Binelli
Office of Fancy Folks203JSam “the fancy one” Sammy
419BLisa “Fancy-tastic” Glass

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 three
OfficeCube numberName
Office of Fancy Folks101A
Jan "Fancypants" Binelli
Sam "the fancy one" Sammy
Lisa "Fancy-tastic" Glass

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 trained1.

Example four
OfficeCube numberName
Office of Fancy Folks101AJan “Fancypants” Binelli
203JSam “the fancy one” Sammy
419BLisa “Fancy-tastic” Glass

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:

Example five
OfficeCube numberName
Office of Fancy Folks101AJan "Fancypants" Binelli
Office of Fancy Folks203JSam "the fancy one" Sammy
Office of Fancy Folks419BLisa "Fancy-tastic" Glass

Accessibility for users with varying cognitive needs is not a terribly well-discussed or formalized area2. 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 data3. 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.

  1. I don’t, by the way, think that everyone needs to be perfectly trained in Microsoft Office. While basic training that breaks peoples’ bad habits (individual formatting instead of styles, say) would be great, even that seems improbable at my office. But if teams are putting out documents, someone who is well-trained should be performing final quality assurance on these things. ↩︎
  2. Accessibility in general is subjective, of course, but cognitive issues seem like largely uncharted territory. W3C has a Cognitive Accessibility Roadmap and Gap Analysis that goes a long way toward planting the seeds of things document creators should keep in mind. ↩︎
  3. I’ve seen some discussion about making null data read ‘Intentionally left blank’ or the like, but this doesn’t seem widely agreed upon. In my experience navigating tables with a screen reader, it would be difficult to accidentally escape the table mid-way through, as boundaries and the like are clearly announced. Something to keep in mind, however. ↩︎

this post is part of the series, accessibility myths:
  1. The delusion of accessibility checkers
  2. The deceitful panacea of alt text
  3. The misguided war on merged cells