JIS X 8341-3:2016は、ウェブコンテンツを多様な利用者が使えるようにするためのアクセシビリティ基準です。
このうち知覚可能は、情報や操作方法を、利用者が認識できる形で提供するための考え方です。
本記事が扱う1.3「適応可能」は、見た目や読み上げ方が変わっても、情報と構造が失われないようにすることを求めています。
対象となるのは、1.3.1「情報及び関係性」、1.3.2「意味のある順序」、1.3.3「感覚的な特徴」の三つです。
1.3「適応可能」で確認する三つの達成基準
三つの達成基準は似ていますが、確認する対象が異なります。
| 達成基準 | 守るもの | 主な確認点 |
|---|---|---|
| 1.3.1 情報及び関係性 | 見出し、一覧、表、フォームなどの構造 | 見た目で示した構造がHTMLまたはテキストでも伝わるか |
| 1.3.2 意味のある順序 | 内容を理解するために必要な読み上げ順 | HTMLを順番に読んでも意味が通るか |
| 1.3.3 感覚的な特徴 | 操作や理解に必要な指示 | 形、色、位置、向き、音だけを手掛かりにしていないか |
1.3.1「情報及び関係性」
見た目の構造をHTMLでも伝える
1.3.1が求めるのは、画面を見れば分かる情報のまとまりや関係を、支援技術でも判別できるようにすることです。
文字を大きくしただけの見出しや、改行と記号だけで作った一覧では、スクリーンリーダーがその役割を正しく把握できない場合があります。
見出しには内容の階層に合う<h2>や<h3>を使い、箇条書きには<ul>または<ol>と<li>を使います。
表では見出しセルに<th>を使い、必要に応じてscope属性やheaders属性で見出しとデータの関係を示します。
詳しい基準の読み方は、サイト内のWCAG 1.3.1「情報と関係性」の解説も参照してください。
フォームのラベルを入力欄に関連付ける
入力欄の近くに項目名が表示されているだけでは、その項目名と入力欄の関係がプログラムに伝わらないことがあります。
表示するラベルと入力欄は、次のようにfor属性とid属性で関連付けます。
<label for="email">メールアドレス</label>
<input id="email" name="email" type="email">この関連付けにより、支援技術は入力欄の名前を利用者へ伝えやすくなります。
1.3.2「意味のある順序」
画面の並びではなく読み上げ順を確認する
1.3.2が対象にするのは、順序が変わると内容の意味も変わってしまう場面です。
例えば、二段組みのページで本文と補足がHTML上では交互に並んでいると、画面では自然に見えても、上から順番に読み上げたときに文脈が途切れます。
CSSで配置を整える前に、HTMLを先頭から読んでも内容が自然につながる順序にします。
確認するときは、画面を一列にした状態やHTMLの並びを確認し、見出し、本文、注記、ボタンの説明が意味の通る順番になっているかを追います。
具体例は、サイト内のWCAG 1.3.2「意味のある順序」の解説で確認できます。
読み上げ順とフォーカス順を分けて考える
元の記事で扱っていたタブキーの移動順は、1.3.2の読み上げ順と関係しますが、同じ達成基準ではありません。
リンクや入力欄をタブキーで移動する順序は、主にフォーカス順序の達成基準として確認します。
ARIAランドマークは、ページ内の主要な領域に役割を付ける仕組みです。
領域の把握には役立ちますが、HTMLの読み上げ順そのものを修正するものではないため、まず元のHTMLを意味の通る順序に整えます。
1.3.3「感覚的な特徴」
名前や目的を含む指示にする
1.3.3は、操作方法や内容を説明する指示が、形、色、大きさ、位置、向き、音だけに依存しないことを求めています。
「右側の赤い丸を押してください」では、位置や色を認識できない利用者が対象を特定できません。
「送信ボタンを押してください。画面右側の赤い丸いボタンです」のように、対象の名前や目的を先に示せば、位置や色の情報は補足として残せます。
アラート音を使う場合も、音だけで状態を伝えず、画面上に内容を示すメッセージを併記します。
実装例は、サイト内のWCAG 1.3.3「感覚的な特徴」の解説も参考になります。
色だけで示す情報は別の確認も必要
赤色だけでエラーを示す設計は避け、「エラー：メールアドレスを入力してください」のようなテキストを添えます。
ただし、色だけで情報を伝えていないかという確認は、1.3.3だけでなく1.4.1「色の使用」でも扱います。
記号やアイコンを追加する場合も、それだけに置き換えず、意味が分かるテキストを併記すると対象を特定しやすくなります。
実装後の確認チェックリスト
- 見出し、リスト、表、フォームの関係を、見た目だけでなくHTMLでも表しているか。
- HTMLを先頭から読んだとき、本文、補足、操作説明の順序が自然につながるか。
- 「右」「赤」「丸」「音が鳴ったら」など、感覚だけを手掛かりにした指示が残っていないか。
- フォームのラベルと入力欄がプログラム上でも関連付いているか。
- スクリーンリーダーで構造と読み上げ順を確認したか。
- タブキーの移動順は、読み上げ順とは別の確認項目として点検したか。
1.3「適応可能」は情報の意味を保つための基準
1.3「適応可能」への対応は、見た目を整えるだけでは完了しません。
情報の構造、読む順序、操作対象の伝え方をHTMLとテキストで明確にすると、表示方法や利用する支援技術が変わっても意味を保ちやすくなります。
まず1.3.1で構造と関係を示し、次に1.3.2で読み上げ順を確認し、1.3.3で感覚だけに頼る指示を見直すと、三つの違いを混同せず点検できます。
当社では、ウェブアクセシビリティへの対応を支援するUUU ウェブアクセシビリティウィジェットツールを提供しています。
アクセシビリティ向上にご興味がある方は、サービスの詳細をご覧ください。