Your Form Is Not Slow — It Just Makes People Type

A prospect opens your contact form on a phone. Name, email address, phone number, company, street, postal code, city. The browser probably already knows most of that information.

Yet the person still has to type it field by field.

At first, that sounds like a minor convenience issue. In an enquiry, checkout, or registration journey, it is ordinary friction: more typing, more opportunities for errors, and more time for a user to decide not to finish.

Autofill is therefore not a decorative browser feature. It is part of form architecture.

That is where a surprisingly quiet quality problem appears. A form can look polished, validate correctly, and submit successfully while still failing to tell the browser what its fields actually mean.

type, inputmode, and autocomplete solve different problems

These attributes are often treated as interchangeable. They are not.

type="email" describes the technical kind of input a control accepts. inputmode="numeric" can encourage a more appropriate virtual keyboard on mobile devices. autocomplete, by contrast, describes the meaning of the value the user is expected to provide.

That distinction matters.

A field can use type="text" and still be identified as a postal code with autocomplete="postal-code". An email field can use type="email" without telling the browser whether the address represents the user's contact email, a sign-in identifier, or something else.

The WHATWG HTML Standard therefore defines a fixed autofill taxonomy including tokens such as:

• name, given-name, and family-name
• email and tel
• organization
• street-address, address-line1, address-level2, and postal-code
• username, current-password, and new-password
• shipping and billing
• named section-* groups for multiple sets of similar information

If the markup only relies on visual labels, the browser has to infer more of the intent.

The business effect is simple: remove unnecessary work

Autofill cannot rescue a badly designed form. A field you do not need is still an unnecessary field.

But for information that genuinely needs to be collected, browser-assisted completion can make the journey much easier. People do not have to repeatedly re-enter familiar data, especially on small screens where typing is slower and errors are easier to make.

That is more than a UX detail. For contact forms, friction can mean fewer completed enquiries. For ecommerce, it affects checkout. For SaaS products, it touches sign-up, invitations, and profile management.

So the useful question is not: "Does the form support autofill?"

It is: "Can a real browser reliably understand what our fields mean?"

Six checks that reveal more than the visual design

1. Do fields declare the correct semantic purpose?

Inspect the actual HTML.

A field visibly labelled "First name" should not use autocomplete="name" if it truly expects only a given name. The more specific token is given-name. There is family-name for a surname, street-address for a full street address, and postal-code for a postal code.

Plausible-looking inventions such as autocomplete="first-name" are not part of the standard token list.

This is an easy bug to miss because the form can look completely correct.

2. Are billing and shipping addresses really distinguished?

When a form contains two addresses, identical fields with identical names are not the clearest signal.

The standard provides shipping and billing grouping tokens. It also supports section-* tokens for separating multiple sets of similar data.

For example, one control can be described as autocomplete="shipping postal-code" and another as autocomplete="billing postal-code".

Without that semantics, the browser has to rely on other clues to decide which stored data belongs in each field.

3. Do the label, input type, and autocomplete token tell the same story?

Good form markup gives the user and the browser a coherent description.

If a visible label says "Email address," the field uses type="tel", and the autofill token is username, the semantics may conflict. Some combinations are intentional—for example, an email address can genuinely be the account username—but they should be deliberate.

Review these together:

• visible label
• name and id
• type
• autocomplete
• inputmode
• validation constraints

The values do not all need to be identical. They do need to describe a consistent purpose.

4. Is autofill disabled globally without a clear reason?

autocomplete="off" can easily end up inside a shared form component and then remain active across contact, checkout, and profile forms for years.

Before disabling autofill broadly, identify the specific problem that decision is solving.

For common personal inputs such as name, address, email, or phone number, browser-assisted completion is often exactly the feature that saves users work. A global "off" should therefore be a deliberate exception, not an accidental component-library default.

5. Does the form only work in a clean test profile?

Developers often test forms in fresh browser profiles, private windows, or with test data that is never stored.

That skips the behaviour many real users actually encounter.

A practical test should include at least:

• desktop and mobile
• a browser profile with saved address data
• several repeated personal-information fields
• a billing/shipping combination where applicable
• keyboard navigation
• an actual submission after autofill
• validation after automatically inserted values

The last point matters. A populated control is not the same as a successfully submitted form. Custom validation, input masking, or JavaScript state can react differently to autofilled values than to characters typed one by one.

6. Can you identify fields where autofill should help but apparently does not?

web.dev documents a method for measuring autofill usage and investigating fields that behave unexpectedly. That can be useful for high-value conversion journeys.

If many users take advantage of autofill but one address field is regularly completed manually, that may point to an unclear label, an invalid token, or an unusual form structure.

Any telemetry should of course be privacy-conscious. For many quality reviews, a reproducible browser test is enough before adding more measurement at all.

Autofill also has an accessibility dimension

WCAG 2.2 Success Criterion 1.3.5, "Identify Input Purpose," requires the purpose of certain fields collecting information about the user to be programmatically determinable when the technology supports doing so.

W3C Technique H98 describes valid HTML autocomplete values as one way to expose that purpose in machine-readable form. This is useful beyond conventional browser autofill. Assistive technologies can use standardized input purposes to present or support fields more consistently.

A visible label is still essential. autocomplete does not replace understandable labelling; it adds machine-readable meaning to it.

What Website-Pflichtencheck would inspect

A technical Website-Pflichtencheck review would not stop at confirming that a form "works."

Relevant checks include:

• correct and valid autocomplete tokens
• appropriate type and inputmode values
• visible labels and their programmatic associations
• separation of multiple address or contact-data groups
• mobile keyboard and autofill behaviour
• validation and JavaScript behaviour after autofill
• unnecessary required fields
• keyboard operation and error handling
• the complete path from populated controls to an enquiry that actually arrives

The goal is not to make every form maximally clever. It is to remove unnecessary effort without sacrificing data quality or clarity.

A five-minute test for today

Open your most important form on a phone and try to complete it without manually typing the information your browser already has.

Then watch what happens.

Which fields are recognised correctly? Which remain empty? Which receive the wrong value? Where do you need to correct the browser? And can you submit successfully afterwards?

If a form is expected to generate leads, orders, or registrations every week, this is not a cosmetic detail. It is part of the conversion journey.

Website-Pflichtencheck can surface these invisible quality gaps before they spend months hiding behind a vague analytics observation: "People just seem not to finish the form."