Cooperating With the Browser: A Field Method for Auditing Autofill in UK Online Forms

A council tax form, an energy switch, a checkout for a routine purchase: each asks for information the user has supplied a hundred times before. In principle, the browser or password manager should fill it in within seconds. In practice, many UK services interrupt that handshake — disabling autocomplete, splitting fields in unusual ways, rejecting pasted values or replacing native inputs with custom widgets that assistive technology cannot interpret. The result is not a minor inconvenience. It is a measurable tax on people who are older, disabled, using a second language or simply short of time.

Why the browser is a reasonable user

Autofill is not a novelty feature. It is the default behaviour of every mainstream browser and a core function of password managers that millions of UK households rely on. When a form refuses to cooperate, the user is asked to do work the software was ready to do for them. That request lands hardest on people with motor impairments, memory conditions, dyslexia or low vision, and on anyone completing a task on a phone in a hurry.

Product teams rarely set out to block these tools. The causes are usually well-intentioned: a developer disables autocomplete to stop sensitive data being cached; a designer builds a bespoke postcode lookup; a security review insists on paste blocks. Each decision has a rationale. The audit question is whether the rationale survives contact with the people the form is meant to serve.

What working autofill actually means

A form cooperates when three things hold. First, the markup describes each field honestly, using the correct HTML autocomplete tokens and input types so the browser knows what it is being offered. Second, the flow allows values to arrive by any reasonable route: typing, pasting, password manager injection or address lookup. Third, the result is visible and correctable, with errors that explain what went wrong rather than simply clearing the field.

This is not only a convenience matter. WCAG 2.2 success criterion 1.3.5 identifies the purpose of input fields, and the GOV.UK Design System offers well-tested patterns for names, addresses and dates. A form that ignores these conventions is not innovative; it is asking users to compensate for a design decision they did not make.

A repeatable test matrix

Run the same scripted journey across a fixed set of combinations, and record the result for every field. A workable matrix for most UK services is:

• Desktop: Chrome, Edge, Safari and Firefox on Windows and macOS.
• Mobile: Safari on iOS and Chrome on Android, on both a recent and an older handset where available.
• Password managers: the browser's built-in manager, plus at least one third-party manager such as 1Password or Bitwarden.
• Assistive technology: VoiceOver on iOS, TalkBack on Android, and NVDA or JAWS on desktop.
• Address routes: native autofill, a postcode lookup, and manual entry as a fallback.
• Authentication: saved credentials, passkeys where offered, and one-time codes delivered by SMS and email.

Use a synthetic test identity rather than a colleague's real details, and repeat the journey twice: once as a first-time user, once as a returning user with saved data. The second pass matters because many faults only appear when stored values are offered back.

Faults we keep finding

Certain patterns recur across UK checkout, council and utility forms. Autocomplete is switched off on the whole form rather than on genuinely sensitive fields. A single full-name input is used where first and last name tokens are expected, so the password manager fills the wrong part. Date of birth is built from three unlabelled selects that neither autofill nor a screen reader can populate reliably. Postcode lookup works, but the manual address option is hidden behind a link that only appears after a failed search. One-time code fields reject paste, penalising anyone using a password manager or a screen reader. Custom comboboxes announce themselves as generic text boxes and drop the value when the page re-renders.

Each fault is small in isolation. Together they turn a two-minute task into a manual re-entry exercise, and they do so unevenly, which is precisely the accessibility problem.

Recording the cost

Score each field as pass, partial or fail, and note the extra time and keystrokes required to recover. A simple severity scale helps: cosmetic friction, recoverable failure, and blocking failure where the user cannot proceed without abandoning their saved data or switching tools. Capture a short screen recording of any blocking failure, because these issues are far more persuasive when a product owner can see the field being cleared.

A fix checklist for product teams

1. Audit every input against the HTML autocomplete specification and correct the tokens field by field.
2. Allow paste everywhere, including one-time codes, and explain any genuine security exception in plain language.
3. Keep native inputs wherever possible; if a custom component is unavoidable, expose the correct role, name and value to assistive technology.
4. Provide a visible manual address route alongside postcode lookup, not as a hidden fallback.
5. Test with saved credentials and stored form data, not only with a clean browser profile.
6. Include autofill and password manager checks in the definition of done for every form change.
7. Re-run the matrix after any redesign of the checkout, account or application journey.

None of this requires new technology. It requires accepting that the browser and the password manager are part of the user's team, not obstacles to be managed. A form that cooperates with them is faster, more accessible and more likely to be completed. In 2026, that is a reasonable baseline for any UK service asking for information it has already been given.