Tag PDF lists so they read as lists
A list in a PDF is built from four tags, and each one has a job. L is the list itself and holds the items. LI is one item. Lbl holds the bullet or the number. LBody holds the item's text. W3C publishes PDF21 as a sufficient technique, and the payoff is navigation, because a tagged list lets a reader move list to list and item to item instead of reading through. Separating items with line breaks produces no structure at all, which is W3C's named anti-pattern here. One rule catches people out. A list nested inside another list goes inside its parent item's LBody, not beside it.
How we find it in an audit
We move through each list with a screen reader and check it is announced as a list with an item count, and that list navigation works. In the tag tree we look for L and LI structure rather than a run of plain paragraphs starting with hyphens, and we open up any nested list to see whether it sits inside the parent item's LBody or has been left as a sibling.
How affected users experience it
An untagged list reads as an undifferentiated run of paragraphs. No count, no sense of where the conditions start and end. In a contract, a line reading "the following events constitute default" followed by untagged lines means the reader cannot tell whether the last line is part of the list or the start of the next clause.
Passes vs. fails
Passes
The nine events are tagged L and LI, with Lbl carrying each number and LBody carrying each event. A screen reader announces a list of nine items, reads each one, and says when the list has ended.
Fails
A loan agreement lists nine events of default as hyphen-prefixed paragraphs. Nothing announces where the list begins, how many events there are, or where it ends.
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 PDF21: Using List tags for lists in PDF documents. 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.