Skip to main content
Accessibility Field Guide

Tables and Data Displays

Use tables when relationships matter, keep headers and labels clear, and avoid turning data into a puzzle.

A hand holds a pen over a printed spreadsheet with charts and survey data.
Photo: Close-up Photo of Survey Spreadsheet via Pexels — https://www.pexels.com/photo/close-up-photo-of-survey-spreadsheet-590022/
View full screen Download image

Tables are helpful when they let people compare related information. They become a problem when they are used as a layout shortcut, when headers do not explain the relationships, or when the data only makes sense visually.

A table should answer a practical question: what belongs together, what can be compared, and what does someone need to act on?

If the table makes those relationships clear only through position, color, spacing, or a screenshot-like layout, some users will have to reconstruct the meaning instead of using the information.

The common project moment

A team adds a table, comparison grid, search-results list, report, or dashboard because the information needs to be scanned quickly.

At first, the layout looks clear. The columns line up. The colors make the status easy to spot. The actions sit neatly at the end of each row.

Then the table starts carrying more work:

  • users need to compare values across rows
  • status changes after filtering or sorting
  • row actions repeat the same labels
  • the layout collapses into cards on mobile
  • icons or colors carry important meaning
  • screen reader and keyboard users need the same relationships that sighted users get from the layout

That is where table accessibility usually breaks down.

The issue is not only whether the page uses a <table> element. The issue is whether the relationships, labels, status, and actions still make sense when someone is not relying on the visual layout alone.

Use this when

Use this page when a screen includes:

  • a comparison table
  • a pricing or plan grid
  • a status/history table
  • a data report or dashboard table
  • a search-results table
  • a schedule, roster, or list of records
  • a table-like display that changes across desktop and mobile layouts

This is not only a developer concern. Product, design, content, QA, and business teams all shape whether a data display is understandable.

What the table needs to do

Before reviewing markup, ask what job the table is doing.

  • Is the user comparing values across rows or columns?
  • Are the column and row labels enough to understand each cell?
  • Does the table support scanning without hiding the meaning from screen reader users?
  • Can someone understand status, priority, change, or error states without relying only on color?
  • Does the mobile version preserve the same relationships as the desktop version?

If the answer is unclear, the accessibility issue may start with the content model, not the code.

Start with the structure

A real data table needs clear headers.

Column headers should describe the kind of information in each column. Row labels should make it clear what record, item, person, task, plan, or event the row is about.

Avoid vague headers like:

  • Info
  • Details
  • Status
  • Action
  • Other

Those labels may look fine visually, but they are weak when someone is moving cell by cell or when the table is reflowed into a smaller layout.

Better labels tell the reader what the data means in context:

  • Submission status
  • Renewal deadline
  • Required action
  • Last updated
  • Assigned reviewer

Do not use tables only for layout

Tables should be used for relationships in data, not for placing unrelated content into columns.

If the content would still make sense as headings, paragraphs, cards, or a normal list, a table may add unnecessary complexity.

A layout table can create confusing reading order, repeated empty cells, and extra navigation work for assistive technology users.

Use native page structure first. Use a table when the relationship between row headers, column headers, and cells matters.

Make visual meaning available in text

Many data displays use visual cues to carry meaning:

  • green, yellow, and red status colors
  • icons without text labels
  • bold or highlighted rows
  • badges such as New, Late, or Required
  • arrows showing increase or decrease
  • blank cells that mean not available, none, or not started

Those cues need text equivalents.

A user should not have to perceive a color, icon shape, or visual position to know what the data means.

For example, if a cell shows a red dot for an overdue item, the accessible meaning should include Overdue, not only a red icon.

Keep actions clear

Tables often include actions inside rows: view, edit, delete, download, renew, assign, approve, or remove.

The action label needs enough context.

A table full of Edit links can be hard to understand out of context. The visible text may be short, but the accessible name should make the target clear, such as Edit permit application for Oak Street project.

This connects directly to accessible names and link text. The row gives visual context, but the control still needs to make sense when someone lands on it directly.

Watch responsive tables

Responsive behavior often breaks table meaning.

A desktop table might become:

  • horizontally scrollable
  • stacked cards
  • expandable rows
  • a shortened mobile summary
  • a downloadable file instead of on-page data

Each pattern has tradeoffs.

If a table becomes cards, each card still needs clear labels for the values. If a table scrolls horizontally, keyboard users need to reach and use the scroll area. If columns disappear on mobile, the missing information still needs a path.

Do not assume the desktop table and mobile table are the same accessibility experience.

Questions by role

Product or business owner

  • What question is this table supposed to help someone answer?
  • Which columns are required for the task, and which are optional?
  • What decisions or actions depend on this data?
  • What happens when the table is empty, loading, filtered, or too large?

Designer

  • Are headers and labels visible enough to explain the data?
  • Does the responsive layout preserve the relationship between labels and values?
  • Are color, icons, badges, and emphasis supported by text?
  • Can row actions be understood without relying only on visual grouping?

Developer

  • Is this a real data table or a layout pattern?
  • Are table headers marked up correctly with native table elements where appropriate?
  • Do complex headers, grouped columns, sortable columns, or row actions expose the right names and states?
  • Does keyboard access still work when the table scrolls, expands, filters, or updates?

QA or reviewer

  • Can you understand the table by reading headers, row labels, and cell values together?
  • Can you tab through interactive elements in a logical order?
  • Do row actions have unique and understandable names?
  • Does the mobile version preserve labels, status, and available actions?

Common trail hazards

The table is really a page layout

If the table is being used to place unrelated content into columns, use page structure instead.

The headers are too generic

A header like Status may need more context if the page has multiple kinds of status. Use labels that match the user's task.

Row actions repeat the same visible text

Repeated View, Edit, or Delete links may need more specific accessible names.

Color carries the status

If green means complete and red means overdue, include the status in text too.

Mobile cards lose the headers

When a table becomes cards, every value still needs a label. A stack of unlabeled numbers is not a usable replacement.

Sorting and filtering are unclear

If users can sort, filter, expand, or update the table, the controls need clear names and the changed state needs to be understandable.

Small habit to build

Read one row out loud without pointing at the screen.

If the row does not make sense without visual position, color, or memory of the column layout, the table probably needs clearer headers, labels, text equivalents, or responsive structure.

WCAG trail markers

What to do next