Input Fields — Accessibility Specification (WCAG 2.1 AA)

What is this component?

What is this component? Input fields collect free‑form user data such as text, email, password, numbers, and dates. Native inputs expose role, name, value and provide built‑in keyboard behavior.

Where and how is it used? Forms, search bars, authentication, profile settings—anywhere user input is required.

Accessibility Requirements

Requirement	WCAG Criteria	Description
Programmatic label	1.3.1, 3.3.2	Use `<label for>`/`id` or `aria-labelledby`. Place labels above inputs for clarity.
Helpful instructions	3.3.2	Provide examples or hints via `aria-describedby` (e.g., password rules).
Error identification and suggestion	3.3.1, 3.3.3	Identify errors in text; provide suggestions to correct when possible.
Keyboard operability	2.1.1	Reachable by Tab; caret navigation works; shortcuts do not trap focus.
Name, Role, Value	4.1.2	Expose role “textbox” (or specific types), accessible name from label, and current value; set `autocomplete` where applicable.

ARIA Roles and Attributes

ARIA Role/Attribute	Used On	Purpose & Usage
`<input type="text\|email\|password\|number\|search\|url\|tel">`	Native inputs	Preferred; include appropriate `autocomplete` tokens.
`aria-describedby`	Inputs with help or error text	Programmatically associates hints and validation messages.
`aria-invalid="true"`	Invalid inputs	Set when validation fails to announce error state.

Implementation Guidelines


Email address

We’ll send confirmations to this address.

Password

8+ chars, one number, one symbol.

DO’s

Use explicit labels; avoid placeholder‑only labeling.
Connect help/error text via aria-describedby.
Use correct type and autocomplete to improve UX and AT.
Preserve user input on validation errors; set aria-invalid.
Ensure sufficient contrast for text, borders, and errors.

Don’ts

Don’t use placeholder as the only label; it vanishes on input.
Don’t block paste for fields like email or password unless required.
Don’t rely on color alone for errors; include icons/text.
Don’t auto‑advance focus unexpectedly.

Common Pitfalls

Missing labels: AT users hear “edit text” with no purpose.
Misused placeholders: instructions disappear on typing.
Unannounced errors: messages not linked via aria-describedby.
Poor mobile keyboards: wrong type leads to inefficient input.

Testing Checklist

Test Item	WCAG Criteria	Pass Criteria
Label and Role	1.3.1, 4.1.2	Screen reader announces label and type (e.g., “Email, edit”).
Hints and Errors	3.3.1, 3.3.2	Hints and errors are announced via `aria-describedby`.
Keyboard	2.1.1	Reachable, editable, and no traps; Tab order follows layout.
Contrast	1.4.3	Field text and error indicators meet contrast requirements.