| name | stakeholder-communication |
| description | Communicate accessibility decisions, requirements, and value to stakeholders who aren't accessibility specialists. Use when presenting accessibility work to leadership, product managers, engineers, or anyone who needs to understand why accessibility decisions matter. Triggers on: stakeholder, business case, justify accessibility, explain accessibility, leadership, executive, ROI, why accessibility, cost of accessibility, persuade, convince, accessibility presentation. |
Stakeholder Communication
Communicate accessibility decisions in language that resonates with
the person you're talking to — because the right argument depends
on who's listening.
Core Principle
Different stakeholders care about different things. The accessibility
argument that moves a CFO is not the one that moves an engineer.
Match your framing to their priorities.
Stakeholder Frames
For Executives and Leadership
They care about: risk, revenue, reputation, legal exposure.
Frame accessibility as:
- Risk reduction: "Non-compliance exposes us to legal action.
ADA lawsuits increased every year for the past decade. The
European Accessibility Act is now in effect."
- Market size: "15% of the global population has a disability.
That's over 1 billion potential users we're currently excluding."
- Brand reputation: "Accessibility failures become public
quickly. Accessibility leadership becomes a differentiator."
- Cost avoidance: "Fixing accessibility at the design stage
costs 10x less than fixing it after launch and 100x less than
fixing it after a lawsuit."
For Product Managers
They care about: user satisfaction, completion rates, scope, timeline.
Frame accessibility as:
- Conversion improvement: "Users who can't complete the flow
don't convert. Every accessibility barrier is a drop-off point."
- User satisfaction: "Accessibility improvements consistently
improve satisfaction scores for ALL users, not just those with
disabilities."
- Scope clarity: "Here are the specific acceptance criteria.
They're not extra work — they're the definition of done."
- Competitive advantage: "Our competitors don't do this well.
Accessibility is a real differentiator in procurement decisions."
For Engineers
They care about: clarity, specificity, standards, implementation cost.
Frame accessibility as:
- Clear specifications: "Here's exactly what needs to happen:
specific WCAG criteria, specific attributes, specific behaviour."
- Code quality signal: "Accessible code is well-structured code.
Semantic HTML, logical DOM order, and proper state management
are engineering best practices regardless of accessibility."
- Testing criteria: "Here's how to test it: these keyboard
sequences, these screen reader announcements, these contrast
ratios."
- Prevention over remediation: "Building it right now is faster
than fixing it after QA finds it."
For Designers
They care about: user experience, craft, professional standards.
Frame accessibility as:
- Design quality: "Accessible design is better design. Clear
hierarchy, consistent patterns, plain language, and forgiving
interactions improve the experience for everyone."
- Professional standard: "Accessibility is not a constraint on
creativity. It's a design requirement, like responsive design
or performance."
- User empathy: "We design for real people in real contexts.
Disability is part of that reality."
Structuring the Conversation
When Asking for Resources
- State the specific user problem (not the technical requirement)
- Quantify who's affected (numbers, not percentages alone)
- Show the fix and its scope (specific, bounded, achievable)
- Connect to something they already care about (legal, revenue, brand)
When Pushing Back on Cuts
- Name exactly who gets excluded by the cut
- State the severity (blocked vs friction)
- Offer an alternative scope reduction that doesn't sacrifice
accessibility
- Document the decision if overruled (this protects everyone)
When Reporting Progress
- Lead with outcomes: "3 more user groups can now complete checkout"
- Show before/after: concrete improvements, not abstract compliance
- Connect to metrics they track: completion rate, support tickets,
satisfaction scores
- Avoid jargon: "users who can't see the screen" not "JAWS users
encountering ARIA violations"
Anti-Patterns
- Leading with compliance alone (feels like box-ticking, not value)
- Using guilt ("disabled people can't use our product")
- Being vague ("we need to improve accessibility")
- Framing as optional ("it would be nice to...")
- Treating accessibility as a separate project rather than part
of quality
Assessment Questions
- Can you articulate the accessibility argument in terms each
stakeholder cares about?
- Are accessibility requirements presented as specific acceptance
criteria, not vague aspirations?
- Is progress reported in user outcomes, not technical compliance?
- When accessibility is deprioritised, is the decision and its
impact documented?
