• Success Criterion 3.3.3
  • Conformance level AA

Correction Suggestions Wrongly Withheld From a Non-Security Field

3.3.3 — Error Suggestion

Scenario

Setting

A music streaming app's playlist screen

What’s wrong

Suggesting corrections that violate security exception boundaries misunderstood in reverse — i.e., *withholding* suggestions for non-security fields citing "policy".

Example 

<label for="playlist-name">Playlist name</label>
<input id="playlist-name" value="Roadtrp Mix">
<p role="alert">Name rejected per policy. No suggestions available.</p>
<!-- 'policy' language borrowed from password rules is applied to a harmless typo'd playlist name -->

Why it matters

A user renaming a playlist gets a security-style refusal for a simple typo, even though nothing about a playlist name is sensitive.

How to test

Check whether correction suggestions are being withheld from non-security fields citing a security exception that doesn't actually apply to them: misapplied withholding fails.

How to fix

The security exception in this criterion applies only to passwords and similar sensitive fields, not to ordinary text like a playlist title.

<label for="playlist-name">Playlist name</label>
<input id="playlist-name" value="Roadtrp Mix" aria-describedby="name-error">
<p id="name-error" role="alert">Did you mean "Roadtrip Mix"?</p>

Outcome

The user accepts the corrected spelling and their playlist saves with the name they meant.

Who is affected

People with cognitive disabilities and screen reader users who lose a helpful correction because a non-security field was treated like a password.

Learn more

Related scenarios