stakeholder-communication

Name: stakeholder-communication
Author: Owl-Listener

82stars25forks

How to install stakeholder-communication?

owl-listener/inclusive-design-skills/stakeholder-communication

$npx -y skills add Owl-Listener/inclusive-design-skills --skill stakeholder-communication

Installs into the current project.

Summary

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:

Files · 1

View on GitHub

SKILL.md

1	# Stakeholder Communication
2
3	Communicate accessibility decisions in language that resonates with
4	the person you're talking to — because the right argument depends
5	on who's listening.
6
7	## Core Principle
8
9	Different stakeholders care about different things. The accessibility
10	argument that moves a CFO is not the one that moves an engineer.
11	Match your framing to their priorities.
12
13	## Stakeholder Frames
14
15	### For Executives and Leadership
16	They care about: risk, revenue, reputation, legal exposure.
17
18	Frame accessibility as:
19	- Risk reduction: "Non-compliance exposes us to legal action.
20	ADA lawsuits increased every year for the past decade. The
21	European Accessibility Act is now in effect."
22	- Market size: "15% of the global population has a disability.
23	That's over 1 billion potential users we're currently excluding."
24	- Brand reputation: "Accessibility failures become public
25	quickly. Accessibility leadership becomes a differentiator."
26	- Cost avoidance: "Fixing accessibility at the design stage
27	costs 10x less than fixing it after launch and 100x less than
28	fixing it after a lawsuit."
29
30	### For Product Managers
31	They care about: user satisfaction, completion rates, scope, timeline.
32
33	Frame accessibility as:
34	- Conversion improvement: "Users who can't complete the flow
35	don't convert. Every accessibility barrier is a drop-off point."
36	- User satisfaction: "Accessibility improvements consistently
37	improve satisfaction scores for ALL users, not just those with
38	disabilities."
39	- Scope clarity: "Here are the specific acceptance criteria.
40	They're not extra work — they're the definition of done."
41	- Competitive advantage: "Our competitors don't do this well.
42	Accessibility is a real differentiator in procurement decisions."
43
44	### For Engineers
45	They care about: clarity, specificity, standards, implementation cost.
46
47	Frame accessibility as:
48	- Clear specifications: "Here's exactly what needs to happen:
49	specific WCAG criteria, specific attributes, specific behaviour."
50	- Code quality signal: "Accessible code is well-structured code.
51	Semantic HTML, logical DOM order, and proper state management
52	are engineering best practices regardless of accessibility."
53	- Testing criteria: "Here's how to test it: these keyboard
54	sequences, these screen reader announcements, these contrast
55	ratios."
56	- Prevention over remediation: "Building it right now is faster
57	than fixing it after QA finds it."
58
59	### For Designers
60	They care about: user experience, craft, professional standards.
61
62	Frame accessibility as:
63	- Design quality: "Accessible design is better design. Clear
64	hierarchy, consistent patterns, plain language, and forgiving
65	interactions improve the experience for everyone."
66	- Professional standard: "Accessibility is not a constraint on
67	creativity. It's a design requirement, like responsive design
68	or performance."
69	- User empathy: "We design for real people in real contexts.
70	Disability is part of that reality."
71
72	## Structuring the Conversation
73
74	### When Asking for Resources
75	1. State the specific user problem (not the technical requirement)
76	2. Quantify who's affected (numbers, not percentages alone)
77	3. Show the fix and its scope (specific, bounded, achievable)
78	4. Connect to something they already care about (legal, revenue, brand)
79
80	### When Pushing Back on Cuts
81	1. Name exactly who gets excluded by the cut
82	2. State the severity (blocked vs friction)
83	3. Offer an alternative scope reduction that doesn't sacrifice
84	accessibility
85	4. Document the decision if overruled (this protects everyone)
86
87	### When Reporting Progress
88	- Lead with outcomes: "3 more user groups can now complete checkout"
89	- Show before/after: concrete improvements, not abstract compliance
90	- Connect to metrics they track: completion rate, support tickets,
91	satisfaction scores
92	- Avoid jargon: "users who can't see the screen" not "JAWS users
93	encountering ARIA violations"
94
95	## Anti-Patterns
96
97	- Leading with compliance alone (feels like box-ticking, not value)
98	- Using guilt ("disabled people can't use our product")
99	- Being vague ("we need to improve accessibility")
100	- Framing as optional ("it would be nice to...")
101	- Treating accessibility as a separate project rather than part
102	of quality
103
104	## Assessment Questions
105
106	1. Can you articulate the accessibility argument in terms each
107	stakeholder cares about?
108	2. Are accessibility requirements presented as specific acceptance
109	criteria, not vag

People who liked this also viewed

6 picks

Type

stakeholder-communication

82stars25forks

View on GitHub

How to install stakeholder-communication?

owl-listener/inclusive-design-skills/stakeholder-communication

$npx -y skills add Owl-Listener/inclusive-design-skills --skill stakeholder-communication

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Stakeholder Communication
2
3	Communicate accessibility decisions in language that resonates with
4	the person you're talking to — because the right argument depends
5	on who's listening.
6
7	## Core Principle
8
9	Different stakeholders care about different things. The accessibility
10	argument that moves a CFO is not the one that moves an engineer.
11	Match your framing to their priorities.
12
13	## Stakeholder Frames
14
15	### For Executives and Leadership
16	They care about: risk, revenue, reputation, legal exposure.
17
18	Frame accessibility as:
19	- Risk reduction: "Non-compliance exposes us to legal action.
20	ADA lawsuits increased every year for the past decade. The
21	European Accessibility Act is now in effect."
22	- Market size: "15% of the global population has a disability.
23	That's over 1 billion potential users we're currently excluding."
24	- Brand reputation: "Accessibility failures become public
25	quickly. Accessibility leadership becomes a differentiator."
26	- Cost avoidance: "Fixing accessibility at the design stage
27	costs 10x less than fixing it after launch and 100x less than
28	fixing it after a lawsuit."
29
30	### For Product Managers
31	They care about: user satisfaction, completion rates, scope, timeline.
32
33	Frame accessibility as:
34	- Conversion improvement: "Users who can't complete the flow
35	don't convert. Every accessibility barrier is a drop-off point."
36	- User satisfaction: "Accessibility improvements consistently
37	improve satisfaction scores for ALL users, not just those with
38	disabilities."
39	- Scope clarity: "Here are the specific acceptance criteria.
40	They're not extra work — they're the definition of done."
41	- Competitive advantage: "Our competitors don't do this well.
42	Accessibility is a real differentiator in procurement decisions."
43
44	### For Engineers
45	They care about: clarity, specificity, standards, implementation cost.
46
47	Frame accessibility as:
48	- Clear specifications: "Here's exactly what needs to happen:
49	specific WCAG criteria, specific attributes, specific behaviour."
50	- Code quality signal: "Accessible code is well-structured code.
51	Semantic HTML, logical DOM order, and proper state management
52	are engineering best practices regardless of accessibility."
53	- Testing criteria: "Here's how to test it: these keyboard
54	sequences, these screen reader announcements, these contrast
55	ratios."
56	- Prevention over remediation: "Building it right now is faster
57	than fixing it after QA finds it."
58
59	### For Designers
60	They care about: user experience, craft, professional standards.
61
62	Frame accessibility as:
63	- Design quality: "Accessible design is better design. Clear
64	hierarchy, consistent patterns, plain language, and forgiving
65	interactions improve the experience for everyone."
66	- Professional standard: "Accessibility is not a constraint on
67	creativity. It's a design requirement, like responsive design
68	or performance."
69	- User empathy: "We design for real people in real contexts.
70	Disability is part of that reality."
71
72	## Structuring the Conversation
73
74	### When Asking for Resources
75	1. State the specific user problem (not the technical requirement)
76	2. Quantify who's affected (numbers, not percentages alone)
77	3. Show the fix and its scope (specific, bounded, achievable)
78	4. Connect to something they already care about (legal, revenue, brand)
79
80	### When Pushing Back on Cuts
81	1. Name exactly who gets excluded by the cut
82	2. State the severity (blocked vs friction)
83	3. Offer an alternative scope reduction that doesn't sacrifice
84	accessibility
85	4. Document the decision if overruled (this protects everyone)
86
87	### When Reporting Progress
88	- Lead with outcomes: "3 more user groups can now complete checkout"
89	- Show before/after: concrete improvements, not abstract compliance
90	- Connect to metrics they track: completion rate, support tickets,
91	satisfaction scores
92	- Avoid jargon: "users who can't see the screen" not "JAWS users
93	encountering ARIA violations"
94
95	## Anti-Patterns
96
97	- Leading with compliance alone (feels like box-ticking, not value)
98	- Using guilt ("disabled people can't use our product")
99	- Being vague ("we need to improve accessibility")
100	- Framing as optional ("it would be nice to...")
101	- Treating accessibility as a separate project rather than part
102	of quality
103
104	## Assessment Questions
105
106	1. Can you articulate the accessibility argument in terms each
107	stakeholder cares about?
108	2. Are accessibility requirements presented as specific acceptance
109	criteria, not vag

People who liked this also viewed

6 picks

Type