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