stakeholder-communication

ステークホルダーとのコミュニケーション

相手に響く言葉でアクセシビリティに関する判断を伝えましょう。適切な主張は、誰が聞いているかによって異なるからです。

基本原則

ステークホルダーによって重視することは異なります。CFOを動かすアクセシビリティの主張は、エンジニアを動かすものとは違います。相手の優先事項に合わせて伝え方を調整しましょう。

ステークホルダー別の視点

経営幹部やリーダー向け

重視すること：リスク、収益、評判、法的責任。

アクセシビリティを次のように伝えます：

• リスクの低減：「コンプライアンス違反は法的措置につながる可能性があります。ADA訴訟は過去10年間、毎年増加しています。欧州アクセシビリティ法はすでに施行されています。」
• 市場規模：「世界人口の15％に障害があります。10億人を超える潜在的なユーザーを、私たちは現在排除しています。」
• ブランドの評判：「アクセシビリティの不備はすぐに公になります。アクセシビリティを主導することは差別化要因になります。」
• コストの回避：「アクセシビリティを設計段階で修正するコストは、リリース後に修正する場合の10分の1、訴訟後に修正する場合の100分の1です。」

プロダクトマネージャー向け

重視すること：ユーザー満足度、完了率、スコープ、スケジュール。

アクセシビリティを次のように伝えます：

• コンバージョンの向上：「フローを完了できないユーザーはコンバージョンしません。アクセシビリティの障壁はすべて、離脱ポイントになります。」
• ユーザー満足度：「アクセシビリティの改善は、障害のあるユーザーだけでなく、すべてのユーザーの満足度を着実に高めます。」
• スコープの明確化：「具体的な受け入れ基準はこちらです。追加作業ではなく、完了の定義です。」
• 競争上の優位性：「競合他社はこれを十分に実践できていません。アクセシビリティは調達の判断における実質的な差別化要因です。」

エンジニア向け

重視すること：明確さ、具体性、標準、実装コスト。

アクセシビリティを次のように伝えます：

• 明確な仕様：「必要な対応は次のとおりです。具体的なWCAG基準、具体的な属性、具体的な動作です。」
• コード品質の指標：「アクセシブルなコードは、適切に構造化されたコードです。セマンティックHTML、論理的なDOM順序、適切な状態管理は、アクセシビリティに関係なく、エンジニアリングのベストプラクティスです。」
• テスト基準：「テスト方法はこちらです。これらのキーボード操作、これらのスクリーンリーダーの読み上げ、これらのコントラスト比を確認します。」
• 修正より予防を：「最初から正しく構築するほうが、QAで問題が見つかった後に修正するより早く済みます。」

デザイナー向け

重視すること：ユーザー体験、ものづくりの質、専門家としての基準。

アクセシビリティを次のように伝えます：

• デザインの質：「アクセシブルなデザインは、より良いデザインです。明確な階層、一貫したパターン、平易な言葉、寛容なインタラクションは、すべての人の体験を向上させます。」
• 専門家としての基準：「アクセシビリティは創造性を制限するものではありません。レスポンシブデザインやパフォーマンスと同様に、デザインに必要な要件です。」
• ユーザーへの共感：「私たちは、現実の状況で暮らす現実の人々のためにデザインします。障害もその現実の一部です。」

会話の組み立て方

リソースを求めるとき

1. 具体的なユーザーの問題を伝える（技術要件ではなく）
2. 影響を受ける人の数を示す（割合だけでなく、実数で）
3. 修正内容とその範囲を示す（具体的で、範囲が限定され、実現可能なもの）
4. 相手がすでに重視していること（法務、収益、ブランド）につなげる

削減に異議を唱えるとき

1. 削減によって排除される人を具体的に示す
2. 深刻度を伝える（利用不能か、使いにくさか）
3. アクセシビリティを犠牲にしない代替のスコープ縮小案を提示する
4. 覆された場合は判断を記録する（これは全員を守ります）

進捗を報告するとき

• 成果から伝える：「新たに3つのユーザーグループがチェックアウトを完了できるようになりました」
• 変更前と変更後を示す：抽象的なコンプライアンスではなく、具体的な改善を示す
• 相手が追跡している指標と結び付ける：完了率、サポートへの問い合わせ、満足度スコア
• 専門用語を避ける：「ARIA違反に遭遇しているJAWSユーザー」ではなく、「画面が見えないユーザー」と伝える

アンチパターン

• コンプライアンスだけを前面に出す（価値ではなく、形式的なチェックに感じられます）
• 罪悪感に訴える（「障害のある人は当社の製品を使えません」）
• 曖昧な表現を使う（「アクセシビリティを改善する必要があります」）
• 任意のものとして位置づける（「できれば対応したいのですが……」）
• アクセシビリティを品質の一部ではなく、独立したプロジェクトとして扱う

評価の質問

1. 各ステークホルダーが重視する観点から、アクセシビリティに取り組む理由を説明できますか？
2. アクセシビリティの要件は、曖昧な理想ではなく、具体的な受け入れ基準として示されていますか？
3. 進捗は、技術的なコンプライアンスではなく、ユーザーにもたらす成果として報告されていますか？
4. アクセシビリティの優先度を下げた場合、その決定と影響は記録されていますか？