Accessibility Definition of Done – Talent Solutions powered by

Version: 1.1

Target Standard: WCAG 2.2 Level AA

Last Updated: January 4, 2026

Purpose

This checklist defines when a feature or component is considered "complete" from an accessibility perspective for the workforce platform. Every feature must pass all applicable criteria before merging to production.

Automated Testing (Required)

CI/CD Pipeline

axe-core automated tests pass with zero violations
IBM Equal Access checks pass with zero violations
Biome linting passes with no accessibility-related warnings
All checks configured to block deployment on failure

Storybook Documentation

Component documented in Storybook with accessibility addon enabled
All interactive states demonstrated (default, hover, focus, disabled, error)
Accessibility violations panel shows zero issues
Component props/variants documented with accessibility notes where relevant

Keyboard Navigation (Required)

Focus Management

All interactive elements are keyboard accessible (no mouse-only interactions)
Focus order is logical and matches visual layout
Focus indicators are clearly visible (minimum 2px outline, 3:1 contrast ratio)
No keyboard traps (users can navigate in and out of all components)
Skip links provided for repetitive navigation blocks

Keyboard Shortcuts

Standard keyboard patterns implemented:
- Tab / Shift+Tab for navigation
- Enter / Space for activation
- Escape to close modals/dropdowns
- Arrow keys for menus, tabs, sliders (where applicable)
Custom shortcuts documented and don't conflict with screen reader shortcuts

Screen Reader Testing (Required)

VoiceOver Validation (Development)

Tested with VoiceOver on Mac (Safari browser) during development
All content is announced in logical reading order
Interactive elements announce their role, name, state, and value
Form inputs have associated labels (not placeholder-only)
Error messages are announced and programmatically associated with inputs
Dynamic content changes are announced via ARIA live regions
Images have meaningful alt text (or alt="" for decorative images)

Note: Comprehensive multi-screen-reader testing (JAWS, NVDA, VoiceOver, TalkBack) is performed during third-party audits. Development teams are responsible for VoiceOver validation to catch issues early.

Semantic HTML

Uses semantic HTML elements (button, nav, main, header, footer, article)
Heading hierarchy is logical (h1 → h2 → h3, no skipped levels)
One <h1> per page matching page title
Landmark regions used appropriately (<main>, <nav>, <aside>)
Lists use proper markup (<ul>, <ol>, <li>)

Visual Design & Color (Required)

Color Contrast

Text contrast meets WCAG AA minimum:
- Normal text (< 18pt): 4.5:1
- Large text (≥ 18pt or 14pt bold): 3:1
- UI components and graphics: 3:1
Contrast verified using automated tools (built into axe-core)
Focus indicators meet 3:1 contrast against background

Color Independence

Information is not conveyed by color alone
Error states use icons or text in addition to red color
Required fields marked with asterisk or "(required)" text, not just color
Charts and graphs use patterns or labels in addition to color

Cognitive Accessibility (Required)

WCAG 2.2 Cognitive Criteria

Redundant Entry (3.3.7): Information previously entered is auto-populated or available for selection (no re-typing required)
Accessible Authentication (3.3.8): Authentication does not require cognitive function tests (no CAPTCHAs, puzzles, or memorization without alternatives)
Consistent Help (3.2.6): Help mechanisms appear in the same relative location across pages

Content Clarity

Instructions are clear and concise
Error messages explain what went wrong and how to fix it
Complex processes are broken into manageable steps
Timeouts are generous or users are warned before expiration

Motion & Animation (Required)

Reduced Motion Support

Animations respect prefers-reduced-motion media query
Essential motion is minimized or replaced with static alternatives
No content flashes more than 3 times per second (WCAG 2.3.1)

Auto-Playing Content

Auto-playing videos or animations can be paused, stopped, or hidden (WCAG 2.2.2)
Carousels and slideshows have visible pause controls
Background videos do not auto-play or have motion disabled by default

Responsive & Zoom (Required)

Responsive Behavior

Tested at 320px viewport width (mobile)
Tested at 1280px viewport width (desktop)
No horizontal scrolling on narrow viewports
Content reflows without loss of information or functionality

Zoom & Text Scaling

Tested at 200% browser zoom without breaking layout
Text remains readable and doesn't overlap
Interactive targets remain usable
No content is clipped or hidden

Touch Target Size (WCAG 2.2)

Interactive elements have a minimum target size of 24x24 CSS pixels (WCAG 2.5.8)
Targets smaller than 24x24px have sufficient spacing (no overlapping targets)
Touch targets on mobile are at least 44x44px for comfortable interaction

Mobile Device Testing

Tested on actual mobile devices (iOS and Android), not just browser emulation
Touch interactions work correctly (tap, swipe, pinch-to-zoom)
On-screen keyboard does not obscure form inputs
Orientation changes handled gracefully (portrait and landscape)

Forms & Inputs (When Applicable)

All inputs have visible and accessible labels
Labels are programmatically associated (htmlFor/id or aria-labelledby)
Required fields clearly marked (visually and to screen readers)
Error messages are:
- Clearly visible near the relevant input
- Announced to screen readers (aria-describedby)
- Specific and actionable (not just "invalid input")
Success states announced to screen readers
Autocomplete attributes used where appropriate (WCAG 2.2)
Multi-step forms indicate progress and allow navigation

Interactive Components (When Applicable)

Modals & Dialogs

Focus trapped within modal when open
Focus returns to trigger element when closed
Closable with Escape key
Has accessible name (aria-labelledby or aria-label)
Background content marked inert or aria-hidden

Dropdowns & Menus

Keyboard navigable (arrow keys, Enter, Escape)
Current selection/state announced to screen readers
Closes on Escape or outside click
Uses appropriate ARIA patterns (menu, listbox, combobox)

Custom Controls

ARIA roles, states, and properties implemented correctly
Behavior matches native equivalents
Documented in Storybook with keyboard instructions
Tested with screen reader to verify announcements

Dynamic Content (When Applicable)

Loading States

Loading indicators announced to screen readers (aria-live or role="status")
Loading text provided (not spinner-only)
Focus managed appropriately during/after load

Real-Time Updates

Changes announced via ARIA live regions (polite or assertive as appropriate)
Updates don't disrupt user's current task
User can pause, stop, or hide auto-updating content (if updates > 5 seconds)

Client-Side Routing

Page title updates on route change
Focus management on navigation (focus moves to main content or h1)
Route changes announced to screen readers

Documentation (Required)

Storybook story includes:
- Component description
- Keyboard interaction instructions
- ARIA pattern reference (if applicable)
- Non-obvious accessibility patterns explained
Known limitations or accessibility caveats documented in Storybook

Manual Review Checklist

Before marking complete, the developer must:

Run automated tests (CI/CD must pass)
Test keyboard navigation (tab through entire feature)
Test with VoiceOver (listen to complete flow)
Verify color contrast (use browser DevTools or axe)
Test responsive behavior (320px and 1280px)
Test at 200% zoom (verify layout doesn't break)
Test on mobile device (actual device, not just emulation)
Verify reduced motion (test with prefers-reduced-motion enabled)
Review Storybook (ensure component is documented)

Exceptions & Edge Cases

If any checklist item cannot be met:

Document the limitation in Storybook
Provide alternative accessible solution where possible
Get approval from VP Digital Experience (executive accountability for accessibility decisions)
Create follow-up ticket with accessibility label and target resolution date

References

Review Schedule

This document will be reviewed and updated:

Quarterly as accessibility standards evolve
When new tools or testing methods are adopted
After accessibility audits or user feedback
When WCAG standards are updated

By following this checklist, we ensure the workforce platform is accessible to all users from day one, meeting WCAG 2.2 Level AA standards and demonstrating our commitment to inclusive design.

Related to