Required fields, instructions & input purpose

A label coloured red to mean "this field is required" carries the whole message in one channel: colour. Someone who can't perceive that red — a colour-blind user, anyone in high-contrast or forced-colours mode, a screen reader user — gets no signal at all that the field is mandatory (1.4.1). And because the colour is purely visual styling, the required state never reaches the accessibility tree, so the field is announced exactly like an optional one (4.1.2). The fix is two-sided: add the native required attribute so the state is programmatic, and pair the visual cue with text such as the word "required" or a visible asterisk that is explained once for the whole form.

<style> .req { color: #d00; } </style>

<label for="email" class="req">Email</label>
<input type="email" id="email" name="email">

<p id="req-note">Fields marked <span aria-hidden="true">*</span> are required.</p>

<label for="email">Email <span aria-hidden="true">*</span></label>
<input type="email" id="email" name="email" required aria-describedby="req-note">

<label for="phone">Phone (required)</label>
<input type="tel" id="phone" name="phone" aria-required="true">

When a field needs a rule — "at least 8 characters", "format DD/MM/YYYY", "use the name on your card" — and that rule lives only in the placeholder, it disappears the instant the user types. The person who most needs the reminder, someone with a memory or attention disability, loses it exactly when they start filling the field. Placeholder text is also low-contrast grey by default, isn't reliably announced as an instruction, and can be mistaken for a pre-filled value. An instruction that the form requires (3.3.2) has to be persistent and tied to the field in the markup (1.3.1) — usually a small line of help text linked with aria-describedby.

<label for="pw">Password</label>
<input type="password" id="pw" name="pw"
       placeholder="At least 8 characters, 1 number">

<label for="pw">Password</label>
<input type="password" id="pw" name="pw" aria-describedby="pw-help">
<p id="pw-help" class="field-hint">Use at least 8 characters and one number.</p>

<label for="dob">Date of birth</label>
<input type="text" id="dob" name="dob"
       aria-describedby="dob-hint dob-error" aria-invalid="true">
<p id="dob-hint" class="field-hint">Format: DD/MM/YYYY.</p>
<p id="dob-error" class="error">Enter a real date, for example 24/05/1990.</p>

Identify Input Purpose (1.3.5) applies to any field that collects information about the user — their name, email, phone, address, birthday. Each such field must declare its purpose with one of the fixed autocomplete tokens from the HTML specification. With the right token the browser can autofill the value, assistive tools can present a familiar icon, and preference extensions can adapt the field — all of which spare people with cognitive, motor, or memory disabilities from recalling and re-typing their own data. A type="text" input with no token leaves that purpose undeclared, and the tokens are a controlled vocabulary, not free text.

<label for="fn">Full name</label>
<input type="text" id="fn" name="fn">

<label for="em">Email</label>
<input type="email" id="em" name="em">

<label for="fn">Full name</label>
<input type="text" id="fn" name="fn" autocomplete="name">

<label for="em">Email</label>
<input type="email" id="em" name="em" autocomplete="email">

<label for="ph">Phone</label>
<input type="tel" id="ph" name="ph" autocomplete="tel">

<input autocomplete="given-name">       <!-- first name -->
<input autocomplete="family-name">      <!-- last name -->
<input autocomplete="street-address">
<input autocomplete="postal-code">
<input autocomplete="bday">             <!-- date of birth -->
<input autocomplete="work email">       <!-- scoped to work contact -->
<input autocomplete="one-time-code">    <!-- SMS code field -->