Monitoring Table Headers on Order History and Account Pages

Data tables in account areas lose their header markup when templates are restyled. How screen readers use th and scope, and what to monitor so order tables stay readable.

An order history table looks identical whether its header cells are marked up as headers or as bold paragraphs in divs. Sighted QA signs it off. A screen reader user hears a stream of dates, totals, and statuses with no way to ask which column a value belongs to, because the association between header and cell exists only in the visual layout.

Account pages get restyled more often than checkout and audited less, which makes them prime territory for this regression. This post covers how header association works, the two markup patterns that survive restyling, and a monitoring check that reads the table the way assistive technology does.

How the association is supposed to work

In a real data table, header cells are th elements and data cells are td. Screen readers announce the header when a user navigates into a cell, so 'Total, $84.00' arrives as one unit of meaning. For simple tables, scope='col' and scope='row' make the relationship explicit. Complex tables with headers on two axes sometimes need headers and id attributes, but an order history table is never that table.

WCAG 1.3.1, Info and Relationships, is the criterion in play: information conveyed visually, here by position under a bold heading, must be available programmatically. A table rebuilt from divs for styling convenience breaks 1.3.1 while looking perfect.

The restyle failure pattern

It usually starts with a CSS grid redesign. The table element is replaced by divs because grid feels easier to control on mobile, the bold first row is recreated with a font weight, and the ticket closes with screenshots attached. Nobody involved made an accessibility decision; they made a layout decision that quietly deleted semantics.

Responsive tables have a second failure: hiding the header row on narrow screens with display:none. The visual fix is common, the accessible fix is to keep headers available to assistive technology or restructure the data as a list where each value carries its label in text.

Sorting controls deserve a mention in the same ticket. When a column header doubles as a sort button, the button needs an accessible name that includes the column and an indication of the current sort direction, usually through aria-sort on the header cell. A restyle that converts the header row to plain text usually deletes the sort semantics in the same commit, so the account page loses two functions while only one shows up in the screenshots.

A monitoring check that reads like a screen reader

Script the check against the accessibility tree, not the screenshot: fetch the account page, query the table, and assert that header cells are th elements with scope, or that each cell resolves an associated header. Run it after any account-area release. Pair the automated pass with a two minute NVDA or VoiceOver table navigation once a quarter, because header association is exactly the kind of thing that passes in markup and fails in one browser pairing.

Related reading: Monitoring Heading Levels After a Section Redesign, Monitoring Error Identification in Checkout and Account Forms, Monitoring Focus Order in Sticky Add to Cart Bars.

Frequently asked questions

Does a bold first row count as a table header?

No. Bold text conveys 'header' visually only. Screen readers need th elements, with scope for clarity, so the relationship exists in the accessibility tree. A styled div row fails WCAG 1.3.1 even though sighted users cannot tell the difference.

What about tables that turn into cards on mobile?

That pattern can work well if each card repeats its labels in real text, such as 'Total: $84.00' as a visible or programmatic label and value pair. What fails is hiding the only copy of the labels and leaving values to float without context.

Which screen reader should we test tables with?

WebAIM's 2026 survey found JAWS the most common primary desktop reader, with NVDA second, and most respondents use more than one. Testing with NVDA on Windows and VoiceOver on macOS covers the two dominant behaviours for table navigation.

Is an order history table a data table or a layout table?

It is a data table. Rows and columns carry meaning, order against date against total, so it needs real table markup. Layout tables are a legacy technique and have no place in a modern account template.