ACCESSIBILITY ≠ OVERLAY · 36
Accessible tables: when data needs context, not an overlay
📅 9 November 2026 · ⏱ 7 min read
A table can look tidy while remaining confusing to someone listening to it or using magnification. Accessibility means preserving the relationship between every value, its row and its column.
01. An isolated number tells you very little
Imagine checking opening hours and hearing only “09:00, 10:00, 11:00, 12:00”. Without knowing the service and day associated with each time, you cannot make a useful decision. The barrier arises when context depends entirely on looking upwards or to the left. The information is visible, but the relationships are unavailable to software.
The same happens in a pricing table. A figure might represent a monthly subscription, an annual price or an additional charge. If visitors must remember every column position, finding information becomes a reconstruction exercise. The practical goal is that someone can answer a specific question independently, without guessing what a number means.
02. Decide whether the information needs a table
Tables are useful when comparison across rows and columns conveys meaning: timetables, prices, features or results. A sequence of instructions or a short description may work better as a list or ordinary paragraphs. Choose the structure because of the information, rather than because the editor offers an attractive grid.
Avoid using tables to position two unrelated content blocks side by side. CSS and layout components should handle presentation. Mixing layout with data creates a structure that assistive technology may announce without helping the reader. Before building anything, write down the comparison visitors need to make and remove columns that contribute nothing to that task.
03. Headers must exist in the markup too
Making the first row bold or blue does not turn its cells into headers. Cells identifying rows or columns should use th; ordinary data cells use td. In straightforward tables, scope="col" and scope="row" can make the direction of the relevant associations explicit.
For example, “Service”, “Monday” and “Tuesday” identify columns. “Appointments” and “Support” can identify rows. When checking an opening time, both the service and the day matter. Do not add ARIA routinely to repeat native semantics. Inspect the HTML generated by the component first, then check how the browser and screen reader combination actually presents those relationships while navigating between cells.
| Service | Monday | Tuesday |
|---|---|---|
| Appointments | 09:00 | 10:00 |
| Support | 11:00 | 12:00 |
04. Provide a useful title and brief orientation
A caption helps identify a table: “Service opening hours” communicates more than “Table 1”. Readers should be able to distinguish it from other tables without reading every preceding paragraph. Where a period, currency or unit is essential, make it clear within the table or an associated explanation.
More complicated tables may also need a short description of their organisation. Explain, for instance, that each column group represents a quarter. This orientation does not replace individual cell headers. Avoid lengthy descriptions repeating every value: the purpose is to support exploration, rather than requiring someone to listen to the same information twice before reaching the relevant cell.
05. Simplify before merging cells
Merged cells and multiple header levels make interpretation and maintenance harder. Before introducing them, consider dividing the information into smaller tables with precise titles. Separating two reporting periods can improve understanding more effectively than adding attributes to an enormous grid.
Where complexity is necessary, model groups and associations deliberately. Depending on the structure, scope="colgroup", scope="rowgroup", or relationships using id and headers may be appropriate. These are not interchangeable recipes for every table. Check the actual relationships and test cells in the middle, at boundaries and within different groups. Correctly reading the first row alone does not demonstrate that the entire table remains understandable.
06. Mobile layouts must preserve relationships
Shrinking text until an entire table fits on a phone makes the information difficult to read. Hiding columns without another way to access their data does not solve the problem either. Responsive design must retain the information needed for comparison and decisions, including when visitors use magnification.
A horizontally scrollable region can be reasonable for data requiring two dimensions. Where necessary, it must be operable with a keyboard and provide a clear indication that additional content exists. If rows become cards, preserve meaningful labels and relationships in the DOM. Verify that the visual transformation neither removes semantics nor forces visitors to infer which label belongs to each value.
07. Colour, abbreviations and empty cells
A green cell does not explain “available” on its own, just as red does not necessarily mean “fully booked”. Provide text or another understandable equivalent and check contrast for text, controls and relevant indicators. Alternating row colours can help people follow a row, but should not be the sole means of understanding relationships.
Explain unfamiliar abbreviations and use consistent units. Distinguish zero, unknown information and an unavailable service: they are different states. Empty cells can be ambiguous both visually and when read aloud. An editorial choice such as writing “No data” prevents silence from being mistaken for a numerical value or a screen reader failure.
08. Make sorting and filters usable
If a header allows sorting, provide the action through a clearly named control that works with a keyboard. Communicate the sorting state programmatically where appropriate; aria-sort can describe that state on the relevant header. A tiny triangle alone does not explain which column currently determines the order.
After filtering, maintain predictable focus and communicate relevant results without excessive announcements. Test the empty-results state and the action for clearing a filter. Do not transform an informational table into an interactive grid with special keyboard navigation unless that behaviour is genuinely required, deliberately designed and tested. Additional interaction patterns create obligations rather than automatically improving accessibility.
09. Test questions, not just tags
Choose a verifiable question: “When is support available on Tuesday?” Answer it visually, then use a screen reader and its table navigation commands. Hearing that a table exists is not the useful test. The person needs to identify the correct value and its headers without losing context.
Repeat the task with magnification and a narrow window. Use the keyboard for buttons, filters and scrollable regions where needed. Cells in a static table do not all need to become Tab stops. Record the browser and assistive technology tested, what happened and the correct answer that a visitor should be able to obtain independently.
10. What automated tools and WCAG contribute
Automated tools can flag some structural problems, but cannot decide whether a header meaningfully describes its data or whether splitting a table would make comparison easier. They do not independently validate every filter state. Combine findings with code inspection, editorial review and manual tasks.
Within WCAG 2.2, criterion 1.3.1, Info and Relationships, is particularly relevant to tabular structure. Depending on the component, keyboard access, contrast, reflow and status messages may also matter. The reflow exception for content requiring a two-dimensional layout does not exempt an entire page. Assess applicable requirements individually and avoid presenting a particular markup recipe as a guarantee of overall conformance.
11. Fix WordPress and Divi output at its source
Inspect the HTML generated by the table module or plugin after saving. An editor might display a highlighted first row while publishing only td cells. Pasting from a spreadsheet can also introduce unnecessary styles and merged cells. Review the real output rather than relying entirely on the builder interface.
If many posts share the same problem, correct the common component or template and document an editorial rule. An overlay cannot reliably infer whether a value is a price, deadline or percentage, or decide which comparison visitors need. Presentation adjustments may complement other work, but the relationships between headers and data belong in the original content.
12. Keep tomorrow’s information understandable
Before publishing, check the title, units, headers, associations and narrow-screen behaviour. Include one concrete task in editorial review and repeat it when the data or plugin changes. A correct table can deteriorate when someone adds a column, merges cells or replaces descriptive labels with icons.
Involve people using assistive technology where possible and respond to their actual difficulties. The best table is not the one with the most attributes. It lets people consult and compare information without mentally rebuilding its structure. Accessibility is demonstrated when someone finds the right value, understands its meaning and can use that knowledge to make their own decision.