WCAG 2.4.6: Headings and Labels

What This Rule Means

WCAG 2.4.6 states: "Headings and labels describe topic or purpose." At its core, this criterion demands that any heading (<h1> through <h6>) or label (<label>, aria-label, aria-labelledby) that appears on a page must be descriptive enough to communicate the subject of the content it introduces or the purpose of the control it identifies.

This criterion does not require that headings or labels be present — that obligation is covered by other success criteria such as 1.3.1 (Info and Relationships) and 2.4.2 (Page Titled). What 2.4.6 governs is the quality of headings and labels that already exist: when you have them, they must be meaningful. A heading that reads "Section 1" or a label that reads "Field" tells users nothing useful about the content that follows or the input it describes. Contrast this with "Your Shipping Address" or "Monthly Budget Summary," which orient users immediately.

Labels in this context include not only the HTML <label> element associated with form controls but also any programmatic labelling mechanism: aria-label, aria-labelledby, the title attribute when used as an accessible name, and the legend element for fieldsets. Any of these that are exposed to assistive technologies must describe the purpose of the associated control clearly.

A failure occurs when a heading or label is so generic, ambiguous, or uninformative that a user cannot determine what the section or control is about without reading the surrounding context. For example, a form with three inputs all labeled "Enter here" fails this criterion, as does a page that uses repeated headings such as "More Info" for every subsection. Equally, a heading that is technically present in the DOM but completely misleads the user — such as labeling a contact form section with a heading that says "News and Updates" — is also a failure.

There is one important official exception: WCAG 2.4.6 only applies when headings and labels are used. If a page legitimately has no headings (for instance, a very short document with a single topic) or a form control that has no visible or programmatic label (which would be caught by 1.3.1 instead), 2.4.6 itself does not apply. The criterion's scope is strictly about descriptiveness, not presence.

Why It Matters

Descriptive headings and labels benefit a remarkably broad audience, but the impact is most acute for people with disabilities who rely on structure to navigate.

Screen reader users — primarily people who are blind or have severe low vision — routinely navigate pages by jumping from heading to heading using shortcut keys (H in NVDA/JAWS, the Rotor in VoiceOver). If headings are vague or misleading, this navigation strategy breaks down entirely. A blind user landing on a government services portal that uses "Section A," "Section B," and "Section C" as its headings must read every word of every section sequentially to find what they need, eliminating the efficiency advantage that headings are supposed to provide. According to the World Health Organization, approximately 2.2 billion people worldwide have some form of vision impairment, making this a substantial global population.

People with cognitive disabilities, including those with attention deficit disorders, memory impairments, or learning disabilities, depend heavily on clear, predictable labels and headings to reduce cognitive load. When a form field is labeled only "Name" on a page that collects both a company name and a contact person's name, a cognitively impaired user may not be able to resolve the ambiguity from context alone, leading to errors and frustration.

Users with motor impairments who rely on switch access, eye-tracking software, or voice control (such as Dragon NaturallySpeaking) benefit from descriptive labels because they can activate a specific form field by speaking its label name. If multiple fields share the same label text, voice control software cannot disambiguate between them, forcing the user into additional steps that are physically taxing.

Consider a real-world scenario: a person using a screen reader visits an e-commerce checkout page. The page contains three address sections — billing, shipping, and a gift recipient address — but each section uses the same generic heading "Address" and each set of inputs uses the same labels: "Street," "City," "Postal Code." Without unique, descriptive headings and labels, the screen reader user cannot determine which group of fields they are filling in, dramatically increasing the risk of ordering errors and the likelihood of abandoning the purchase entirely.

Beyond accessibility, descriptive headings provide substantial SEO value. Search engines use heading structure as a strong signal for understanding page content and matching it to user queries. Meaningful headings help search engines index pages more accurately and can improve click-through rates in search results where headings are often surfaced as preview text. This aligns business incentives directly with accessibility requirements.

Related Axe-core Rules

WCAG 2.4.6 requires manual testing because no automated tool can reliably determine whether a heading or label is descriptive. Descriptiveness is a semantic, contextual judgment — a heading that reads "Products" might be perfectly descriptive on one page and completely ambiguous on another. Automated scanners can detect the presence or absence of headings and labels, but they cannot assess whether the text of those headings and labels is meaningful without human interpretation.

• Manual review of heading text: Axe-core will flag missing headings or improper nesting (via rules like heading-order), but it cannot flag a heading that says "Click Here" or "Untitled Section" as a 2.4.6 violation. A human tester must read each heading in isolation — as a screen reader user would encounter it navigating by headings — and assess whether it communicates the topic of the content below.
• Manual review of form label text: Axe-core's label rule verifies that every form input has an associated label, but it does not evaluate whether that label's text is descriptive. A label element that contains only a placeholder character, an icon character, or a generic word like "Input" will pass automated checks while still failing 2.4.6. Manual review requires reading each label and confirming it accurately describes the purpose of its associated control.
• Manual review of aria-label and aria-labelledby values: Similarly, the axe-core aria-label-is-accessible family of rules confirms that ARIA labels are syntactically valid and referenced elements exist, but they do not assess whether the label text is semantically meaningful or descriptive of the control's purpose.
• Duplicate label detection: While some tools can flag duplicate label text across a page, they cannot determine whether duplication is intentional and appropriate (two fields with the same purpose on different rows of a table) or a genuine failure of descriptiveness where multiple distinct controls share an ambiguous label. Manual review is required to make this distinction.

How to Test

1. Run an automated scan first: Use axe DevTools (browser extension) or Lighthouse in Chrome DevTools to identify any structural heading or label issues that automated tools can catch, such as missing labels, skipped heading levels, or empty heading elements. While these are not direct 2.4.6 violations, they indicate areas to scrutinize more carefully during manual review. Note every heading and labelled control flagged or identified in the report.
2. Extract the heading list: Use a browser extension such as the HeadingsMap extension (available for Firefox and Chrome) or the WAVE tool to generate a flat list of all headings on the page, stripped of their surrounding content. Read through this list as if it were a table of contents. Ask: could a user understand the structure and main topics of this page from headings alone, without reading the body text? If any heading is ambiguous or uninformative in isolation, it is a 2.4.6 failure.
3. Test with NVDA and Firefox: Open the page and press H to navigate heading by heading. Listen to each heading announcement and assess whether it describes the content that follows. Then press F to cycle through form fields and listen to the label announced for each input. Record any heading or label that does not clearly describe its topic or purpose.
4. Test with VoiceOver and Safari (macOS/iOS): Use the Web Rotor (VO+U) to open the Headings list and the Form Controls list. Navigate through each list and evaluate every item's descriptiveness independently of the page context. On iOS, use a three-finger swipe to navigate by headings in the Rotor.
5. Test with JAWS and Chrome: Press H to navigate headings and use the Forms Mode (F) to move between form controls. Use the JAWS List of Headings dialog (Insert+F6) to view all headings in a flat list, which replicates how a screen reader user would scan the page structure.
6. Evaluate form labels in isolation: For every form control, cover or ignore all surrounding context and read only the programmatic label (visible label text, aria-label, or aria-labelledby target). Confirm that the label alone is sufficient to understand what information should be entered or what action the control performs.
7. Check for duplicated heading or label text: Search the page for repeated heading text (e.g., multiple "Read More" headings or multiple "Learn More" sections). If the same text is used for headings or labels that refer to different topics or controls, this is a failure of 2.4.6.

How to Fix

Generic Section Headings — Incorrect

<section>
  <h2>Section 1</h2>
  <p>We offer a range of enterprise software solutions tailored for logistics companies.</p>
</section>
<section>
  <h2>Section 2</h2>
  <p>Our pricing is flexible and based on the number of active users.</p>
</section>

Generic Section Headings — Correct

<!-- Each heading now describes the actual topic of its section,
     enabling screen reader users to jump directly to what they need -->
<section>
  <h2>Enterprise Logistics Software Solutions</h2>
  <p>We offer a range of enterprise software solutions tailored for logistics companies.</p>
</section>
<section>
  <h2>Flexible User-Based Pricing</h2>
  <p>Our pricing is flexible and based on the number of active users.</p>
</section>

Ambiguous Form Labels — Incorrect

<!-- A checkout form with two address blocks, both using identical labels -->
<fieldset>
  <legend>Address</legend>
  <label for='street1'>Street</label>
  <input type='text' id='street1'>
  <label for='city1'>City</label>
  <input type='text' id='city1'>
</fieldset>
<fieldset>
  <legend>Address</legend>
  <label for='street2'>Street</label>
  <input type='text' id='street2'>
  <label for='city2'>City</label>
  <input type='text' id='city2'>
</fieldset>

Ambiguous Form Labels — Correct

<!-- Legends now distinguish the two fieldsets; labels remain short because
     the legend provides the distinguishing context programmatically -->
<fieldset>
  <legend>Billing Address</legend>
  <label for='billing-street'>Street</label>
  <input type='text' id='billing-street'>
  <label for='billing-city'>City</label>
  <input type='text' id='billing-city'>
</fieldset>
<fieldset>
  <legend>Shipping Address</legend>
  <label for='shipping-street'>Street</label>
  <input type='text' id='shipping-street'>
  <label for='shipping-city'>City</label>
  <input type='text' id='shipping-city'>
</fieldset>

Non-descriptive ARIA Label on Icon Button — Incorrect

<!-- aria-label provides a label but it does not describe the button's purpose -->
<button aria-label='button'>
  <svg aria-hidden='true' focusable='false'><!-- search icon --></svg>
</button>

Non-descriptive ARIA Label on Icon Button — Correct

<!-- aria-label now clearly communicates what activating the button will do -->
<button aria-label='Search products'>
  <svg aria-hidden='true' focusable='false'><!-- search icon --></svg>
</button>

Repeated "Read More" Headings or Links — Incorrect

<article>
  <h3>Latest News</h3>
  <p>Istanbul metro expands to three new districts...</p>
</article>
<article>
  <h3>Latest News</h3>
  <p>New regulations affect e-commerce platforms...</p>
</article>

Repeated "Read More" Headings or Links — Correct

<!-- Each article has a unique, descriptive heading that identifies its topic -->
<article>
  <h3>Istanbul Metro Expands to Three New Districts</h3>
  <p>Istanbul metro expands to three new districts...</p>
</article>
<article>
  <h3>New Regulations Affect E-Commerce Platforms</h3>
  <p>New regulations affect e-commerce platforms...</p>
</article>

Common Mistakes

• Using positional or ordinal headings such as "Step 1," "Step 2," "Section A" without any descriptive text: these headings tell the user only where they are in a sequence, not what the section is about. Always combine sequence indicators with a descriptive noun phrase, e.g., "Step 2: Verify Your Email Address."
• Giving all card or article components on a listing page the same heading text (e.g., every product card has an <h3> that just says "Product"): each card heading must uniquely identify that specific product, blog post, or item.
• Using placeholder text as the accessible label for a form input (relying on the placeholder attribute instead of a <label> element or aria-label): placeholders disappear on input and are not reliably announced by all screen readers as accessible names. Even when a placeholder exists, a separate descriptive label is required.
• Writing an aria-label that merely restates the element type rather than its purpose, such as aria-label='input' on a text field or aria-label='button' on a button: the label must describe what the control does or what value it collects, not what kind of element it is.
• Using tooltip text or title attributes as the sole label for a form control and assuming this satisfies 2.4.6: title-based labels are often inaccessible to keyboard-only users and are not consistently announced by screen readers. Rely on visible <label> elements or aria-label instead.
• Labeling search inputs with just "Search" on a page where multiple search scopes exist (e.g., site-wide search and a search within a data table): when two controls perform different searches, each label must specify the scope, such as "Search all products" and "Search within order history."
• Applying the same heading text to a modal dialog's heading as the page's main heading: modal headings should describe the specific task or content of the dialog (e.g., "Confirm Your Cancellation") rather than inheriting the page title, which would be confusing to screen reader users navigating within the dialog.
• Omitting a descriptive <legend> for radio button or checkbox groups while providing individual option labels: the <legend> provides essential context that makes each individual label meaningful. "Yes" and "No" as standalone option labels are uninformative without a legend such as "Do you agree to the terms and conditions?"
• Truncating heading text in the DOM for visual design reasons (e.g., a heading that only contains an icon or a single word because the full text is in adjacent visual elements): the programmatic heading must be fully descriptive because screen reader users hear it without seeing the surrounding visual layout.
• Assuming that because a label is visible to sighted users it is therefore descriptive enough for all users: a label that relies on spatial position (e.g., a column header in a custom grid where the label's meaning depends on seeing its relationship to surrounding cells) may be visually clear but fail to convey the same information programmatically. Always verify that the accessible name alone is sufficient.

Relation to Turkey's Accessibility Regulations

Turkey's Presidential Circular 2025/10, published in the Official Gazette No. 32933 on June 21, 2025, establishes mandatory digital accessibility obligations for a wide range of public and private entities operating in Turkey. The Circular explicitly references WCAG 2.1 Level AA as the technical standard for conformance, and Level AA requirements under WCAG 2.2 — which is backward compatible with WCAG 2.1 at the AA level — are strongly encouraged and required for entities seeking the official Accessibility Logo (Erişilebilirlik Logosu) issued by the Ministry of Family and Social Services (Aile ve Sosyal Hizmetler Bakanlığı).

WCAG 2.4.6 is a Level AA criterion, meaning it falls squarely within the scope of what covered entities must address to achieve full conformance. The following entity types are covered by the Presidential Circular: public institutions and government agencies; e-commerce platforms; banks and financial institutions; hospitals and healthcare providers; telecommunications operators with 200,000 or more subscribers; travel agencies; private transportation companies; and private schools authorized by the Ministry of National Education (Millî Eğitim Bakanlığı).

For these entities, failing to provide descriptive headings and labels carries concrete regulatory risk. A government portal with vague section headings impedes citizens with disabilities from accessing public services, which conflicts directly with the Circular's stated goal of ensuring equal access. An e-commerce site with ambiguous form labels on its checkout flow may prevent users with visual or cognitive disabilities from completing purchases, constituting a barrier to economic participation that the Circular is designed to eliminate.

Entities seeking the Erişilebilirlik Logosu must demonstrate conformance through an accessibility audit, and 2.4.6 is among the criteria that auditors will evaluate manually. Because this criterion requires human judgment — automated tools cannot assess descriptiveness — organizations should include structured manual review of all headings and form labels as a standard part of their accessibility audit process. Building this review into content management workflows and design systems, rather than treating it as a one-time audit task, is the most effective strategy for maintaining ongoing compliance as content changes over time.