Headings and Labels

In brief

Headings tell people what a section is about, and labels tell them what to enter in a field or what a control does. "Section 1", "Details" and "Field" tell them nothing. Screen reader users jump between headings and form fields, and they depend on what those say.

This criterion requires that headings and labels describe topic or purpose. It does not require that headings or labels exist, but when they do, they must be descriptive.

What does it cover?

• Headings: Each heading should describe the content that follows it (G130).
• Labels: Each label for a form field or control should describe what the field is for (G131).
• Short is fine: A label can be a single word, or even one character, if it cues the user to the content.
• Images as labels: An icon can serve as a label if its meaning is widely understood in context, such as a magnifying glass next to a search field.
• Existence is separate: This criterion does not require labels to exist. That is 3.3.2. Whether they are marked up correctly is 1.3.1, and whether the name includes the visible text is 2.5.3.
• Unique where needed: Repeated fields, such as several address blocks, need labels that tell them apart.
• Out of scope: Section headings throughout long content are 2.4.10 (Level AAA).

Who does it affect?

Screen reader users, who navigate by headings and form controls. People with cognitive or short-term memory difficulties, who rely on clear headings to predict content. People who read slowly or scan, who use headings to find what they need. Voice control users who select controls by label.

In the EAA and EN 301 549

The European Accessibility Act (Directive (EU) 2019/882) applies to in-scope products and services placed on the market after 28 June 2025. Recital 47 names four principles for websites and mobile applications: perceivable, operable, understandable and robust. Descriptive headings and labels are part of "operable".

The technical counterpart is the standard EN 301 549, which incorporates WCAG 2.4.6 by reference and turns it into separate clauses for each kind of ICT.

Whether and how the criterion applies to non-web documents is stated in clause 10 of the standard. Clause numbers follow the "9. + WCAG number" pattern of EN 301 549. In V3.2.1 the software clause is divided into further subclauses for open and closed functionality. Check the exact numbers in the standard when you cite them.

Standard version: EN 301 549 V4.1.1 (September 2026) is based on WCAG 2.2 and is the first version prepared specifically for the EAA. It has not yet been cited in the Official Journal of the European Union, so for now it is best treated as a voluntary technical route to the EAA's requirements. Once cited, it will give a presumption of conformity. The text of criterion 2.4.6 is the same in WCAG 2.1 and 2.2. It is a Level AA criterion.

A note on EAA scope: Article 2(4) of the Directive excludes certain content from the requirements, for example office file formats published before 28 June 2025 and archives that are not updated after that date. Content you publish or change after that date is not covered by these exclusions.

Directive (EU) 2019/882, EUR-Lex, opens in a new tab

Code examples for the web

1. Descriptive headings

A heading should tell users what the section is about.

Section 1
Details
More

Delivery options
Returns and refunds
Contact the support team

2. Descriptive form labels

A label must say what to enter.

Field 1

Surname

3. Labels for repeated fields

When the same field appears more than once, the label or its group must tell them apart.

Street 
Street 

  
Billing address
  Street 


  
Delivery address
  Street 

4. Descriptive button and control labels

A button label should say what will happen.

Submit
OK

Send message
Save changes

5. Headings that are real headings

A heading must be marked up as one, and must describe the section. Do not use heading levels just for styling.

Opening hours

Opening hours

6. Icon labels

An icon alone is acceptable only when its meaning is widely understood. Otherwise add text.

 Add to favourites

Code examples for mobile

In native apps, screen titles, section headers and control labels need the same quality, and the labels must be exposed to assistive technology.

iOS (SwiftUI)

import SwiftUI

struct AddressForm: View {
    @State private var street = ""

    var body: some View {
        Form {
            // Descriptive section header, marked as a heading
            Section(header: Text("Delivery address")) {
                // Avoid: TextField("Field 1", text: $street)
                TextField("Street and house number", text: $street)
                    .textContentType(.streetAddressLine1)
            }
        }
    }
}

Android (Jetpack Compose)

import androidx.compose.material3.*
import androidx.compose.runtime.*
import androidx.compose.ui.Modifier
import androidx.compose.ui.semantics.heading
import androidx.compose.ui.semantics.semantics

@Composable
fun AddressForm() {
    var street by remember { mutableStateOf("") }

    Text(
        "Delivery address",
        style = MaterialTheme.typography.titleMedium,
        modifier = Modifier.semantics { heading() }
    )
    // Avoid: label = { Text("Field 1") }
    OutlinedTextField(
        value = street,
        onValueChange = { street = it },
        label = { Text("Street and house number") }
    )
}

How to test

• List the headings: Use a heading list in a screen reader or a browser extension. Does each heading describe its section? Could you understand the page from the heading list alone?
• Read the labels: Go through every form field and control. Does each label say what the field is for?
• Look for generic text: Search for "Section", "Details", "More", "Field", "Submit" and "OK" as headings or labels.
• Check repeated fields: Do fields that appear more than once have distinct labels or group labels?
• Check icon labels: Is the meaning of each icon obvious in context, or does it have text?
• Check mobile: Do screen titles, section headers and control labels describe their purpose when read by a screen reader?
• Use a checker as a starting point: Automated tools find missing and empty labels and headings, but cannot judge whether text is descriptive.

Common mistakes

• Generic headings: "Section 1", "Details" and "Information" describe nothing.
• Generic button labels: "Submit" and "OK" do not say what will happen.
• Placeholder as the only label: It disappears when the user types.
• Duplicate labels: Several fields called "Street" or "Name" with no group.
• Headings used for styling: A heading that does not describe a section.
• Vague link-like headings: "Click for more" as a heading.
• Over-long labels: A label should be concise enough to be read quickly.
• Labels that do not match the field: A label "Phone" on an email field.

Sources

• Understanding SC 2.4.6: Headings and Labels (W3C), opens in a new tab
• G130: Providing descriptive headings (W3C), opens in a new tab
• G131: Providing descriptive labels (W3C), opens in a new tab
• Directive (EU) 2019/882, European Accessibility Act (EUR-Lex), opens in a new tab
• EN 301 549 V4.1.1 (ETSI), opens in a new tab
• The European accessibility standard EN 301 549 has been updated (AccessibleEU), opens in a new tab

Standard version: EN 301 549 V4.1.1 (2026-09), WCAG 2.2. This page is for informational purposes only and is not legal advice. For binding requirements, refer to the official texts of the European Accessibility Act (Directive (EU) 2019/882) and EN 301 549.