The data table looks neat visually, but the screen reader can't understand it? A truly accessible Table needs to establish a relationship between the table header and the data

Visual users can tell at a glance that "the second column is the amount and the third row is Beijing". If screen readers do not have the correct header semantics, they will only read a string of numbers continuously. The core of an accessible table is not to add more ARIA, but to express the row and column relationships between data with the correct structure.

01 Only data with genuine two-dimensional relationships should use the Table

The W3C Tables Tutorial clearly distinguishes between data tables and layout tables. Tables are used to convey information through the row and column relationships themselves and should not be used to arrange cards or page layouts.

Incorrect use of tables can cause assistive technologies to misread pure visual layouts as data relationships.

02 Visual bold is not the header, HTML th establishes semantics

The first line of the design draft with a gray background and bold only tells the visual user, "This is the Header." Development requires the use of th and setting scope="col" or scope="row" based on simple table relationships.

In this way, when the screen reader reads the value, it can simultaneously associate the corresponding table header.

03 Complex multi-level headers require pre-designed relationships

For instance, if the three-layer header "2025 / Q1 / revenue" is merely visually merged into cells, it is very easy to lose the machine-understandable relationship.

Complex tables may require methods such as id/headers to establish associations. Meaningless cross-column and excessive nesting should be avoided during the design stage. If necessary, the table should be split.

04 A Caption or a clear title can explain what this table "is about".

When there are multiple tables on a page at the same time, "Data Table 1" alone is not enough. The title should describe the object and the time, for example, "Sales by Region in the Second quarter of 2026".

Carbon currently also suggests that Data tables have clear titles and descriptions, indicating the commonalities and uses of the data.

05 Sorting must have both visual and program states

A perishable sequence cannot only show a small arrow when the mouse hovers over it. Keyboard users need to be able to focus and operate through Enter/Space.

The Carbon accessibility Guide uses aria-sort to express the current sorting status, and the design should also provide continuously visible sorted indications.

06 Inline controls need to enter the normal Tab order

The links, checkboxes, menus, and expand buttons in the table are all normal interactions and should support a keyboard.

If there are ten focused controls per line, the keyboard cost will be very high. This is also an important reason to reduce in-line operations and use batch operations.

07 Reactive transformation should also retain data semantics

After changing the Table to a card on the mobile, fields cannot be expressed merely by visual position. Each value still needs a clear label.

If you scroll horizontally to retain the table, make sure that the table header, focus, and scroll container are all operable.

08 Automatic accessibility testing cannot replace real table reading tasks

Tools can detect issues such as the absence of th, but it is difficult to determine whether a 30-column table is actually understandable.

Ultimately, keyboard and screen readers are still needed to test typical tasks: finding a row, comparing two columns, sorting, selecting and performing the operation.

09 Complex table headers prioritize simplifying the information structure rather than continuing to stack ARIA

Although multi-level merged cells and bidirectional grouping in both horizontal and vertical directions can be expressed through more complex association methods, the cost of understanding will increase simultaneously. As long as the business permits, splitting a super table into several subject tables is often more user-friendly for all users.

Accessibility is not an attribute added after a complex design is completed; it can also prompt the team to re-examine whether the information was inherently overly complex.

10 Data semantics should also be retained when switching between export and visualization

High-frequency enterprise users may switch between tables, charts and CSV. If the colors, ICONS and abbreviations on the page lose their meanings after being exported, it will affect collaboration.

Therefore, the names, units and statuses of key fields should be clearly expressed in text, and visual reinforcement is only supplementary.

Frequently Asked Questions

Is it considered barrier-free if the header is in bold?

Not counted. The row-column association needs to be established using the correct HTML header semantics.

Does a simple table require ARIA?

Usually, native table/th/scope can provide good semantics, so there is no need to add complex ARIA unnecessarily.

Does a table necessarily need a Caption?

It may not be so when the context is already very clear, but multiple tables or independent tables with clear titles are easier to understand.

Does the sorting icon need to be displayed all the time?

At least the current sorted state should remain visible and there should be a procedural aria-sort.

Will card-based mobile devices disrupt the accessibility of tables?

It will not necessarily be damaged, but clear labels and reading sequences need to be re-provided for each value.