Mark up lists with real list elements
Anything a reader perceives as a list should be built from real list elements, because the markup is what tells software how many items there are and where in them the reader currently is. W3C lists H48 as sufficient for 1.3.1 Info and Relationships. Its full title reaches further than ul and ol, and both extra halves are worth having. A description list, dl, is the element for name and value pairs, which is what a glossary is and what a set of questions and answers is. A group of links is a list too. Marking one up lets a screen reader user jump from the first link straight to the end of the group. After a skip link, that is the cheapest way past a repeated block. W3C also draws a limit that saves you work. Not every list needs markup, and a sentence with commas in it is still a sentence.
How we find it in an audit
Visual lists built from divs and line breaks are the pattern we look for. The accessibility tree settles it in seconds, because a real list carries a count and a fake one is loose text. Scanners hint at this and rarely confirm it. Our reviewers read the other direction too, checking that a run of asterisks typed at the start of each line is not standing in for the markup. That is W3C's own example of the failure.
How affected users experience it
A real list announces itself before it starts. List, six items. That one phrase hands the listener the map before the territory. They know how much is coming, they know when it ends, and they can leave in one keystroke if it turns out not to be what they wanted. Six lines separated by line breaks arrive as six unconnected sentences with no shape and no exit.
Passes vs. fails
Passes
<ul>
<li>Free returns</li>
<li>Next-day delivery</li>
<li>Gift wrapping</li>
</ul>Fails
<div>* Free returns<br>* Next-day delivery<br>* Gift wrapping</div>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
Other ways to satisfy this rule
52 guides on this site are filed under 1.3.1 Info and Relationships. W3C lists this one as sufficient for that rule when used for making information and relationships conveyed through presentation programmatically determinable, so the condition is part of the test rather than a footnote to 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 H48: Using ol, ul and dl for lists or groups of links. 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.