アクセシビリティ成熟度モデル

英語名 Accessibility Maturity Model
読み方 アクセシビリティ マチュリティ モデル
難易度
所要時間 1〜2時間(現状評価)
提唱者 W3C ARRM(Accessibility Roles and Responsibilities Mapping)やTPGiの成熟度評価を統合
目次

ひとことで言うと
#

組織のアクセシビリティ(a11y)対応状況を5段階のレベルで評価し、現在地を把握したうえで次のレベルへ進むための具体的なアクションを定義するフレームワーク。個人の善意に頼る「場当たり的な対応」から、組織全体で持続的にa11yを推進する「文化としての対応」へ段階的に移行するためのロードマップを提供する。

押さえておきたい用語
#

押さえておきたい用語
アクセシビリティ(Accessibility / a11y)
障害の有無や利用環境にかかわらず、すべての人がプロダクトやサービスを利用できる状態。a11y は accessibility の略記(aとyの間に11文字)
WCAG(Web Content Accessibility Guidelines)
W3Cが策定するWebアクセシビリティの国際標準ガイドライン。A・AA・AAAの3つの適合レベルがあり、AAが一般的な目標水準。
成熟度レベル(Maturity Level)
組織のa11y対応の進捗度合いを示す段階。初期(無自覚)から最適化(継続的改善)まで段階的に進む。
a11yチャンピオン(Accessibility Champion)
チーム内でa11yの知識を持ち、推進役を担う人。全員が専門家でなくても、チャンピオンがいることで組織全体の意識が上がる。
インクルーシブデザイン(Inclusive Design)
最初から多様なユーザーを想定して設計するアプローチ。a11yは結果としての品質基準、インクルーシブデザインはそこに至るプロセス

アクセシビリティ成熟度モデルの全体像
#

アクセシビリティ成熟度モデル:5段階で組織のa11y対応を評価・向上させる
アクセシビリティ成熟度の5段階Lv.1 無自覚a11y未着手認識なしLv.2 場当たり個人の善意で対応Lv.3 計画的ガイドラインプロセス整備Lv.4 統合開発プロセスに組み込みLv.5 最適化継続的改善文化として定着評価の4軸: 組織体制 | プロセス | 技術・ツール | 文化・教育
アクセシビリティ成熟度向上のフロー
1
現在地を評価する
4軸で現状のレベルを判定
2
次レベルの要件を確認
1段上に必要なアクションを整理
3
ロードマップを策定
四半期単位で実行計画を作成
定期的に再評価
半年ごとにレベルを再判定し計画を更新

こんな悩みに効く
#

  • アクセシビリティに取り組みたいが、何から始めればいいか分からない
  • 個人の善意で対応しているが、組織全体の取り組みに昇華できていない
  • WCAG準拠を目指しているが、どこまでやれば「十分」なのか基準がない
  • a11y対応がリリース直前の「後付けチェック」になっており、手戻りが大きい

基本の使い方
#

4つの評価軸で現在レベルを判定する

以下の4軸について、自組織がどのレベルにあるかを評価する。

  • 組織体制: a11yの責任者やチャンピオンがいるか。予算が確保されているか
  • プロセス: デザイン・開発・テストのどの段階でa11yを確認しているか
  • 技術・ツール: 自動テストツール(axe、Lighthouse等)やスクリーンリーダーでのテストを実施しているか
  • 文化・教育: チームメンバーがa11yの基礎知識を持っているか。研修があるか

各軸のレベルを1〜5で採点し、最も低い軸が組織全体のボトルネックになる。

次のレベルに必要なアクションを整理する

一気にLv.5を目指すのは非現実的。現在レベル+1の要件に集中する。

  • Lv.1→2: まずa11yの基礎研修を実施し、チーム内に1名のチャンピオンを置く
  • Lv.2→3: WCAG 2.1 AAの社内ガイドラインを策定し、デザインレビューにa11yチェック項目を追加
  • Lv.3→4: CI/CDに自動a11yテスト(axe-core等)を組み込み、リリース基準にa11yスコアを含める
  • Lv.4→5: 障害当事者によるユーザーテストを定期実施し、a11yの改善指標をKPIとして経営に報告
四半期ロードマップを策定する

アクションを時間軸に落とし込み、進捗を追跡可能にする。

  • Q1: 基礎研修 + チャンピオン任命 + 現状監査(自動ツールで主要画面をスキャン)
  • Q2: ガイドライン策定 + デザインシステムにa11yコンポーネントを追加
  • Q3: CI/CDへの自動テスト組み込み + 開発ワークフローへの統合
  • Q4: 障害当事者テストの実施 + 成果の社内共有 + 次年度計画策定
  • ロードマップは経営層にも共有し、予算とリソースの確保を得る
半年ごとに再評価して計画を更新する

成熟度は一方向に進むとは限らない。人の異動やプロダクトの変化で後退もありうる。

  • 半年ごとに4軸の再評価を実施し、レベルの変化を記録する
  • 改善が進んだ軸を確認し、次のボトルネック軸に注力を移す
  • 新規プロダクトや大型リデザイン時には追加のa11y監査をトリガーする

具体例
#

例1:スタートアップがLv.1からLv.3に成長する

従業員45名のBtoC SaaS企業。a11yは「余裕ができたらやる」の位置づけで、WCAG準拠率を調べたこともなかった。きっかけは大手企業との商談で「御社のプロダクトはアクセシビリティ対応していますか?」と聞かれ、答えられなかったこと。

現状評価(Lv.1):

  • 組織体制: a11y担当者なし、予算ゼロ
  • プロセス: デザイン・開発でa11yは一切考慮されていない
  • 技術・ツール: テストツール未導入
  • 文化・教育: 「a11yとは何か」を説明できるメンバーが2名だけ

Q1のアクション(Lv.1→2):

  • エンジニア1名をa11yチャンピオンに任命。週4時間をa11y学習に充当
  • 全エンジニア・デザイナー向けに2時間の基礎研修を実施(WCAG概要、スクリーンリーダー体験)
  • Lighthouseで主要10画面をスキャン → 平均スコア38点

Q2-Q3のアクション(Lv.2→3):

  • WCAG 2.1 AA準拠の社内ガイドライン(20ページ)を策定
  • デザインシステムの全コンポーネントにa11y仕様(ロール、ラベル、コントラスト比)を追記
  • PRレビューのチェックリストにa11y項目(5つ)を追加
  • axe-coreをCI/CDに組み込み、criticalエラーがあるとマージブロック

1年後の成果:

  • Lighthouseスコア: 38点 → 82点
  • WCAG 2.1 AA違反項目: 156件 → 23件
  • 成熟度レベル: Lv.1 → Lv.3
  • 大手企業との商談: a11y対応を説明できるようになり、3社との契約に成功(年間契約額計1,800万円
例2:中規模企業がLv.3からLv.4に移行し開発プロセスに統合する

従業員250名のBtoB SaaS企業。a11yガイドラインは存在するが、実際の開発で参照されることは少なく、リリース直前のチェックで問題が大量に見つかり手戻りが発生していた。直近のリリースでは修正に2週間かかり、ロードマップに遅延が生じた。

現状評価(Lv.3):

  • 組織体制: チャンピオン3名、年間予算あり(ただし少額)
  • プロセス: ガイドラインはあるがリリース前チェックのみ。デザイン段階での確認なし
  • 技術・ツール: Lighthouseは手動実行。CIに未統合
  • 文化・教育: 研修は入社時のみ。継続的な学習機会なし

統合のためのアクション:

  • デザイン段階: Figmaプラグイン(Stark)でコントラスト比・フォントサイズを設計時にチェック。デザインレビューの必須項目にa11yを追加
  • 開発段階: axe-coreをGitHub ActionsのCIに組み込み。criticalとseriousのエラーでPRがブロックされる設定
  • テスト段階: QAチームにスクリーンリーダー(VoiceOver / NVDA)テストのトレーニングを実施。主要フローのa11yテストケースを自動テストスイートに追加
  • 文化: 月1回の「a11yランチ勉強会」を開始。障害当事者をゲストに招き、実際の利用体験を共有

6か月後の成果:

  • リリース前a11yチェックでの手戻り: 平均2週間 → 平均2日(デザイン段階で大半を解消)
  • CI/CDでのa11yテスト合格率: 68% → 94%
  • チーム全体のa11y知識テスト(20問): 平均正答率45% → 78%
  • 成熟度レベル: Lv.3 → Lv.4
例3:大企業がLv.4からLv.5に到達しa11yを文化にする

従業員3,000名のIT企業。5つのプロダクトラインを持ち、a11yはCI/CDに組み込まれているが、プロダクトラインごとに対応レベルにバラつきがあった。また、法的リスク(障害者差別解消法、EU European Accessibility Act)への対応を経営層が懸念し始めていた。

現状評価(Lv.4):

  • 組織体制: a11yチーム5名。各プロダクトにチャンピオン配置
  • プロセス: CI/CDに自動テスト。デザインレビューにa11yチェック
  • 技術・ツール: axe-core、Stark、VoiceOverテスト実施
  • 文化・教育: 研修あり。ただし受講率は**40%**にとどまる

Lv.5に向けたアクション:

  1. 経営レベル: a11yスコアを四半期の経営KPIに追加。プロダクトごとのWCAG準拠率を経営会議で報告
  2. 当事者参加: 障害当事者パネル(視覚障害、聴覚障害、運動障害の方各2名)を組成し、四半期ごとにユーザーテストを実施
  3. 全社教育: 研修を必須化し、a11y基礎(2時間)と職種別応用(デザイナー向け、エンジニア向け、PM向け、各3時間)を体系化
  4. データ駆動: a11yダッシュボードを構築。WCAG違反数の推移、自動テストカバレッジ、当事者テストでの発見件数を可視化
  5. 外部発信: a11yへの取り組みを技術ブログやカンファレンスで発信し、採用ブランディングにも活用

1年後の成果:

  • 全プロダクトのWCAG 2.1 AA準拠率: 72%(バラつき大) → 91%(標準偏差3%)
  • 研修受講率: 40% → 92%
  • 当事者テストでの発見・改善件数: 年間68件
  • 障害のあるユーザーからのサポート問い合わせ: 月45件 → 月18件
  • 成熟度レベル: Lv.4 → Lv.5
  • 副次効果: a11y対応の実績が評価され、政府系大型案件(年間契約3億円)の入札で競合に勝利

やりがちな失敗パターン
#

  1. 一足飛びにLv.5を目指す — 基盤がないままCI/CD統合や当事者テストを始めても形骸化する。現在レベル+1を着実にクリアするのが最短ルート
  2. 自動テストだけで完結する — axeやLighthouseで検出できるのはWCAG違反の**30〜40%**程度。手動テストとスクリーンリーダーテストを組み合わせなければ本質的な品質は担保できない
  3. チャンピオンに丸投げする — チャンピオン1名にすべてを任せるとバーンアウトする。チャンピオンの役割は「推進」であり、実行はチーム全体で分担する
  4. 法的リスクだけを動機にする — 「訴えられないように」という消極的な動機では、最低限の対応で止まる。「すべてのユーザーに価値を届ける」というポジティブな動機で推進した方が、チームのモチベーションが持続する

まとめ
#

アクセシビリティ成熟度モデルは、組織のa11y対応を5段階で評価し、「今どこにいて、次に何をすべきか」を明確にするフレームワークである。重要なのは1段ずつ着実に登ること。Lv.1の組織はまずチャンピオンを1名置いて基礎研修を実施する。Lv.3ならCI/CDへの統合を進める。各段階で「組織体制・プロセス・技術・文化」の4軸をバランスよく引き上げることで、a11yは個人の善意から組織の文化へと進化する。