When providing programming documentation to users of an office suite software, does intelligent cell merging in tables, make the info more accessible?

Question

Examples of such merged-cell use, alongside versions of same info without merged-cell use

Info using merged cells

Table 1

Table 2

Same info without using merged cells

Table 1

Table 2

Background

I was advised that such merging might make it more difficult for such users to access the information (rather than help them). The adviser also implied that I should ask other programmers of the programming language, what they would prefer in regards to the merging. Because of this, I am posting this question here & at other places.

Answer 1

I respectively disagree that merged cells are bad. I've been using a screen reader for a dozen years and if tables are marked up properly, merged cells work great. But that's a big IF.

Tables get a bad rap with respect to accessibility. Even complex tables can be easy to make accessible if you try to keep it simple. In your merged example (your first table 2), if rowspan were used and the table cell is marked as a row header (<th scope="row">), then it works fantastic. There's no need to "dumb down" the interface if using merged cells makes sense for everyone. It makes the table cleaner visually and it works great with a screen reader.

Screen reader users also have keyboard shortcuts so no matter what cell they're in, they can have the row and/or column header (<th>) re-announced for the cell. But again, that only works if you coded your <table> properly.

Update: June 30, 2019

I want to address a few issues from the comments on my answer as well as the accepted answer.

I don't want to take anything away from @schmuddi as they did provide some links to back up their opinion. However, the links posted have several problems. The articles posted are just people's opinions and not authoritative (and I totally admit that my answer is my opinion and not authoritative either, but does have a little more "weight" as I'll mention later.)

All the articles talk about how sighted users can read a table easier than a screen reader user, and that a table should be made simple for the screen reader user. Well, keeping a table simple is good advice for all users. Screen reader users are highly intelligent, just like anyone else. Just because vision is impaired to a degree does not mean that the brain does not work. A complex table that is well formed is easy for a sighted user to understand and for a screen reader user to understand.

I would venture to guess that the articles cited were all written by people who do not use a screen reader, so they are somewhat guessing on how a screen reader user can navigate a table. Screen reading software has tons of shortcut keys to help with navigation. There are probably a dozen different ways to navigate through tables. The authors did not provide any evidence to back up what they're saying. They just said it's hard for a screen reader user to navigate a table. That's just blatantly false. Yes, it's hard to navigate a poorly marked up table but it's super easy to navigate a well-formed table.

Here are a few examples from the articles:

• Accessibility and Usability at Penn State

When sighted users focus on a table cell, they are able to visually determine which row and column the cell is in and what the data means.

So can a screen reader user. There are shortcut keys to read the column header, row header, and the position within the table (eg, row 5 column 3)

On the other hand, a screen reader can only read aloud each cell one by one from left to right top to bottom.

Not true. I can read an entire row or even the entire table if I want. And I'm not limited to "left to right top to bottom". That's absurd and utterly false. Written by someone who apparently has never used a screen reader. I can navigate through a table the same way you would navigate through a spreadsheet, moving horizontally or vertically through cells. I am not limited to just "left to right top to bottom"

Don’t Merge Cells
Even with headers properly marked, if cells are merged, a screen reader could find it difficult to determine which cell when cells become merged. Therefore it is recommended not to merge cells.

Properly marked up tables have no trouble communicating which cells are merged. Just make sure you use rowspan and colspan. What source does the author cite to backup their claim that screen reader users would find it difficult to navigate cells? Nothing. They are just guessing based on their lack of knowledge of how a screen reader works.

That's just the first article that was cited. Moving on

• Accessible U, University of Minnesota

"Complex tables, on the other hand, are ... when cells are unpredictably merged"

"It is recommended NOT to use ... tables with randomly merged cells."

(emphasis mine). I would agree that if cells are unpredictably merged or randomly merged, that absolutely it could be a problem for all users, sighted or not. But the article is not saying that you should not have merged cells. Only that poorly formed tables should be avoided.

Tables should not contain merged cells as they are difficult to navigate with screen readers.

Says who? You, the author, that doesn't use a screen reader? What's your basis for that statement? It'd be nice if they cited a source that showed that merged cells were difficult to navigate. But they won't find one because merged cells are not difficult to navigate. And to beat the horse again, they are not hard to navigate if the table is marked up properly.

• Office of Integrity, Safety & Compliance, University of Colorado

How to Make a Good Table 3. Avoid merging cells. When cells are merged, it blocks a screen reader from navigating in a way that makes sense

Makes sense to whom? You, the non-screen reading user author? As I keep stating, navigating merged cells is super easy (and makes sense) with a screen reader.

• Windows: Best practices for making Word documents accessible

You cited this reference in your comment as "offical advice" on tables. That reference is for Microsoft Word tables, not HTML tables. Word tables do indeed lack decent support for screen readers but that's Microsoft's problem for not having good accessibility for tables. There's no way to mark a row header and no way to mark merged cells properly, so of course Microsoft will say you shouldn't have merged cells. It's totally irrelevant to HTML tables which has the proper semantics to mark up merged cells.

Now, can I cite any references to back up what I'm saying? I can point to the various screen reader documents that list all the keyboard shortcuts. They don't say whether you should have merged cells but they tell you the different ways you can navigate a table.

• NVDA keyboard shortcuts
• JAWS keyboard shortcuts
• VoiceOver keyboard shortcuts

For example, JAWS, which is very feature rich, has this for table navigation:

• List keystrokes for table navigation - INSERT+SPACEBAR, followed by T, and then QUESTION MARK
• Next Table - T
• Prior Table - SHIFT+T
• Select Table - F8
• Next Row - WINDOWS KEY+ALT+DOWN ARROW
• Prior Row - WINDOWS KEY+ALT+UP ARROW
• Read Row - WINDOWS KEY+COMMA or WINDOWS KEY+NUM PAD 5
• Next Column - WINDOWS KEY+ALT+RIGHT ARROW
• Prior Column - WINDOWS KEY+ALT+LEFT ARROW
• Read Column - WINDOWS KEY+PERIOD
• Next Cell in Row - ALT+CTRL+RIGHT ARROW
• Prior Cell in Row - ALT+CTRL+LEFT ARROW
• Cell Below in Column - ALT+CTRL+DOWN ARROW
• Cell Above in Column - ALT+CTRL+UP ARROW
• Jump to Table Cell - CTRL+WINDOWS KEY+J
• Return to Previous Cell - CTRL+WINDOWS KEY+SHIFT+J

Does that sound like a screen reader user is limited to "left to right top to bottom"?

As another source, the W3C has several accessibility tutorials. One is specifically for tables. It has sections for "irregular headers" and "multi-level headers". These sections don't talk about merged data cells but they do talk about merged header cells, so it's the same principle. No where does it recommend not having merged cells. It just talks about how to implement them properly.

So going back to my original statement, I respectively disagree that merged cells are bad. If tables are marked up properly, merged cells work great.

Answer 2

You use the "Accessibility" tag for this question, which is defined here as (my emphasis):

a general term used to describe the degree to which a product, device, service, or environment is available to as many people as possible. Accessibility is often used to focus on people with disabilities or special needs and their right of access to entities

In other words, if you are concerned about the accessibility of your table, you should take users with special needs into account. With regard to merged cells, it has been argued that collapsing multiple cells into one decreases the accessibility of the table:

Even with headers properly marked, if cells are merged, a screen reader could find it difficult to determine which cell when cells become merged. Therefore it is recommended not to merge cells. (Accessibility and Usability at Penn State)

Tables should not contain merged cells as they are difficult to navigate with screen readers. (Accessible U, University of Minnesota)

Avoid merging cells. When cells are merged, it blocks a screen reader from navigating in a way that makes sense, increasing the likelihood a user will miss content or be unable to understand the overall layout. (Office of Integrity, Safety & Compliance, University of Colorado)

Thus, if accessibility is important for your application, those who discuss this issue in relation to tables and merged cells advise against their use.

Caveat: I couldn't find any peer-reviewed publication on the topic so I don't know how well-founded these recommendations are.

Answer 3

Data Redundancy control

As we can see and it is definitely evident that it eradicates data redundancy in the table. The user directly gets the commonality of entities. User needs to read less and would understand more than while comparing/reading each entity with one other and analyzing that they are the same.

The Con: The main issue that we would face with tables containing merged cells is the inability to apply Mathematical & Sort functions upon it.

So we should first identify the use case of the table and decide whether to merge cells or not.

Also, as your colleague rightly implied, Merged cells might be hard to comprehend for some users. We cannot ignore that. But comparing the pain point weights: Should we rather not merge the cells to cater to the very small amount of people who are able to comprehend the merge slowly; or should we merge the cells in order to cater to a vast majority of people who are going to waste their time with redundancies and comparisons.