ウェブアクセシビリティという言葉を聞いたことはありますか?
弊社では以前からウェブアクセシビリティ対応、診断サービスを展開してきましたが、今日はウェブアクセシビリティとは何なのか?どんなメリットがあるのか?どのように取り組んでいくのか?まとめて紹介します。
ウェブアクセシビリティの重要性、取り組む意義など、少しでもウェブアクセシビリティを知ってもらえれば幸いです。
なぜ今、ウェブアクセシビリティなのか?
「ウェブアクセシビリティって聞いたことはあるけど、うちには関係ないかな…」
そう思っている方、ちょっと待ってください!ウェブアクセシビリティは特別なことではありません。ウェブデザインやウェブサイトの意図をすべての人に伝えるためにも大切な基礎となります。これからのウェブサイトでは避けて通れない重要なポイントになる場合もあります。
ウェブアクセシビリティが重要な3つの理由
誰もが平等に情報にアクセスできる世の中に
インターネットは「誰もが自由に情報にアクセスできる場所」というイメージがありました。でも実際は、視覚や聴覚に障害のある方、特定の環境やデバイスでサイトを見ている方など、様々な制約のある人たちが存在します。
例えば、「デザインや企画にこだわった情報豊富なウェブサイトを構築」したのは良いが、画像の説明がないため、全盲の利用者の方には一部情報が伝わらないという問題がおきます。これでは折角、いろいろな人に見てもらおうと構築したウェブサイトなのに、「誰でも自由にアクセスできない」ものになってしまいます。
企業の信頼性とブランド価値の向上につながる
最近では、「この会社は社会貢献活動にちゃんと取り組んでいる」という評価が、企業イメージに大きく影響するようになってきました。特に、若い世代を中心に、企業の社会的責任を重視する傾向が強まっています。
実際、エシカル就活という考えが就活中の学生には浸透しており、「社会貢献」を重視する層が今後は増えていくと予想されます。
(参考URL 企業選びの新たな軸に?「エシカル就活」聞いたことありますか )
ウェブアクセシビリティは障害の有無に関係なく、誰でも利用できるウェブサイトを目指すものですが、これは国連の定める SDGs(持続可能な開発目標)のキーワードである「誰も取り残さない」に共鳴するものです。自社サイトのウェブアクセシビリティに取り組むことは、立派な社会貢献であり、信頼性とブランド力の向上に貢献するのです。
ウェブアクセシビリティは義務なの?
これは少し硬い話になりますが、とても重要なポイントです。結論からいうとウェブアクセシビリティは義務ではありません。ただし、日本では障害者差別解消法や公的機関向けのJIS規格など、ウェブアクセシビリティに関する取り組みが推奨、整備されています。
2024年4月、障害者差別解消法が改正され、「できる範囲で利用者の障害を取り除きましょう」という合理的配慮が、公的機関だけでなく民間に対しても義務となりました。ウェブサイトは環境の整備なので、引き続き「努力義務」ですが、例えば「ウェブサイトの一部機能が利用できない」という問い合わせがあった場合、合理的配慮の範囲で対応することは義務となります。つまり、間接的にはなりますが、ウェブアクセシビリティに対応することはウェブサイト運用上の合理的配慮を軽減する効果もあるのです。
ただし、公的機関のウェブサイトでは、JIS X 8341-3:2016への準拠が総務省より求められています。法改正により、民間企業でもウェブアクセシビリティが努力義務として認識されるようになってきました。
(参考サイト みんなの公共サイトガイドライン)
アクセシビリティ対応で得られる具体的なメリット
SEOの向上
「え?アクセシビリティ対応がSEOに効くの?」と思われるかもしれません。でも、これは本当なんです。
検索エンジンは、HTML/CSSといったウェブサイトのコードを元に評価を行っています。そして、このコードはちゃんとしたルールがあるので、正しく使わないと評価されなくなります。ウェブアクセシビリティに配慮するということは、このコードを正しく使うことにもなるので、高く評価されることになるのです。例えば:
- 適切な見出しがあるか?
- 画像の代替テキストがあるか?
- 分かりやすいリンクテキストになっているか?
- 構造化されたHTMLになっているか?
これらは全て、SEO対策としても効果的な要素なんです。
ユーザーインターフェース/ユーザーエクスペリエンス(UI/UX)の向上
アクセシビリティ対応は、実は全てのユーザーにとって便利な機能になります:
- 読みやすい文章
- 分かりやすいナビゲーション
- 明確なエラーメッセージ
- 十分な文字サイズとコントラスト
使いやすい検索機能や、分かりやすいページ、サイト構造は「見やすさ」「使いやすさ」を向上させます。ウェブアクセシビリティのガイドラインが「誰でも使える」を実現すると、デザインや企画・設計で目指したUI/UX が誰にとっても「使いやすい」ものとなるのです。
より広いユーザー層の獲得
高齢化社会が進む中、また様々な機器でウェブサイトを見る人が増えている中で、アクセシビリティに配慮したサイトは、より多くのユーザーに対応できます。
アクセシビリティ対応が必要な人たち
「具体的にどんな人のために対応すればいいの?」という質問をよく受けます。実際の現場での経験を交えながら、詳しく見ていきましょう。
視覚障害のある方々への対応
全盲の方の場合
スクリーンリーダーという、画面の内容を音声で読み上げてくれるソフトを使用します。つまり、ウェブサイト上のテキストや画像などの情報はすべて、音声として聞き、理解し、サイト閲覧をしているのです。
- 画像の代替テキストが不適切で内容が伝わらない
- 見出しの階層構造が不適切で、ページの全体像が掴めない
- フォーム入力時のエラーメッセージが分かりづらい
弱視の方の場合
画面を拡大して使用される方が多いです。特にスマートフォンは画面も小さいので、メガネを忘れた!という人とかでも日常的に拡大操作をすることはあるでしょう:
- 拡大時にテキストレイアウトが崩れる
- コントラストが低く、文字が読みづらい
- クリックターゲット(ボタンやリンク)が小さすぎる
色覚特性のある方の場合
色の組み合わせによっては、情報が正しく伝わらないことがあります。場合によっては、サイトの色を設定した色合いに変更して閲覧している人もいます:
- 赤色で重要情報を表示している
- 色だけで状態を表現している(例:エラーは赤、成功は緑)
- グラフの線の色分けが識別しづらい
聴覚障害のある方々への対応
動画コンテンツが当たり前になってきた今、この対応の重要性は増す一方です。
まだまだウェブ上の動画では一般的ではないですが、公共電波を使うテレビ番組は字幕を提供していることが多いです。
- 音声・動画コンテンツには字幕を付ける
- 動画の重要な音声情報をテキストで提供
- 音声による警告やお知らせを視覚的にも表示
聴覚障害のない人でも、下記のような環境では字幕は有効です:
- オフィスで音を出せない環境の人
- 電車内でスマホを見ている人
- 騒がしい場所で動画を見る人
運動機能に制約のある方々への対応
マウスやタッチパネルの操作が困難な方への配慮も重要です。キーボードでウェブサイト閲覧するので、マウスでできることは全部、キーボードでもできるようにしましょう:
キーボード操作への対応
- 全ての機能をキーボードだけで操作できるようにする
- フォーカスの順序を論理的に設定する
- フォーカスの位置を視覚的に分かりやすくする
実際にあったケースですが、普段マウスを使えない方から「サイト内検索の候補が選択できない」という指摘を受けました。キーボードでの操作を想定していなかったのです。
理解や操作にサポートが必要な方々への対応
ウェブサイトの操作や情報の理解には、「複雑な操作」や「大量の情報」 が障壁になることがあります。ウェブフォントやリンクボタン、ボタンの説明文は分かりやすいようにしましょう:
- 分かりやすい文章と構造
- 見やすいフォントと適切な行間
- 背景と文字色のコントラスト
- 予測可能な操作性
- 十分な時間的余裕の提供
アクセシビリティ対応の実践的なアプローチ
ここからは具体的な対応方法について、段階を追って説明していきます。
事前準備とチーム作り
プロジェクトの範囲を決める
運用中の既存サイト、サイト新規構築、サイトリニューアルとアクセシビリティ対応するタイミングはそれぞれですが、まずはウェブアクセシビリティ方針を作成しましょう。
ウェブアクセシビリティ方針で決める内容:
- 対象範囲
- 達成する適合度
- 達成する期限
基本的に、対象範囲はサイトの全ページ、達成する適合度はAAを目指します。
達成する期限ですが、既存サイトで対応する場合「一気にやらなきゃ」と思う必要はありません。新規構築、サイトリニューアルでも、予算や工数の関係で公開時には対応済みとできない時も同じです。方針でしっかり期限と優先順位を決めましょう。
- 最も利用の多いページから
- 新規に作成するページから
- 重要な機能(検索、問い合わせなど)から
チーム編成のポイント
アクセシビリティ対応は、一人で行うものではありません。
チームメンバーの協力が必要です:
- ウェブディレクター:全体の進行管理
- デザイナー:視覚的なアクセシビリティの担当
- フロントエンド開発者:技術的な実装の担当
- コンテンツ担当者:テキストや画像の担当
- テスト担当者:動作確認の担当
現状分析と課題の洗い出し
既存サイトでアクセシビリティ対応する場合、大まかで良いのでツールを使って現状分析を行いましょう。
自動チェックツールの活用
- Lighthouse:Googleの提供する総合的な診断ツール
- miChecker;総務省で開発・公開している診断ツール
ただし、これらのツールは全ての問題を検出できるわけではありません。例えば:
- 代替テキストが適切かどうか
- コンテンツの順序が正しいか
- キーボード操作ができるか
自動チェックツールは便利ですが結果が間違っていることもあります。注意しましょう。
具体的な実装のポイント
ここからは実装上のポイントについて、具体例を交えながら説明していきます。
HTML構造の適切な実装
「HTMLは適当でも見た目が同じならいいじゃない」
よく聞く声ですが、これが大きな落とし穴になります。
悪い例:
<div class="heading">重要なお知らせ</div>
<div class="text">
<div class="important">※本日のメンテナンス予定※</div>
<div class="time">14:00-15:00</div>
</div>
良い例:
<h2>重要なお知らせ</h2>
<div class="announcement">
<h3>本日のメンテナンス予定</h3>
<time datetime="2024-12-06T14:00">14:00-15:00</time>
</div>
見た目は似ていても、スクリーンリーダーでの読み上げ方が変わります。
それはなぜか?HTML要素を正しく使っていないからです。
スクリーンリーダーなどの支援技術はHTML要素から、文書の構造を理解しています。
見出しはどれか?この数字情報は日時なのか?支援技術に理解させるためにも正しい実装は不可欠です。
悪い例はdiv要素しか使っていないので、見出しが何か?数字の羅列は日時なのか判断できません。
一方、良い例はheading要素やtime要素を使っているので、見出しがどれで、数字の羅列は日時であることが正しく伝わります。
フォームの落し穴
フォームは、アクセシビリティの問題が最も見つかりやすい部分です。
ウェブアクセシビリティ対応では特に気をつけて実装し、優先的に対応したい箇所です。
以下はよくある問題点です:
- ラベルと入力フィールドを紐付けられていない
スクリーンリーダーで読み上げる時、不自然になる場合があります - エラーメッセージがテキストで、具体的に示されていない
どこでどういうエラーが起きているか判断しにくい - 必須項目を色やアイコンだけで表現している
必須項目がどれか分からない場合があります
動きのあるコンテンツ
最近のウェブサイトにはアニメーションや、利用者の操作でコンテンツが変化(動的コンテンツ)することがありますよね。
これらは利用者に「楽しさ」を提供するためにとても大切です。ただ、やりすぎるとウェブアクセシビリティ上、よくないこともあるので注意が必要です:
- スライドを繰り返すコンテンツ(カルーセル)などは利用者が止めたり、再生できるようにコントロールを設けましょう
- アニメーションは派手な点滅は避けて、なるべく5秒以内に終わるようにする
- モーダルウィンドウ(ページ内に表示される別画面)のキーボード操作はその中に限定する
- 選択肢から表示させるコンテンツを選ぶ時は、利用者が決定できるようにする
ウェブアクセシビリティ試験
「よし、実装できた!」と思っても、まだ終わりではありません。方針に従い、ウェブアクセシビリティ試験を行いましょう。
ウェブアクセシビリティ試験を分かりやすくいうと、「ウェブアクセシビリティ版、テスト、検証作業」です。公開前作業の一部と見なしてもいいでしょう。
ウェブアクセシビリティ試験の詳細は、JIS X 8341-3:2016 附属書に詳しく書いてあります。
ウェブアクセシビリティ試験のアプローチ
現状分析でも使った自動ツールを使って効率化しつつ、必ず人間の目と手でのチェックを行いましょう。
ただし、機械的に試験手順に従って達成基準を満たしているかチェックするだけでは、本当のウェブアクセシビリティ対応とは言えません。
キーボードしか使えない、画面がよく見えないというシチュエーションを想定したユーザーテストとしての側面も大切です。達成基準を満たしているから「使いやすい」とは限らないのです。ユーザビリティの面も忘れないようにしましょう:
- 自動テスト
- WAVE、Lighthouse、miChecker などのツール
- HTML validator などによる構文チェック
※HTMl構文チェックは、WCAG2.2ではガイドラインから外れています
- 手動テスト
- キーボードのみでの操作確認
- スクリーンリーダーでの読み上げテスト
- 拡大表示での確認
実践的な運用体制づくり
さて、ここまでアクセシビリティ対応の具体的な実装方法を見てきましたが、実は一番難しいのは「いかに継続的に維持していくか」なんです。
ウェブサイトは日々更新したり、コンテンツが追加、修正されるものです。つまり、試験から数年経てば、違ったウェブサイトになっていることもあります。
また、ウェブアクセシビリティのガイドラインも定期的に追加があります。利用者のデバイスも、PCからスマホに移行したように、変化があるかもしれません。
せっかく構築したウェブアクセシビリティ対応したサイト、それを維持していくことも取り組みの一部なのです。
ドキュメント作成とナレッジ共有の実践
「せっかく対応したのに、他のメンバーに伝わっていなくて更新するたびに悪くなる」
これはよくある問題です。チームで伝わっていても、ウェブ更新者に伝わっていないとか、デザインとの兼ね合いで協議したことが、すっかり抜け落ちてしまっている、などちょっとした行き違いがウェブアクセシビリティの維持には問題となります。
そこで登場するのが「更新ガイドブック」のようなドキュメントです。
ガイドラインの作成例
HTML/CSSに詳しくない方が記事更新する場合のガイドライン例です。
ガイドラインはウェブ技術に関する知識レベルも考慮しましょう。
普段のマニュアルにちょっとウェブアクセシビリティに対する注意点を追加するくらいでも大丈夫です。
画像の代替テキスト
基本ルール:
- 画像:「固有名 + 主な特徴を説明するテキスト」
- バナー:「キャンペーン名 + 期間を説明するテキスト」
- アイコン:「機能や目的を簡潔に説明するテキスト」
良い例:
- 画像:「取締役〇〇さん」
- バナー:「無料相談キャンペーン、2024年12月20日まで」
- アイコン:「youtube公式チャンネルに移動します」
悪い例:
- 「img_0123.jpg」
- 「キャンペーンバナー画像」
- 「クリックしてください」
見出し構造
基本ルール
- h1: ページのメインタイトル(1ページに1つのみ)
- h2: 主要セクションの見出し
- h3-h6: サブセクションの見出し
おわりに
ここまで長い記事を読んでいただき、ありがとうございます。
ウェブアクセシビリティの取り組み方のほんの一部ですが、この記事が、みなさんの助けとなれば幸いです。
ウェブアクセシビリティ対応は、一見すると「面倒」「大変」と感じるかもしれません。でも、誰もが使いやすいウェブサイトを作ることは、結果として全てのユーザーにとってより良いウェブサイトを提供することになります。
弊社ではウェブアクセシビリティ診断、対応サイト構築サービスも行っています。
興味のある方はぜひ、気軽にお問い合わせください。