WCAG 2.4.6 Headings and Labels: How to Create Clear Website Content

WCAG 2.4.6 requires that headings and labels describe the topic or purpose of the content they refer to. This short guide explains what that means, shows common failures, and gives a step-by-step audit and fixes you can apply today.

What WCAG 2.4.6 requires

WCAG 2.4.6 is a Level AA success criterion in the WCAG 2.x family. The rule is simple: headings and labels must describe the topic or purpose of the content, control or link they name. When they do, users who scan pages with assistive technology can predict where content will lead them.

Why clear headings and labels matter

• Screen reader users move by headings. Clear headings save time.
• Keyboard users rely on labels to know which control does what.
• People with cognitive impairments benefit from direct, concrete labels.
• Descriptive labels improve findability for everyone.

Common failures

• Headings that are vague, such as “More” or “Options”.
• Form inputs without a visible label or with labels that only repeat placeholder text.
• Links or buttons with text like “Click here” or “Read more” that do not explain the destination.
• Using visual styling to create headings instead of semantic heading elements.
• Relying on aria-label when a visible label is easy to provide.

Examples: bad vs good

Element	Bad	Good
Section heading	More	Shipping times for UK orders
Link text	Click here	Download invoice PDF
Form label	Enter value	Mobile number for delivery updates
Button	Go	Search orders

How to audit WCAG 2.4.6: step-by-step

1. Crawl and list headings

Use a site crawler or a browser extension to export page headings. For each page, list headings in order and check whether each heading describes the section that follows.

2. Review form fields

Find all form controls. Confirm each control has a visible label. If a visible label is not possible, check for a programmatic label using aria-label or aria-labelledby. Prefer the native element with a matching for attribute.

3. Inspect links and buttons

Scan link and button text. Ensure each one makes sense out of context. Ask: would the text alone tell a user where it goes or what it does?

4. Check navigation and repeated components

Check top level navigation and any repeated lists of links. Give each navigation region a clear label or heading, and use landmarks where relevant.

5. Test with assistive technology

Listen to headings and labels using a screen reader. Try keyboard-only navigation. Confirm that the label or heading that announces is the same meaningful text you expect.

6. Record and prioritise fixes

Log each failure, why it fails, and the estimated effort to fix. Tackle high-impact low-effort items first, such as missing form labels or ambiguous link text.

Fixes for specific elements

Headings

• Use semantic heading elements (h2, h3) rather than styled divs.
• Make each heading describe the section precisely. Include scope if needed, for example “Account settings: security”.
• Keep headings short and specific. Avoid generic words like “Details”.

Form labels

• Always provide a visible label. Use when possible.
• Do not rely on placeholder text as the only label. Placeholders disappear and are not sufficient for accessibility.
• When a visible label cannot be shown, use aria-labelledby to reference visible text or aria-label as a last resort.

Links and buttons

• Make link text descriptive on its own. For example “View April invoice” not “View”.
• Where links repeat, add context such as the item name to each link.
• For icon-only buttons, provide an accessible name through a visible label, aria-label, or aria-labelledby.

Navigation menus and landmarks

Label navigation regions with clear headings such as “Primary navigation” or “Footer links”. Use ARIA landmarks to let users jump to key parts of the page.

Dynamic interfaces

When content changes, update headings and labels so they still reflect the new content. For widgets, keep a stable, descriptive label that explains the widget purpose.

Common mistakes and how to avoid them

• Adding headings only for visual layout. If it looks like a heading, it should be a semantic heading.
• Copying the same short label across many controls. Add context so each label is unique where users need to distinguish items.
• Hiding real labels with CSS. If you hide a visible label, ensure you provide an equivalent programmatic label.
• Assuming icons speak for themselves. Icon-only controls need accessible names.

Testing tools and simple checks

• Screen readers: NVDA, VoiceOver, TalkBack.
• Browser accessibility tree in DevTools to confirm programmatic names.
• Automated checkers such as axe DevTools or WAVE for quick detection of missing labels and empty link text.
• Manual checks: navigate by headings and tab through forms while listening to what a screen reader announces.

Prioritisation checklist

• High priority: missing labels on forms used for transactions or account access.
• Medium priority: ambiguous top-level headings and primary navigation labels.
• Low priority: decorative headings used in isolated, non-critical sections.

Final quick checklist

• Do headings describe the section topic?
• Does each form control have a programmatic label?
• Can link and button text be understood out of context?
• Are icon-only controls given accessible names?
• Have you tested with a screen reader and keyboard only?

Follow this guide to find and fix the most common WCAG 2.4.6 problems quickly. Clear headings and labels improve usability for everyone and help you meet Level AA expectations.