1.3.1 Info and Relationships
- Level A
- Perceivable
- Since WCAG 2.0
Summary
When a sighted user glances at a page, its structure is obvious: big bold text is a heading, indented lines with bullets are a list, a grid of figures is a table, and a caption next to a field labels it. This criterion requires that the same structure exists in the code, not just in the pixels. Headings must be marked up as headings, lists as lists, table headers as table headers, and labels must be programmatically tied to the controls they describe.
Screen reader users depend on this constantly: navigating by headings is the single most common way they skim a page, and a braille display can only present the relationships the software exposes. The criterion has been at Level A since WCAG 2.0, and it is routinely among the most cited in audits because the failure mode is so easy to introduce: styling something to look structural without telling assistive technology what it is.
Official wording
Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text.
EN 301 549 mapping
- Web pages
- Clause 9.1.3.1
- Software and native apps
- Clause 11.1.3.1
- Closed functionality (kiosks, terminals)
On systems closed to screen readers, the standard recommends (does not require) auditory information that lets users correlate what they hear with what is shown on screen.
Clause 9.1.3.1 applies this criterion to web pages unchanged. Clause 11.1.3.1 applies it to software that supports assistive technologies. On closed systems the standard only recommends auditory information correlating with the screen, so a missing structure on a kiosk is not a failure of a mandatory requirement.
Clause references are to EN 301 549 V3.2.1 (2021-03), the harmonised European standard. Descriptions are our own summary, not the text of the standard.
In practice
Web
Start with headings. Text that looks like a heading (larger, bolder, set apart) must be an h1 to h6 element or carry role="heading" with an aria-level. A div styled with bold 24 pixel text conveys structure visually and nothing programmatically, which is the textbook failure. The reverse also fails: heading elements used purely to get big text, applied to content that is not a heading, misrepresent the structure.
Lists need ul, ol, or dl markup; a run of paragraphs starting with hyphens or bullet characters announces as flat prose. Data tables need real header cells: th elements with scope (or headers/id for complex tables) so each data cell can be related to its row and column headers. A genuine layout table, if you still meet one, should convey no structure at all, which role="presentation" achieves. Form fields need programmatic labels via label for, aria-label, or aria-labelledby, and related groups of controls (radio sets, address blocks) usually need fieldset and legend or an equivalent group role so the shared context is announced.
To test, read the browser's accessibility tree in developer tools rather than the DOM, then confirm with a screen reader: pull up the heading list or rotor and check that every visual heading appears at a sensible level, tab through forms listening for label announcements, and arrow through tables checking that headers are read with the data.
iOS
The classic mobile failure is the bold section title that is not a header. VoiceOver users navigate screens with the rotor's Headings option; that only works if section titles carry the header trait (accessibilityTraits = .header in UIKit, .accessibilityHeading(.h1) or accessibilityAddTraits(.isHeader) in SwiftUI). A settings screen with six visually distinct sections and zero programmatic headers forces a VoiceOver user to swipe through every row.
Grouping matters as much as headings. A card whose icon, title, and subtitle read as three separate stops fragments a single visual unit; shouldGroupAccessibilityChildren, a curated accessibilityElements array, or SwiftUI's .accessibilityElement(children: .combine) restores the relationship. The opposite failure also occurs: merging so aggressively that distinct items lose their identity.
Native data tables are rare on iOS, but collection semantics still apply: lists built with table and collection views generally announce position in list for free, whereas fully custom scroll layouts may need container semantics added. Labels follow the same rule as the web: a text view sitting beside a switch is only a label if the control's accessibility label actually contains it. Test with VoiceOver running: rotor to Headings and confirm every visual section title is reachable, then swipe through each screen checking that grouped content stays grouped.
Android
TalkBack offers heading navigation just as VoiceOver does, and it is just as commonly broken. Mark section titles with ViewCompat.setAccessibilityHeading(view, true) (or android:accessibilityHeading from API 28) in the view system, and Modifier.semantics { heading() } in Compose. Without it, a visually obvious section title is just another text node.
List semantics come largely for free: RecyclerView and Compose's LazyColumn expose collection info, so TalkBack announces item position without extra work. Custom containers built from plain layouts do not, and may need collection semantics added by hand. For grouping, prefer making the container focusable with a sensible description, or Modifier.semantics(mergeDescendants = true) in Compose, so an icon, title, and value read as one element; avoid stuffing a long contentDescription onto a container while its children remain separately focusable, which duplicates content. Label relationships use android:labelFor in the view system so the field announces its visible label; in Compose, text fields should carry the label within the component's own semantics.
Test with TalkBack: switch reading controls to Headings and jump through the screen, then linear-swipe checking that lists announce positions and that labels arrive with their fields rather than as orphaned text.
Pass and fail examples
Passes:
- A blog article whose visual section titles are
h2andh3elements matching the visual hierarchy. - A pricing comparison rendered as a data table with
th scope="col"andth scope="row"headers on every axis. - A native app settings screen where each section title carries the header trait, so VoiceOver and TalkBack users can jump section to section.
- A radio group wrapped in
fieldsetwith alegendof "Delivery method", so each option is announced with its shared context.
Fails:
- A
divstyled bold and large acting as a page section title with no heading markup: the structure exists only visually. - A table of opening hours built from
divgrids with the day names styled bold: no programmatic row or column relationships. - A form where the only "label" is placeholder text inside the field. Placeholder alone usually fails this criterion because no programmatic label relationship exists; note that once a placeholder is exposed as the accessible name the failure may shift to a naming-quality issue instead, so check what the accessibility tree actually reports before writing it up.
- A mobile card whose title, status badge, and timestamp are three unrelated focus stops with nothing tying them together.
Not a fail under this criterion:
- A decorative horizontal divider between sections: it conveys no information or relationship, so it needs no structural markup (hiding it from assistive technology is good practice, not a requirement here).
- A heading whose wording is vague or unhelpful: if the markup is correct, wording quality belongs to 2.4.6.
- Bold or italic used purely for visual emphasis with no structural meaning, such as a brand name set in bold mid-sentence.
Commonly confused with
- Headings and Labels, SC 2.4.6. 1.3.1 asks whether the heading exists programmatically; 2.4.6 asks whether its wording is descriptive. A correctly marked up
h2that says "Section" passes here and fails there. - Name, Role, Value, SC 4.1.2. Custom interactive components (toggles, tabs, accordions) missing a role or state are 4.1.2 findings. 1.3.1 covers structural relationships in content: headings, lists, tables, groupings. A fake button is 4.1.2; a fake heading is 1.3.1.
- Meaningful Sequence, SC 1.3.2. 1.3.1 is about what things are and how they relate; 1.3.2 is about the order in which they are read. A visually two-column layout that reads in a nonsensical order is a sequence finding, not a relationships finding.
- Non-text Content, SC 1.1.1. An informative image missing a text alternative is 1.1.1. If an image of a table or chart is the only way structured data is conveyed, both criteria may be in play, but grade the missing alternative under 1.1.1 first.
How AUDITSU tests this
AUDITSU's audit walkthrough puts structure questions on every screen you review, with the screen reader running. For each screen the walkthrough asks you to navigate by headings and confirm every visual section title is reachable, check that lists, tables, and grouped content announce their relationships, and verify each form field is announced with its label. Each question records a pass, fail, or not applicable result with evidence attached, so findings land in your report tied to the exact screen and element.
The criterion maps directly to mandatory requirements in the European standard for both web content and native software, so failures count against EN 301 549 conformance in both contexts. One nuance for hardware audits: on closed systems such as kiosks and self-service terminals, the European standard only recommends that auditory output correlate with the visual structure, so a structure finding on closed hardware should be reported as an advisory rather than a failure of a mandatory requirement.
For the full guided workflow, see the audit platform.