Checkout fields missing an autocomplete purpose

What goes wrong, and who it shuts out

Most of a WooCommerce checkout is typing. Name, house number, street, town, postcode, email, phone — a browser can fill all of it in a single action, but only if each input declares what it holds. The autocomplete attribute is that declaration. Without it autofill either does nothing at all or drops a value into the wrong box, and the customer types every character by hand.

For most shoppers that is friction. For some it is the end of the order:

• A customer with a hand tremor or arthritis, for whom a long address line is a minute of corrections and a postcode that fails validation twice.
• Someone using switch access or a head pointer, entering text one scanned letter at a time — autofill turns four minutes of scanning into one press.
• A customer with dyslexia or a memory impairment, who recognises their own address the moment it appears but cannot reliably reproduce it from memory.
• A returning customer on a phone, one-handed, on a moving train, who has bought from you before and expects the form to remember.

The criterion is narrower than people assume, and that matters when you fix it. WCAG 1.3.5 covers fields collecting information about the user. Your search box, quantity inputs and coupon code are out of scope. In scope, and usually where the gaps are: the postcode field in the basket page shipping calculator, every billing and shipping field at checkout, the login and registration forms, the address book in My Account, and any newsletter or contact form.

How it is detected here

Two engines carry a named rule for 1.3.5, and both run over the same rendered page:

• axe-core 4.12.0 — autocomplete-valid
• IBM Equal Access (ACE) — input_autocomplete_valid

Because they are independent implementations of the same requirement, a token that both reject is corroborated rather than asserted once. HTML_CodeSniffer references the criterion in its own message set, but our rule export attributes no named rule id to it here, so we do not present it as a third opinion. No Klarvo probe covers 1.3.5 — the criterion is not in the probe set, and nothing on this page depends on one.

Be clear about what those two rules actually judge: a token that is present. Neither reports an input carrying no autocomplete attribute at all — a missing attribute breaks no grammar. That gap is exactly why this fix family exists. A field with no token is identified deterministically from the field’s own markup: its name, id, type and associated label. The engine rules then confirm that whatever ends up in the attribute is a real input purpose.

1.3.5 is Level AA, introduced in WCAG 2.1.

What Klarvo does about it

This family is automatic. The token is derived deterministically — a fixed mapping from the field’s identity to the matching name in the WCAG input-purposes list, with no model asked to guess — then applied server-side in the HTML your store serves, before it reaches the browser. It is not an overlay: the markup that leaves your server is the corrected markup, so it is what a screen reader, an autofill engine and a scanner all see. The page is then re-rendered and re-scanned independently, and the fix is recorded as applied only when the engines agree it took.

Two limits worth stating. Where a field’s purpose cannot be established from its own markup, no token is written automatically — the field goes to your review queue instead: an invented token is a new failure rather than a fix, which is precisely what failure F107 describes. And card fields rendered inside a payment gateway’s iframe belong to the gateway’s document — nothing applied to your HTML reaches inside it.

How to fix it yourself

Learn the token grammar

A value is an optional section-* group, then optionally shipping or billing, then the field name. WooCommerce core writes section-billing billing given-name. The names you will use most: given-name, family-name, organization, address-line1, address-line2, address-level2 (town or city), address-level1 (county or state), postal-code, country, tel, email, bday, username, current-password, new-password. Never borrow a name that does not describe the field — email on a “confirm your order reference” input is a failure, not a fix.

Check your theme first

This is where most stores lose it. WooCommerce core already ships tokens on the standard address fields and on the login and registration inputs. But a child theme that overrides those templates wins, and a copy taken years ago predates the attributes. Look for these and diff them against the current plugin originals in wp-content/plugins/woocommerce/templates/:

wp-content/themes/your-child-theme/woocommerce/checkout/form-billing.php
wp-content/themes/your-child-theme/woocommerce/checkout/form-shipping.php
wp-content/themes/your-child-theme/woocommerce/myaccount/form-login.php

The override convention keeps the plugin’s folder structure but drops the templates/ segment. If the only reason a template was copied has since been solved by a filter, delete the copy — that alone restores the tokens.

Classic shortcode checkout

Add tokens with a filter in your child theme’s functions.php, at a priority above core so yours runs last:

add_filter( 'woocommerce_checkout_fields', function ( $fields ) {
	if ( isset( $fields['billing']['billing_dob'] ) ) {
		$fields['billing']['billing_dob']['autocomplete'] = 'bday';
	}
	if ( isset( $fields['billing']['billing_company'] ) ) {
		$fields['billing']['billing_company']['autocomplete'] = 'section-billing billing organization';
	}
	return $fields;
}, 20 );

To change a field in the billing and shipping sections at once, filter woocommerce_default_address_fields instead. For a field you render yourself, use WooCommerce’s own helper rather than hand-written markup — it copies autocomplete into the rendered attributes, and a hard-coded <input> cannot:

woocommerce_form_field( 'billing_dob', array(
	'type'         => 'date',
	'label'        => __( 'Date of birth', 'your-child-theme' ),
	'required'     => false,
	'autocomplete' => 'bday',
), '' );

Checkout and Cart blocks

Stores created recently use the Cart and Checkout blocks rather than the shortcodes. The block’s own address fields already carry tokens. Fields you add through the additional checkout fields API take an attributes array, and autocomplete is on its allow-list:

add_action( 'woocommerce_init', function () {
	woocommerce_register_additional_checkout_field( array(
		'id'         => 'your-plugin/date-of-birth',
		'label'      => __( 'Date of birth', 'your-plugin' ),
		'location'   => 'contact',
		'type'       => 'text',
		'attributes' => array(
			'autocomplete' => 'bday',
		),
	) );
} );

Everything outside checkout

Account forms need username, current-password for signing in and new-password for registration and password resets — a password manager and a browser both rely on that distinction. A footer newsletter input needs email; a contact form needs name, email and tel. In a block theme the site editor exposes no attribute setting for these, because the forms come from plugins: use the plugin’s own field settings where it has them, or filter its rendered output. Page-builder-generated forms behave the same way — the token belongs on the input the builder emits.

How you know it worked

Re-scan the basket, checkout, login and My Account pages and expect no findings from autocomplete-valid or input_autocomplete_valid. Then confirm the change is real by viewing the page source rather than the browser’s inspector: source shows what your server sent, which is where a genuine fix lives.

The check that actually matters is not a rule count. Save an address in your browser’s autofill settings, open checkout, autofill in one action, and read every field. Right values in the right boxes is the proof. A surname sitting in address line one means a token is present but wrong, and no clean scan will tell you that. Tab through the form with the keyboard only and confirm the suggestions appear where you expect them.

Re-check after theme and plugin updates. A template override or a new checkout field reintroduces the gap silently, which is why this is monitored rather than done once. And keep the claim the right size: a clean scan is evidence that one specific barrier is gone, nothing more.