Handling Blank Data Cells in Accessible Tables

A question we hear all the time is what to do with blank cells in a table. The good news is there is a clear path forward. The approach simply depends on the kind of cell you are working with. A header cell asks for one solution, while a data cell calls for another. Once you know the difference, it becomes much easier to decide what to do.

Header Cells

Every table needs headers. These can be column headers, row headers, or both. Header cells are what give a table its logic and structure, helping readers and screen readers understand how the data fits together.

WCAG does technically allow the first cell in the top left corner—the A1 cell—to be blank. But beyond that, no other header cells should be left empty. If you want to see examples of well-structured tables and how header relationships work, the  W3C’s Tables Tutorial is a great place to start.

Before we dive in, remember this: we can’t control exactly how every screen reader will read a table. What we can do is follow accessibility best practices to give users the clearest, most consistent experience. This lines up with the P.O.U.R. principles of accessibility:

• Perceivable – People can see or hear the information.
• Operable – People can use it with their tools.
• Understandable – People can make sense of it.
• Robust – It works across different devices and screen readers.

Blank Data Cells

It’s common to see empty data cells in tables. The challenge is that screen readers don’t treat them the same way. Let’s investigate how two different screen readers will announce an empty data call:

• JAWS will announce the word “blank,” so users know there is an empty cell.
• NVDA does not announce the empty cell at all. It skips ahead to the next cell, although it will still read the column header if the table is set up correctly with scope.  

Because of this, as accessibility experts we suggest that you never leave a cell empty. Instead, consider putting something in the cell to show there is no value. This isn’t required by WCAG, but it usually makes the table easier to understand.

What Should You Put in the Blank Cell?

Here are some options people use, and how JAWS and NVDA read them:

Notice: A dash (“-”) doesn’t get read at all in NVDA, which could confuse users.

Our Recommendation: The best choice depends on your audience and the type of data. Phrases like “Not applicable” or “No value” are usually the clearest for all audience members.

What If You Can’t Change the Cell Value?

Sometimes, especially with financial or legal documents, you aren’t allowed to change what appears in the table. In that case, you can’t just replace a blank with “No value.”

There are advanced techniques, like adding hidden (invisible) text for screen readers—but these are complex and not something the average user will need. In fact, older methods like adding alt text no longer work because accessibility checkers now flag them as errors.

Key Takeaways

Blank cells are tricky because various screen readers have different ways of announcing them. But here are some guiding principles:

• Use clear headers for all rows and columns.
• If possible, avoid blank data cells. Add text like “Not applicable” instead.
• If you can’t change the cell value (like in legal or financial documents), know that there are advanced fixes, but they may not always be practical.
  

At the end of the day, your goal is simple: make tables easy to understand for everyone. When a table is clear and consistent, screen reader users do not have to guess or work harder, and all users can move through the information with confidence.