Accessibility Roles in the SDLC: Who Owns What from Product Brief to Production

Accessibility SDLC integration requires clear ownership at every phase. When accessibility is "everyone's job," it often becomes no one's job. Requirements get written without accessibility considerations. Designs get handed off without focus states. Code ships without keyboard testing. QA doesn't include screen reader checks. And production reveals the barriers that ambiguous ownership allowed through.

Mapping accessibility responsibilities across the Software Development Life Cycle ensures accountability without bottlenecks. Every role contributes; each understands their specific responsibilities; nothing falls through the cracks.

This guide provides practical frameworks for accessibility ownership across product management, design, engineering, QA, and beyond—with concrete checkpoints that make accountability clear at every SDLC stage.

Everyone's Job, but No One's Job?

The Ownership Problem

What causes accessibility to fall through the cracks? Without explicit role assignments and checkpoints, each team assumes someone else handles accessibility. Product doesn't include it in requirements because "that's a dev thing." Dev doesn't implement it because "design didn't specify it." QA doesn't test it because "it wasn't in acceptance criteria."

The diffusion of responsibility creates predictable failures:

No requirements: Features launch without accessibility considerations because product briefs didn't mention them.

No design specs: Engineering guesses at focus order, state communication, and keyboard interactions.

No implementation verification: Code reviews don't check accessibility; accessibility isn't part of "done."

No testing coverage: QA plans include functional and visual testing but not accessibility testing.

No accountability: When accessibility fails, everyone points elsewhere.

According to research by Level Access, organizations with clearly defined accessibility roles achieve significantly better compliance rates than those without.

The Solution: Explicit Ownership

Clear role mapping solves the ownership problem:

Named responsibilities: Each role knows exactly what accessibility work belongs to them.

Explicit checkpoints: Handoffs include accessibility verification at defined gates.

Shared understanding: Everyone knows what others are responsible for—reducing gaps and duplicated effort.

Accountability metrics: Ownership enables measurement of who catches issues when.

Mapping Responsibilities Across the SDLC

Product Management

Product managers set the foundation:

Accessibility in requirements:

• Include accessibility requirements in user stories
• Define acceptance criteria that include accessibility
• Prioritize accessibility alongside other product priorities
• Ensure roadmap includes accessibility improvements

User representation:

• Consider users with disabilities in persona development
• Include accessibility in user research
• Advocate for accessibility in prioritization discussions

Documentation expectations:

## User Story: Checkout Flow Redesign

**Acceptance Criteria**:
- [ ] Users can complete checkout using keyboard only
- [ ] Form errors announced to screen readers
- [ ] All form fields have visible labels
- [ ] Focus order follows logical sequence
- [ ] Loading states communicated to assistive technology

Design

Designers create accessible foundations:

Accessible design deliverables:

• Color contrast verification in color choices
• Focus state designs for all interactive elements
• Keyboard interaction documentation
• Responsive behavior including accessibility implications
• Component state documentation (error, loading, disabled)

Handoff specifications:

• Reading order annotations
• Heading structure
• Alternative text suggestions
• ARIA relationship notes
• Touch target sizing

Design checkpoint:

## Design Accessibility Checklist

Before handoff:
- [ ] Color contrast meets WCAG AA (4.5:1 text, 3:1 UI)
- [ ] Focus states designed for all interactive elements
- [ ] Heading hierarchy documented
- [ ] Touch targets minimum 44x44px
- [ ] Error states designed with accessible patterns
- [ ] Form labels positioned and connected
- [ ] Reading order annotated
- [ ] Animation respects reduced motion preferences

Engineering

Developers implement accessible code:

Implementation responsibilities:

• Use semantic HTML as foundation
• Implement keyboard interactions per design spec
• Apply ARIA attributes correctly
• Manage focus appropriately
• Handle dynamic content accessibly

Code review accessibility:

• Verify semantic structure
• Check ARIA usage correctness
• Test keyboard navigation
• Verify focus management
• Run automated accessibility checks

Development checkpoint:

## Development Accessibility Checklist

Before PR merge:
- [ ] Semantic HTML used (not div soup)
- [ ] Interactive elements keyboard accessible
- [ ] Focus visible and managed correctly
- [ ] Form inputs properly labeled
- [ ] Images have appropriate alt text
- [ ] ARIA attributes valid and necessary
- [ ] Color not sole information conveyor
- [ ] Automated tests pass (axe, etc.)

QA

Quality assurance validates accessibility:

Testing responsibilities:

• Include accessibility in test plans
• Perform keyboard testing on all flows
• Conduct screen reader testing
• Verify against acceptance criteria
• Document accessibility bugs clearly

QA accessibility testing:

• Automated scan execution
• Manual keyboard walkthrough
• Screen reader testing (at least one)
• Visual accessibility verification
• Responsive accessibility check

QA checkpoint:

## QA Accessibility Testing Protocol

For each feature:
1. Run automated accessibility scan
2. Keyboard-only navigation test
3. Screen reader announcement verification
4. Color contrast spot check
5. Touch target verification (mobile)
6. Error handling accessibility check

Pass criteria: All tests pass or bugs documented

Legal and Compliance

Legal ensures organizational accountability:

Compliance responsibilities:

• Monitor regulatory requirements
• Define organizational accessibility policy
• Review accessibility statements
• Manage legal risk assessment
• Coordinate incident response for accessibility complaints

Governance role:

• Set organizational accessibility standards
• Establish audit and reporting cadence
• Ensure vendor contracts include accessibility
• Oversee remediation priorities

Example RACI Matrix for Accessibility Tasks

Using RACI for Clarity

How do you assign accessibility responsibilities clearly? Use a RACI matrix defining who is Responsible (does the work), Accountable (owns the outcome), Consulted (provides input), and Informed (kept updated) for each accessibility task.

Sample RACI matrix for accessibility:

| Task                             | Product | Design  | Dev     | QA      | Legal   |
|----------------------------------|---------|---------|---------|---------|---------|
| Include a11y in requirements     | **A/R** | C       | C       | I       | I       |
| Design accessible patterns       | C       | **A/R** | C       | I       | I       |
| Create focus state specs         | I       | **A/R** | C       | I       | I       |
| Implement accessible code        | I       | C       | **A/R** | C       | I       |
| Write accessibility tests        | I       | I       | C       | **A/R** | I       |
| Conduct screen reader testing    | I       | I       | C       | **A/R** | I       |
| Set compliance standards         | C       | C       | C       | C       | **A/R** |
| Maintain accessibility statement | C       | I       | I       | I       | **A/R** |
| Prioritize accessibility fixes   | **A/R** | C       | C       | C       | C       |

Key: A = Accountable, R = Responsible, C = Consulted, I = Informed

Common Variations

Organizations adapt RACI based on structure:

Dedicated accessibility role: When present, may take Accountable role for many tasks, with others Responsible for execution.

Centralized QA: QA team may handle all testing responsibilities.

Designer-developer pairs: Shared responsibility for component implementation.

External auditors: Consulted for compliance verification, not ongoing tasks.

Embedding Accessibility Checkpoints in Each Stage

Stage-by-Stage Verification

Build accessibility gates into your workflow:

Brief/Discovery:

• Checkpoint: Accessibility requirements documented
• Gate: Cannot proceed to design without accessibility acceptance criteria
• Owner: Product Manager

Design:

• Checkpoint: Design accessibility checklist completed
• Gate: Cannot proceed to development without accessibility specs
• Owner: Designer

Development:

• Checkpoint: Code accessibility checklist completed
• Gate: Cannot merge without accessibility verification
• Owner: Developer

QA:

• Checkpoint: Accessibility testing protocol completed
• Gate: Cannot release without accessibility test sign-off
• Owner: QA Engineer

Release:

• Checkpoint: Accessibility regression scan
• Gate: Deployment includes accessibility verification
• Owner: Release Manager / DevOps

Post-Release:

• Checkpoint: Monitor accessibility in production
• Gate: Accessibility incidents trigger remediation process
• Owner: Product + Engineering

Gate Enforcement

Make checkpoints meaningful:

Automated enforcement:

# CI/CD accessibility gate
- name: Accessibility Check
  run: npm run test:a11y
  continue-on-error: false  # Blocks merge on failure

Process enforcement:

• PR templates require accessibility verification
• Design handoff includes accessibility sign-off
• Sprint completion requires accessibility testing
• Release checklist includes accessibility items

Using Automation to Support Each Role

TestParty as Shared Source of Truth

TestParty provides role-appropriate accessibility views:

For Product:

• Dashboard showing accessibility status across product areas
• Priority recommendations based on user impact
• Trend reporting for planning

For Design:

• Component-level accessibility analysis
• Pattern recommendations
• Visual issue identification

For Engineering:

• Code-level fix suggestions
• CI/CD integration for automated checks
• PR-level accessibility feedback

For QA:

• Comprehensive test coverage reporting
• Regression detection between releases
• Issue tracking and verification

For Leadership:

• Compliance status reporting
• Progress metrics over time
• Risk visibility

Automation Across Roles

Automation supports without replacing human judgment:

What automation provides:

• Consistent baseline checking
• Regression detection
• Coverage metrics
• Issue identification at scale

What humans provide:

• Context and priority judgment
• Complex interaction evaluation
• User experience assessment
• Creative problem-solving

Frequently Asked Questions

Should we hire a dedicated accessibility person?

Depends on organization size and digital footprint. Small teams can distribute responsibility with champions. Larger organizations benefit from dedicated accessibility expertise—either internal or through partnerships. Even with dedicated roles, accessibility remains everyone's responsibility; the specialist provides expertise and coordination.

How do we handle pushback when teams feel accessibility isn't their job?

Connect accessibility to existing responsibilities: designers create usable designs—accessibility is usability; developers write quality code—accessibility is code quality; QA ensures functionality—accessibility is functionality. Executive sponsorship helps establish accessibility as expectation, not optional extra.

What happens when we find accessibility issues in production?

Treat accessibility bugs like other bugs: severity assessment, prioritization, assignment, resolution, verification. Build process to route accessibility issues to appropriate owners. Track and analyze patterns to improve prevention at earlier stages.

How do we measure role accountability for accessibility?

Track metrics by role: requirements including accessibility criteria (Product), design specs with accessibility documentation (Design), code changes with accessibility issues found (Engineering), accessibility test coverage (QA). Review metrics in retrospectives without blame—focus on process improvement.

How often should we review role responsibilities?

Quarterly review of accessibility role assignments and checkpoint effectiveness. Adjust based on: where issues are slipping through, changing team structure, new process implementations, and feedback from teams.

Conclusion: Clarity of Ownership Is the First Accessibility Control

When everyone knows exactly what accessibility work belongs to them, accessibility happens. When ownership is vague, accessibility fails despite good intentions.

Building clear accessibility ownership requires:

• Explicit role mapping defining what each function contributes
• RACI clarity eliminating ambiguity about accountability
• Stage checkpoints ensuring accessibility verification at each gate
• Enforcement mechanisms making checkpoints meaningful, not optional
• Automation support providing consistent checks across roles
• Continuous refinement adjusting as teams and processes evolve

The goal isn't bureaucratic overhead—it's making accessibility natural, expected, and trackable. When ownership is clear, accessibility becomes part of how products get built rather than something extra that someone else should handle.

Want a tailored accessibility RACI for your org? Book a consult and we'll map your roles and tools together.

Related Articles:

• Building Accessibility Checks Into Modern CI/CD Workflows
• Equitable Design: Beyond Accessibility Compliance
• Score Your Accessibility Program: A Practical Maturity Model for 2025