If your website displays pricing plans, schedules, comparison charts, or any kind of structured data, chances are you are using tables. Tables are one of the most common — and most frequently broken — elements when it comes to web accessibility.

A sighted user can glance at a table and instantly understand the relationship between rows and columns. A screen reader user, on the other hand, navigates a table one cell at a time. Without proper markup, they hear a stream of disconnected values with no way to know which column or row each number belongs to. Imagine hearing “29.99” without knowing whether that is a monthly price, an annual price, or the cost of shipping.

The European Accessibility Act (EAA) and the Americans with Disabilities Act (ADA) both require that digital content be perceivable and understandable to all users. Tables with missing headers, merged cells that lack proper associations, or layout tables mistaken for data tables are among the most cited WCAG failures in accessibility audits. The good news is that most table accessibility issues are straightforward to fix, even if you are not a developer.

Why Table Accessibility Matters

According to WebAIM’s annual accessibility survey, data tables are one of the top barriers reported by screen reader users. When a table lacks proper header associations, users must memorize column positions to make sense of the data — a cognitive burden that makes the content effectively unusable.

Tables appear everywhere on business websites:

• Pricing pages comparing plan features and costs
• Service schedules showing times, locations, and availability
• Product specifications listing technical details
• Financial reports with quarterly data
• Comparison charts evaluating products or services

Each of these use cases relies on the relationship between row and column headers to convey meaning. Without accessibility markup, that meaning is lost for the estimated 7.6 million people in the US alone who use screen readers.

The Four Essentials of an Accessible Table

1. Use Real HTML Tables, Not Fake Ones

Some website builders and content editors create “tables” using grids of images, columns of text, or CSS layouts that look like tables visually but are not recognized as tables by assistive technology. Screen readers have special table navigation commands — they let users jump between columns and rows, hear column headers announced automatically, and get a summary of the table structure. None of this works if the table is built with divs or images.

What to check: If you can select your table in your CMS editor and it appears as a “Table” block or element, you are likely using a real HTML table. If you built it by arranging text blocks in columns, it is not a real table and screen readers cannot navigate it properly.

How to fix it: Use your CMS’s built-in table tool. In WordPress, use the Table block in Gutenberg. In Squarespace, use the Markdown block with table syntax. In Shopify, use the table option in the rich text editor. If your platform does not offer a native table tool, ask your developer to implement a proper HTML table.

2. Add Table Headers with Scope Attributes

The single most impactful accessibility improvement you can make to a table is ensuring that header cells are marked as headers — not just visually bold, but structurally identified using the <th> element with a scope attribute.

The scope attribute tells screen readers whether a header applies to a column (scope="col") or a row (scope="row"). Without it, screen readers may guess incorrectly or not associate headers at all.

Simple table example:

A pricing table should have column headers marked with scope="col" so that when a screen reader user navigates to a price cell, they hear “Enterprise plan, Monthly price, $49.99” rather than just “$49.99.”

What to check: In your CMS table editor, look for an option to designate the first row as a “Header row.” In WordPress’s Table block, toggle “Header section” on. Most CMS platforms will generate the correct HTML when you use their header row feature.

How to fix it: If your CMS does not offer header row options, or if you have access to the HTML, ensure the first row uses <th scope="col"> instead of <td> for each cell. If your table also has row headers (like a list of feature names in the first column), those cells should use <th scope="row">.

3. Add a Caption or Accessible Name

Every data table should have a caption that describes what the table contains. The caption serves two purposes: it gives sighted users context about what they are looking at, and it gives screen reader users an announcement when they first encounter the table.

Think of a caption like a title for the table. “Monthly pricing for Standard, Professional, and Enterprise plans” is much more useful than arriving at a table and hearing “table with 5 rows and 4 columns” with no other context.

What to check: Does your table have a visible title or description above it? Even better, is that title part of the table element itself (using the <caption> tag)? Many CMS platforms do not expose a caption field, so you may need to add a heading above the table as an alternative.

How to fix it: If you cannot add a <caption> element through your CMS, place a descriptive heading (H3 or H4, depending on your page structure) immediately before the table. You can also ask your developer to add an aria-label or aria-describedby attribute to the table element that references a nearby description.

4. Avoid Complex Merged Cells When Possible

Merged cells (using colspan or rowspan) create complex tables where header associations become ambiguous. Screen readers struggle with multi-level headers, and even the best markup cannot fully compensate for a confusing table structure.

What to check: Look at your table and ask whether any cells span multiple columns or rows. If so, consider whether the table can be restructured into simpler tables or whether the merged cells are truly necessary.

How to fix it: Split complex tables into multiple simpler tables, each with a clear caption. For example, instead of one table with merged headers comparing three product categories across multiple dimensions, create three separate tables — one per category. This is easier for everyone to read, not just screen reader users.

Common Table Accessibility Mistakes

Using Tables for Layout

Before CSS became widespread, web developers used tables to create page layouts — sidebars, header areas, multi-column content. Some older websites and email templates still use layout tables. If a table is used purely for visual layout and does not contain data, it should have role="presentation" to tell screen readers to ignore its table structure. Otherwise, screen readers will announce rows and columns for content that has no tabular relationship.

Relying on Visual Formatting Instead of Headers

Making the first row bold or a different color does not make it a header row for assistive technology. Visual formatting and semantic meaning are separate concerns. A cell must be a <th> element to be recognized as a header — styling it to look different is not enough.

Empty Header Cells

Some tables have an empty cell in the top-left corner where the row and column headers intersect. While this looks fine visually, an empty <th> element confuses screen readers. If the top-left cell does not need a label, add a visually hidden description or use the column/row context to make the table structure clear.

Overly Wide Tables on Mobile

Tables that are too wide for mobile screens often become horizontally scrollable containers that keyboard users cannot easily navigate. Consider whether a responsive design — such as stacking rows vertically on small screens or allowing horizontal scroll with clear visual indication — would improve usability.

How to Test Your Tables

You do not need to be a developer to test table accessibility. Here are three approaches:

1. Keyboard navigation: Press Tab to reach the table, then use arrow keys to move between cells. If your browser supports table navigation, you should be able to move cell by cell. If you cannot reach or navigate the table with keyboard alone, there is an accessibility barrier.

2. Free browser tools: Install the WAVE browser extension (available for Chrome and Firefox). It will highlight tables on your page and flag missing headers, empty header cells, and layout tables. The axe DevTools extension also catches table issues and explains exactly which WCAG criterion each violation affects.

3. Screen reader testing: If you are on a Mac, turn on VoiceOver (Command + F5) and navigate to your table. Listen to how it announces each cell. Are column headers read with each data cell? Can you understand the data without looking at the screen? On Windows, the free NVDA screen reader provides similar testing capabilities.

Quick Table Accessibility Checklist

• Every data table uses actual HTML <table> markup, not divs or images
• Column headers use <th scope="col">
• Row headers (if applicable) use <th scope="row">
• The table has a caption or a descriptive heading immediately before it
• No cells are merged unless absolutely necessary
• Layout tables (if any) use role="presentation"
• The table is navigable using only a keyboard
• The table works on mobile screens (responsive or scrollable with indication)
• Empty header cells are avoided or have visually hidden descriptions

What About Your CMS?

Different website platforms handle tables differently:

• WordPress: The Gutenberg Table block supports header rows and basic styling. For more complex accessible tables, the TablePress plugin generates proper markup. Always toggle “Header section” on in Table block settings.
• Shopify: The rich text editor’s table tool generates basic tables. For product comparison tables, ensure your theme handles <th> elements correctly. Check our Shopify accessibility guide for more platform-specific tips.
• Squarespace: Native table support is limited. Use Markdown blocks or Code blocks for proper table markup. See our Squarespace accessibility guide for workarounds.

Related Reading

• Your First 5-Minute Accessibility Audit — A quick way to check your entire site for common accessibility issues, including tables
• How to Write Accessible Forms — Forms and tables often appear together; learn how to make both accessible
• WCAG Explained in Plain English — Understand the standards behind table accessibility requirements

---

We’re building a simple accessibility checker for non-developers — no DevTools, no jargon. Join our waitlist to get early access.