デジタル庁デザインシステムの活用例：よくあるアクセシビリティの課題とその解決策
- 公開日:
目次
- はじめに
- デジタル庁デザインシステムを採用するメリット
- よくあるアクセシビリティの課題とデジタル庁デザインシステムを活用した解決策（1）
- よくあるアクセシビリティ上の課題とデジタル庁デザインシステムを活用した解決策（2）
- デジタル庁デザインシステムを活用するための準備と注意事項
はじめに
デジタル庁では、主に行政分野や公共分野で利用されることを念頭に構築した「デジタル庁デザインシステム」を提供しています。
●デジタル庁デザインシステムβ版（※外部リンク）
デジタル庁デザインシステムは、ウェブアクセシビリティの確保を最優先に設計したものであること、行政サービスの画面で利用しやすいルールをそろえていることなどが特徴です。例えば、行政機関や公共機関の手続についてオンライン化するプロジェクトを実施する際等、画面設計や画面デザインの検討の段階からデジタル庁デザインシステムを活用することで作業の効率化を図ることができます。
デジタル庁デザインシステムは行政機関や公共機関のみならず、民間事業者を含むどなたでも無料で利用することができます。デジタル庁デザインシステムを活用することで、情報システムの開発工数やコミュニケーションコストの省力化、アクセシビリティの向上にもつながります。
デジタル庁では2025年5月、デジタル庁におけるシステム関連調達の受託事業者等を対象にデジタル庁デザインシステムの勉強会を開催しました。この記事では、よくあるアクセシビリティの課題とデジタル庁デザインシステムを活用した解決策を抜粋して紹介します。ぜひご活用いただければ、幸いです。
●デザインシステムの説明やデジタル庁デザインシステムの特徴については、以下のリンクで紹介しています。
- デザインシステムとは｜デジタル庁デザインシステムβ版（※外部リンク）
●デジタル庁デザインシステムとアクセシビリティの関係については、以下のリンクで紹介しています。
- アクセシビリティ｜デジタル庁デザインシステムβ版（※外部リンク）
デジタル庁デザインシステムを採用するメリット
最新のアクセシビリティの国際規格であるWCAG 2.2の達成基準86項目のうちの43項目で「適合」または「適合が容易」に
アクセシビリティファーストを掲げているデジタル庁デザインシステムは、基本的に日本のアクセシビリティ規格であるJIS X 8341-3:2016に準拠しています。
一方で、このJIS規格は約10年前に策定されたもので、スマートフォンなどのモバイル機器への対応が含まれていないなど現在の基準からすると不十分な点があります。そのため、デジタル庁デザインシステムは、最新のウェブアクセシビリティの国際基準であるWCAG2.2（Web Content Accessibility Guidelines）の達成基準AAおよび同AAAの一部に準拠することとしています。
また、JIS X 8341-3:2016の付属文書で定義されているウェブアクセシビリティ試験を踏まえており、加えて、HTMLのインタラクション等に関するアクセシビリティ基準WAI-ARIA1.2（Web Accessibility Initiative Accessible Rich Internet Applications）にも準拠しています。
このほか今後規格化されるであろうWCAG3.0およびWAI-ARIA1.3のドラフト仕様、CSS（Cascading Style Sheets）の最新基準であるHTML StandardやCSSのLiving Standardなど最新の動向を常に確認しつつ、各種ブラウザのサポート状況を慎重に見定めながら、アクセシビリティに寄与すると判断した最新仕様の技術も取り込んでいます。色使いは色覚多様性に対応したカラーユニバーサルデザイン推奨配色セットを踏まえています。
WCAG2.2には86項目の達成基準がありますが、デジタル庁デザインシステムを利用することで、そのうちの43項目について「適合できる」または「適合が容易になる」ことが可能になります。アクセシビリティ試験における作業の手戻りを減らすことができるため、より比重をかけるべき作業内容に注力できるようにもなると考えています。
さらに、以下のようなメリットもあると想定しています。
- コンポーネントやパーツの呼び名が統一化されることで、コミュニケーションコストが低下
- 一から画面設計を行う必要がなく、パーツを組み合わせることで設計のコストが低下
- 別々のサービスでも同じ場面で同じ利用体験ができるため、利用者の学習コストが低下
サンプルコードをコードスニペットで提供、すぐに活用可能
デジタル庁デザインシステムでは、ガイドラインデザインデータをもとにコンポーネントの一部をHTML/CSS/JavaScriptおよびReact/Tailwind CSSで実装したサンプル集を以コードスニペットとして提供しています。
すべてのサンプルコードは、デジタル庁内のアクセシビリティスペシャリストによるアクセシビリティチェックを実施していることから、キーボード操作、スクリーンリーダーをはじめ、より多くの環境からの利用に対応することができます。
サンプルコードをコードスニペットとして利用するだけでも、アクセシビリティ関連の問題が発生するのを未然に防ぐことにもつながります。
以降のパートでは、よくあるアクセシビリティの課題とデジタル庁デザインシステムを活用した解決策を紹介します。
よくあるアクセシビリティの課題とデジタル庁デザインシステムを活用した解決策（1）
ここでは、画面全体の一部分しか見えない「視野狭窄（きょうさく）」の方に向けたアクセシビリティ対応についてご紹介します。
具体的なアクセシビリティの性能について：視野狭窄の当事者による閲覧に対応
視野狭窄とは、視野の一部が見えなくなり、見える範囲が狭まる障害です。視野狭窄の方の視野では、常に全体の一部しか見えません。
視野狭窄の見え方は、人や症状によってさまざまです。中心部分だけしか見えない人、視野の半分が欠けている人もいますし、視力によっても異なります。見える範囲が狭いため、日常生活に困難が生じるということがイメージできるかと思います。
視野狭窄を考慮したアクセシビリティ1：「操作対象から離れた重要なコンテンツの変化に気づけない」問題と解決策
視野狭窄の方がウェブサイトを閲覧するときに、どのような問題が生じるのか。また、デジタル庁デザインシステムは、問題をどのように解決しているのかを紹介します。
一つ目は、操作対象から離れた重要なコンテンツの変化に気づけない問題です。視野狭窄の場合、画面の一部しか見えず、視野の範囲外で起きた変化に気づくことは難しいからです。
例えば、下の画像のようなお問い合わせフォームがあったとします。
このフォームでは、入力欄からフォーカスが外れたとき、入力に不備があるとリアルタイムで画面右下にエラーメッセージが表示される仕様になっています。画像では、画面右下に赤文字で「氏名を入力してください」という通知が表示されています。
視野狭窄の視野範囲でこのページを見た場合、右下にエラーが出ていることに気づくことができません。下の送信ボタンにフォーカスしても、視野の範囲によっては気づかない可能性があります。
この場合、送信ボタンを押しても送信することができない上、なぜ送信できないのかもわからないほか、そもそもエラーが発生していると認識できない可能性もあります。見えている範囲外で何らかの変化が起こっていても、気づく手段がありません。
このような場合、操作対象の要素に近く、かつ見える範囲に表示することが重要です。
上の画像のように、デジタル庁デザインシステムでは、エラーメッセージは操作対象の真下に配置するよう設計されています。入力欄の真下に表示することで、視野狭窄の視野範囲でもエラーメッセージが表示されていることがわかりますし、送信できない理由を把握することができます。
デジタル庁デザインシステムのコンポーネント実装サンプル集では、以下のように実装されています。こちらを活用いただくことで問題を未然に防ぐことができます。
（コードスニペット（React版）Storybook：インプットテキスト）（※外部リンク）
視野狭窄を考慮したアクセシビリティ2：「右端にある要素に気づかないことがある」問題と解決策
二つ目は、右端にある要素に気づかないことがあるという問題です。右側に単独で配置した要素は見落とされやすくなり、必要な情報が伝わらない可能性があります。
ここでは、FAQページなどでよく使われる「アコーディオン」（コンテンツを開閉できるコンポーネント）を例に紹介します。
例えば、下の画像のようなECサイトのページがあったとします。
ここでは、「お支払い方法」の項目が開いた状態で、その下にある「配送日当日のキャンセルはできません」などをクリックすると、中に格納されているコンテンツが表示されます。
それぞれの見出しの項目がアコーディオンであることは、右側に置かれた矢印のアイコンを見ることで認識することができます。このアイコンを見ることで、コンテンツを開閉できることや現在の開閉状態がわかります。
しかしながら、視野狭窄の視野範囲で見た場合、左からテキストを読み、文章の終わりに到達した状態となっても、右側には何もないように見えてしまいます。右側のアイコンに気づくことができず、コンテンツを開閉できるかどうか認識できません。
このように、単独で離れたところに置かれている要素は見落とされる可能性が高くなります。
もし、見出しの文章が長ければ運良くアコーディオンのアイコンを発見できるかもしれませんが、それは見出しの文章の長さに依存することになり、アコーディオンの有無の伝えやすさは安定しません。
アコーディオンは開くことが前提のユーザーインターフェースです。開くことができると認識させられない場合、ユーザーに必要な情報が伝わらない可能性があります。
この問題に対応するために、デジタル庁デザインシステムでは下の画像のようにアコーディオンの開閉を表すアイコンを冒頭に配置するようにしています。
ここでは左側に開閉アイコンが置かれているため、カーソルを移動しなくても開閉できることがわかりやすくなります。
アイコン自体もボタンのような見た目をしているため、より知覚しやすくなっています。
こちらもデジタル庁デザインシステムのコンポーネント実装サンプル集では、以下のように実装されています。
コードスニペット（React版）Storybook：アコーディオン）（※外部リンク）
こちらを活用いただければ、同じように冒頭にアイコンを配置したアコーディオンを簡単に実装することができます。
視野狭窄を考慮したアクセシビリティ3：「右端にある要素に気づかないことがある」問題と解決策
三つ目の事例も、右端にある要素に気づかないことがあるという問題です。
ウェブサイトに入力欄が設けられているケースで、ラベルと入力欄のフォームコントロールが横に並べられているケースがあります。この場合も視野狭窄の視野範囲では見えにくく、ユーザーが操作する際に大きな負担となります。
例えば、下の画像のようにラベルとフォームコントロールが横並びに配置されているページがあったとします。
ここには2つの入力欄があり、上の氏名入力欄のラベルは右寄せになっているため、左側にはかなりの余白が生じています。また、下の「問題の詳細を教えてください」というラベルは、文字数が多いことでかなり長いものとなっています。
このフォームを視野狭窄の視野範囲で見た場合、「問題の詳細を教え」の部分までしか見えません。テキストを左から読むと、入力欄の存在には気づけるかもしれませんが、まずその移動が大変です。
また、上にある氏名のラベルとフォームは、ラベルの左側に余白があるためラベルとフォームの存在に気づかない可能性が高くなります。
この例ではフォームコントロールは2か所だけですが、例えば10か所ならどうでしょうか。入力の都度、右や左に何度も移動しなければならず、ユーザーにとって大きな負担となります。
このような問題に対して、デジタル庁デザインシステムではフォームのレイアウトを縦方向にすることで対応しています。
下の画像は、先述と同じ内容を、デジタル庁デザインシステムを用いた縦積みのフォームで表示したものです。
縦積みのフォームであれば、左を見ている状態でもラベルを確認でき、ラベルとフォームコントロールのどちらも視野の範囲に入りやすくなります。
フォームコントロールが増えても、縦に移動するだけで進むことができるので、横並びのフォームに比べてユーザーの負担はかなり軽減されるはずです。
視野狭窄を考慮したアクセシビリティ4：「マウスオーバーやマウスアウトで要素が表示・非表示になる」問題と解決策
四つ目は、マウスオーバーやマウスアウトで要素が表示・非表示になっていると視野狭窄の方がウェブサイトを閲覧することが困難になるという問題です。
画面の移動時、マウスを意図せずボタンなどの要素上を通過させてしまうと、マウスオーバーで突然メニューが表示され、もともと読もうとしていたコンテンツが読めなくなってしまいます。メニューは急に表示されるので、ユーザーには非表示にする方法もわかりづらいという問題が生じます。
下の画像を例に説明します。
画像にある通常の例では、左上に「Language 」と書かれた言語切り替えメニューを表示するボタンがあります。意図せずLanguageボタンをマウスオーバーすると、右側の画像にあるマウスオーバーでメニューが表示された状態になります。
この状態では、メニューがコンテンツに覆いかぶさってしまい、コンテンツが読めなくなってしまいます。
デジタル庁デザインシステムのコンポーネントでは、下の図のように対応しています。
デジタル庁デザインシステムでは、マウスオーバーによる表示・非表示は採用していません。上の図のように、すべての要素をクリックで表示・非表示を切り替えられるようにしています。
視野狭窄かどうかにかかわらず、マウスオーバーで表示・非表示するUIは問題となるケースがあるので、クリックで要素の展開ができる実装を推奨しています。
デジタル庁デザインシステムのコンポーネント実装サンプル集では、以下のように実装されています。
（コードスニペット（React版）Storybook ：ランゲージセレクター）（※外部リンク）
よくあるアクセシビリティ上の課題とデジタル庁デザインシステムを活用した解決策（2）
ここでは、「強制カラーモード」での閲覧への対応について紹介します。
具体的なアクセシビリティの性能について：強制カラーモードでの閲覧に対応
強制カラーモードとは、アプリケーションやウェブサイトの色を高コントラストの色に強制的に変更する機能です。ユーザーまたはOSが設定した高コントラストの色に変更することで、テキストの読みやすさやアプリケーション画面の見やすさが向上します。
Windowsでは4種類のテーマから自分にとって読みやすい色に設定することができます。
（※システム設定＞アクセシビリティ＞コントラストテーマから設定）
また、ウェブブラウザのMicrosoft Edgeではブラウザレベルで強制カラーモードの設定が可能です。
なお、macOSにはコントラストテーマのような機能はありませんが、カラー反転やコントラストを上げる機能などを使うことで、読みやすさの調整が可能です。
実際に、Microsoft Edgeを使ったデモが以下になります。
左が強制カラーモード適用前で、右の2つは「夕暮れ」と「砂漠」というコントラストテーマの見た目になります。ぜひご自身でそれぞれのコントラストテーマを実際に試していただければと思います。
強制カラーモードは、主に弱視・ロービジョンの方や視覚過敏、ディスレクシアの方がよく利用している機能です。まぶしい環境下やモニターの影響など、一時的に見にくいという問題で強制カラーモードを使う方もいるかと思います。
ただし、「一時的に見にくい」という問題は、コントラスト比の低いウェブサイトの場合が多く、これは適切なコントラスト比（テキストと背景色の比率が4.5：1以上）を満たすことで基本的には解決可能です。そのため、ここでは強制カラーモードの主な利用者には含まないものとします。
強制カラーモードのウェブ制作者視点の注意事項
次に、ウェブ制作者の方に向けて、強制カラーモードを有効にするとソースコードにどのような影響があるかを説明します。
まず、強制カラーモード時はCSSで設定している背景色、背景画像、影がすべて無視されます。文字色やボーダー色などは、ユーザーもしくはOSがコントラストテーマで設定した色に上書きされます。そのため、ウェブ制作者側でそれらの色を任意の色で上書きすることはできません。
ただし、HTMLのイメージタグなどで入れた画像は強制カラーモードの影響を受けず、そのまま表示されます。この場合、例えばロゴが黒文字の場合は強制カラーモードで背景色が黒になると、ロゴが見えなくなってしまいます。この場合は画像内の文字の下にあらかじめ背景色を入れたり、インラインSVG（Scalable Vector Graphics）を使って塗りや線の色を文字色と連動させたりすることで対応可能です。
以上の注意事項を踏まえて、強制カラーモードを考慮したアクセシビリティについて、デジタル庁デザインシステムではどのように対応しているのか紹介します。
強制カラーモードを考慮したアクセシビリティ①： 「重要な情報が表示されない」問題と解決策
一つ目の問題は、強制カラーモードにすると重要な情報が表示されなくなる可能性があることです。
背景色や背景画像は無視されるため、これらに依存した情報はすべて見えなくなります。特にラジオボタンやチェックボックスなどのフォームコントロールは、見た目を細かく調整するために、一般的にブラウザネイティブのものではなく、背景色や背景画像を用いて実装される場合が多くなります。そのため、強制カラーモードの影響を受けるので注意が必要です。
例えば、下の画像のような荷物の配送希望時間帯を選ぶフォームがあったとします。
ここでは配送希望時間帯をラジオボタンで選択します。通常の見た目では、配送希望時間帯として「14：00-16：00」の選択肢が選ばれていることがわかります。
ところが、強制カラーモードで見ると、「14：00-16：00」を選んでいるにもかかわらず、何も選ばれていないように見えます。ラジオボタンが選択されたときに表示される中央の円の背景色が無視されるためです。
デジタル庁デザインシステムでは、強制カラーモードに応じて重要な情報を適切に表示できるように調整しています。
実際の対応例として、デジタル庁デザインシステムのコンポーネント実装サンプル集を使った下の画像をご覧ください。
画像の左側は先ほどと同じく配送希望時間帯を選ぶラジオボタンのフォームを強制カラーモードで見たものですが、こちらは「14：00-16：00」が選ばれていることがわかるようになっています。右側のチェックボックスの例でも、チェックされている項目がわかります。
デジタル庁デザインシステムのコンポーネント実装サンプル集では、以下のように実装されています。
（コードスニペット（React版）Storybook ：ラジオボタン）
こちらを活用いただければ、ラジオボタンやチェックボックスの問題を解決可能です。
強制カラーモードを考慮したアクセシビリティ2： 「塗りつぶしや影を使用した要素同士の境界がわかりづらい」問題と解決策
二つ目は、塗りつぶしや影を使用した要素同士の境界がわかりづらいという問題です。
メニューなどを格納したドロワー（格納された要素が右・左から出てくるUI）やダイアログで背景色や影だけを用いて要素を区切っている場合、下に表示されているコンテンツとの境界がわからなくなります。
そもそも強制カラーモードでは影は無視されますので、エレベーション（コンポーネントの高さの度合いを示す概念）がなくなります。
下の画像で、具体的な事例を紹介します。
通常の見た目では、右側にメニューを格納したドロワーが表示され、コンテンツ部分をオーバーレイシェード（薄いグレー）で覆うことでドロワーとコンテンツの境界を表現しています。
これを強制カラーモードで見ると、影もオーバーレイシェードもなくなり、コンテンツとの境界がわからなくなります。どこまでがドロワーで、どこからがコンテンツなのか非常にわかりにくくなります。
デジタル庁デザインシステムでは、ドロワーの左側に強制カラーモードの時だけ見えるボーダーを影と一緒に入れることで解決しています。実際の対応例として、下の画像をご覧ください。
通常の見た目は、先ほどと同様の見た目のドロワーですが、強制カラーモードにするとドロワーの左側に縦の白いボーダーが表示されています。
オーバーレイシェードも、強制カラーモードのときにだけ通常よりも不透明度を上げることで視認できるように調整しています。これらの対応で強制カラーモードでもコンテンツとの境界がわかるようにしています。
デジタル庁デザインシステムのコンポーネント実装サンプル集では、以下のように実装しています。
（コードスニペット（React版）Storybook ：ドロワー
強制カラーモードを考慮したアクセシビリティ3：「色を使用した重要度の表現がわからない」問題と解決策
三つ目は、色を使用した重要度の表現がわからないという問題です。
色でボタンの種類を区別したり、重要な情報を赤字で表現したりすることがよくあると思いますが、こうした表現は強制カラーモードでは機能しません。
下の図で具体的な事例を紹介します。
通常の見た目の3つのボタンをご覧ください。一番上は青背景で白文字の塗りボタン、中央は白背景で青いボーダーで囲まれた青文字のアウトラインボタン、一番下は背景色もボーダーもなく青文字のテキストリンクのような見た目のテキストボタンです。
この例では、視覚的に目立つ上の塗りボタンを「重要度：高」、アウトラインボタンを「重要度：中」、テキストボタンを「重要度：低」として設定しています。
これを強制カラーモードで見ると、一番上の「重要度：高」の塗りボタンの背景色が消えてしまい目立たなくなっています。真ん中のアウトラインボタンのボーダーはそのまま残るので、これが最も重要度が高そうに見えてしまいます。
このように、重要度が逆転しているように見えることで、ユーザーが操作ミスを起こしてしまう可能性があります。
この問題も、デジタル庁デザインシステムでは強制カラーモードの時だけ見えるボーダーを使うことで対応しています。実際の対応例として、下の図をご覧ください。
最も重要度の高いボタンに強制カラーモードの時だけ見える二重線を設定しています。これによって、「重要度：高」のボタンが最も目立つようになりました。重要度の逆転も生じていません。
デジタル庁デザインシステムのコンポーネント実装サンプル集では以下のように実装されています。ぜひご参照ください。
コードスニペット（React版）Storybook ：ボタン）（※外部リンク）
具体的なアクセシビリティに関する問題とデジタル庁デザインシステムによる解決策の紹介は以上となります。
デジタル庁デザインシステムを活用するための準備と注意事項
デジタル庁デザインシステムの本体は、以下のリンクの専用サイトで提供しています。
●デジタル庁デザインシステムβ版（※外部リンク）
デジタル庁デザインシステムには、ガイドライン、デザインデータ（Figma）、コードスニペット（HTML版およびReact版）が含まれます。
専用サイトには利用上の注意事項、ガイダンス、カラーやタイポグラフィなど基本デザインの一覧や定義、コンポーネントの仕様、アクセシビリティについてのドキュメントなどがありますので、ご利用前に必ずご確認ください。新しいコンポーネントの追加や仕様変更があった際は、更新情報ページに情報が掲載されます。
デザインデータ（Figma）は、デザイナーの方が個々のサイトやサービスのスタイルガイドを作成する際や、情報設計の担当者が画面イメージを作る際などに活用可能です。FigmaのDevモードでは、マージンやパディングなどのスタイリングの実装に必要な情報を簡単に取得可能です。
エンジニアの方向けには、HTML版とReact版のコードスニペットを提供しているほか、カラーやタイポグラフィが定義されたデザイントークンをCSSのCustom PropertiesやJavaScriptの変数に変換してコード上で使えるパッケージも提供しています。CSS向けには、デザイントークンをユーティリティクラスとして設定済みのプラグインも提供しています。もちろん、デザイントークンはFigma VariablesとしてFimgaデータに含まれていますので、デザイナー・エンジニア間での共通言語として機能します。
なお、デジタル庁デザインシステムのライセンスは、クリエイティブ・コモンズ・ライセンス CC BY 4.0と互換性のある政府標準利用規約（第2.0版）となっており、Figmaデータやコードスニペットも同様です。内容は自由に改変したり、独自コンポーネントを追加したりできますが、本記事でご案内したアクセシビリティの確保（WCAGの達成基準への適合性等）は改変前の状態に限りますので、ガイドラインの記述に従って改変や拡張を行ってください。
是非、デジタル庁デザインシステムをご活用ください。
●デジタル庁ニュースでは、デザインシステムやアクセシビリティに関する記事を掲載しています。以下のリンクをご覧ください。
- デジタル庁のプロフェッショナルが答える、「ウェブアクセシビリティ」10の質問
- 障害当事者と共に挑む デジタル庁のアクセシビリティとは
- アクセシビリティファーストで推進する 「デジタル庁デザインシステム」の現在地
- 省庁の垣根を越えて！ 国民へ届けるつなげる政府ウェブサイトコミュニティ
●デジタル庁ニュースの最新記事は、以下のリンクからご覧ください。