WCAG 2.4.6 (Level AA) requires that any heading or label on your page describes its topic or purpose. It does not force you to add headings or labels — it says that the ones you already use must be clear enough that a person can predict what a section or control is for before they engage with it.

What WCAG 2.4.6 actually requires

The normative wording from the W3C Understanding document is short: “Headings and labels describe topic or purpose.” That single sentence carries three precise ideas that people routinely get wrong.

First, 2.4.6 does not require headings or labels to exist. It only governs the ones that are present. The requirement to actually have a visible label on a form input is a different criterion, 3.3.2 Labels or Instructions.

Second, descriptive is not the same as correctly marked up. Whether your “Pricing” text is a real <h2> element or just bold styled <div> text is decided by 1.3.1 Info and Relationships. Whether the word “Pricing” is a good description is decided by 2.4.6. A page can pass one and fail the other.

Third, short is fine. The W3C explicitly states that a word, or even a single character, can satisfy this criterion if it gives a useful cue. “Q3” can be a perfectly descriptive column heading. The test is meaningfulness, not length.

Who 2.4.6 affects

Clear headings and labels matter most for the people who cannot skim a page the way a sighted mouse user does:

  • Screen reader users (JAWS, NVDA, VoiceOver) pull up a list of all headings to navigate a page — the equivalent of a table of contents read aloud. If every heading says “Section” or “More,” that list is useless and the user has to read the whole page linearly.
  • People with cognitive disabilities or limited short-term memory rely on descriptive headings to keep their place and understand how parts of the page relate. Vague headings force them to re-read.
  • Screen magnifier users see only a small slice of the screen at high zoom, so a meaningful heading or label is often the only context they have for what they are looking at.
  • Users with reading difficulties, including dyslexia, scan headings to find the part they need without processing every paragraph.

This is a Perceivable and Operable concern at once: it lives under the Operable “Navigable” guideline because descriptive headings are how non-visual users operate and move through a page.

Concrete failure examples and fixes

These are the patterns we correct most often during remediation.

Generic “read more” links as labels. Ten links all labeled “Read more” are indistinguishable in a screen reader’s link list. The label must describe its own destination.

<!-- Fails 2.4.6: every link reads identically out of context -->
<a href="/blog/aria-basics">Read more</a>

<!-- Passes: the visible label describes the target -->
<a href="/blog/aria-basics">Read more about ARIA basics</a>

Vague section headings. Headings like “Information,” “Details,” or “Overview” do not predict what the section contains. Rename them to the actual topic — “Shipping options,” “Refund policy,” “Account settings.”

Misleading form labels. A field labeled “Name” that actually wants your username, or a label sitting next to the wrong input, fails because it does not describe the control’s true purpose.

Accessible name that contradicts the visible text. A search box can have a programmatic name set by aria-label that is wrong or unhelpful even when 4.1.2 technically passes:

<!-- Visually a search field, but the accessible label is vague -->
<input type="text" aria-label="field" />

<!-- Passes 2.4.6: the label states the control's purpose -->
<input type="text" aria-label="Search products" />

Note the relationship to 4.1.2 Name, Role, Value: a control can have an accessible name (passing 4.1.2) yet still fail 2.4.6 if that name is not descriptive. The two work together — 4.1.2 says a name must exist and be exposed; 2.4.6 says it must be meaningful.

The W3C’s sufficient techniques here are deliberately plain: G130 (Providing descriptive headings) and G131 (Providing descriptive labels). There is no clever code trick — the fix is writing better words.

How to test for 2.4.6

This criterion resists full automation because a scanner cannot judge whether “Details” is meaningful for your content. The reliable approach mixes a quick tool pass with human judgment.

  1. Pull the heading outline. Use a browser extension that lists all <h1>–<h6> elements, or your screen reader’s headings list (in NVDA press the H key; in VoiceOver use the rotor). Read the headings alone, with no body text. Can you tell what each section covers? If not, it fails.
  2. Read every link and button label out of context. Open the screen reader’s links list. Any label that repeats — “Read more,” “Click here,” “Learn more” — or that is meaningless alone is a candidate failure.
  3. Walk the forms. Tab through each form and confirm every label honestly describes what the field wants. Cross-check that the label requirement itself is met under 3.3.2.
  4. Check icon-only controls. A bare hamburger or magnifying-glass icon needs an accessible name like “Menu” or “Search,” and that name must match its real purpose.

Because the judgment call is human, this is exactly the kind of issue that thorough manual testing catches and automated overlays miss. See our broader heading structure guide for how descriptive headings and correct nesting work together.

Why 2.4.6 matters legally

ADA website litigation keeps climbing. UsableNet’s year-end report counted 4,187 federal and state digital accessibility lawsuits in 2024, and filings were on track to surge nearly 20% in 2025. Courts and the DOJ treat WCAG 2.1 AA — which includes 2.4.6 — as the practical yardstick for an accessible site.

Heading and label problems show up in demand letters constantly because they are trivial for a plaintiff’s tester to document: open a screen reader, pull the headings list, and screenshot a wall of identical “Read more” links. They also expose a hard truth about widgets — UsableNet found that more than 1,000 businesses with accessibility overlays installed were sued anyway in 2024. An overlay cannot rewrite a vague heading into a useful one, because it does not understand your content. That is why we are deliberately anti-overlay and fix the words in your actual markup.

This page is general information, not legal advice. For your specific exposure, consult a qualified attorney.

Fixing it the right way

Conforming to 2.4.6 is editorial work, not engineering. We review your heading outline, rewrite generic links and headings to describe their real topic, correct misleading form labels, and verify the result with a screen reader — then document conformance in a VPAT if you need one. It is one of the cheapest criteria to satisfy and one of the most visible to a tester, which makes it a smart place to start. Run a free scan and we will show you exactly which headings and labels fall short — then fix them with you or for you.