2.4.6 Headings and Labels
- Level AA
- Operable
- Since WCAG 2.0
Summary
Descriptive headings and labels are how people find their way through a page without reading all of it. Screen reader users pull up a list of headings and jump straight to the section they need; people with cognitive or memory limitations rely on clear section names and field labels to keep their place; screen magnifier users see only a fragment of the page at a time and depend on the nearest heading or label to tell them where they are. When a heading says "Section 1" or a field is labelled "Details", every one of those users has to read the surrounding content to work out what it is for, which is precisely the cost this criterion removes.
The auditor's mental model: this is a quality criterion, not an existence criterion. It grades the headings and labels that are present, asking only whether each one describes the topic or purpose of what it heads or labels. It does not require a page to have headings at all, and it does not require form fields to have labels; those absences are graded elsewhere (see the confusions section below). So the test is always the same two steps: find the headings and labels that exist, then judge each in isolation: would a user reading only this text know what the section or field is about? Under the European standard the requirement applies unchanged to web content and to software, so the same descriptiveness bar governs apps.
Official wording
Headings and labels describe topic or purpose.
EN 301 549 mapping
- Web pages
- Clause 9.2.4.6
- Software and native apps
- Clause 11.2.4.6
Clauses 9.2.4.6 (web) and 11.2.4.6 (software) apply this criterion unchanged, so the same requirement binds web pages and native app user interfaces.
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 the headings out of context, because that is how screen reader users consume them. With VoiceOver, open the rotor's Headings list; with a Windows screen reader, use the equivalent elements list; or read the document outline in the browser's accessibility devtools panel. Read the list without looking at the page. Every entry should tell you what its section contains: "Delivery options" works, "Section 3", "More", or three identical "Overview" headings on one page do not. Generic headings that only make sense next to their content are the core failure.
Then scan the form labels for distinguishability. Read each visible label and ask whether it identifies the field's purpose on its own. Watch especially for repeated or ambiguous labels: two fields both labelled "Name" (one for the cardholder, one for the account holder) are individually plausible and jointly useless; the label must carry the distinction ("Cardholder name", "Account holder name"). Check groups too: a set of radio buttons labelled "Yes" and "No" needs a group label that says what the question is.
Two style points worth grading as advisories rather than failures: front-loading (putting the distinctive word first, "Pricing: annual plans" rather than "Everything you need to know about pricing on annual plans") helps scanning but is best practice, not a requirement; and headings need not be unique unless sameness makes them ambiguous in context.
iOS
The criterion applies unchanged to native apps under the European standard, so grade app headings and labels to the same bar. In iOS apps, "headings" are the elements exposed with the header trait: screen section headers, table and collection section headers, and settings-style group titles. Run VoiceOver and use the rotor's Headings option to jump between them; Accessibility Inspector in Xcode shows which elements carry the trait and what text they expose. Judge each header text out of context, exactly as on the web: "Account" and "Notifications" as settings group titles pass; "Group 1" or an unlabelled divider posing as a section break do not.
For labels, walk each form or input screen and read the visible field labels: text field titles, toggle row text, picker prompts. The common iOS failure spots are settings screens where a toggle's row text describes the mechanism rather than the purpose ("Enable feature" tells the user nothing), reused generic titles across sections ("Options" three times in one screen), and multi-field forms where two amount or name fields carry identical labels. Remember the scope: a field with no visible label at all is not graded here, and a header that visually looks like one but lacks the header trait is a structure finding, not a descriptiveness finding.
Android
The same bar applies to Android apps under the European standard. Headings here are the views marked as accessibility headings (the accessibilityHeading property in views, or heading semantics in Compose). Run TalkBack, set reading controls to Headings, and swipe through the screen heading by heading: the sequence you hear should read as a usable table of contents for the screen. Layout Inspector in Android Studio shows which views carry heading semantics and what text they expose, which helps separate "the heading text is vague" (this criterion) from "the heading is not marked up" (a structure finding).
For labels, review each form screen's visible field labels, preference category titles, and preference item titles. Typical Android failure spots: preference screens with catch-all categories ("General", "Other", "More settings") stacked so that related items land in arbitrary buckets, dialogs titled "Confirm" with no indication of what is being confirmed, and forms where hint text stands in for a label and says only "Enter value". As on iOS, grade the text that exists: missing labels and unmarked headings are filed under other criteria.
Pass and fail examples
Passes:
- A support article with the headings "Symptoms", "Cause", and "How to fix it": each one read alone in a headings list tells the user what the section covers.
- A checkout form with fields labelled "Cardholder name" and "Billing address", distinguishable at a glance even though the page also collects a delivery contact.
- A settings screen with group headers "Notifications", "Privacy", and "Data usage": short, but each describes its group's topic.
- Two blog posts on an index page each headed by their article title: headings are not required to be unique, and here each title describes its own article.
Fails:
- Page sections headed "Section 1", "Section 2", "Section 3": the headings exist but describe nothing.
- A payment form with two fields both labelled "Name", one for the cardholder and one for the account holder: neither label describes which name is wanted.
- A settings row labelled "Enable" next to a toggle, with the actual purpose explained only in smaller helper text below: the label itself does not describe the purpose.
- An FAQ page where every question is headed "Question" and every answer "Answer": the heading text is generic where the question text itself should have been the heading.
Not a fail under this criterion:
- A long page with no headings at all: this criterion does not require headings to exist. If the visual design conveys sections that are not programmatically marked up, grade that under 1.3.1 Info and Relationships.
- A form field with no label of any kind: label existence is SC 3.3.2 Labels or Instructions, not here.
- A heading styled with bold text instead of heading markup: a markup finding under 1.3.1, provided the visible text itself is descriptive.
- "Click here" and "Read more" links: vague link text is graded under SC 2.4.4 Link Purpose (In Context). This criterion covers headings and labels, not links.
- A button whose visible label is descriptive but whose accessible name does not contain it: that mismatch is SC 2.5.3 Label in Name.
Commonly confused with
- Info and Relationships, SC 1.3.1. 1.3.1 asks whether structure that is conveyed visually is exposed programmatically (is this heading real heading markup?). 2.4.6 asks whether the heading's text is any good. A bolded pseudo-heading with clear text fails 1.3.1 only; real heading markup reading "Section 2" fails 2.4.6 only.
- Labels or Instructions, SC 3.3.2. 3.3.2 requires labels or instructions to be provided when content requires input; 2.4.6 requires the labels that are provided to be descriptive. A field with no label is a 3.3.2 finding; a field labelled "Details" is a 2.4.6 finding. File each absence or vagueness once, under the right one.
- Link Purpose (In Context), SC 2.4.4. Links have their own criterion. "Click here" is a 2.4.4 finding, not a 2.4.6 one, even though the underlying problem (generic text that describes nothing) feels identical. Grade link text under 2.4.4, heading and label text under 2.4.6.
- Label in Name, SC 2.5.3. 2.5.3 is about the relationship between a control's visible label and its accessible name (speech input users say what they see). 2.4.6 is about the quality of the visible label itself. A descriptive visible label with a mismatched accessible name passes 2.4.6 and fails 2.5.3.
- Page Titled, SC 2.4.2. The page title describes the whole page; headings describe its sections. A vague browser tab title is a 2.4.2 finding even when every heading on the page is exemplary.
How AUDITSU tests this
AUDITSU's audit walkthrough covers headings and labels on every screen you review, with the screen reader running where it matters. The walkthrough prompts you to read the headings list out of context (rotor on the web and iOS, heading navigation with TalkBack on Android) and judge whether each entry describes its section, then to sweep the screen's visible form labels for fields that are ambiguous alone or indistinguishable from their neighbours. Each question records a pass, fail, or not applicable result per screen with the evidence attached, and the walkthrough's framing keeps existence findings routed to 1.3.1 and 3.3.2 so this criterion stays a pure descriptiveness check.
For the full guided workflow, see the audit platform.