「アクセシビリティ対応、何をどう進める？」 UIデザイナーによる実践事例と課題：＠IT Techブログ PickUp（TISインテックグループ編）

2024年の法改正などをきっかけに、ウェブやアプリでのアクセシビリティ対応の重要性が急速に高まっています。アクセシビリティは一定の水準まで対応することが求められる一方、現場では予算や期間などの制約を踏まえながら、顧客とともに対応方針を検討していく必要があります。本稿では、UIデザイナーが実際に手掛けたプロジェクトをもとに、検討の流れや実践内容をご紹介します。これからアクセシビリティ対応に取り組む方に向けて、実務で進める際のヒントをお届けします。

[Fintan]

注目のテックブログから「現場の知恵」をあなたに――

各社のエンジニアが発信する「テックブログ」。その熱量を＠IT編集部がピックアップ。 生成AI前提時代に向けて環境が激変する中、“隣のエンジニア”は何を感じ、何を考え、どうアクションしているのか？――試行錯誤のプロセス、成功の鍵、変化に立ち向かうマインドなど現場のリアル、ナレッジを凝縮してお届けします。

本稿はTISインテックグループが運営する、開発現場から生まれた技術ノウハウを公開するサイト「Fintan」上で2025年6月23日に掲載した記事を転載するものです。そのため、用字用語の統一ルールなどが、＠ITのものと異なります。ご了承ください。

連載目次

ウェブアクセシビリティとは

　デジタル庁が公開している『ウェブアクセシビリティ導入ガイドブック』によると

ウェブアクセシビリティは、「利用者の障害の有無やその程度、年齢や利用環境にかかわらず、ウェブで提供されている情報やサービスを利用できること、またはその到達度」を意味すると記述されています。

　このウェブアクセシビリティを達成するには、例えば以下のような点を考慮する必要があります。

• 色の見え方が異なる人がいる。
  例：赤や緑が似た色に感じる人など。
• 周囲の環境によって、文字の視認性が異なる。
  例：日差しの強い屋外では、屋内よりもスマートフォンの文字が見づらい。

　2024年に障害者差別解消法が改正され、「合理的配慮の提供」が民間事業者に義務化されました。このような背景からアクセシビリティ対応の重要性が高まっています。

※以降、本稿の「アクセシビリティ」という言葉はウェブアクセシビリティを指します。

　以降、ウェブアクセシビリティの対応について、あるプロジェクトでの事例を紹介します。

　社会的に重要性が高まっているアクセシビリティ対応について、対応方法の参考になれば幸いです。

アクセシビリティの対応事例

　アクセシビリティの対応を考える際、WCAG（※）などのガイドラインには多くの項目があり、様々な検討や対応が必要です。

　コストや期間が限られる中で何を優先するのか、どこまで対応するのかを考える必要があります。さらにブランディングとの兼ね合いなども考慮しなければなりません。

　ここからは、実際のプロジェクトでの事例を、対応の流れ、具体的な対応内容、より取り組めると良かったところの順に紹介します。

※ WCAGとは、Web Content Accessibility Guidelinesの略で、ウェブコンテンツに対するアクセシビリティ対応のガイドラインです。同じ内容がISO規格やJIS規格として採用されています。

アクセシビリティ対応の流れ

　本プロジェクトでは以下の手順で対応を行いました。

• 利用者・利用環境を確認する
• 対応方針を定める
• 対応方針を関係者全体に共有する
• アクセシビリティ対応を行う
• 対応をチェックする

　図に表すと、下のような流れになります。

　以後、上記手順に沿って、具体的にどのように進めたかを紹介します。

※説明中に使用している画像は、事例説明のために作成した画像であり、実際のプロジェクトのデータではありません。

1. 利用者・利用環境を確認する

　例えば、利用ユーザーは何歳から何歳までか、どのような端末でどのような場所で利用するかという想定を定めます。これにより、どのような対応に注力すべきなのかを明確にすることができます。

2. 対応方針を定める

　本プロジェクトは、アプリ内外を含めてブランド全体のガイドラインが存在しました。それを元にコストなども踏まえた総合的なバランスを考え、対応方針を定めました。対応しないと決めた内容については、対応しなかった理由も明確にしています。

　本プロジェクトで立てた方針を一部紹介します。

• 利用する色彩はWCAGのAAをクリアする。
• 主要画像には代替テキストを設定する。
• ダークモード対応は、サービスの世界観やロゴとの調和を図るために行わない。

　方針を定めた後、資料にまとめてその内容を関係者と合意しました。

3. 対応方針を関係者全体に共有する

　色彩はデザイナーが検討し、代替テキストはエンジニアが実装するなど、アクセシビリティの対応には様々な役割が関わります。そのため、プロジェクト関係者全体でどこまで対応するのか共通認識を持つ必要があります。

　本プロジェクトでは、デザインデータの中で目に入りやすい場所に対応方針が書かれた資料を配置し、いつでも確認できるようにしました。また、馴染みの薄い用語の説明を参考として掲載しました。

　筆者自身は本プロジェクトに途中から参加しましたが、アクセシビリティに関する方針が短くまとまっていたため、すぐに理解することができました。

4. アクセシビリティ対応を行う

　デザイナー複数名による目視で、デザインデータがアクセシビリティに対応できているかチェックを行いました。チェック項目は、対応方針の項目だけでなく、WCAGの項目や、WCAGには記載されていない文字の大きさなどにも踏み込んでいます。

　具体的にアクセシビリティ対応のために改善した例を紹介します。

・例1：対応方針に従う

　色彩については「WCAGのAAをクリア」を対応方針として定めていました。

下記がその内容です。

1.4.3 コントラスト (最低限) : テキスト及び文字画像の視覚的提示に、少なくとも 4.5:1 のコントラスト比がある。ただし、次の場合は除く: (レベル AA)

• 大きな文字: サイズの大きなテキスト及びサイズの大きな文字画像に、少なくとも 3:1 のコントラスト比がある。
• 付随的: テキスト又は文字画像において、次の場合はコントラストの要件はない。アクティブではないユーザインタフェース コンポーネントの一部である、純粋な装飾である、誰も視覚的に確認できない、又は重要な他の視覚的なコンテンツを含む写真の一部分である。
• ロゴタイプ: ロゴ又はブランド名の一部である文字には、最低限のコントラストの要件はない。

『Web Content Accessibility Guidelines (WCAG)2.0』 日本語訳より

　コントラストは、「周囲の色との異なり度」を表します。コントラスト比のチェックには、Adobe Colorのようなチェックツールを用いて確認を行いました。

　例えば、白い背景に薄い色を使用した場合、コントラスト比が不十分で基準に違反することになります。特にタップ領域に薄い色を使用すると、背景が見えない場合、タップできなくなってしまうため対応が必要です。

　本プロジェクトでは、周囲を線で囲むことで対応しました。

・例2：WCAGに従う

　WCAGにはこのような基準があります。

1.4.1 色の使用: 色が、情報を伝える、動作を示す、反応を促す、又は視覚的な要素を判別するための唯一の視覚的手段になっていない。 (レベル A)

『Web Content Accessibility Guidelines (WCAG)2.0』 日本語訳より

　例えば、ステッパーの各ステップの状態を色だけで表していると、区別がつかないことがあります。画像の改善前は色を明暗のみで識別すると、完了済みのステップとこれから実施するステップの違いが分かりません。

　これを改善する場合、色だけでなく、形などを変える必要があります。改善後のようなデザインであれば、色の区別がつかなくても識別することができます。

　このような確認は、目視で全て発見することが難しいため、ツールを用いることをおすすめします。今回は、「Color Blindly」というChromeの拡張機能を用いました。

・例3：信頼できるデザインガイドラインに従う・デザイナーの手で確認する

　文字のサイズについて、WCAGでは大きさを変更できるようにするべきという基準はありますが、サイズの値に関する具体的な規定はありません。しかし、文字の大きさの変更はスマートフォンなどの設定を変更する必要があるため、設定の変更が無い状態で文字が見やすい状態であることが理想です。そのため、目視や、信頼できるデザインガイドライン（Appleの『Human Interface Guidelines』やGoogleの『Material Design 3』など）を参照して文字サイズを検討しました。

　また、一部UIがモダンなデザインのため、そのようなデザインに馴染みの薄いユーザーが戸惑う可能性がありました。この点については、アプリの様々な場所からヘルプにアクセスしやすいようにデザインするといった調整を行っています。

　このようにデザイン時にアクセシビリティの考慮を行い、作成したデザインに沿って開発が実装を行いました。画像の読み上げテキストなどもデザイン時に決定し、決定事項に沿って開発が進められました。

5. 対応をチェックする

　代替テキストの設定を行ったものは音声読み上げ機能により、きちんと読み上げられるかのテストも行いました。デザイナーもテスト時の動画を見て、指定通りに読み上げられているか確認を行いました。

　また、デザインの作成中や、実装後に何度か社内の人をテスターとして、ユーザーテスト（※）を社内で行い、操作に困る場所が無いか確認しました。

※ユーザーテストとは

実際のアプリやそれを模したものをユーザーに操作してもらい、いくつかのタスク（ユーザーを登録する など）を実施してもらいます。その中でユーザーからフィードバックを得てアプリの改善を行います。

　以上がアクセシビリティを考慮した具体的な手順です。

より取り組めるとよかったところ

　今回、コストとのバランスを取りながらアクセシビリティ対応を行いましたが、さらに取り組めると良かった点を紹介します。

同様の対応を行おうと思う方の参考となれば幸いです。

音声読み上げ機能

　今回は、画像の音声読み上げは確認していましたが、音声読み上げ機能でのアプリケーションの操作については確認していませんでした。しかし、オンボーディングや初回登録などは操作できないと、アプリ自体使用できなくなってしまうので、主要な機能に絞って確認するなどできると良さそうです。一見奇抜なレイアウトではなくても、そのまま読み上げ機能を使用すると読み上げや操作が思い通りにならないことがありました。

複雑な操作

　アカウント登録にてメールアドレスを認証する際に、他アプリとの行き来が必要になるなど、アプリの中で複雑な操作が必要になる部分がありました。特にセキュリティに関する部分は操作が煩雑になりがちですが、高齢のユーザーにとっては操作が難しいとフィードバックがあったため、今後案内を工夫するなどUIを重点的に検討する必要がありそうです。

最後に

　今回、完全なアクセシビリティ対応を目指さなかったとはいえ、様々な点に注意を払っても十分な対応が難しいことを経験し、アクセシビリティ対応は一筋縄ではいかないと感じました。

　一方で、実際に対応を行い、ユーザーからのフィードバックを得ることで、繰り返し発生しやすい課題や、気づきにくい問題があると分かり、繰り返し対応を経験すれば、次回はもっとより良く対応できるのではないかと感じています。

　アクセシビリティの重要性は社会的に増しているとはいえ、現状、まだ広く普及した概念ではありません。

　対応方針に苦慮される方、関心は持っていても手の付け方が分からない方もいると思いますし、これから増えるのではないかと思います。

　アクセシビリティに関心を持った方、これから取り組む方にとって、本稿が、アクセシビリティを知る・アクセシビリティ対応についてより良い対応を行うための一助となることを願います。

本記事で引用した・取り上げた文献

• デジタル庁 ウェブアクセシビリティ導入ガイドブック （参照；2025/04/14）
• W3C Web Content Accessibility Guidelines (WCAG) 2.0 日本語訳（参照；2025/04/08）
  • ウェブアクセシビリティ基盤委員会 (WAIC)翻訳
  • 原文（英語）
• Apple Human Interface Guidelines
• Google Material Design 3

元ブログもチェック！

元記事はコチラ。ぜひチェックしてみてください！