In each form, are each field label and its associated field placed next to each other (except in special cases)?

A visually impaired user who zooms to 200% sees only a reduced portion of the screen. If a field's label is three lines away from that field, the visual connection breaks: they no longer know which label corresponds to which input. This criterion requires that each visible label be directly adjacent to the field it describes.

The positioning rule varies depending on field type. For text fields, dropdowns, text areas, and any element that is neither a checkbox nor a radio button: the label is placed immediately above or to the left of the field (in French, a language read left-to-right). For checkboxes and radio buttons: the convention reverses — the label is placed immediately to the right or below. It's the exact opposite.

This criterion only applies if the label is visible. If you hide the label with a sr-only or visually-hidden class, criterion 11.4 is not applicable for that field. Programmatic association, however, remains mandatory via criterion 11.1.

No element between the label and the field. Truly none. A help text, a decorative icon, a link placed between the two is enough to break the required adjacency.

3 tests to confirm that each label is visually attached to its field

Visual alignment between label and field

For each form field in the document:

  1. Identify the label associated with the field (via <label>, aria-label, aria-labelledby, or title).
  2. Verify that the visible label and the field are directly adjacent, visually and in the DOM — no element between the two.
  3. If all fields have their label adjacent, the test is validated.

Label position for text fields and lists

This test concerns all fields except <input type="checkbox">, <input type="radio">, and elements with role="checkbox", role="radio", or role="switch".

For each field in scope:

  1. Locate the visible label of the field.
  2. Check its visual position according to the label's language:
    • Left-to-right language (French, English…): the label must be immediately above or to the left of the field.
    • Right-to-left language (Arabic, Hebrew…): the label must be immediately below or to the right of the field.
  3. If all fields respect this position, the test is validated.

The test is not applicable if the label mixes opposite reading directions, or if the UX context justifies a different position (see edge cases).

Label position for <input type=checkbox> and radio

This test concerns only <input type="checkbox">, <input type="radio">, and elements with role="checkbox", role="radio", or role="switch".

For each field in scope:

  1. Locate the visible label of the field.
  2. Check its visual position according to the label's language:
    • Left-to-right language (French, English…): the label must be immediately below or to the right of the checkbox or radio button.
    • Right-to-left language (Arabic, Hebrew…): the label must be immediately below or to the left.
  3. If all fields respect this position, the test is validated.

The test is not applicable if the checkbox or radio button is not presented visually as such (custom widget, styled toggle), or if the UX context justifies a different position.

Examples

❌ Non-compliant : Help text inserted between label and field

<div class="form-group">
  <label for="email">Email address</label>
  <p class="hint">Use your work email address.</p>
  <input type="email" id="email" name="email">
</div>

The help paragraph comes between the <label> and the <input>. The label is no longer visually adjacent to the field. For a user zoomed to 200%, the label may have scrolled off-screen by the time the input is visible.

✅ Compliant : Help text moved after the field

<div class="form-group">
  <label for="email">Email address</label>
  <input type="email" id="email" name="email" aria-describedby="email-hint">
  <p id="email-hint" class="hint">Use your work email address.</p>
</div>

The label directly precedes the field, with no interposed element. The help text is moved after the <input> and linked via aria-describedby — it remains accessible to screen readers without breaking the required proximity between label and field.

❌ Non-compliant : Checkbox label positioned on the left

<div class="form-check">
  <label for="cgu">I accept the terms of use</label>
  <input type="checkbox" id="cgu" name="cgu">
</div>

For a checkbox in French (left-to-right language), the label must be to the right or below the checkbox. Here it is on the left — the opposite of expected positioning. Test 11.4.3 fails.

✅ Compliant : Checkbox label correctly positioned on the right

<div class="form-check">
  <input type="checkbox" id="cgu" name="cgu">
  <label for="cgu">I accept the terms of use</label>
</div>

The checkbox precedes its label in the DOM, and the label appears visually to the right of the checkbox. This is the standard convention for binary controls: control first, label second. Compliant with test 11.4.3.

Tips and pitfalls

⚠️ Help text between label and field: the number one audit error

This is the most frequent non-compliance found for this criterion. A <p class="hint">, a <span> with a character counter, or an information icon placed between the <label> and the <input> breaks adjacency. The fix is simple: move these elements after the field and link them via aria-describedby. Two problems solved at once: 11.4 compliance and screen reader accessibility.

💡 Hidden label = criterion 11.4 not applicable

If your label is hidden visually via sr-only or visually-hidden, visual proximity no longer applies. Criterion 11.4 is then not applicable for that field. Programmatic association, however, remains mandatory and is evaluated by criterion 11.1. Do not confuse inapplicability with compliance: 11.4 inapplicable does not validate 11.4.

⚠️ Forms with bidirectional or multilingual text

Tests 11.4.2 and 11.4.3 are not applicable when a label mixes portions of text with opposite reading directions (left-to-right and right-to-left within a single label), or when a form contains labels in multiple languages whose reading directions reverse. An order form in Arabic offering a product list with French labels illustrates this case. Explicitly note inapplicability and its justification in your audit report.

⚠️ Checkboxes and radio buttons no longer in their standard form

Test 11.4.3 applies to elements visually presented as checkboxes or radio buttons. If a <input type="checkbox"> is styled as a toggle button, a filter chip, or a selectable card, test 11.4.3 is not applicable. The right/below positioning rule targets controls recognizable as such, not fully customized widgets.

⚠️ The legitimate UX exception: use sparingly

The RGAA allows exemption when it would be legitimate, from a user experience standpoint, to place the label differently than prescribed by tests 11.4.2 and 11.4.3. This exception is intentionally broad and should be used sparingly. An inline search form or newsletter field does not qualify. However, a date-picker component with constrained layout, or a form embedded in a business application interface with strong space constraints, may qualify. Always document the justification.

⚠️ Placeholder without visible label: neither 11.1 nor 11.4 are satisfied

A field with only a placeholder and no visible <label> fails criterion 11.1 (no label). If you add a hidden label to fix 11.1, criterion 11.4 becomes not applicable — there is no longer a visible label to adjacent. This is not validation of 11.4, it is inapplicability. Only a visible and adjacent label satisfies both criteria simultaneously.

Frequently asked questions

How does RGAA criterion 11.4 apply to visually hidden labels?

It does not. Criterion 11.4 measures visual proximity between a visible label and its field. If the label is hidden via sr-only, visually-hidden, or any equivalent technique, there is no visible label to evaluate: the criterion is not applicable. Programmatic association remains evaluated by criterion 11.1, which is always applicable.

How do you visually audit RGAA criterion 11.4 and what elements should you check?

Two verifications: (1) that no element comes between the label and the field, and (2) that the position respects the convention according to field type. For text fields, the label is above or to the left. For checkboxes and radio buttons, the label is to the right or below. Enable browser zoom to 200% to simulate a visually impaired user: if the label disappears while entering data, proximity is insufficient.

Why does a label positioned to the right of a field violate RGAA criterion 11.4?

For a standard text field in French, a label on the right is non-compliant with test 11.4.2. The label must be immediately above or to the left. The layout "Label: [Field]" on the same line is compliant if the label is on the left, with no interposed element between the two.

In which contexts are RGAA tests 11.4.2 and 11.4.3 applicable?

No, four situations render them not applicable: (1) label mixing left-to-right and right-to-left reading directions within a single label, (2) form with labels in multiple languages whose reading directions reverse, (3) checkboxes or radio buttons not presented visually as such, (4) UX context where a different position is legitimate and justifiable. In all these cases, note inapplicability in your report.

Which ARIA components like role="switch" are covered by RGAA criterion 11.4?

Yes, partially. Elements with role="checkbox", role="radio", or role="switch" are explicitly covered by test 11.4.3: their label must be immediately to the right or below (in French). Other form ARIA roles (role="combobox", role="spinbutton"…) fall under test 11.4.2 by analogy with text fields. Adjacency is always assessed visually.

References

RGAA 4.1.2: Criterion 11.4
WCAG 2.1:3.3.2 (A)G1623.3.2 (A)