Position labels where users expect them
G162 is about where the label sits. In left-to-right languages that means directly before the field, either to its left or above it, and after the field for checkboxes and radio buttons. Those positions are conventional, which is the entire argument for them, and putting labels before the input also lets them line up in a column that a magnifier user can follow. Status varies by rule, so read it before you file the finding. W3C lists this as sufficient for 3.3.2 Labels or Instructions at Level A only when it is used together with the technique that makes labels descriptive, since a well-placed label that says nothing is no help. At the structure rule it is advisory rather than sufficient, and it is advisory again at the Level A rule about the visible label matching the accessible name.
How we find it in an audit
Our reviewers work through forms at high magnification, where ambiguous spacing becomes obvious in a way it never is at normal size. Equal gaps above and below a field make ownership a coin flip. Checkbox and radio labels get checked separately. They follow the opposite convention and get flipped often.
How affected users experience it
Someone using screen magnification sees a few fields at a time, without the overview that makes a form's grouping obvious. If the label could belong to the field above or the field below, they have to zoom out to check and zoom back in to type, on every field. Predictable positions remove that trip entirely. Programmatic association still matters underneath, because position is a visual cue and a screen reader reads the association.
Passes vs. fails
Passes
Text-field labels sit directly above their fields, and checkbox and radio labels sit immediately to the right, exactly where readers expect them.
Fails
Labels float in a grid with equal spacing above and below each field, so under magnification it is a coin flip which label owns which box.
How this gets tested
The W3C publishes test rules that define what a checker looks for here.
- ARIA attribute is defined in WAI-ARIAA tool can check this
- ARIA state or property has valid valueA tool can check this
- Element with role attribute has required states and propertiesA tool can check this
- Form field has non-empty accessible nameA tool can check this
- Headers attribute specified on a cell refers to cells in the same table elementA tool can check this
- Role attribute has valid valueA tool can check this
- ARIA global properties not used where prohibitedA tool can check this
- ARIA required context roleA tool can check this
- ARIA required owned elementsA tool can check this
- ARIA state or property is permittedA tool can check this
- Table header cell has assigned cellsA tool can check this
- Visible label is part of accessible nameNothing implements this yet
The other techniques filed under this rule
52 guides on this site are filed under 1.3.1 Info and Relationships. W3C lists this one as advisory for that rule rather than sufficient, which means it helps real readers without being accepted as evidence you conformed.
- ARIA11sufficientAdd landmarks so users can skip around
- ARIA12sufficientUse role=heading when h1-h6 is impossible
- ARIA13sufficientName repeated landmarks so they are distinguishable
- ARIA16sufficientName controls from visible text with aria-labelledby
- ARIA17sufficientGroup related form fields with ARIA roles
- ARIA20sufficientMark leftover page areas with role=region
This guide is our interpretation of W3C technique G162: Positioning labels to maximize predictability of relationships. W3C publishes its techniques as guidance rather than as the standard, and says so on every one of them. The success criterion is what conformance is measured against, and a technique is one documented way to meet it.