0

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

Info using merged cells

Table 1

VBA non-intrinsic data types table with merged cells

Table 2

VBA intrinsic data types table with merged cells

Same info without using merged cells

Table 1

VBA non-intrinsic data types table without merged cells

Table 2

VBA intrinsic data types table without merged cells


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.

0

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:

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

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

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.

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.

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.

  • Thanks for your input on this. Great to have a screen-reader user adding their thoughts. – Mark Fernandes Jun 22 at 17:35
  • Whilst what you say makes perfect sense, unfortunately, it seems to clash with the generally held official advice re. complex tables. It appears to clash with Microsoft's advice; such advice bears weight for my particular circumstances. See support.office.com/en-us/article/…. Is it possible for you to cite some kind of official advice re. your opinions? I think that would improve this StackExchange question a great deal. Thanks. – Mark Fernandes Jun 22 at 17:35
  • There is no "official" advice re. complex tables. As noted in my update, all the "official" advice was purely subjective and one person's opinion and was based on incorrect information. Note also that the most recent WebAIM screen reader survey (2017) says that complex tables are one of the least problematic areas - webaim.org/projects/screenreadersurvey7/#problematic – slugolicious Jul 10 at 17:00
  • Hello @slugolicious, thanks for improving your answer. Whilst your personal experiences and the survey results did add weight to your argument, the thing that convinced me in the end was your pointing out that the Microsoft Word advice didn't necessarily apply to HTML tables and your pointing out that the W3C accessibility tutorials covering complex tables, didn't mention that merged cells were a problem. – Mark Fernandes Jul 20 at 7:57
  • When I looked at the university advice, I mistook the advice as being the direct fruits of academic research. Looking at it again, I can see that the advice wasn't specifically part of any academic research and I agree that the true nature of the advice lessens how official it is. If you are able to edit your post to include links to academic research agreeing with your opinion, that would improve your answer probably a great deal. – Mark Fernandes Jul 20 at 8:04
1

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.

  • Great answer, thanks for pointing these things out which I never considered before. – Mark Fernandes Jun 19 at 9:56
  • I've accepted this answer as the correct answer because there exist visually-impaired programmers who use screen readers, because of the links cited in this post, & because of other information I have discovered. See github.com/MicrosoftDocs/VBA-Docs/issues/… for more info. – Mark Fernandes Jun 19 at 14:17
  • If possible, please edit post such that you indicate that it is likely the case that programming documentation for general users of an office suite software, needs to be accessible to the visually impaired, & so consequently complex tables (including tables with merged cells) appear to be ill-advised for such documentation. This would probably make this answer more beneficial to viewers of this StackExchange question. – Mark Fernandes Jun 19 at 14:23
  • @Schmuddi Great answer. You looked onto the question with a different POV, unlike my answer, considering accessibility as the utmost priority. – Kishan Jun 19 at 16:05
0

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.

  • Hello @Kishan, thanks for your answer. Even though your answer is very good, I'd like to leave this question unanswered for a little while in order to prompt more answers to it. When you talk about applying mathematical functions, do you mean having spreadsheet formulae that reference the information inside the table? Sorry, I'm just a bit confused. The table is only meant to be read as documentation. – Mark Fernandes Jun 18 at 15:26
  • Also, what do you think about the opinion that users would find such merged cells difficult to comprehend? To my mind, they're quite easy to comprehend. However, someone else implied it would be more difficult to comprehend the information. – Mark Fernandes Jun 18 at 15:28
  • @MarkFernandes Definitely, we should wait for better answers. About fn: yes I mean about the spreadsheet formulae in general even though it is not valid in your case, It is a deciding factor of whether to merge cells in general. – Kishan Jun 18 at 15:41
  • 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. – Kishan Jun 18 at 15:45
  • Good point @Kishan. If possible, can you edit your answer to include this last point that you have made about who we should cater to? Thanks. – Mark Fernandes Jun 18 at 16:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.