You did the polite thing. You had "Q1 Revenue," "Q2 Revenue," and "Q3 Revenue" crammed into a title row, so you selected all three header cells and hit Merge, and now your title sits centered and tidy above the data like it belongs there. Looks great. Ship it.
Except a screen reader user just opened that file, tabbed into the header row, and heard one long cell read as a single blob of text — with no idea it was ever supposed to mark the top of three separate columns. Every number underneath it is now floating, unlabeled, disconnected from the header that was supposed to identify it. You didn't break the formatting. You broke the map.
This is a five-minute fix, and it's one of those rare accessibility wins that also makes your spreadsheet look exactly the same to everyone else. Nobody sighted will notice the difference. Screen reader users will notice immediately.
The Stat: Microsoft's own official support documentation ("Accessibility best practices with Excel spreadsheets") states that merged cells break the row-and-column structure screen readers rely on to identify headers and read data accurately — and recommends using "Center Across Selection" instead of merging cells to get the identical visual look without breaking navigation. (Source: Microsoft)
Why One Merged Cell Wrecks the Whole Sheet
A sighted user reads a spreadsheet by scanning: eyes jump to the header row, then drop down a column, cross-referencing visually as they go. A screen reader can't scan. It navigates by structure — it counts rows, counts columns, and announces which header a given cell belongs to when you land on it. That's the whole trick that makes a spreadsheet usable non-visually: "Revenue, Row 4: 128,000" instead of just "128,000" floating in space.
Merging cells corrupts that structure at the file-format level, not just the display level. When you merge A1:C1, the spreadsheet no longer has three header cells named "Q1," "Q2," and "Q3" — it has one cell that spans the space where three used to be. Every cell in columns B and C, for every row below it, now has no header to be associated with. The screen reader can still read the numbers. It just can't tell you what they mean.
This is exactly the same failure mode as a merged <td> in an HTML table without proper scope or headers attributes — and it's worth reading WebAIM's guide to accessible data tables if you build tables anywhere else, because the underlying rule is identical: assistive technology needs an explicit, unambiguous link between a data cell and the header that describes it. Merging breaks that link. It doesn't matter whether the merge happens in Excel, Google Sheets, or raw HTML — the moment two logical header cells become one physical cell, everything under the missing header goes unlabeled.
It gets worse the further down the sheet you go. Merge one header cell and you've lost three column labels. But merged cells tend to travel in packs — a merged title banner across row 1, a merged subtotal label spanning three columns in row 12, a merged "Notes" cell stretching across the bottom. Each one is a small, independent break. String enough of them together and a screen reader user isn't reading a spreadsheet anymore; they're reading a sequence of disconnected fragments and having to reconstruct the meaning by trial and error, jumping back up to the last-known header and guessing whether it still applies. That's not a minor inconvenience — it's the difference between a report someone can actually use and one they have to ask a sighted colleague to read to them.
The Fix Microsoft Already Built For You
Here's the part that makes this an easy win rather than a redesign: Excel has had a built-in alternative to merging for years, and it produces the exact same visual result. It's called Center Across Selection, and per Microsoft's own guide to accessible Excel spreadsheets, it's the recommended replacement specifically because it centers text visually across a range of cells without merging their underlying structure. The cells stay separate. The screen reader still sees three headers. The eye still sees one centered title.
To use it in Excel:
- Select the range of cells you'd normally merge (e.g., A1:C1)
- Open the Format Cells dialog (Ctrl+1, or right-click → Format Cells)
- Go to the Alignment tab
- Under "Horizontal," choose Center Across Selection
- Click OK — the text now appears centered across the range, and each cell remains individually addressable
That's it. No macros, no add-ins, no visual compromise. If you've already merged cells in an existing file, the fix is just as fast in reverse: select the merged range, click "Unmerge Cells" on the Home tab, then apply Center Across Selection instead.
What About Google Sheets?
Google publishes its own accessibility documentation for Google Workspace, including Sheets, covering the built-in accessibility features available across its apps — it's worth a look via Google Workspace's accessibility page if you're standardizing a team on Sheets. Google Sheets doesn't currently offer a direct equivalent named "Center Across Selection," which means the safest path in Sheets is simpler: don't merge header cells at all. Keep each header in its own cell, and if you want a wider visual title above the whole table, put it in the row above your actual headers as its own separate line rather than folding it into row one. It's a smaller visual win than Excel's trick, but it keeps every column header intact and independently readable.
If your team works across both apps — building in Sheets, exporting to Excel for a client, or vice versa — it's worth agreeing on "no merged header cells, ever" as a house rule rather than trying to remember which fix applies in which tool. It's one less thing to think about mid-deadline, and it means a file built in Sheets doesn't quietly pick up a broken merge the moment someone opens it in Excel and "cleans it up" visually without realizing what they're doing structurally.
Merge vs. Center Across Selection, Side by Side
| Merge Cells | Center Across Selection | |
|---|---|---|
| Visual result | Centered across range | Centered across range (identical) |
| Underlying cell structure | Collapsed into one cell | Stays as separate cells |
| Screen reader reads header row as | One unlabeled block | Each header individually |
| Column headers below stay linked to data | No | Yes |
| Available in | Excel, Google Sheets | Excel only |
| Recommended by Microsoft's own guidance | No | Yes |
A Quick Audit for Files You Already Have
Before you send that next spreadsheet, spend two minutes running through this:
- Select your header row — does it highlight as one continuous merged cell, or as separate cells?
- If merged, unmerge and reapply the heading style using Center Across Selection instead
- Check for merged cells lower in the sheet too — subtotal rows and section dividers are common repeat offenders
- Make sure the very first row (or column) of real data consistently holds your headers — screen readers and both Excel's and Sheets' "freeze row" features rely on that consistency
- Re-read the sheet with your own screen reader's table-navigation shortcut, if you have one installed, as a final sanity check
None of this requires redesigning your spreadsheet. It requires trading one formatting habit for a nearly identical one that doesn't quietly erase your table's structure for a chunk of your readers.
Spreadsheets are just one place this kind of structural accessibility issue hides — the same "looks fine, reads broken" problem shows up constantly in web pages, too. If you want to know where it's hiding on your site, get a free scan of your website and find out before a user has to tell you.