stakeholder-communication

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

1. State the specific user problem (not the technical requirement)
2. Quantify who's affected (numbers, not percentages alone)
3. Show the fix and its scope (specific, bounded, achievable)
4. Connect to something they already care about (legal, revenue, brand)

When Pushing Back on Cuts

1. Name exactly who gets excluded by the cut
2. State the severity (blocked vs friction)
3. Offer an alternative scope reduction that doesn't sacrifice accessibility
4. 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

1. Can you articulate the accessibility argument in terms each stakeholder cares about?
2. Are accessibility requirements presented as specific acceptance criteria, not vague aspirations?
3. Is progress reported in user outcomes, not technical compliance?
4. When accessibility is deprioritised, is the decision and its impact documented?