Accessibility
Accessible UI is not a compliance add-on. It is core quality. Interfaces that are accessible are usually clearer, more resilient, and easier for everyone to use.
The Inclusive Design Baseline
| Area | Minimum Expectation |
|---|---|
| Keyboard | All interactive elements reachable and usable |
| Focus | Visible focus indicator on every interactive element |
| Contrast | Text and controls meet WCAG-aligned contrast needs |
| Semantics | Headings, lists, buttons, links, and form elements use proper HTML |
| Labels | Inputs have clear labels and instructions |
| Motion | Reduced motion preference is respected |
| Zoom | Content works at 200% without breaking core tasks |
Practical Accessibility Rules
Structure
- use one meaningful H1 per page
- keep heading order logical
- use lists and tables only when the content is truly a list or table
- use landmarks like header, nav, main, aside, and footer where appropriate
Interaction
- buttons trigger actions; links navigate
- focus order should match visual order
- modals must trap focus and return focus on close
- dropdowns and comboboxes need explicit keyboard behavior
Forms
| Need | Good Pattern |
|---|---|
| Required fields | Indicate clearly in text, not color alone |
| Errors | Associate message with the field and explain how to fix it |
| Help text | Keep it close to the field |
| Validation | Avoid interrupting too early; support correction |
Accessible Form Example
<label for="password">Password</label>
<input
id="password"
name="password"
type="password"
aria-describedby="password-hint password-error"
aria-invalid="true"
/>
<p id="password-hint">Use at least 12 characters.</p>
<p id="password-error">Add one number and one special character.</p>
This pattern works because the field has a persistent label, explicit guidance, and an error message that assistive technology can discover reliably.
Accessible Visual Design
- do not encode state only with color
- make focus clearly visible, not subtle
- avoid low-contrast placeholder-like body text
- ensure charts use multiple cues: labels, patterns, legends, annotations
Motion and Animation
Animation should support comprehension, not dominate attention.
Use motion to:
- confirm state changes
- preserve spatial continuity
- reveal causality between user action and result
Avoid motion that:
- auto-plays excessively
- creates dizziness or distraction
- blocks task completion
- cannot be reduced when the user prefers reduced motion
Testing Methods
| Method | What It Catches |
|---|---|
| Keyboard-only test | Focus issues, missing states, unreachable controls |
| Screen reader pass | Semantic and labeling problems |
| Zoom to 200% | Layout breakage and overflow issues |
| Contrast audit | Readability and control visibility issues |
| Real user testing | Problems tools do not catch |
Common Mistakes
- clickable
divelements instead of buttons or links - removing focus rings without replacing them
- error messages shown only as red text
- inaccessible custom selects, menus, and date pickers
- relying entirely on automated tools and skipping manual checks
Accessibility Mindset
Accessibility is easiest when it is built into the system:
- semantic defaults
- reusable accessible components
- documented keyboard behaviors
- content rules that prevent contrast and labeling failures