Skip to main content
WCAGrules
Quick navigation

Headings and Labels

Where headings and labels exist, they have to describe the topic or the purpose of what they head or label. The rule does not require you to have headings, and it does not require a form to have labels, which is 3.3.2's job. It also says nothing about markup. A heading can be perfectly coded and still fail here for saying nothing, and a descriptive heading marked up as a bold paragraph passes this rule while failing 1.3.1. The same split applies to controls. A button with a correctly computed accessible name satisfies 4.1.2 and still fails this rule if that name is vague. Length is not the test either. A single word, or even one character, is enough when it tells somebody what they will find.

Why it matters

Headings are the promises a page makes, and readers spend their attention based on them. Break the promise and you break the skimming everybody does, sighted or not. For a screen reader user, running down the heading list is not a convenience laid on top of reading. It is the navigation. That list only exists because the headings were marked up as headings, which is a different rule doing the work underneath this one. People with limited short-term memory get the most out of clear section titles, because predicting what a section holds saves reading it to find out. The research W3C points to behind this rule is the work showing that most people scan a page rather than read it.

Who this rule protects

This affects screen-reader users skimming by heading list, people with limited short-term memory or reading disabilities who rely on predicting what a section holds, people with cognitive disabilities orienting by signposts, and every reader who scans a page before committing to it.

How to check it yourself

  1. Pull the heading list on its own and read it top to bottom. Ask whether somebody could work out what the page holds from those words alone.
  2. Read each form label and ask whether a first-time visitor would know what to type. Two fields both called 'Name' fail that. 'First name' and 'Last name' pass it.
  3. Judge the words, not the markup. Whether the heading is coded as a heading is 1.3.1, and whether the control has an accessible name at all is 4.1.2. This rule only asks whether the words describe anything.
  4. Do not treat short as vague. One word is enough when it names the thing, and an icon can be the label where its meaning is understood in that spot.

Failures we see most often

  • Section headings reading 'More', 'Other', 'Details' and 'Info', none of which says what follows.
  • Two fields on the same form both labelled 'Name', with nothing saying which is the person and which is the company.
  • A marketing question standing in for a heading in a checkout, where the reader needs to know which step they are on.
  • A heading list that reads like a slogan reel, so a screen-reader user pulling it up learns nothing about where anything is.

Who this one is for

Read from this rule's own note above, so the grouping and the note cannot disagree.

How this one is tested

We list 2 ACT rules against 2.4.6. Each one defines exactly what a checker looks at, which is how automated tools decide what to flag. Each one also checks a slice, so passing every rule here is not the same as meeting the criterion, and a rule can be proposed rather than approved or need a person to finish it. The note beside each says which.

How to fix it

  • Rewrite headings so they name their contents. 'Shipping address' and 'Refund policy' let a reader jump straight to the one they came for.
  • Disambiguate similar labels rather than lengthening all of them. 'Full name', 'Company name' and 'Cardholder name' beat three fields called 'Name'.
  • Keep section headings consistent across pages that do the same job. A set of articles that all run summary, then detail, then conclusion is faster to read on the second one than on the first.
  • Where an icon is the label, check its meaning is obvious in that spot, and give it a text alternative naming the function rather than the picture. A magnifying glass beside a search field is 'Search'.
Step-by-step fix guides (4)

Passes vs. fails

A general illustration of the pattern rather than a test of 2.4.6. Passes: headings exist in the code. Fails: one flat wall of text.

Passes

A heading list reads 'Your cart, Shipping address, Payment, Order review', naming exactly what each section holds.

Fails

A heading list reads 'Welcome, More, Details, Other', which tells the reader nothing about any section.

In audits and lawsuits

No failure technique exists for this criterion, which is unusual and it says something. There is no mechanical pattern to catch, only a judgement about whether the words describe what follows. The two automated rules that do exist are semi-automated for the same reason, since a machine can find the heading and cannot decide whether it means anything. Our reviewers read heading lists page by page, the way a screen-reader user meets them. One thing that is not automatically a finding. An icon can be a descriptive label by itself where its meaning is widely understood, which is why a magnifying glass beside a search field is fine.

Go somewhere useful

Find tools, resources and your workspace.

29 destinations