2.4.6 Headings and Labels

WCAG 2.2 · 2.4.6 AA Operable

What it requires

Headings and labels — when they are present — must describe their topic or purpose. The criterion does not require that headings or labels exist; it requires that any you do provide are meaningful. A reader scanning a page by its headings, or moving field to field through a form, should be able to tell what each section or control is for from its text alone. Generic strings like “Heading”, “More”, or an unlabelled “Field” fail because they describe nothing.

The label text only needs to be descriptive, not lengthy or unique — though unique labels help. Note this is about the visible/programmatic text of headings (<h1>–<h6>) and form labels, distinct from 1.3.1 (structure), 2.4.10 (section headings), and 4.1.2 (name/role/value).

  • Screen-reader users who navigate by pulling up a list of headings or jumping between form fields — vague text leaves them guessing.
  • Sighted users who scan rather than read, including many people with cognitive or attention disabilities, who rely on descriptive headings to find content quickly.
  • Low-vision and magnifier users who see only a small slice of the page and depend on accurate labels to orient themselves.

How to detect it

Ways to check Headings and Labels
Check How Catches
Manual review Read each heading and label out of context. Does it describe the section or control? Vague, generic, or misleading text.
Screen reader Pull up the headings list (e.g. NVDA Insert+F7) and tab through form fields; judge each announcement alone. Headings/labels that read as meaningless when isolated.
Keyboard + zoom Tab to each field at 200%+ zoom; confirm the label is present and clear. Placeholder-only or truncated labels.
Automated tools axe, WAVE, Lighthouse can flag empty or missing labels/headings. Only blank text — they cannot judge whether wording is descriptive, so this is largely a human check.

How to fix it

  1. Rewrite each heading to name the content beneath it — “Billing address”, not “Section 2”.
  2. Give every form control a label that states what to enter; never rely on a placeholder alone.
  3. Disambiguate repeated controls (e.g. several “Edit” buttons) so each label stands on its own.
  4. Re-test by reading headings and labels out of context and with a screen reader.
<h2>Shipping address</h2>

<label for="email">Work email address</label>
<input id="email" type="email" name="email" autocomplete="email">

Copy-paste tests

Automated coverage

There is no fully automated axe-core rule that confirms headings and labels are descriptive — clarity is a judgement call. This criterion needs manual review using the console check and steps below.

Run this in the browser console

headings-and-labels.js 
// Read-only: lists headings and form labels so you can judge clarity.
const rows = [];
document.querySelectorAll('h1,h2,h3,h4,h5,h6').forEach(h => {
  rows.push({ type: h.tagName, text: h.textContent.trim() });
  h.style.outline = '2px solid orange';
});
document.querySelectorAll('label,[aria-label]').forEach(l => {
  rows.push({ type: 'LABEL', text: (l.getAttribute('aria-label') || l.textContent).trim() });
  l.style.outline = '2px solid teal';
});
console.table(rows);

What to check manually: read each heading and label out of context — does it describe the topic or purpose on its own? Watch for vague repeats like "More", "Details", or several labels all reading "Email".