WCAG 3.3.2: Labels or Instructions

What This Rule Means

WCAG Success Criterion 3.3.2 — Labels or Instructions (Level A) states: "Labels or instructions are provided when content requires user input." In practical terms, every form field, input control, text area, and select element that asks a user to enter or select information must have a visible, meaningful label or a set of instructions that makes the purpose of the field clear before the user interacts with it.

The criterion is deliberately broad in scope. It covers any mechanism through which a user provides data: <input> elements of all types (text, email, password, number, date, checkbox, radio, file upload), <textarea> elements for multi-line text, and <select> dropdowns. It also applies to custom interactive controls built with ARIA roles such as role='combobox' or role='listbox'.

A label can be provided in several ways that satisfy this criterion. The most robust is a programmatically associated <label> element that is visually present and linked to the control via a matching for/id pair. Alternatively, a visible label text can be associated using aria-labelledby pointing to an existing element, or supplementary instructions can be connected with aria-describedby. The key requirement is that the label or instruction is provided — it must exist in some form the user can perceive. Placeholder text alone does not satisfy this criterion because it disappears as soon as the user begins typing, and it is not reliably conveyed by all assistive technologies as a persistent label.

A pass requires that each input has a label that is visible (or at minimum programmatically determinable), present before the user commits to filling in the field, and descriptive enough to convey what data is expected. A fail occurs when a field has no label at all, when the only label is a placeholder attribute, when the label is visually present but not programmatically associated, or when instructions about required format (e.g., "Enter date as DD/MM/YYYY") are absent entirely.

WCAG does note a narrow exception: when a form contains a single, obvious field — such as a site-wide search bar with a clearly labeled submit button directly adjacent — the context itself may supply sufficient instruction. However, this exception is narrow and should not be used as a general justification for omitting labels on multi-field forms.

Why It Matters

Form labels are the single most impactful accessibility feature for a wide spectrum of users. Their absence creates barriers that can make it impossible for many people to complete transactions, register for services, or contact an organization.

For blind and low-vision users relying on screen readers, an unlabeled field is announced simply as "edit text" or "blank" with no context. The user has no way to know whether to enter their name, their email address, or their credit card number. According to the World Health Organization, approximately 2.2 billion people globally have some form of vision impairment, and millions of them use screen readers as their primary means of interacting with the web.

For users with cognitive and learning disabilities — including dyslexia, ADHD, and memory-related conditions — placeholder text is especially harmful. Because placeholders disappear on focus or input, a user who pauses mid-form has no reference for what was expected in a field they have already started filling in. This forces them to clear the field to re-read the instruction, introducing confusion and frustration. Persistent, visible labels remove this cognitive burden entirely.

For motor-impaired users who navigate by keyboard, switch device, or voice control, labels serve an additional function: they provide the spoken words used to activate a field via voice control software such as Dragon NaturallySpeaking. If the visible label text does not match the programmatic accessible name, the voice command fails silently.

Consider a concrete real-world scenario: a user with low vision is applying for a government benefit on a Turkish public institution's portal. The form uses placeholder text instead of labels. As the user zooms to 200% to read the screen, placeholders vanish before they can be read. The user fills the fields by guessing and submits a form with errors, only to receive a generic error message with no indication of which fields are incorrect. This scenario results in exclusion from a critical public service — and it is entirely preventable.

Beyond accessibility, labeled forms improve SEO because search engine crawlers can better understand form purpose, and they improve usability for all users, including those on mobile devices where small touch targets benefit from tappable label areas that expand the activation zone of the associated input.

Related Axe-core Rules

• label — This rule checks that every <input> element (except those with type='hidden', type='image', type='button', type='submit', and type='reset'), every <textarea>, and every <select> has an accessible name. The rule flags elements that lack an associated <label>, an aria-label attribute, an aria-labelledby reference, or a title attribute. This is the primary automated signal for 3.3.2 violations on standard form controls.
• select-name — This rule specifically targets <select> dropdown elements and verifies that they have a non-empty accessible name. Developers sometimes assume that a dropdown's options make its purpose self-evident, but without a label, screen reader users hear only the currently selected option value — which may be a generic default like "Select one" — with no indication of what category they are choosing from. Axe flags <select> elements missing any of the standard labeling mechanisms.
• textarea-label — This rule checks <textarea> elements for an accessible name. Multi-line text areas are frequently used for comments, messages, or detailed input, yet they are often left unlabeled under the mistaken assumption that surrounding context is sufficient. Axe flags any <textarea> that cannot be programmatically associated with a label through <label for>, aria-label, aria-labelledby, or title.

It is important to understand the limits of automated testing for this criterion. Axe-core can detect the absence of a programmatic label, but it cannot determine whether a label that is present is actually meaningful or accurate. A field labeled "Field 1" or a label that simply reads "*" will pass automated checks while completely failing users. Manual review is always required to confirm that labels describe the expected input clearly, that format instructions are present where needed (e.g., date formats, password requirements), and that required fields are identified — ideally both visually and programmatically.

How to Test

1. Automated scan with axe DevTools or Lighthouse: Open the page containing the form in Chrome or Firefox. Run the axe DevTools browser extension and filter results by the rules label, select-name, and textarea-label. Note every flagged element. Run Google Lighthouse (Accessibility audit) as a secondary check. Export or screenshot all violations. Remember that a clean automated report does not guarantee compliance — proceed with manual steps.
2. Visual inspection: Without using any assistive technology, review every form field on the page. Confirm that each field has a visible, static label — not just a placeholder — positioned clearly near the field (typically above or to the left). Confirm that format requirements (e.g., "Password must be at least 8 characters") are shown before or at the time of input, not only after a failed submission. Confirm that required fields are identified by more than color alone.
3. Keyboard navigation test: Tab through every form field. Ensure that as each field receives focus, its purpose is immediately clear from the visible label. No field should be reachable by keyboard without an adjacent, persistent label being visible at that moment.
4. Screen reader test with NVDA and Firefox: Open the form with NVDA running. Press Tab to move through each interactive control. NVDA should announce the label, the role (e.g., "edit", "combo box"), and any state (e.g., "required"). If NVDA announces only the role and state with no label, the field fails. Use NVDA's form mode (triggered automatically on interactive elements) to simulate realistic user navigation.
5. Screen reader test with VoiceOver and Safari (macOS/iOS): Enable VoiceOver (Command + F5 on Mac). Use Tab or swipe to navigate to each form field. VoiceOver should announce the label before the role. On iOS, tap each field and confirm that the label is read aloud before the keyboard appears. Placeholder-only fields will typically be read as the placeholder on first focus but will become silent once text is entered.
6. Screen reader test with JAWS and Chrome: Open JAWS and navigate the form using Tab. Use JAWS's Forms Mode. Confirm that each field's announced name corresponds exactly to its visible label. Use JAWS's Insert + F1 (field help) to check for any additional descriptions via aria-describedby.
7. Voice control test with Dragon NaturallySpeaking: Activate Dragon and attempt to interact with each field by speaking its visible label. If the spoken label does not match the programmatic accessible name, the field will not respond to the voice command, indicating a mismatch that fails both 3.3.2 and related criteria.

How to Fix

Missing label on a text input — Incorrect

<!-- No label provided; placeholder is the only hint -->
<input type='text' name='email' placeholder='Email address' />

Missing label on a text input — Correct

<!-- Visible <label> associated via matching for/id attributes.
     Placeholder may still be used as supplementary hint,
     but the label is the primary, persistent identifier. -->
<label for='email'>Email address</label>
<input type='text' id='email' name='email' placeholder='[email protected]' />

Unlabeled select dropdown — Incorrect

<!-- No label; screen readers will only announce the selected option value -->
<select name='city'>
  <option value=''>Select a city</option>
  <option value='istanbul'>Istanbul</option>
  <option value='ankara'>Ankara</option>
</select>

Unlabeled select dropdown — Correct

<!-- Programmatically associated label makes the field's purpose clear
     before the user opens the dropdown. -->
<label for='city'>City</label>
<select id='city' name='city'>
  <option value=''>Select a city</option>
  <option value='istanbul'>Istanbul</option>
  <option value='ankara'>Ankara</option>
</select>

Textarea with no label — Incorrect

<!-- The textarea has no label; surrounding paragraph text is not
     programmatically associated and will not be read by screen readers
     as the field's label. -->
<p>Please describe your issue:</p>
<textarea name='message' rows='5'></textarea>

Textarea with no label — Correct

<!-- Using aria-labelledby to associate the existing visible heading
     with the textarea, or alternatively wrapping with a <label> element. -->
<label for='message'>Please describe your issue</label>
<textarea id='message' name='message' rows='5'></textarea>

Format instructions absent for a date field — Incorrect

<!-- Label present but no instruction about expected date format;
     users must guess whether to enter 01/06/2025 or 2025-06-01. -->
<label for='dob'>Date of birth</label>
<input type='text' id='dob' name='dob' />

Format instructions present for a date field — Correct

<!-- Format instruction is visible and linked via aria-describedby
     so screen readers announce it when the field receives focus. -->
<label for='dob'>Date of birth</label>
<span id='dob-hint'>Enter as DD/MM/YYYY, e.g. 15/06/1990</span>
<input type='text' id='dob' name='dob' aria-describedby='dob-hint' />

Common Mistakes

• Using placeholder as the sole label: Placeholder text disappears on input, is not reliably announced as a label by all screen readers, and fails users with cognitive disabilities who need persistent reference text. Always provide a visible <label> in addition to any placeholder.
• Visually positioning a label near a field without a programmatic association: A <p> or <span> placed visually above an input looks like a label to sighted users but is ignored by screen readers. Use <label for='id'>, aria-labelledby, or wrap the input inside a <label> element.
• Using aria-label with text that does not match the visible label: When the programmatic accessible name differs from the visible text, voice control users cannot activate the field by speaking what they read on screen, violating SC 2.5.3 (Label in Name) as well as creating confusion for screen reader users.
• Labeling a group of radio buttons but omitting the group legend: Individual radio buttons may each be labeled with their option text, but if the overarching question (e.g., "Payment method") is not provided via a <fieldset> and <legend>, users navigating by keyboard hear each option in isolation without understanding what they are choosing between.
• Identifying required fields by color or asterisk alone without explanation: An asterisk (*) next to a label conveys nothing to screen reader users unless its meaning is explained (e.g., a note at the top of the form stating "Fields marked with * are required") and required fields also carry the required or aria-required='true' attribute.
• Omitting format instructions until after a failed submission: Showing password rules or date format requirements only in post-submission error messages forces users to make a mistake before they can learn what is expected. Instructions must be present before or at the time the user interacts with the field.
• Hiding labels using display:none or visibility:hidden: These CSS properties remove labels from the accessibility tree entirely. If a label must be visually hidden (e.g., for a minimal design), use a visually-hidden CSS class that keeps the element in the accessibility tree while moving it off-screen.
• Using the title attribute as the only label and assuming it is sufficient: While axe-core may not flag a title-only label, the title attribute appears only as a tooltip on hover and is inaccessible to keyboard-only users and mobile users. It should be used as supplementary description, not as a primary label.
• Applying a single aria-label to a container <div> and expecting it to label child inputs: ARIA labels on container elements are not inherited by their child form controls. Each interactive control must be individually labeled.
• Failing to re-associate labels after dynamic content updates: When form fields are injected dynamically via JavaScript (e.g., adding an address row), newly inserted inputs often lack associated labels because the developer only added the visible label text as a sibling element without the proper for/id binding.

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 web accessibility requirements aligned with WCAG 2.2. WCAG Success Criterion 3.3.2 — Labels or Instructions is a Level A requirement, meaning it sits at the baseline of conformance and is among the most strictly enforced provisions under the circular.

The circular covers a broad range of entity types, and compliance timelines differ by sector. Public institutions — including ministries, municipalities, state agencies, and publicly funded organizations — must achieve full Level A conformance within one year of the circular's publication. Private sector entities within scope must comply within two years. The private sector entities explicitly covered include e-commerce platforms, banks and financial institutions, hospitals and private healthcare providers, telecommunications companies with 200,000 or more subscribers, travel agencies, private transportation companies, and private schools authorized by the Ministry of National Education (MoNE).

For all of these entities, the failure to label form fields is not merely a usability shortcoming — it constitutes a direct regulatory non-compliance. Forms are pervasive across all covered digital services: citizens submit applications on government portals, patients book appointments on hospital websites, customers complete purchases on e-commerce platforms, and students enroll through school portals. Every one of these journeys relies on forms, and every unlabeled field in those forms is a demonstrable WCAG 3.3.2 violation that auditors can document and report.

Organizations subject to the circular should treat SC 3.3.2 compliance as a prerequisite for any accessibility audit or certification process. Because this is a Level A criterion, it cannot be waived or deferred — partial conformance claims that exclude Level A items are not recognized. Entities that cannot demonstrate labeled inputs across all their public-facing forms risk regulatory findings, public reporting of non-compliance, and reputational damage in a market where digital trust is increasingly linked to inclusive design.

From a practical standpoint, achieving 3.3.2 compliance is among the lowest-effort, highest-impact steps an organization can take. Associating labels with existing form controls typically requires only minor HTML changes and has no effect on visual design when implemented correctly. For organizations using Accsible's overlay SDK, automated detection of missing labels can surface these violations during routine scanning, providing development teams with actionable remediation guidance before regulatory deadlines arrive.