こんにちは!
今日は、デジタル庁のアクセシビリティチームの取り組みを手がかりに、「誰一人取り残さない」を現場でどう形にするかを書きたいと思います。
同庁では、当事者(たとえば全盲のメンバー)を含む専門チームが、企画・設計・開発・テストの各段階に入り込んでいます。これは、世界的に見ても本気度の高い体制だと感じます。
まずはここから見えてくるヒントを、よくある悩みとセットで考えていきますね。
参考リンク:
- デジタル庁ニュース「障害当事者と共に挑む デジタル庁のアクセシビリティとは(動画)」 https://digital-agency-news.digital.go.jp/articles/2024-12-05
- デジタル庁「アクセシビリティ・ステートメント(英語)」 https://www.digital.go.jp/en/accessibility-statement
要約
「基準に適合=終わり」ではなく、「使える=始まり」です。
JIS X 8341-3やWCAGに準拠することは重要ですが、実際に使えるかは別軸です。そこで大事なのは、
1)初期から当事者と専門家を入れること。
2)DoD(完成の定義)にアクセシビリティを組み込むこと。
3)ALTテキスト・キーボード操作・コントラスト・音声での操作など“日々の作法”をチーム全員が共有すること。
4)公開後も試験結果やステートメントを出して改善を回すこと、です。
また、2024年4月から「合理的配慮」は民間事業者にも義務になりました。「環境の整備」(例:ウェブの情報アクセシビリティ向上)は努力義務ですが、先回りして設計しておくと良いと考えます。
参考リンク:
- 内閣府「障害者差別解消法に基づく基本方針(合理的配慮の義務化)」
https://www.cao.go.jp/press/new_wave/20230331_00008.html - 内閣府ポータル「環境の整備とは」
https://shougaisha-sabetukaishou.go.jp/kankyonoseibi/
問題提起:「アクセシビリティ=障害のある人だけの話」ではない?
「自分のサービスにユーザー補助は不要では?」という声、まだまだ耳にします。自分の業界やサービスでは「健常者」「五体満足」の人のみが対象で、そこに該当しない人は考慮しない、というものです。
ラーメン屋さんや飲食店なんかでは中には「子どもお断り」「早く食べられない人お断り」なんて場合で客を排除することをする場合もあります。
でも、朝の強い日差しで画面が見えにくい。満員電車で片手操作しかできない。子どもが寝ているので音声を出せない。こうした“誰にでも起きる条件”でも、アクセシビリティの考えは重要になります。
さらに、直接の当事者も少なくありません。厚生労働省の調査(令和4年時点)では、身体障害者手帳所持者約415.9万人、療育手帳約114.0万人、精神障害者保健福祉手帳約120.3万人という推計があります。合計で約650万人規模です。対象は決して小さくありません。
20人に一人の割合でなにかしら障害や問題、できないことを抱えていて、更に言えば「環境や状況によってできない場合」を考慮するとその数はもっと多いはずです。
参考リンク:
- 厚生労働省「令和4年 生活のしづらさなどに関する調査(結果概要)」
https://www.mhlw.go.jp/content/12201000/001271100.pdf
一般論への疑問:「JISに準拠したからOK」で本当にいい?
多くの現場で「JIS X 8341-3:2016のAAに準拠しました、このページとこのページが達成しています、以上」というゴール設定を見かけます。もちろん、標準に寄せるのは正しい姿勢です。
ただし、標準は“最低ラインをそろえる”ためのものです。使いやすさの天井ではありません。
たとえばデジタル庁は、JIS準拠の試験に加えて当事者テストを繰り返し、マイナポータルのリニューアルではAA準拠に加え一部AAA項目まで対応しています。さらに、試験方法と結果の公開にも踏み込んでいます。
紙の上の達成基準だけでなく、実装の品質確認と運用の透明性まで見ているのがポイントです。
参考リンク:
- デジタル庁「マイナポータル|ウェブアクセシビリティ(ステートメント)」
https://services.digital.go.jp/mynaportal/accessibility-statement/ - デジタル庁「事例:マイナポータル(JIS準拠)」
https://www.digital.go.jp/resources/user-centered-approach-guidebook/case-study/mynaportal
納期・人手…現場はいつもカツカツです
正直、現場はいつも余裕がないです。クライアントからの要望と実際のユーザー調査との不整合、ブランドカラーが薄くてコントラストが足りない。カレンダーUIがドラッグ前提になっている。動画の字幕は後回しになりがち。
わかっていても直せない事情があるのが現実です。
さらに「専門家(シニア)レビューを最後に一発」という“打ち上げ花火方式”は、手戻りが雪だるまになります。ここで心を軽くする視点は「行為を小さく前に出す」ことです。
つまり、企画書に要件を書く段階から“キーボード操作可能”“代替テキスト必須”“エラーメッセージはテキストで”“ターゲットサイズ”など、毎日触る設計とコードの粒度に落とすのがコツです。
参考リンク:
- WAIC「WCAG 2.2(日本語訳)— キーボード操作、フォーカス可視性、ターゲットサイズ」
https://waic.jp/translations/WCAG22/
誤解1:「ALTはとりあえず入れておけばいい」
代替テキストは“画像のラベル”ではなく、“その画像がこの文脈で果たす役割”の翻訳です。
装飾なら空のalt=""でスキップし、情報を持つなら簡潔に要点だけを書きます。
W3Cの“ALTディシジョンツリー”を共通言語にすると、判断とレビューが早くなります。長すぎは逆効果なので、目安をチームで決めて運用しましょう。
現場ヒント:
- 情報を運ぶ画像=短く要点だけ。装飾=空ALT。UIアイコン=役割(例:「検索」)。
- 「画像」「写真」などの語は基本不要です(スクリーンリーダーが既に告げるため)。
参考リンク:
- W3C WAI「Images Tutorial — Decision Tree(日本語)」
https://www.w3.org/WAI/tutorials/images/decision-tree/ja
誤解2:「キーボードで一応動けば十分」
“動く”と“快適”には差があります。
フォーカスが見える。トラップがない。タブ順が論理的。モーダルの開閉で焦点が正しく移る。こうした基本はUXの品質として重要なものです。
WCAG 2.2では、フォーカスの可視性やターゲットサイズなど、より“使い勝手”に踏み込んだ達成基準が加わりました。フォームや検索など主要導線は、まずキーボードで触って詰まる箇所を洗い出しましょう。短時間でも学びの密度は高いです。
現場ヒント:
- すべての機能をキーボードで操作できること(ガイドライン2.1)。
- ターゲットサイズは最小24×24 ピクセル相当(ガイドライン2.5.8)。
誤解3:「色の見え方は人それぞれなので仕方ない」
“区別は色だけに頼らない”は鉄則です。
グラフにはパターンやラベルを併記し、エラーには色+テキストで伝達します。コントラスト比も、通常テキスト4.5:1(大きなテキスト3:1)が目安です。
ブランドカラーが薄い場合は、背景を調整する、濃淡の使い分けをルール化するなど、デザイン・実装の両面で妥協点を設計します。必要ならアクセント色の段階(トークン)を増やすと、表現の自由度が上がります。
参考リンク:
- W3C WAI「コントラストと色の使用(基礎)」
https://www.w3.org/WAI/fundamentals/accessibility-principles/#distinguishable
誤解4:「字幕は余裕が出たら対応でいい」
動画は“音声を文字にする”だけでなく、“音がないと伝わらない情報を補う”のが字幕・キャプションの役割です。
行政サービスのように代替が効かない場面では特に重みが増します。制作会社任せにせず、発注仕様に“字幕必須・公開基準”を書いておくと、工数も見積もりもブレにくくなります。
デジタル庁はアクセシビリティ入門ガイドブックを公開し、字幕や代替テキストの考え方を含む実践的な解説を広く提供しています。
参考リンク:
- デジタル庁「ウェブアクセシビリティ導入ガイドブック」
https://www.digital.go.jp/resources/introduction-to-web-accessibility-guidebook - 同PDF(2024/03/29版)
https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/08ed88e1-d622-43cb-900b-84957ab87826/53f76eaa/20240329_introduction_to_weba11y.pdf
誤解5:「法律対応は法務の仕事。プロダクトには関係ない」
2024年4月1日から、事業者にも「合理的配慮の提供」が義務化されました。
現場での“その場対応”を支えるためにも、日頃からの「環境の整備」(例:フォームのエラーをテキストで伝える、情報へのアクセス手段を複線化する等)を進めておくのが最も効率的です。
環境の整備は努力義務ですが、結果的に合理的配慮のコストを下げ、トラブルも減らします。プロダクトの“品質と法令遵守”は一本の線でつながっています。
参考リンク:
- 内閣府「障害者差別解消法に基づく基本方針(合理的配慮の義務化)」
https://www.cao.go.jp/press/new_wave/20230331_00008.html - 内閣府ポータル「環境の整備とは」
https://shougaisha-sabetukaishou.go.jp/kankyonoseibi/
デジタル庁の実践から学ぶ「仕組み化」
1)初期から当事者・専門家を入れる マイナポータルの開発では、デザイン初期からアクセシビリティ専門家が参加し、当事者テストも重ねています。要件化→設計→実装→試験の各段で、判断コストを減らせます。
参考リンク:
- デジタル庁「事例:マイナポータル(JIS準拠)」
https://www.digital.go.jp/resources/user-centered-approach-guidebook/case-study/mynaportal
2)DoDに“毎日触る作法”を入れる
- すべての機能をキーボードで操作可能。
- フォーカス可視・順序論理的。
- 主要導線のターゲットサイズ24×24以上。
- 画像は適切なALT/装飾は空ALT。
- フォームエラーはテキストで明示。
- 動画は字幕・文字起こし。
このレベルが“完了”の最低ラインだとチーム全員が共有できると、レビューの乱立が減ります。
3)公開後の透明性を上げる アクセシビリティ・ステートメントや試験結果の公開は、改善の前提を共有する営みです。マイナポータルはJIS X 8341-3:2016に準拠することを明記し、継続的改善を宣言しています。
参考リンク:
- デジタル庁「マイナポータル|ウェブアクセシビリティ(ステートメント)」 https://services.digital.go.jp/mynaportal/accessibility-statement/
とはいえ:“完全対応”はしんどいのでステップを踏む
ステップ1:見える化 主要導線(トップ→検索→申請→完了)をキーボードで踏査して詰まる箇所を洗い出します。画像資産のALT棚卸しを行います。チケット化の粒度は小さく、分類はUI/本文/メディア/ナビで分けると進みが早いです。
ステップ2:設計の手当て タブ順・フォーカスリング・エラーメッセージ仕様を一枚にまとめます。コンポーネントのターゲットサイズを24×24以上に揃えます。配色トークンを整理し、コントラストの下限を決めます。
ステップ3:実装・検証 重要ページでALT・フォーム・コントラストを集中改修します。5名程度のユーザーテスト(キーボード中心)+当事者レビューを実施します。学びはその日にデザインシステムへ反映します。
ステップ4:公開・宣言 ステートメントを用意し、次回の改善計画(いつ・何を・どう測るか)まで書きます。可能なら試験結果の概要を掲載し、問い合わせ導線に「アクセシビリティに関するご意見」を追加します。
参考リンク:
- デジタル庁「ウェブアクセシビリティ導入ガイドブック」
https://www.digital.go.jp/resources/introduction-to-web-accessibility-guidebook - デジタル庁「マイナポータル|ウェブアクセシビリティ」
https://services.digital.go.jp/mynaportal/accessibility-statement/
よくあるアドバイスの落とし穴を、やさしく回避
「ARIAを足せば解決」
まずネイティブHTMLで意味付けし、必要最低限のARIAに絞ると、読み上げの破綻が減ります。
「音声読み上げでしか使わないから後回し」
字幕やテキスト化は、夜間・騒音・通信不良など“誰にでも起きる”条件で効きます。
「色を変えるとブランドが壊れる」
背景や線の濃度を調整したり、パターン・アイコン併用で“色以外”の手掛かりを増やすと、ブランドは守れます。
「テストはリリース直前に」
早い段階でチェックをするべきところ、テストを最後にまとめてしまう場合、テスト後の修正対応のほうがコストも高くつきます。
というわけで:アクセシビリティは「追加作業」ではなく「作り続ける姿勢」
アクセシビリティは“後付けの要求”ではなく、“日々の作法”だと考えると、一気に現実味が出ます。
デジタル庁のように当事者と専門家が初期から関与するチームは、日本の文脈に合った学びの宝庫です。法律の後押しも入りました。
完璧主義より、まず“誰かのつまずきを一つ減らす”ところから始めると、チームの空気が確実に変わります。今日のどれか一つでも、あなたのプロダクトで試してみてください。思っているよりずっと軽やかに前に進めます。
企業や組織において、作り続ける姿勢という文化が醸成することで、アクセシブルな世の中になっていけばいいなと考えています。
参考リンク
- デジタル庁「ウェブアクセシビリティ導入ガイドブック」
https://www.digital.go.jp/resources/introduction-to-web-accessibility-guidebook - 同 PDF(2024/03/29版)
https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/08ed88e1-d622-43cb-900b-84957ab87826/53f76eaa/20240329_introduction_to_weba11y.pdf - デジタル庁「マイナポータル|ウェブアクセシビリティ」
https://services.digital.go.jp/mynaportal/accessibility-statement/ - デジタル庁「事例:マイナポータル(リニューアルとJIS準拠)」
https://www.digital.go.jp/resources/user-centered-approach-guidebook/case-study/mynaportal - W3C WAI「altディシジョンツリー(日本語)」
https://www.w3.org/WAI/tutorials/images/decision-tree/ja - WAIC「WCAG 2.2(日本語訳)」
https://waic.jp/translations/WCAG22/ - 内閣府「障害者差別解消法に基づく基本方針の改定(合理的配慮の義務化)」
https://www.cao.go.jp/press/new_wave/20230331_00008.html - 内閣府ポータル「環境の整備とは(情報アクセシビリティ等)」
https://shougaisha-sabetukaishou.go.jp/kankyonoseibi/ - 厚生労働省「令和4年 生活のしづらさなどに関する調査(結果概要)」
https://www.mhlw.go.jp/content/12201000/001271100.pdf - W3C WAI「Accessibility Principles」
https://www.w3.org/WAI/fundamentals/accessibility-principles/






