Roles and Responsibilities

Accessibility is not owned by one person or team. It is the cumulative result of decisions made across every role in an organization. A perfectly coded component cannot compensate for inaccessible copy. An excellent content strategy fails if the design uses poor contrast. A well-designed site becomes inaccessible if developers do not implement focus management correctly.

This page describes what each role controls, where their accessibility accountability lies, and the most common mistakes made at that level.

Executive and Leadership

Leadership

What you control

• Budget: Whether accessibility testing, training, and remediation are funded
• Policy: Whether accessibility is a named organizational priority with accountability attached
• Procurement: Whether accessibility requirements appear in vendor contracts and RFP evaluation criteria
• Culture: Whether accessibility is treated as a compliance checkbox or a quality standard
• Legal exposure: Canadian law (ACA, AODA, CHRA, provincial human rights codes) creates organizational liability for inaccessible services — executives carry that risk

Accountability

Executive teams are accountable for:

• Publishing accessibility plans and progress reports (required under ACA and AODA for covered organizations)
• Ensuring legal compliance deadlines are met
• Designating an accessibility lead or champion with sufficient authority and resources
• Ensuring accessibility is included in project approval criteria, not added at the end

Common executive mistakes

Mistake	Consequence
”We’ll do accessibility after launch”	Remediation costs 5–10× more than building accessibly from the start
Treating accessibility as a one-time project	Accessibility degrades as content and features are added without ongoing standards
No dedicated budget	Teams lack tools, training, and time — accessibility becomes aspirational, not actual
Delegating to a single “accessibility person”	One person cannot review all output; accessibility must be distributed across teams
Measuring compliance instead of usability	Passing an automated scan is not the same as being accessible to disabled users

What good looks like

• Accessibility included in the organizational definition of quality (alongside performance and security)
• Named accountability in job descriptions and performance reviews for relevant roles
• Annual accessibility audit with external review
• Disability inclusion in user research panels
• Public accessibility statement with honest status and contact information

Product Manager / Project Manager

Leadership

What you control

• Requirements: Whether accessibility requirements are included in user stories and acceptance criteria
• Prioritization: Whether accessibility bugs are triaged and fixed with the same urgency as functional bugs
• Timeline: Whether accessibility testing is scheduled before launch, not deferred to post-launch
• Handoff quality: Whether design handoffs to development include accessibility annotations
• Definition of done: Whether a feature is considered complete without accessibility review

Accountability

Product managers are accountable for:

• Writing user stories that include accessibility acceptance criteria: “As a keyboard user, I can complete this form without a mouse”
• Ensuring accessibility testing is included in the sprint or project timeline
• Treating WCAG failures as bugs, not enhancements
• Reviewing the accessibility implications of scope decisions (“let’s skip the alt text for now” has legal and reputational consequences)

Common PM mistakes

Mistake	Consequence
Accessibility tickets moved to backlog indefinitely	Legal risk accumulates; remediation debt compounds
No accessibility acceptance criteria in stories	Developers have no standard to implement against
”We’ll fix it in the next sprint” applied to every sprint	Inaccessibility ships permanently
Scheduling accessibility testing after usability testing	Accessibility issues found late cost more to fix
Treating a WCAG A failure as a “nice to have”	Level A failures are legal violations under Canadian law

Practical steps

• Add accessibility acceptance criteria to your story templates
• Include accessibility review in your definition of done
• Block launch on any Level A or AA failure (WCAG 2.1 AA is the Canadian legal standard)
• Schedule at least one screen reader walkthrough per major feature before launch

Designer

Designer

What you control

• Colour contrast: The single most frequently failed WCAG criterion is Low Contrast Text — this is a design decision
• Focus states: If focus indicators are not designed, developers often skip them
• Touch target sizing: Small tap targets are a design constraint, not a development one
• Information architecture: Navigation order, heading hierarchy intent, and landmark structure
• Motion: Animation choices directly create vestibular risks
• Colour independence: Whether status, state, and data rely only on colour
• Typography: Line height, font size, text alignment, and letter spacing affect cognitive accessibility

Accountability

Designers are accountable for:

• Meeting WCAG contrast ratios in every design file — not “close enough, dev will adjust”
• Including visible focus states in every interactive component design
• Annotating designs with accessibility notes: reading order, heading levels, ARIA roles for custom components, alt text intent for images
• Specifying how colour-only information is supplemented with non-colour indicators
• Ensuring prefers-reduced-motion states are designed, not left to developer interpretation

Common designer mistakes

Mistake	Consequence
Designing focus states as “outline: none”	Keyboard users cannot navigate
Using colour alone to show form errors	Users who cannot distinguish red from grey miss errors
”The developer will handle contrast”	Developers implement what is designed; contrast must be correct in source
Small icon buttons with no text	Voice control users cannot activate them; screen reader users hear only “button”
Hover-only tooltips containing required information	Touch and keyboard users cannot access the information
Animation without reduced-motion consideration	Vestibular disorder users may experience dizziness or nausea
Designing for mouse hover states only	Keyboard focus states are a separate, required design state

Practical steps

• Add a contrast check plugin (Stark, Contrast, Able) to your Figma workflow — check before handoff, not after
• Create a standard focus ring style as a design token and apply it to every interactive component
• Include accessibility annotations as a standard layer in your design files:
  • Reading order numbers
  • Heading levels (H1, H2, H3)
  • Alternative text intent for images
  • ARIA roles or landmarks for custom components
  • Interaction states: focus, hover, active, disabled, error
• Design for minimum 44×44px touch targets on all interactive elements

Developer

Developer

What you control

• Semantic HTML: Whether you use <button> or <div onclick> makes the difference between accessible and inaccessible
• Keyboard implementation: Focus order, keyboard interactions, focus trap management
• ARIA implementation: Whether live regions, roles, and states are correct
• Form accessibility: Label association, error handling, autocomplete attributes
• Focus management: Whether focus moves correctly after dynamic content changes
• Performance: Page speed affects users on slow connections and cognitive load
• Animation implementation: Whether prefers-reduced-motion is respected in code

Accountability

Developers are accountable for:

• Implementing designs with correct semantic HTML — pushing back on designs that cannot be implemented accessibly (e.g., a <div> styled as a button)
• Running automated accessibility tests (axe) on every component and page
• Never suppressing focus indicators without replacement
• Implementing keyboard interactions for every custom component per ARIA APG patterns
• Ensuring dynamic content changes are announced via live regions or focus management

Common developer mistakes

Mistake	Consequence
outline: 0 on :focus	Keyboard users lose all navigation cues
<div role="button"> without keyboard handler	Tab-reachable but not activatable by keyboard
Missing alt on <img>	Screen readers announce the filename
Positive tabindex values	Focus order becomes unpredictable
autocomplete="off" on personal information fields	Users with memory disabilities cannot use autofill
No focus management in modals	Screen reader users cannot find the modal content
Live region not present on page load	Dynamically injected content is not announced
CSS animation without prefers-reduced-motion	Vestibular disorder users experience motion effects even when reduced motion is set

Practical steps

• Install axe DevTools and run it on every page and component before PR review
• Add eslint-plugin-jsx-a11y (React projects) or equivalent to your linting config
• Use the browser accessibility tree view (DevTools → Accessibility panel) to verify roles and names
• Write keyboard tests for every interactive component
• Treat accessibility failures from automated or manual tests as bugs, not enhancements

Content Author / Editor

Author

What you control

• Plain language: Reading level, sentence length, active voice — directly affects users with cognitive disabilities and second-language readers
• Alt text: Every image published needs correct alt text — decorative or descriptive
• Link text: “Click here” and “Read more” fail WCAG and break screen reader navigation
• Heading structure: Headings must reflect document structure, not visual style preferences
• Captions: All video content must have captions; auto-captions must be reviewed before publishing
• Document accessibility: PDFs and Word documents must meet accessibility requirements before posting
• Tables: Must have captions and header markup — cannot be used for layout

Accountability

Content authors are accountable for:

• Writing alt text for every non-decorative image they publish
• Using heading styles (H2, H3) rather than bold text for section structure
• Reviewing and correcting auto-generated captions before publishing video
• Linking to PDFs only when an HTML alternative is provided or the PDF has been made accessible
• Writing descriptive link text that makes sense out of context

Common content author mistakes

Mistake	Consequence
”Click here” and “Read more” link text	Screen reader users cannot identify link destinations by navigating links
Alt text = “image.jpg” or “photo”	No useful information; screen reader announces filename or generic description
Publishing unreviewed auto-captions	Inaccurate captions misrepresent content; legal liability under AODA
Using bold text for visual headings instead of heading styles	Screen readers cannot navigate by heading; reading order is lost
Pasting unformatted content from Word	Heading and list structure is lost; accessibility fails
No alt text on charts, graphs, or infographics	Data in visual form is inaccessible to screen reader users
Using tables for visual layout	Screen readers announce table cell context that makes no sense in a layout table

Practical steps

• Run WAVE (wave.webaim.org) on pages you publish — it catches missing alt text, poor link text, and heading errors
• Create a pre-publish checklist: alt text on all images, captions on all video, headings are heading styles, link text is descriptive
• Ask the question: “If someone is listening to this page with their eyes closed, does the content make sense?”

QA / Tester

What you control

• Automated scan coverage: Whether accessibility scans run against all pages and components
• Keyboard testing: Whether keyboard walkthroughs are part of the test protocol
• Screen reader coverage: Whether screen reader testing is part of the release checklist
• Regression: Whether accessibility is tested after every significant change, not just at first release
• Documentation: Whether accessibility failures are logged with sufficient detail for developers to fix

Accountability

QA teams are accountable for:

• Running automated accessibility scans as part of the standard test suite
• Including keyboard walkthrough in test plans for all user flows
• Testing with at least one screen reader (NVDA+Chrome is the minimum)
• Blocking release on Level A and AA failures
• Retesting remediated accessibility issues — accessibility fixes are as likely to regress as any other fix

Practical steps

• Add accessibility to your test plan template: automated scan results, keyboard walkthrough, screen reader check
• Use the Testing and Evaluation page on this site as your testing protocol
• Include accessibility in smoke tests after every deployment

Accessibility Champion / Lead

Not every organization has a dedicated accessibility role. Where one exists:

What you control

• Standards: Maintaining and communicating the organization’s accessibility standard and target level
• Training: Ensuring all roles have appropriate accessibility knowledge
• Tooling: Selecting and maintaining testing tools
• Review: Conducting or commissioning periodic audits
• Escalation: Providing a route for teams to get accessibility guidance before committing to implementations
• Community: Connecting practitioners across teams; sharing knowledge

Common mistakes of accessibility programs

Mistake	Consequence
Single point of failure — one person “owns” accessibility	Person leaves; institutional knowledge and commitment collapse
Standards without enforcement	Teams know what to do but face no consequences for not doing it
Compliance-only framing	Teams optimize for passing scans, not for usability by disabled people
No user testing with disabled users	Passes WCAG but still has significant usability barriers
No training budget	Practitioners cannot build the skills needed to sustain accessible work

Related pages

• Training Paths — Role-specific learning paths for each of the roles above
• Testing and Evaluation — What each role should test
• Procurement — How procurement teams evaluate vendor accessibility
• Plain Language Writing — The content author’s primary technical guide
• Development Practices — The developer’s primary technical guide
• Design Principles — The designer’s primary technical guide