# Accessible Forms

Labels, error handling, autocomplete, input purpose, predictable behavior, authentication.

## Criteria

| Standard | Criteria                                                                                                                                                                                                                                                                                        |
| -------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| WCAG 2.2 | 1.3.5 Identify Input Purpose (AA), 2.5.3 Label in Name (A), 3.2.1 On Focus (A), 3.2.2 On Input (A), 3.3.1 Error Identification (A), 3.3.2 Labels or Instructions (A), 3.3.3 Error Suggestion (AA), 3.3.4 Error Prevention (AA), 3.3.7 Redundant Entry (A), 3.3.8 Accessible Authentication (AA) |
| RGAA 4.1 | 11.1 Labels, 11.2 Label relevance, 11.3 Label consistency, 11.4 Label proximity, 11.5 Field grouping, 11.6 Group legend, 11.7 Legend relevance, 11.8 Select grouping, 11.9 Button labels, 11.10 Input control, 11.11 Error suggestions, 11.12 Error prevention, 11.13 Autocomplete              |

---

## RGAA 11.1 — Form field labels (A)

Does each form field have a label?

WCAG: 1.3.1 (A), 2.4.6 (AA), 3.3.2 (A), 4.1.2 (A)

### Test 11.1.1

Each form field meets one of these conditions:

- Has `aria-labelledby` referencing an identified text passage
- Has `aria-label`
- Has an associated `<label>` with `for` attribute
- Has a `title` attribute
- An adjacent button provides a visible label AND a visually hidden `<label>`, `aria-label`, `aria-labelledby`, or `title` provides an accessible name

**Methodology:**

1. Find all form fields in the document
2. For each field, verify at least one of the above conditions is met
3. If true for every field, test passes

### Test 11.1.2

Each form field associated with a `<label>` having a `for` attribute meets these conditions:

- The form field has an `id` attribute
- The `for` value equals the field's `id` value

**Methodology:**

1. Find all form fields associated with a `<label>` element
2. For each field, verify the field has an `id` and the `for` value matches
3. If true for every field, test passes

### Test 11.1.3

Each form field whose label is not visible or not adjacent (hidden, `aria-label`) or not contiguous (`aria-labelledby`) meets one of these conditions:

- Has a `title` attribute whose content conveys the expected input
- Is accompanied by an adjacent text passage that becomes visible on focus, conveying the expected input
- Is accompanied by a visible adjacent text passage conveying the expected input

**Methodology:**

1. Find fields whose label is not visible/adjacent (hidden, `aria-label`) or not contiguous (`aria-labelledby`)
2. For each field, verify at least one condition above is met

---

## RGAA 11.2 — Label relevance (A)

Is each label associated with a form field relevant? (Special cases apply)

WCAG: 2.4.6 (AA), 2.5.3 (A), 3.3.2 (A)

### Test 11.2.1

Each `<label>` conveys the exact function of its associated form field.

**Methodology:**

1. Find fields whose label is provided by a `<label>` element
2. Verify the content is relevant (describes the expected input)
3. If true for every field, test passes

### Test 11.2.2

Each `title` attribute conveys the exact function of its associated form field.

**Methodology:**

1. Find fields whose label is provided by a `title` attribute
2. Verify the content is relevant
3. If true for every field, test passes

### Test 11.2.3

Each `aria-label` attribute conveys the exact function of its associated form field.

**Methodology:**

1. Find fields whose label is provided by `aria-label`
2. Verify the content is relevant
3. If true for every field, test passes

### Test 11.2.4

Each text passage referenced via `aria-labelledby` conveys the exact function of its associated form field.

**Methodology:**

1. Find fields whose label is provided by `aria-labelledby`
2. Verify the referenced text passage content is relevant
3. If true for every field, test passes

### Test 11.2.5

Each form field with a visible label meets these conditions (special cases apply):

- If present, `aria-label` contains at least the visible label text
- If present, `aria-labelledby` text passage contains at least the visible label text
- If present, `title` contains at least the visible label text
- If present, `<label>` content contains at least the visible label text

**Methodology:**

1. Find fields with both a visible label and a `<label>`, `title`, `aria-label`, or `aria-labelledby`
2. Verify the accessible name contains the visible label text
3. If true for every field, test passes

### Test 11.2.6

Each adjacent button providing a visible label conveys the exact function of the associated form field.

**Methodology:**

1. Find fields whose visible label is provided by an adjacent button
2. Verify the button's visible content is relevant
3. If true for every field, test passes

### Cas particuliers (11.2)

For test 11.2.5:

- Punctuation and uppercase in the visible label may be ignored in the accessible name
- If the visible label text serves as a symbol (e.g. "B" for bold in an editor), the accessible name must express the function (e.g. "Mettre en gras"), not the literal character. Exception: mathematical symbols may be used literally (e.g. "A>B")

This also applies to test 11.9.2.

---

## RGAA 11.3 — Label consistency (AA)

Are labels for fields with the same function consistent across a page or set of pages?

WCAG: 3.2.4 (AA)

### Test 11.3.1

Labels for fields with the same function repeated on the same page are consistent.

**Methodology:**

1. Find form fields with the same function on the page (e.g. multiple address fields)
2. Verify labels are consistent (convey identical input nature)
3. If true for every field, test passes

### Test 11.3.2

Labels for fields with the same function repeated across a set of pages are consistent.

**Methodology:**

1. Find form fields with the same function across the page set (e.g. search field, newsletter signup)
2. Verify labels are consistent across all pages
3. If true for every field across all pages, test passes

---

## RGAA 11.4 — Label proximity (A)

Are labels and their associated fields visually adjacent? (Special cases apply)

WCAG: 3.3.2 (A)

### Test 11.4.1

Each label and its associated form field are visually adjacent.

**Methodology:**

1. Find all form fields
2. Verify each field is adjacent to its label
3. If true for every field, test passes

### Test 11.4.2

For fields that are NOT checkboxes, radios, or elements with `role="checkbox"`, `role="radio"`, or `role="switch"`, the label is visually adjacent:

- Immediately above or to the left (LTR languages)
- Immediately above or to the right (RTL languages)

**Methodology:**

1. Find fields excluding `<input type="checkbox">`, `<input type="radio">`, and elements with `role="checkbox"`, `role="radio"`, `role="switch"`
2. Verify label placement per reading direction rules above
3. If true for every field, test passes

### Test 11.4.3

For checkboxes, radios, and elements with `role="checkbox"`, `role="radio"`, or `role="switch"`, the label is visually adjacent:

- Immediately below or to the right (LTR languages)
- Immediately below or to the left (RTL languages)

**Methodology:**

1. Find `<input type="checkbox">`, `<input type="radio">`, and elements with `role="checkbox"`, `role="radio"`, `role="switch"`
2. Verify label placement per reading direction rules above
3. If true for every field, test passes

### Cas particuliers (11.4)

Tests 11.4.2 and 11.4.3 are not applicable when:

- The label mixes LTR and RTL text
- The form has labels in multiple languages with opposing reading directions
- Checkboxes/radios/switches are not visually presented as standard checkbox/radio controls
- Fields are used in a context where a different label placement is legitimately better for UX

---

## RGAA 11.5 — Field grouping (A)

Are related fields grouped when necessary?

WCAG: 1.3.1 (A), 3.3.2 (A)

### Test 11.5.1

Related fields meet one of these conditions:

- Grouped in a `<fieldset>`
- Grouped in an element with `role="group"`
- Radio inputs (or `role="radio"`) grouped in an element with `role="radiogroup"` or `role="group"`

**Methodology:**

1. Find groups of related fields (e.g. identity info, checkbox series, multi-field date)
2. Verify they are grouped using `<fieldset>`, `role="group"`, or `role="radiogroup"`
3. If true for every group, test passes

---

## RGAA 11.6 — Group legend (A)

Does each grouping of related fields have a legend?

WCAG: 1.3.1 (A), 3.3.2 (A)

### Test 11.6.1

Each grouping of related fields has a legend:

- If `<fieldset>`, it contains a `<legend>`
- If `role="group"` or `role="radiogroup"`, it has `aria-label` or `aria-labelledby`
- Otherwise, each field in the group has a `title`, `aria-label`, `aria-labelledby`, or `aria-describedby` that indicates group membership

**Methodology:**

1. Find groups of related fields
2. Verify legend presence per mechanism above
3. If true for every group (or every field in the group), test passes

---

## RGAA 11.7 — Legend relevance (A)

Is each legend associated with a grouping of related fields relevant?

WCAG: 1.3.1 (A), 3.3.2 (A)

### Test 11.7.1

Each legend text is relevant (describes the group purpose).

**Methodology:**

1. Find groups of related fields
2. For each group (or field) with a legend, verify the legend text is relevant
3. If true for every group, test passes

---

## RGAA 11.8 — Select option grouping (A)

Are items of the same nature in a select list grouped appropriately?

WCAG: 1.3.1 (A)

### Test 11.8.1

For each `<select>`, items of the same nature are grouped with `<optgroup>` when necessary.

**Methodology:**

1. Find `<select>` elements
2. For each select with groups of same-nature items, verify `<optgroup>` is used
3. If true for every select, test passes

### Test 11.8.2

Each `<optgroup>` has a `label` attribute.

**Methodology:**

1. Find `<select>` elements containing `<optgroup>`
2. Verify each `<optgroup>` has a `label` attribute
3. If true for every `<optgroup>`, test passes

### Test 11.8.3

Each `<optgroup>` `label` attribute content is relevant.

**Methodology:**

1. Find `<select>` elements containing `<optgroup>` with `label`
2. Verify each `label` content is relevant
3. If true for every `<optgroup>`, test passes

### Notes techniques (11.8)

A `role="listbox"` element can replace `<select>`, but WAI-ARIA cannot create option groups. A list requiring grouped options that uses `role="listbox"` will be considered non-conformant to criterion 11.8.

---

## RGAA 11.9 — Button label relevance (A)

Is each form button label relevant? (Special cases apply)

WCAG: 2.5.3 (A), 4.1.2 (A)

### Test 11.9.1

Each button label meets these conditions (special cases apply):

- If present, `aria-label` is relevant
- If present, `aria-labelledby` text passage is relevant
- If present, `value` of `<input type="submit|reset|button">` is relevant
- If present, `<button>` content is relevant
- If present, `alt` of `<input type="image">` is relevant
- If present, `title` is relevant

**Methodology:**

1. Find all buttons within forms
2. Verify the visible label and accessible name are relevant
3. If true for every button, test passes

### Test 11.9.2

Each button with a visible label meets these conditions (special cases apply):

- If present, `aria-label` contains at least the visible label
- If present, `aria-labelledby` text contains at least the visible label
- If present, `value` of `<input type="submit|reset|button">` contains at least the visible label
- If present, `<button>` content contains at least the visible label
- If present, `alt` of `<input type="image">` contains at least the visible label
- If present, `title` contains at least the visible label

**Methodology:**

1. Find all buttons within forms
2. Verify the accessible name contains at least the visible label
3. If true for every button, test passes

### Cas particuliers (11.9)

For test 11.9.2, see special cases for criterion 11.2 (punctuation, uppercase, symbol labels).

---

## RGAA 11.10 — Input control (A)

Is input control used appropriately? (Special cases apply)

WCAG: 3.3.1 (A), 3.3.2 (A)

### Test 11.10.1

Required field indicators meet one of these conditions (special cases apply):

- A visible indication of the required nature identifies the field by name, prior to form submission
- The field has `aria-required="true"` or `required` prior to form submission

**Methodology:**

1. Find required form fields
2. Verify that before submission, either a visible indication names the field, or the field has `aria-required="true"` / `required`
3. If true for every required field, test passes

### Test 11.10.2

Required fields with `aria-required="true"` or `required` meet one of these conditions:

- A visible required-field indication is in the associated label, prior to submission
- A visible required-field indication is in the associated text passage, prior to submission

**Methodology:**

1. Find required fields with `aria-required="true"` or `required`
2. Verify a visible required indication is in the label or associated text passage before submission
3. If true for every such field, test passes

### Test 11.10.3

Error messages for missing required field input meet one of these conditions:

- The error message is visible and identifies the field by name
- The required field has `aria-invalid="true"`

**Methodology:**

1. Find error messages for missing required field input
2. Verify either the message is visible and names the field, or the field has `aria-invalid="true"`
3. If true for every such error message, test passes

### Test 11.10.4

Required fields with `aria-invalid="true"` meet one of these conditions:

- The error message indicating invalid input is visible and in the associated label
- The error message indicating invalid input is visible and in the associated text passage

**Methodology:**

1. Find required fields with `aria-invalid="true"`
2. Verify the error message is visible in the label or in the associated text passage
3. If true for every such field, test passes

### Test 11.10.5

Instructions/indications for required data types and/or formats meet one of these conditions:

- A visible instruction/indication identifies the field by name, prior to submission
- A visible instruction/indication is in the label or associated text passage, prior to submission

**Methodology:**

1. Find required fields with data type/format instructions
2. Verify the instruction is visible and either names the field or is in the label/text passage, before submission
3. If true for every such field, test passes

### Test 11.10.6

Error messages providing data type/format instructions meet one of these conditions:

- The error message is visible and identifies the field
- The field has `aria-invalid="true"`

**Methodology:**

1. Find error messages providing data type/format instructions
2. Verify either the message is visible and names the field, or the field has `aria-invalid="true"`
3. If true for every such error message, test passes

### Test 11.10.7

Fields with `aria-invalid="true"` requiring a specific data type/format meet one of these conditions:

- A data type/format instruction is visible in the associated `<label>`
- A data type/format instruction is visible in the associated text passage

**Methodology:**

1. Find fields with `aria-invalid="true"`
2. Verify a type/format instruction is visible in the `<label>` or associated text passage
3. If true for every such field, test passes

### Cas particuliers (11.10)

Tests 11.10.1 and 11.10.2 are not applicable when:

- The form has a single field, or
- Optional fields are explicitly indicated visually AND in the `<label>` or associated legend

When ALL fields are required, tests 11.10.1 and 11.10.2 remain applicable.

### Notes techniques (11.10)

In a long form where most fields are required, the few optional fields may be marked instead. Ensure:

- A visible message at the top states "All fields are required except those indicated as optional"
- A visible "optional" mention appears in the label or legend of optional fields
- `required` or `aria-required="true"` remains on every non-optional field

---

## RGAA 11.11 — Error suggestions (AA)

Are input errors accompanied by suggestions to help correction?

WCAG: 3.3.3 (AA)

### Test 11.11.1

For each input error, are expected data types and formats suggested when necessary?

**Methodology:**

1. Find error messages in the document
2. Verify expected data types and formats are suggested
3. If true for every error message, test passes

### Test 11.11.2

For each input error, are examples of expected values suggested when necessary?

**Methodology:**

1. Find error messages in the document
2. Verify examples of expected values are suggested
3. If true for every error message, test passes

### Notes techniques (11.11)

Some HTML5 input types provide automatic help messages (e.g. `type="email"` shows "Please enter a valid email"). These can be customized via the Constraint Validation API, which satisfies this criterion. The `pattern` attribute performs automatic format checks via regex and shows a customizable message via the `title` attribute, also satisfying the criterion.

---

## RGAA 11.12 — Error prevention for critical submissions (AA)

For forms that modify/delete data, submit test/exam answers, or have financial/legal consequences, can the user modify, update, or recover entered data?

WCAG: 3.3.4 (AA)

### Test 11.12.1

For each such form, data entry meets one of these conditions:

- The user can modify or cancel data and actions after submission
- The user can verify and correct data before final submission in a multi-step form
- An explicit confirmation mechanism (checkbox via `<input type="checkbox">` or `role="checkbox"`, or additional step) is present

**Methodology:**

1. Find forms that modify/delete data, submit test/exam answers, or have financial/legal consequences
2. Verify at least one condition above is met
3. If true for every such form, test passes

### Test 11.12.2

Each form whose validation modifies or deletes financial, legal, or personal data meets one of these conditions:

- A mechanism allows recovery of deleted or modified data
- An explicit confirmation mechanism (form field or additional step) is provided for the deletion/modification

**Methodology:**

1. Find forms that modify/delete financial, legal, or personal data
2. Verify either a recovery mechanism or an explicit confirmation mechanism exists
3. If true for every such form, test passes

---

## RGAA 11.13 — Autocomplete / Identify input purpose (AA)

Can the purpose of form fields be programmatically determined to enable autofill?

WCAG: 1.3.5 (AA)

### Test 11.13.1

Each form field relating to user information meets these conditions:

- The field has an `autocomplete` attribute
- The `autocomplete` value is from the list of valid autocomplete values
- The `autocomplete` value is relevant to the expected information type

**Methodology:**

1. Find form fields relating to user info (name, phone, email, etc.)
2. Verify the field has `autocomplete` with a valid, relevant value
3. If true for every such field, test passes

### Notes techniques (11.13)

The list of valid `autocomplete` values comes from the WCAG 2.1 specification, which mirrors the HTML5.2 "field name" values. Only one "field name" value is allowed per `autocomplete` attribute, but it may be combined with "scope" and "hint set" values (e.g. `autocomplete="shipping name"` or `autocomplete="section-software shipping street-address"`).

---

## WCAG-only criteria (no direct RGAA 11.x mapping)

### On Focus — WCAG 3.2.1 (A)

Receiving focus must not cause context change. No navigation, popup, or form submission on focus alone.

### On Input — WCAG 3.2.2 (A)

Changing a setting must not automatically trigger navigation or form submission. Require explicit user action (submit button).

### Redundant Entry — WCAG 3.3.7 (A)

Previously entered info must be available for re-use. Don't require re-entry of shipping address for billing. Exceptions: security-sensitive data (passwords, PINs).

### Accessible Authentication — WCAG 3.3.8 (AA)

Authentication must not rely on cognitive function tests. Allowed: username/password with paste, passkeys, biometrics, email/SMS codes with paste. Not allowed without alternative: CAPTCHA requiring recognition, password fields blocking paste.

---

## Patterns

**Always associate labels:**

```html
<label for="email">Email Address</label>
<input type="email" id="email" autocomplete="email" />
```

**Error handling:**

```html
<label for="email">Email <span aria-hidden="true">*</span></label>
<input
  type="email"
  id="email"
  aria-required="true"
  aria-invalid="true"
  aria-describedby="email-error"
/>
<p id="email-error" role="alert">Please enter a valid email (e.g., name@example.com)</p>
```

**Autocomplete:**

```html
<input type="text" autocomplete="name" />
<input type="email" autocomplete="email" />
<input type="tel" autocomplete="tel" />
<input type="text" autocomplete="street-address" />
```

**Field grouping:**

```html
<fieldset>
  <legend>Shipping address</legend>
  <!-- address fields -->
</fieldset>
```

Always use `aria-required` over HTML `required` for better screen reader support.