Headings and Labels: What WCAG SC 2.4.6 Actually Requires for E-Commerce Pages
Quick answer: WCAG SC 2.4.6 Headings and Labels (Level AA) requires that “headings and labels describe topic or purpose.” That’s a narrower requirement than it sounds — it doesn’t require a heading or label to exist (that’s SC 1.3.1 and SC 3.3.2), and it doesn’t require correct markup (also 1.3.1). It only asks: once a heading or label is there, does its text actually tell someone what it’s attached to? A product-page accordion labeled “More,” a filter group labeled “Options,” or a billing form with two fields both simply labeled “Name” can pass every other WCAG check and still fail 2.4.6, because the words themselves don’t do their job.
This article covers technical accessibility practice, not legal advice — it explains what WCAG 2.1 AA requires for heading and label text and how to meet it, not whether a specific site carries legal risk.
What the criterion does and doesn’t require
The Understanding doc’s Intent section is unusually precise about its own boundaries:
- It doesn’t require headings or labels to be present. The intent is “not to fail pages where a heading or label should be added for clarity” — it only evaluates the ones already there. A page with no heading at all isn’t a 2.4.6 failure, though it may fail other criteria.
- It doesn’t require length, or even text. The doc states plainly: “A word, or even a single character, may suffice if the topic or purpose is clear from it,” and an image can serve as a label “if the meaning is clear and widely understood.”
- It’s distinct from three other criteria that get confused with it: SC 1.3.1 Info and
Relationships covers
whether a heading or label is marked up correctly (a real
<h2>, a<label>tied to its field) — not whether the words are good. SC 3.3.2 Labels or Instructions covers whether a form field has a label at all. SC 4.1.2 Name, Role, Value covers whether an interactive control’s accessible name is exposed to assistive technology at all — a control can have a perfectly exposed, perfectly programmatic accessible name of “Submit” and still fail 2.4.6 if “Submit” doesn’t actually describe what submitting does.
The Understanding doc’s own worked example is a single sentence, and it’s worth sitting with because of how ordinary it is: “A form asks for the name of the user. It consists of two input fields to ask for the first and last name. The first field is labeled First name, the second is labeled Last name.” That’s the whole example — two adjacent fields, each needing a distinct label describing what goes in it, not “Name” and “Name” or “Name” and “Name (2).”
Where this shows up on an e-commerce site
Accordion, tab, and filter-group headings that describe nothing
Product-detail pages are built almost entirely out of headed sections now — an accordion for “Shipping,” “Returns,” “Materials,” a tab strip for “Description,” “Specs,” “Reviews,” a filter sidebar grouped under category labels. Each heading is a real, load-bearing piece of navigation for anyone using a screen reader’s “jump to next heading” command (the same command Technique G130, Providing descriptive headings is written around), or a sighted user scanning the page instead of reading every paragraph. The failure isn’t a missing heading — it’s one that exists but gives up the one piece of information it’s there to provide: an accordion trigger labeled “More” instead of “Shipping & Returns,” a PDP tab labeled “Info” instead of “Specifications,” a filter group labeled “Options” instead of “Size” or “Color,” FAQ accordion headings that are literally “Question 1,” “Question 2,” with the real question text only inside the collapsed panel.
G130’s own worked example shows the fix: a page titled “Disaster preparation” with subheadings
“Flood preparation” and “Fire preparation,” not “Preparation for floods” — put the distinguishing
word first, since that’s what a skimmer actually needs. This is a text-content fix, not a markup
fix. A heading can be a real <h3>, correctly nested, correctly exposed to the accessibility
tree — pass SC 1.3.1 and 4.1.2 cleanly — and still fail 2.4.6 if the words inside it are “More.”
Repeated form fields with the same label
Checkout is the other place this shows up constantly: a guest-checkout flow with separate billing and shipping sections duplicates nearly every field name on one page. If both sections’ name fields render identical visible text — “First Name” under “Shipping Address” and “First Name” again under “Billing Address” — a sighted user reads the section heading above each block and never notices the ambiguity. A screen-reader user tabbing field-by-field, or pulling up a list of form fields out of context, hears “First Name, edit text” twice with nothing distinguishing which block either one belongs to.
Technique G131, Providing descriptive
labels is the sufficient technique the
Understanding doc points to here, and its worked examples apply directly: it shows “First name”
and “Last name” fixing two otherwise-identical adjacent fields, and separately shows map zoom
controls labeled “Zoom in (Ctrl + Shift + L)” and “Zoom out (Ctrl + Shift + R)” — pairing a
control’s function with disambiguating context. Applied to a billing/shipping form: the
accessible label (not necessarily the visible one, if the design needs “First Name” under each
section for sighted users) should fold in which section it belongs to — “First name, shipping
address” versus “First name, billing address” — via aria-label or a <label> with
visually-hidden text, while the printed text stays short.
This is a different failure from WCAG 2.2’s SC 3.3.7 Redundant Entry, which is about not re-asking for information a shopper already gave earlier in the same process. Billing and shipping asking for two genuinely different addresses isn’t redundant entry — it’s two legitimate fields that happen to share a generic starting label, exactly the case 2.4.6 and Technique G131 exist for.
Where this isn’t the right criterion
Worth being precise about what 2.4.6 doesn’t cover, since the adjacent failure is more common and
already has its own article here: a product grid where every card’s link or button says the same
generic thing — “Shop Now,” “Add to Cart” — repeated identically across twenty products. That’s
SC 2.4.4 Link Purpose (In Context) territory
for links and SC 4.1.2 territory for an unlabeled button’s name, not 2.4.6: a vague link whose
purpose is only determinable from surrounding context is a Link Purpose problem; a heading or
label whose own text is non-descriptive regardless of context is a 2.4.6 problem. The fix differs
accordingly — Link Purpose is fixed by exposing more context (an aria-label tying the link to
the specific product name beside it); 2.4.6 is fixed by making the label’s own words better.
What a scanner catches here, and what it can’t
This is one of the cleaner pillar-4 cases on this site, in the opposite direction from most: the
DOM structure is entirely fine, and the scanner just has no way to judge the words in it. Checked
directly against axe-core’s own
rule-descriptions.md:
empty-heading flags a heading with no accessible text at all, and heading-order flags a level
that skips a step (<h2> straight to <h4>) — neither asks whether the text that is there means
anything. “More” and “Shipping & Returns” are indistinguishable to both.
The W3C’s own accessibility-conformance-testing project has a rule aimed at this gap, “Heading is
descriptive” (b49b2e) —
its status, as of this writing, is Proposed, not an approved rule. The rule’s own text explains
why: it requires checking that a heading “describes the topic or purpose of the first perceivable
content” that follows it, which means comparing a short string against the meaning of everything
underneath it — a semantic judgment, not a DOM property. For 2.4.6, a manual pass that actually
reads the heading and the section it introduces is the only reliable check today.
A quick pass you can run yourself
Pull up every heading on your PDP, category page, and checkout flow in isolation — a browser extension that lists a page’s heading outline, or a screen reader’s “list headings” command, does this fastest. Read just the list, with no surrounding content. If “More,” “Info,” “Options,” or “Details” shows up more than once, that’s the pattern to fix. Separately, on any form with more than one section asking for the same field name (billing/shipping, primary/gift recipient), check what a screen reader actually announces for each field, not what’s printed on screen — if two announce identically, the accessible label needs the disambiguating context G131 describes, even if the visible label stays the same for sighted users.
FAQ
Does “Description,” “Shipping,” or “Reviews” as a PDP tab label pass 2.4.6? Yes — each one genuinely describes the content behind it, and the Understanding doc explicitly says short labels are fine, even a single word, as long as the topic is clear from it. The failure pattern is a generic word that could apply to any section (“More,” “Info,” “Details”), not a short one.
Is this the same as making sure headings use real <h2>–<h6> tags instead of bold text?
No — that’s SC 1.3.1 Info and Relationships, covered in our heading-structure and landmarks
guide. A heading can be a
real, correctly nested <h3> and still fail 2.4.6 if its text is vague; it can also have perfect,
descriptive text and still fail 1.3.1 if it’s just large bold body text with no heading markup at
all. They’re independent checks.
Can an automated scanner flag this for us during development? Not reliably today. The closest thing, the W3C’s own “Heading is descriptive” ACT rule, is still in Proposed status and states outright that it requires semantic judgment a tool can’t fully automate. Treat this one as a manual-review item in your own QA pass, the same way you’d review microcopy.
Get it checked by a person, not just a parser
Heading and label wording is exactly the kind of finding Quietramp’s manual review is built to catch and a free scanner isn’t — it’s a content-quality judgment call, not a DOM property. See a real sample report or check pricing: $890 for a one-time audit, $99/month if you want ongoing re-checks after fixes ship.
This is educational content about technical accessibility practice, not legal advice. Meeting WCAG 2.1 AA does not constitute a legal compliance determination under the ADA or any other standard — consult qualified counsel for legal risk questions.
This article was drafted with AI assistance and reviewed by a person for accuracy before publication.