Do not put role="presentation" on meaningful content
The attribute role="presentation" tells assistive technology to throw an element's meaning away, and somebody has put it on a data table. F92 is the failure technique for that, so a match is a defect rather than a shortcut. Its synonym role="none" behaves the same way and fails the same way. The role has a real job, which is exactly what makes this easy to get wrong. A table used only for layout is supposed to carry it, so the tool is right and the target is not. Reach is what makes it expensive on genuine content. Applied to a table or a list, the role strips the children too, so the rows and the items lose their meaning along with the container.
How we find it in an audit
We list every use of role presentation and role none across the audited pages automatically, which is the easy half, and a reviewer then judges each one. Layout scaffolding keeps it. A price table, a list of steps and a heading all lose it. The accessibility tree shows exactly what got flattened, so the finding can quote what a screen reader now hears rather than what the markup says. Component libraries get a second look, because a wrapper carrying the role by default takes every table you put inside it down as well.
How affected users experience it
A screen-reader user meets a data table that announces as loose text. No row navigation, no column navigation, no headers, just values running past in a stream. A list of five steps that would have arrived as list, five items turns into an undifferentiated paragraph, so there is no way to know how many steps there are or which one is being read now. The structure was there. Someone switched it off, and the user has no way to switch it back on.
Passes vs. fails
Passes
<table>
<caption>Plans and pricing</caption>
<tr><th scope="col">Plan</th><th scope="col">Price</th></tr>
...
</table>Fails
<table role="presentation">
<tr><th>Plan</th><th>Price</th></tr>
...
</table>How this gets tested
The W3C publishes test rules that define what a checker looks for here.
- ARIA attribute is defined in WAI-ARIAA tool can check this
- ARIA state or property has valid valueA tool can check this
- Element with role attribute has required states and propertiesA tool can check this
- Form field has non-empty accessible nameA tool can check this
- Headers attribute specified on a cell refers to cells in the same table elementA tool can check this
- Role attribute has valid valueA tool can check this
- ARIA global properties not used where prohibitedA tool can check this
- ARIA required context roleA tool can check this
- ARIA required owned elementsA tool can check this
- ARIA state or property is permittedA tool can check this
- Table header cell has assigned cellsA tool can check this
The other techniques filed under this rule
52 guides on this site are filed under 1.3.1 Info and Relationships. W3C documents this one as a failure of that rule, so it describes a way the rule gets broken rather than a way to pass it.
- ARIA11sufficientAdd landmarks so users can skip around
- ARIA12sufficientUse role=heading when h1-h6 is impossible
- ARIA13sufficientName repeated landmarks so they are distinguishable
- ARIA16sufficientName controls from visible text with aria-labelledby
- ARIA17sufficientGroup related form fields with ARIA roles
- ARIA20sufficientMark leftover page areas with role=region
This guide is our interpretation of W3C technique F92: Failure of Success Criterion 1.3.1 due to the use of role presentation on content which conveys semantic information. W3C publishes its techniques as guidance rather than as the standard, and says so on every one of them. The success criterion is what conformance is measured against, and a technique is one documented way to meet it.