Core programme roles
These roles can be part-time in smaller orgs, but the responsibilities must exist.
Executive sponsor
- Sets a non-negotiable expectation: no release without accessibility acceptance
- Funds training, audits, remediation time, tooling, and scalable enterprise solutions
- Removes organisational blockers, aligns leaders
Accessibility lead / champion
- Owns the strategy, standards, prioritisation model, and governance
- Coordinates across functions (product, UX, engineering, marketing, legal)
- Runs escalation, decision-making, and reporting
Accessibility coach (enablement)
- Builds team capability and confidence and upskills through real work (pairing, reviews, examples)
- Embed accessibility into process (Definition of Done, acceptance criteria, design systems)
- Drive accountability and momentum (team alignment, tracking metrics and progress)
Programme manager
- Turns goals into a roadmap, milestones, and deliverables
- Keeps remediation and “new work” moving without chaos
- Makes sure work is tracked in a single system
Data analyst (or reporting owner)
- Defines KPIs, dashboards, benchmarks, and trends
- Tracks: defects by severity, fix rate, regressions, training completion
Delivery roles
Below are the highest-impact responsibilities, organised in a way teams can operationalise.
Business analyst (requirements and acceptance criteria)
- Capture accessibility requirements as testable acceptance criteria
- Ensure user journeys include assistive tech considerations (keyboard, screen reader, zoom, mobile)
- Specify behaviour for focus, hover, errors, timeouts, motion, gestures
- Ensure components and flows have clear labels, instructions, and outcomes
- Confirm non-functional requirements include accessibility (performance can affect accessibility too)
What “Done” looks like:
- Stories have accessibility acceptance criteria
- Known constraints documented (for example third-party widgets)
User experience design (interaction, structure, behaviour)
- Define and document keyboard interaction for every interactive element
- Plan focus order, skip patterns, and navigation landmarks for complex pages
- Avoid interaction patterns that rely on hover-only or gesture-only
- Ensure overlays, tooltips, and popovers triggered by hover/focus are dismissible, persistent enough, and not traps
- Specify safe interactions for motion, shake, single-pointer down events, and shortcuts
What “Done” looks like:
- Prototype can be navigated end-to-end with keyboard expectations documented
- Focus states and error recovery are specified, not implied
Visual design (layout, contrast, states, readability)
- Do not rely on colour alone for meaning (status, errors, selected state)
- Meet contrast requirements for text, UI controls, and meaningful graphics
- Ensure visible focus indicators are designed (not left to chance)
- Design for 200% zoom and reflow (single column where possible)
- Avoid text baked into images, especially for essential content
- Provide clear visual cues for errors and instructions
What “Done” looks like:
- Contrast checked, focus state designed, and layouts work at zoom/reflow
Content authoring (words, headings, alt text, clarity)
- Write meaningful page titles and headings, in a correct hierarchy
- Provide accurate alt text (informative vs decorative handled correctly)
- Ensure link and button text is descriptive (no “click here” style ambiguity)
- Keep content clear, scannable, and structured (supports cognitive accessibility)
- Ensure visible labels align with what assistive tech announces (names that match)
What “Done” looks like:
- Headings are in order, titles are unique, images have appropriate alt text
- Content is readable and avoids over-reliance on images for meaning
Front-end development
- Use correct HTML semantics (landmarks, lists, headings, forms)
- Implement accessible names, roles, and states correctly (avoid ARIA misuse)
- Ensure keyboard access for all controls, with no traps
- Preserve meaning when content updates dynamically (announce changes appropriately)
- Avoid putting essential text in CSS background images
- Ensure focus management works for modals, dialogs, menus, and injected content
What “Done” looks like:
- UI is operable by keyboard, readable by screen readers, and resilient to zoom/reflow
- Dynamic updates are communicated appropriately
QA testing
- Run manual checks (keyboard, screen reader spot checks, zoom, reflow)
- Validate fixes with the same method used to find issues
- Prevent regressions with smoke tests and “known risk” checks per release
What “Done” looks like:
- Evidence captured (screenshots, notes, defect IDs, steps to reproduce)
- Regression checks built into release workflow
Shared responsibility roles
Product team
- Makes accessibility a roadmap requirement, not a nice-to-have
- Prioritises remediation using severity + user impact + legal risk
Procurement
- Requires accessibility evidence from vendors (VPAT, test results, contract clauses)
- Ensures ongoing monitoring, not one-off assurance
Legal / compliance
- Interprets obligations, supports policy, manages complaint handling
- Reviews completion evidence against the internal policy
Marketing and social media
- Produces accessible public content, campaigns, and events
- Uses alt text, captions, and inclusive representation
Customer support
- Handles accessibility queries respectfully
- Routes issues into the product backlog with clear timelines and updates
HR
- Ensures accessible hiring and internal tooling, embeds skills into job descriptions