# Stakeholder Communication

> 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.

- Skill: `owl-listener/stakeholder-communication` (Agent Skill)
- Install (CLI): `npx skillmds@latest add owl-listener/stakeholder-communication`
- Raw SKILL.md: https://api.skillmd.com/api/skills/owl-listener/stakeholder-communication/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Product & Planning
- Author: Owl Listener (https://skillmd.com/u/owl-listener)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/owl-listener/stakeholder-communication

---


# 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?