Accept form autofill purpose and section identity

Separate purpose from input type and observed convenience

W3C’s WCAG 2.2 understanding guidance, checked 7 November 2026, distinguishes programmatically identified input purpose from broad input type and from whether a browser happens to autofill. Its scope concerns applicable inputs collecting information about the user. A browser’s heuristic guess is not equivalent to a correctly exposed purpose, and this narrow review is not a full accessibility audit.

Inventory the form’s actual task and identify whose information each field requests. A contact address for the visitor differs from a referral contact belonging to someone else. Keep required and optional fields visible, but do not add personal-data collection merely to make the taxonomy easier to apply. Record fields outside the criterion’s scope instead of forcing every business identifier into a personal-data purpose.

Map purpose and repeated groups deliberately

The WHATWG HTML Living Standard defines ordered autocomplete detail tokens, including an optional named section, optional shipping or billing context and a supported field-purpose token. Section names group fields; their arbitrary names are not semantic instructions about a person. Check the current standard and implemented control rather than inventing token syntax from a visible heading.

Build a field map with visible label, requested subject, control type, programmatic purpose and group. For repeated address blocks, decide which fields describe the same intended address and which describe a separate one. A copied component can accidentally reuse the wrong grouping even though its heading has changed. Have the developer show the delivered attributes, not merely the component’s internal configuration or a design-file annotation.

Test semantics separately from browser behavior

Review the delivered markup against the field map, using the supported purpose vocabulary and token order. Keep that structural check distinct from an observed browser test. A browser may offer a plausible value despite incorrect markup, or decline to autofill a correctly identified field because of its settings or available profile data. Record those outcomes separately so one does not conceal the other.

Use only invented profile information in an approved test environment. Give the repeated groups visibly different synthetic values so accidental cross-population is easy to notice. Check entry, correction and return to the form without submitting to a live endpoint. Do not enable persistent personal-data storage, use actual customer information or alter browser security settings to make the demonstration work. Any unsupported behavior becomes a documented limitation for the implementation owner.

Preserve user control and the receiving meaning

Verify that a person can review and correct suggested content before the intended submission. Check the receiving field mapping through a supplied synthetic output where available: the value labeled billing should not arrive as shipping merely because a backend key was copied. This is an end-to-end semantic check, not permission to send a real form or collect unnecessary information.

Retain the field-purpose map, inspected implementation and browser observations with their versions. Recheck copied components and newly added groups after changes. Resolve defects by correcting purpose and grouping, not by assuming every visitor should disable a helpful browser feature. Close the review with an explicit scope: programmatic meaning and tested behavior for the named form, while other accessibility, privacy and validation obligations remain with their respective reviews.

Make the reasoning concrete.

A fictional business-sample form has separate billing and delivery blocks. The headings look correct, but a copied component exposes the same context for both. One browser fills them identically, and the team assumes the user simply has one address.

The team requests a corrected field map and repeats the synthetic comparison without sending the form or saving real profile information.

Take the questions into your next brief.

Use these prompts in your own notes. Nothing is submitted from this page.

1. Subject

   Whose information does each field actually request?

2. Purpose

   Which supported programmatic purpose matches that request?

3. Group

   Which controls describe the same address or distinct repeated section?

4. Evidence

   What does markup inspection establish separately from observed autofill?

5. Control

   Can the person review and correct the value before submission?

Watch for the wrong conclusion.

• Equating a broad email input type with a precise user-data purpose.
• Accepting browser guesses as semantic conformance.
• Copying repeated groups without reviewing their context.

Sources & scope

Workflows, fixtures, worksheets and examples are original editorial analysis. Sources support the narrow attributed statements, not measured business results. Platform guidance is scoped to the documented implementation and date checked. Synthetic offline acceptance only; no real redaction, signing, trust change, transmission or account operation is performed.

• Understanding SC 1.3.5 Identify Input Purpose (Level AA) →Primary technical documentation · Supports: Supports the scoped distinction between purpose, type and observed autofill. The field map and fixture are original.
• HTML Living Standard: Autofilling form controls: the autocomplete attribute →Primary technical documentation · Supports: Supports ordered detail tokens, group context and opaque section names; not identical autofill across browsers.