この記事は最終更新日から1年以上経過しています。
ウェブアクセシビリティ4つの原則 ①知覚可能
公開日:
更新日:
こんにちは!kanappleです。
アクセシビリティ4つの原則について理解を深めましょう。
WCAG2.0は大きく4つの原則から構成されています。
1. 知覚可能
2. 操作可能
3. 理解可能
4. 堅牢
今回は知覚可能についてです。
1.知覚可能
知覚可能とは、利用者が知覚できる方法でwebページを認識できるということです。
例えば、視覚に障害がある方がスクリーンリーダーを使ってウェブページを読み上げることができたり、聴覚に障害がある方が字幕やキャプションで動画や音声を理解できるようにする対応になります。
知覚可能にはどのように対応すれば良いか、レベルA、レベルAAに対応したガイドラインについて、例を交えて説明します。
1.1 代替テキスト
このガイドラインの目的は、すべての非テキストコンテンツが、テキストでも利用可能であるようにすることです。
すべての非テキストコンテンツが、拡大印刷、点字、音声、シンボル、平易な言葉などの利用者が必要とする形式に変換できるように、テキストによる代替を提供します。
・意味のある内容を伝える全ての画像には、適切な代替テキストを提供する
例) 国際首相会議で握手を交わしている写真
代替テキストにはalt=“X 国の X 大統領が、Y 国の Y 首相と握手している。”と記述します。
例)アイコン画像にfacebookページへのリンクをつけている
画像の代替テキストにはalt=“facebookページ”と、リンク先を示す内容を入れます。
例)装飾画像や意味のないイラスト
cssの背景画像を使用します。HTMLに<img>として置く必要がある場合は、altを空にしましょう。空にしておかないと、スクリーンリーダーがファイルパスなどを読み上げようとする可能性があります。
・音声や動画にはキャプションを与える
例) 演説を録音した音声
「議会での議長の演説」という音声クリップへのリンクを置き、音声クリップへのリンクの直後に、テキストの書き起こしへのリンクを置きます。
例) アニメーション動画
動画にキャプションををつけ、音がなくても動画の内容がわかるようにします。
・フォーム要素やボタンにはテキストラベルを付ける
例) 画像のアップロードボタン
<button>画像のアップロード</button>と、ボタンの機能を説明したテキストを置きます。
<button>要素は、キーボードアクセシビリティを備えている為、Tabで移動したり、Enterを使ってアクティブにすることもできます。
1.2 時間依存メディア
このガイドラインの目的は、時間の経過に伴って変化する、同期したメディアへのアクセスを提供することです。
具体的には、音声しか含まない、映像しか含まない、音声と映像を含む、インタラクションを組み合わせた音声と映像、又は音声あるいは映像のどちらかを含むメディアになります。
・収録済みの音声や映像には解説や字幕をつける
例) 収録済みの記者会見の映像がある
記者会見のテキストによる書き起こしのリンクを置きます。
書き起こしには、発言したすべての記録だけではなく、喝采、笑い、聴衆からの質問など、その録音の一部であるその他の重要な音声も記載します。
・ライブ映像には翻訳ツールでキャプションをつける
例)リアルタイムの音楽ライブ映像
リアルタイム翻訳ツールを使い、キャプションを提供します。
歌詞や会話を取り込むだけではなく、タイトル及び楽章、作曲者、利用者が音楽の性質を理解するのに役立つあらゆる情報によって、歌のない音楽を特定できるようにします。
1.3 適応可能
このガイドラインの目的は、音声で読み上げたり、より単純なレイアウトで提示したりというように、すべての情報をすべての利用者が知覚できるように提供することです。
・フォーム要素は関連づける
例)チェックボックス
ラジオボタンやチェックボックスには、項目名を<labe>要素で囲み関連づけます。
・項目の情報と関係性がわかるようにする
例)必須項目のある入力フォーム
赤字で必須というテキストラベルと*をつけ、「必須項目にはアスタリスク(*)が付いています」と説明文を記載します。
・構造をプログラムによる解釈が可能であるようにする
例)リスト
リストは<ul>を使い、順序付きリストでは<ol>を使用します。
・意味のある順序にする
例) 独特なレイアウト
独特なレイアウトを使いたい場合でも、読み上げ順序を考えてマークアップします。レイアウトはCSSを使用して実装します。
・コントロールを操作したりコンテンツが理解できるようにする
例)続きのリンクをクリックしてもらう
「続きを読む」というテキストリンクやボタンを設置し、どこをクリックするのかを明確に示します。
「丸いボタンをクリック」や「右のボタンをクリック」等では、形や配置を知覚できない場合があるので使わないようにしましょう。
例)ページ遷移ボタン
「次へ」「前へ」とテキストで表示し、アイコンだけや色だけで案内しないようにします。
一部の利用者は、端末がタッチに対応していない為、スワイプ動作は使わないようにします。
1.4 判別可能
このガイドラインの目的は、デフォルトの提示を障害のある利用者にとってできる限り知覚しやすくすることです。
・色の使い方を考える
例)必須項目や使用不可状態がある入力フォーム
フィールドの状態を色だけで示すことはせず、「必須」など適切なラベルをつけます。
使用不可状態はがグレーアウトなどの色だけで示さず、disabled属性を使いフォーカスされないようにします。
・3秒以上の動画や音声には、操作可能なコントロールを用意する<非干渉>
例)ページを開いたときに自動で再生される動画
停止、音量調整、ミュート、再生を行うためのコントロールを用意し、利用者が操作できるようにします。
これは非干渉の達成基準であり、必ず達成する必要があります。
・コントラスト比を提供する
例) 背景にテキストを重ねる
テキストとその背景のコントラスト比は少なくとも 4.5:1 であるようにします。
コントラストチェックツールを使い確認しましょう。
例) 見出し
テキストの比は、少なくとも 3:1 であるようにします。 大きいテキストは、少なくとも 18 ポイント、または 14 ポイントの太字とします。
・テキストサイズが変更できるようにする
例) テキストサイズの変更
テキストサイズが変更されても、レイアウト崩れを起こさず、最適なデザインが適用されるようにします。
・テキストであるべきものを画像にしない
例)見出しや文章
ビットマップ画像を使わず、CSSで同じ見栄えになるようにしましょう。ロゴ画像には代替テキストを付けます。
以上が、知覚可能のガイドラインになります。
これらはJIS X 8341-3:2016の、知覚可能の原則(レベルA、レベルAA)ガイドラインで、14の達成基準があります。
実装例を参考に、ひとつずつ達成していきましょう。
まとめ
・知覚可能の原則とは利用者が知覚できる方法でwebページを認識できるということ
・視覚に障害がある方は聴覚で認識ができるように、聴覚に障害がある方は視覚で認識ができるようにする
・スクリーンリーダーを使い、読み上げ順序に問題はないか、画像の説明が明確にされているかを確認する
・動画や音声は、音がなくても理解できるものになっているかを確認する
次回は、操作可能の原則について説明します。
関連記事
この記事のハッシュタグ #Accessibility から関連する記事を表示しています。
タブのアクセシビリティ実装テクニック
タブはなぜ難しい?ウェブでよく使われるUIのひとつが「タブ」。見た目はシンプルですが、実際にアクセシビリティ対応を行うと「ロールや属性の付与」「選択状態の管理」「キーボード操作」など考えることが多く、実装難度は意外と高めです。タブをUIとして選択しないという手段もありますが、必要なケースもあります。よくある惜しい実装例キーボード操作できない現在地が伝わらないすべてtabindex="0"こうした実装を避けるため、ここでは APG(ARIA Authoring Practices Guide) をベースにしつつ、利用シーンに合わせて調整できる実装方法を紹介します。https://www.w3.org/WAI/ARIA/apg/patterns/1) ロールと要素を正しく関連付けるタブUIの基本は 「どことどこが結びついているか」を明示することです。tablist・tab・tabpanel のロールを付与し、aria-controls・aria-labelledby で相互参照を作ります。参照IDは一意であることが必須です。2) ロービングタブインデックスを理解Tabキーで移動したときに、選択中のタブだけがフォーカス可能にするのが「ロービングタブインデックス」です。aria-selected とセットで更新するのがポイントです。これにより、矢印キーやTabキーでの移動が直感的かつスムーズになります。3) キーボード操作(矢印+Home/End)タブは キーボード操作のしやすさが大事です。横型なら ←/→、縦型なら ↑/↓ を割り当て、Home/End で先頭・末尾に移動できるようにします。循環移動(最後の次は最初へ)も実装すると操作性が上がります。また、aria-orientationで 向きを明示することも大切です。これにより、縦型タブでもスクリーンリーダー・キーボード操作の両方に正しく伝わります。タブとスクリーンリーダー対応について主要な支援技術での挙動は以下の通りです。特に PC-Talker ユーザーにとっては「タブUIそのものが見えない」課題が残ります。NVDA(Windows):○ タブを認識するVoiceOver(iOS / Mac):○ タブを認識するTalkBack(Android):○ タブを認識するPC-Talker(Windows):△ タブを認識しないPC-Talker向け改善案他のスクリーンリーダーでは少し冗長になりますが、補助的にスクリーンリーダー用テキストなど用意することで改善できる場合があります。「現在は〇〇のタブを表示中です」といった短い一言を補足的に伝えるイメージです。プロジェクトの性質や利用者層に応じて、採用してみてください。まとめタブのアクセシビリティ実装は難しく見えますが、ポイントを押さえればシンプルです。ロールや要素で関係を作る選択中だけtabindex=0とaria-selected="true"矢印キー操作を入れる向きをaria-orientationで伝えるこの4つを押さえるだけで、支援技術ユーザーにとってぐっと快適になります。告知2025年10月3日(金)21:00 - 26:00 オンライン開催の「#朝までマークアップ 3(JS編)」に出演いたします。当日は、アクセシビリティを考慮したUIの話をします。この記事にご興味を持っていただけましたら、ぜひご参加ください!
スタッフブログ
動きのあるウェブアクセシビリティ対応はどうやって対応するの?
モーダルやタブ、アコーディオンなど「動き」のあるUIは、デザイン性や利便性を高める一方で、支援技術ユーザーにとっては操作や理解が難しくなることがあります。そのため、動きを伴うコンポーネントを実装する際は「アクセシビリティ対応」が欠かせません。参考ガイドラインW3C が公開している ARIA Authoring Practices Guide (APG) では、実際のUIパターンごとに「ロールや属性の付け方」「キーボード操作の仕様」などが整理されています。タブ、モーダル、ツリー、メニューなど、多くのケースで 実装コード例 が紹介されており、開発者が迷わず対応できるようになっています。ARIA Authoring Practices Guide (APG)このガイドを参考にすることで、動きのあるUIをアクセシブルに作るための基本を把握することができます。実際にどう活かすか実務では、APGが全て正解として見るだけでなく、実装しているUIが 想定された操作と一致しているかロービングタブインデックスやaria属性の相互参照が抜けていないかスクリーンリーダーで操作が伝わるかスクリーンリーダー読み上げに無理はないかキーボード操作で操作できるかといった観点でチェックするのも大事なポイントです。自社の取り組み:ハンドブックとブログ私たち、ましじめでも、社内外の方に役立つよう「ウェブアクセシビリティハンドブック」と「アクセシビリティ連載ブログ」を公開しています。日本語で考え方もまとめていますので、ぜひ参考にしてみてください。ウェブアクセシビリティハンドブックブログ:アクセシビリティ連載おわりに「動きのあるUI」をアクセシブルにすることは、単に基準に適合させるためだけではなく、誰にとっても「自然に使いやすい」体験につながります。APGを基盤としつつ、私たちのハンドブックやブログも実装の一助になれば幸いです。
スタッフブログ