WCAG 2.4.6 — Headings and Labels

What this requires

When headings and labels exist, they must describe the topic or purpose of the section or control they introduce. The criterion is about information quality, not presence — <h2>Heading</h2> technically has a heading, but it tells a screen-reader user nothing useful when they jump to it. Labels on form fields and buttons have the same requirement: enough specificity that a user can act on the label alone.

How AI coding tools fail this

The most common failure: generic placeholder headings that survive into production. "Section", "Header", "Content", "Details" — text that was correct as a CSS class name but was never replaced when the section gained an actual topic. The screen-reader user navigating by headings arrives at "Section" and has to read the next paragraph to find out what it's a section about.

The second pattern: identical labels on multiple controls. Three "Edit" buttons in a list of three projects, with no context to distinguish them. The screen reader announces "Edit, button" three times in a row; the user has to inspect the surrounding context to find out which project each one edits.

The third: vague form labels. "Name" on a field that wants a project name, when the form also has a person's name. "Date" on a field that could be a start date or an end date.

Failing examples

A heading that conveys no topic:

<h2>Section</h2>
<p>Manage your billing details and payment methods.</p>

Identical labels on multiple buttons:

{projects.map(p => (
  <li key={p.id}>
    <span>{p.name}</span>
    <button>Edit</button>
  </li>
))}

Passing examples

A heading that names the topic:

<h2>Billing and payment methods</h2>
<p>Manage your billing details and payment methods.</p>

Labels that include the context:

{projects.map(p => (
  <li key={p.id}>
    <span>{p.name}</span>
    <button aria-label={`Edit ${p.name}`}>Edit</button>
  </li>
))}

Edge cases

Visually-hidden context added with an sr-only span (e.g. <button>Edit <span className="sr-only">{p.name}</span></button>) is another way to disambiguate identical visible labels.
Heading levels matter for WCAG 1.3.1 but not for this criterion. 2.4.6 is about the heading text.
Empty headings (decorative, layout-only) should not be <hN> elements at all. Move them to a <p> or remove the role.
Pagination labels ("Page 1", "Page 2") are clear in context. When the same label appears on different pagers in the same page, prefix or suffix with the pager's identity ("Page 1 of search results").
Truncated headings — text cut off by text-ellipsis — still expose their full content to assistive tech, so the criterion still asks whether the underlying text is descriptive.

How Jeikin handles this

Jeikin's MCP server flags repeated identical labels in the same page and prompts the connected AI tool to add disambiguating context. The dashboard tracks heading and label findings together with the surrounding DOM, so the fix can be applied where the duplication lives.