a11y Stakeholders — Who Is Responsible for Accessibility

In this tutorial, you will learn about a11y stakeholders. We cover key concepts, practical examples, and best practices to help you master this topic.

Accessibility is everyone's responsibility in an organization: executives fund it, product managers prioritize it, designers create inclusive interfaces, developers implement accessible code, QA tests with assistive technology, and content writers use plain language.

What You'll Learn

You will learn which roles in an organization are responsible for accessibility, what each role should do, and how to build a culture of shared accessibility ownership.

Why It Matters

Accessibility fails when it is seen as one person's job. When every team member owns a piece of accessibility, barriers are caught earlier and fixed faster.

Real-World Use

DodaTech assigns an accessibility champion in every product team. The Durga Antivirus Pro team includes a dedicated accessibility specialist who reviews designs, code, and documentation before release.

flowchart TD
  A[Accessibility Stakeholders] --> B[Executives]
  A --> C[Product Managers]
  A --> D[Designers]
  A --> E[Developers]
  A --> F[QA Engineers]
  A --> G[Content Writers]
  A --> H[Legal Team]
  B --> I[Budget and policy]
  C --> J[Prioritize a11y work]
  D --> K[Inclusive UI design]
  E --> L[Semantic HTML, ARIA]
  F --> M[Test with assistive tech]
  G --> N[Plain language, alt text]
  H --> O[Compliance and risk]

Executives

Executives set the tone. When the CEO says accessibility matters, the organization listens. Executives allocate budget for accessibility tools, training, and remediation. They include accessibility in the company's mission and values.

What Executives Should Do

Publish an accessibility policy. Fund accessibility training for all employees. Require VPAT documentation for procurement. Include accessibility in product requirements.

Product Managers

Product managers decide what gets built and when. They prioritize accessibility issues alongside feature work rather than relegating them to a separate backlog.

What Product Managers Should Do

Include accessibility acceptance criteria for every feature. Schedule regular accessibility audits. Track accessibility metrics like WCAG violation counts over time.

Designers

Designers create the interfaces that users interact with. They choose colors, layout, typography, and interaction patterns that either include or exclude users.

What Designers Should Do

Use accessible color palettes validated for contrast. Design visible focus states for every interactive element. Create designs that work at 400 percent zoom. Annotate Figma components with ARIA information.

/* Designer-specified focus token */
:root {
  --focus-ring: 2px solid #005fcc;
  --focus-offset: 2px;
}

Developers

Developers build what designers create. They translate designs into semantic HTML, CSS, and JavaScript that assistive technologies can parse.

What Developers Should Do

Use semantic HTML elements by default. Add ARIA only when native semantics are insufficient. Ensure keyboard navigation for all interactive elements. Test each component with a screen reader before marking it done.

<!-- Developer implements accessible button -->
<button type="button" onclick="handleClick()" aria-pressed="false">
  Enable security mode
</button>

QA Engineers

QA engineers catch what others miss. They test with assistive technologies that developers may not use daily.

What QA Engineers Should Do

Include accessibility test cases in every test plan. Test with keyboard-only navigation. Test with NVDA or VoiceOver screen reader. Test at 200 percent and 400 percent zoom. Test with Windows High Contrast Mode.

Content Writers

Content writers create the words people read. They write alt text, error messages, instructions, and documentation.

What Content Writers Should Do

Write descriptive alt text for images. Use plain language accessible to users with cognitive disabilities. Write clear error messages that suggest fixes. Use descriptive link text instead of click here.

Legal Team

The legal team monitors Compliance with accessibility laws and manages lawsuit risk.

What Legal Teams Should Do

Track applicable accessibility laws in each region. Review VPAT documentation. Respond to accessibility complaints and demand letters. Ensure procurement contracts include accessibility requirements.

// Stakeholder responsibility tracking
const a11yResponsibilities = {
  executive: ['Policy', 'Budget', 'Culture'],
  productManager: ['Prioritization', 'Criteria', 'Metrics'],
  designer: ['Color', 'Focus', 'Zoom', 'Annotations'],
  developer: ['Semantic HTML', 'ARIA', 'Keyboard', 'Testing'],
  qa: ['Test cases', 'Screen reader', 'Keyboard', 'Zoom'],
  content: ['Alt text', 'Plain language', 'Error messages'],
  legal: ['Compliance', 'VPAT', 'Contracts']
};

function getRoleResponsibilities(role) {
  return a11yResponsibilities[role] || [];
}

console.log(getRoleResponsibilities('developer'));

Expected output:

['Semantic HTML', 'ARIA', 'Keyboard', 'Testing']

Common Mistakes

1. Making One Person the Accessibility Hero

Accessibility champions burn out when they are the only ones who care. Build a culture where everyone owns a piece.

2. Skipping Designer Involvement

Developers cannot fix accessibility alone. Many issues originate in design: color choices, focus states, and layout decisions.

3. Not Including Accessibility in Acceptance Criteria

If accessibility is not in the definition of done, it will not be done. Add a11y criteria to every user story.

4. Forgetting Content Writers

Alt text and plain language are accessibility requirements. Content writers need training and guidelines.

5. Testing Only at the End

Accessibility Testing should happen at every stage: design review, code review, QA testing, and user acceptance testing.

6. No Executive Sponsorship

Without executive support, accessibility competes with feature work for resources and always loses.

7. Ignoring Procurement

Legal teams must ensure that third-party tools and services meet accessibility requirements before purchase.

Practice Questions

1. Why should accessibility not be one person's job?

When one person owns accessibility, a single point of failure exists. Burnout and turnover can destroy progress. Shared ownership is more resilient.

2. What should product managers include in every user story?

Accessibility acceptance criteria. For example: all functionality is keyboard accessible, color contrast meets WCAG AA, and images have alt text.

3. What is the designer's primary accessibility responsibility?

Creating inclusive visual designs with proper color contrast, visible focus states, zoom-friendly layouts, and ARIA annotations.

4. What is the developer's primary accessibility responsibility?

Building semantic HTML structures, implementing keyboard navigation, adding appropriate ARIA, and testing with screen readers.

5. Challenge: Map the stakeholders in your organization. Identify which roles are currently involved in accessibility and which gaps exist.

FAQ

Mini Project

Create an accessibility responsibility matrix for your team or organization. List every role and what accessibility tasks they own. Present it to your team and identify gaps.

What's Next

Explore Inclusive Design as the broader methodology that includes accessibility as one outcome. Then learn about Universal Design principles.