Search topics
Layout tables read as data tables, or out of order
A newsletter lays its products out with tables, so a screen reader reads each product as a column header, or reads every name before any price.
<tr><td>$18</td><td>$32</td>…</tr> The problem
Screen reader users hear a newsletter's products announced as a data table, or hear every name before any price, and can't tell which price is whose.
A homeware shop sends a weekly newsletter. Under "New this week" it shows three products side by side, each a photo with its name and price under it: an enamel mug for $18, a linen tote for $32 and a speckled mug for $24. The email is laid out with tables, as emails still are, because the classic Outlook for Windows draws email with Word's engine, which ignores most CSS layout. The same HTML is the "view in your browser" page.
There are two common ways the grid goes wrong. In the first, the template comes from an email framework that writes each column as a th, as Foundation for Emails does. A screen reader user reaching the products hears a table announced, with its rows and columns, and then each product as a column header, as if they were the headings of figures to compare. In the second, the grid is built row by row: a row of three photos, a row of three names and a row of three prices, so each column lines up on screen. Read from the top, it says "Enamel mug, Linen tote, Speckled mug, $18, $32, $24", and the person has to count back to learn that the tote is $32.
Table markup tells assistive technology that the content is data, arranged in rows and columns under headers. WCAG 1.3.1 Info and Relationships asks that structure in the code matches what is shown, and a header cell in a table that only places products side by side states a structure that isn't there: failure F46 names th, caption and summary in layout tables. Browsers guess whether a table holds data: Chrome marks a plain table with no borders and no th as a layout table in its accessibility tree, and screen readers read a layout table's cells as plain content. A th ends the guessing: in Chrome's accessibility tree, the first build is a table whose column headers are named "Enamel mug $18" and "Linen tote $32".
A screen reader reads a table one row at a time, left to right, in the order of the markup. WCAG 1.3.2 Meaningful Sequence asks that when the order matters, the order in the code is the one that makes sense. In the second build, the meaning runs down each column, a photo, then its name, then its price, but the reading runs across the rows: failure F49, a layout table that doesn't make sense when read in order. Marking that table as presentation hides the table but not the order.
On a phone, a screen reader user swipes through the email one piece at a time, in the same order as the markup, so a price several swipes away from its name is as far from it as it is when listening on a computer.
2 of 10 groups affected
- No vision (affected)
- Low vision (not affected)
- Colour vision (not affected)
- No hearing (not affected)
- Hard of hearing (not affected)
- No speech (not affected)
- Motor (not affected)
- Reach, strength (not affected)
- Cognitive (affected)
- Seizures (not affected)
- Without vision Before the products, a screen reader announces a table and reads each product as a column header, so the person expects figures to compare. In the grid built row by row, they hear three names and then three prices, and have to count back to pair them.
- Limited language, cognitive and learning abilities Read-aloud tools, which some people with dyslexia use, follow the markup too, so in the grid built row by row each price is read far from its name.
axe has no rule for header cells in a layout table: in the first build, its th-has-data-cells rule only lists the header cells for review, and the second build passes it. No tool can tell from the code alone whether a table holds data, or whether its reading order makes sense. This audit reports a finding when a th holds a whole table, a sign that the table lays content out, as in the first build. For every other table that looks like layout, one that holds another table, is marked as presentation, or has a row of pictures over a row of text and no header cells, it sends a lead that quotes the cells in the order a screen reader reads them, and says when a row of pictures sits over a row of text. An email an AI code generator writes with Foundation for Emails' <columns> tags gets the same th cells when it is built, because the framework's Inky compiler writes them, not the generator.
Try it
Find the linen tote’s price from what a screen reader reads, not from the email.
Broken 1: the panel lists what a screen reader reads from the top of the products. What does it say they are?
Broken 2: the email looks the same. Read the panel: which price is the tote’s?
Apply a fix. Read the panel again: each product is read whole, before the next.
Broken Can you fix this?
New this week
|
|
|
|---|
Reading from the top, a screen reader says:
- Table, 3 columns, 1 row
- Column header, Enamel mug, $18
- Column header, Linen tote, $32
- Column header, Speckled mug, $24
- Out of table
The fix
Read each product whole, with no table around it.
Each column a header cell
<table class="row"> <tr> <th class="columns"> <table> <tr> <th> <img src="enamel-mug.jpg" alt=""> <p>Enamel mug</p> <p>$18</p> </th> </tr> </table> </th> <th class="columns"> <table> <tr> <th> <img src="linen-tote.jpg" alt=""> <p>Linen tote</p> <p>$32</p> </th> </tr> </table> </th> … </tr></table>What is wrong3 points
The order is right: each product is read whole, in one cell. The cells are where it fails.
- Each column is a
th, so the browser treats the outer table as a data table, and a screen reader announces a table with its rows and columns before the products. - Each product is read as a column header, which heads nothing.
- No table has
role="presentation"to say it only places content.
One product to a cell, in tables marked as presentation
<table class="row" role="presentation"> <tr> <td class="columns"> <table role="presentation"> <tr> <td> <img src="enamel-mug.jpg" alt=""> <p>Enamel mug</p> <p>$18</p> </td> </tr> </table> </td> <td class="columns"> <table role="presentation"> <tr> <td> <img src="linen-tote.jpg" alt=""> <p>Linen tote</p> <p>$32</p> </td> </tr> </table> </td> … </tr></table>How it is fixed3 steps
- Make every cell a
td. Nothing in the grid heads anything, so nothing is ath. - Put each product's photo, name and price in one cell, so it is read whole, and the next product starts only after it.
- Give every table
role="presentation", the nested ones too. The role reaches the table's own rows and cells but not a table inside them. A screen reader now reads the three products as plain content, with no table announced.
This fixes both Befores and passes 1.3.1 and 1.3.2, as long as every table the template writes for layout has the role, including the wrappers, spacers and buttons that emails draw with tables.
Why this fix: Write the source in the order it is read
Both pass. In an email, use the presentation tables: they are the layout that every mail client draws, including the classic Outlook for Windows. On a web page, use the list: it needs no table at all, stacks on a narrow screen without a media query, and tells a screen reader user how many products there are.
A framework that writes th. Foundation for Emails writes each column as a th in a table with no role, so every email built with its <columns> tags carries the first Before. If you can't change what it writes, role="presentation" on every table it writes still makes those th cells plain content in Chrome's accessibility tree; F46 as written still counts any th in a layout table, so replace them where the template lets you. MJML puts role="presentation" on the tables it writes.
presentation or none. ARIA defines role="none" as a synonym for role="presentation". Email frameworks such as MJML write presentation, and that is what this guide uses.
Data in an email. An order confirmation's list of items, quantities and prices is data. Keep it a data table, with header cells and a caption, as in data tables with headers that are only bold text, and never mark it as presentation.
Borders change the browser's guess. Chrome treats a table of plain cells with borders between them as data, even with no th, so a layout table drawn with lines needs role="presentation" as much as one with header cells.
The photos. Each photo here has an empty alt, because the name under it already says what it is; an alt that repeated the name would be read twice. Where a photo shows what the words don't, such as the colour of a mug, describe that; see decorative images read out as file names or repeated text.
Stacking on a phone. Emails often stack their columns on a narrow screen by setting each cell to full width. The cells stack in markup order, so the grid built row by row stacks as three photos, three names and three prices: the order problem becomes visible there too.
Verify the fix
5 checks, no mouse.
Test with: Screen reader, Styles off, Zoom
Record the OS, browser and assistive-technology versions, the build, the date, and the actual result of each step. Repeat after the template changes.
Limits
This is a starting pattern, not a guarantee for every email. Mail clients differ, and a webmail service shows the email inside its own page, so test in the clients your customers use. Whether a table without a role is announced depends on the guesses of each browser and screen reader. Reading order on a page laid out with CSS, where the order on screen is changed by the layout rather than by a table, is covered in reading order that doesn't match the layout.
This is a recreated teaching example, not a finding about a named client. The code is a starting pattern: test it in your own product. No completed assistive-technology test is claimed here.
EaseWeb service
Fixed it? Keep it from coming back.
I turn guides like this one into rules your coding agents follow and checks your CI runs. Then I retest by hand with a keyboard and screen readers, periodically.