Goal
Use headings and labels that clearly describe content and controls.
Success Criterion · WCAG 2.4.6
Headings and Labels
Headings and labels describe topic or purpose.
Level AAWCAG 2.0Operable2.4 · Navigable
Copy button ready
What to do
Write descriptive headings and form labels that communicate the topic or purpose.
Why it matters
Clear headings and labels help users understand structure and reduce confusion—especially for screen reader users and users with cognitive disabilities.
Success criterion
What WCAG 2.4.6 requires
Summarized directly from the official Understanding document so teams can quote the requirement accurately.
Headings and labels describe topic or purpose.
Intent
Why WCAG created this requirement
- Headings provide structure and support navigation.
- Labels help users understand what to enter or select.
- Consistency improves predictability and comprehension.
Benefits
Who gains when you pass
- Screen reader users can navigate by headings and quickly find relevant sections.
- Users with cognitive disabilities benefit from clear, specific labels and section names.
- All users complete forms more accurately when labels are descriptive.
Why it matters
User impact when this criterion fails
Summaries drawn from the Understanding document help you socialize impact statements with product stakeholders.
Users may enter incorrect data when labels are unclear.
Users may not find content when headings are vague or misleading.
Overview
Headings and labels must be meaningful and descriptive. Avoid vague headings like “Section 1” or labels like “Input” that don’t communicate what the section or control is for.
- Use headings that reflect section content (not just visual styling).
- Use labels that match the visible purpose and expected input format.
- Avoid placeholder-only labeling; placeholders are not a substitute for labels.
Reference: All summaries and highlights originate from Understanding WCAG 2.4.6 and the W3C quick reference.
Fast facts
- Conformance level
- Level AA
- WCAG version introduced
- WCAG 2.0
- Principle
- Operable
- Guideline
- 2.4 · Navigable
Examples
Make success tangible for teams
Share pass/fail snapshots to coach designers, engineers, QA, and content authors.
Heading
Pass
“Billing details” heading for a billing section.
Fail
“Section 2” heading with no meaning.
Input label
Pass
Label: “Email address (for receipts)”.
Fail
Label: “Input” or placeholder-only text.
Evidence to keep
Document conformance decisions
Capture artifacts for VPATs, procurement reviews, and regression testing.
- Document content guidelines for headings and labels.
- Create a label glossary for common fields (email, phone, address) for consistency.
Official resources
Deep dives and supporting material
Keep these links handy when writing acceptance criteria or responding to audits.
Implementation checklist
Capture progress and blockers
- Audit headings for clarity and uniqueness within a page.
- Ensure all form controls have visible labels or accessible names that describe purpose.
- Avoid vague labels (“Name” vs “Full name”, “Search” vs “Search tools”).
- Ensure headings follow a meaningful hierarchy (h1 → h2 → h3).
Testing ideas
Prove conformance with evidence
- Navigate headings with a screen reader and verify headings make sense out of context.
- Tab through form controls and verify label announcements match visible labels.
- Review pages for placeholder-only inputs and replace with labels.
Related success criteria
More from Navigable (2.4)
WCAG 2.4.1Bypass BlocksLevel AWCAG 2.4.2Page TitledLevel AWCAG 2.4.3Focus OrderLevel AWCAG 2.4.4Link Purpose (In Context)Level AWCAG 2.4.5Multiple WaysLevel AAWCAG 2.4.7Focus VisibleLevel AAWCAG 2.4.8LocationLevel AAAWCAG 2.4.9Link Purpose (Link Only)Level AAAWCAG 2.4.10Section HeadingsLevel AAAWCAG 2.4.11Focus Not Obscured (Minimum)Level AAWCAG 2.4.12Focus Not Obscured (Enhanced)Level AAAWCAG 2.4.13Focus AppearanceLevel AAA