• Success Criterion 1.3.5
  • Conformance level AA

Custom Form Widget That Drops the Native Autocomplete Behavior

1.3.5 — Identify Input Purpose

Scenario

Setting

A news outlet's article page

What’s wrong

Custom JS widgets replacing native inputs (framework "smart fields") that drop the underlying autocomplete/purpose semantics.

Example 

<div class="smart-field" data-field="email">
  <div class="floating-label">Email</div>
  <input type="text" class="smart-input">
</div>

Why it matters

A reader trying to quickly subscribe to the newsletter gets no autofill suggestion and must type their email manually every time this widget appears.

How to test

Inspect a custom-built 'smart field' component in DevTools: check whether the rendered input still carries the correct native autocomplete attribute, or whether the framework stripped it.

How to fix

Whatever the framework, make sure the rendered output is a real input with name and autocomplete set, not just a styled shell.

<div class="smart-field" data-field="email">
  <label for="news-email" class="floating-label">Email</label>
  <input type="email" id="news-email" name="email" autocomplete="email" class="smart-input">
</div>

Outcome

A subscriber's email now autofills on the newsletter widget, matching what real inputs elsewhere on the site do.

Who is affected

Users with motor and cognitive disabilities who depend on autofill lose that support entirely on this custom-built field.

Learn more

Related scenarios