ウェブサイト制作案件でのアクセシビリティのチェックポイントを個人的に整理した話（その４・コーディング・CMS実装編）

2023年3月12日 20:29

この記事は「ウェブサイト制作案件でのアクセシビリティのチェックポイントを個人的に整理した話（その３・デザイン編）」の続きです

コーディングになると、表示の制御だけでなくマークアップでの補助も行うことになります。それだけに、チェックリストの中でも一番項目数が多くなっています。

また、CMS実装の場合は多くの処理をテンプレートに組み込むことになります。ユーザーの入力に任せるのかテンプレート側で処理をするのかの判断が必要なものがあるだけでなく、テンプレートで実装に漏れやミスがあると多くのページに影響するので、チェックには十分注意が必要です。

HTMLはvalidatorやlinterでチェックが通る

支援技術が正しくコンテンツを解釈できるよう、HTMLは正しい書式で記述されている必要がある。
制作されたHTMLは「Nu Html Checker」でエラーのない状態とする。
https://validator.w3.org/nu/

ただし、YoutubeやGoogleMapなど、外部サービスの埋め込みによって発生しているものは除く

関連項目：4.1.1（A）※廃止予定項目

lang属性で言語を明示する

スクリーンリーダーが読み上げに使用する音声言語を正しく判定できるようにするために、ページ全体のhtml要素のlang属性で言語を指定する。

なお、コンテンツ中のテキストの一部に別の言語が用いられている以下のような場合、その要素にlang属性を追加するとより望ましい

まとまった文章を引用している箇所
別の言語の用語説明をしている箇所

関連項目：3.1.1（A）、3.1.2（AA）

見出しはh1〜h6の順でマークアップする

見出しのレベルが飛んだり順番の入れ替えがあると、スクリーンリーダーや支援技術がコンテンツの関係性を正しくユーザーに伝えられない。
見出しはデザインされた際の重要度に従ってh1〜h6の順でマークアップする。

関連項目：1.3.1（A）、2.4.10（AAA）

フォーカス時のアウトラインを消さない

キーボードで操作するユーザーにとっては、現在フォーカス位置がわからないと入力や操作ができない。
フォーカスのアウトラインはCSSで非表示にしない。

コンテンツエリアのHTMLの記述は読み上げ時に適切な順序でおこなう

スクリーンリーダーでのコンテンツ読み上げ順を混乱させないよう、HTMLの記述順は理由なしに操作しない。

関連項目：1.3.1（A）、1.3.2（A）、2.4.3（A）

メインコンテンツセクションを<main>要素で示す

スクリーンリーダーはページのHTMLを上から順に解釈して読み上げるため、サイト全体で繰り返し表示される共通のグローバルナビゲーションを毎回読み上げるとコンテンツの理解に時間を要する。

そのため、多くのスクリーンリーダーでは「メインコンテンツにスキップする」機能があるが、これを利用するにはコンテンツのHTML側で適切なマークアップが必要である。

現在、<main> 要素で記述された要素は主要なスクリーンリーダーでメインコンテンツとして認識される（暗黙的にrole="main"として解釈）ため、メインコンテンツ部分は<main>要素でマークアップする。

ナビゲーションセクションを<nav>要素で、ヘッダー・フッターセクションを<header><footer>で示す

適切にセクショニングすることで、スクリーンリーダーの操作がより簡便になる。
最近のスクリーンリーダーでは、主要なセクションを示す箇所は適切な役割のあるrole属性を持つものとして暗黙で解釈されるため、グローなバルナビゲーション、ヘッダー、フッターは最低限専用の要素でマークアップすることが望ましい。

画像・写真・ロゴには必ずalt属性を設ける

スクリーンリーダーなど視覚情報を解釈しない支援技術でも、視覚的オブジェクトで提供されている情報を取得できるようにしなければならない。

コンテンツ内の画像・写真・ロゴにつき、その画像自体に伝達すべき意味のあるものについてはalt属性を付与する。

なお、単純装飾のために用いられている画像の場合は、画像自体に伝達すべき情報がない。この場合はalt属性を空（alt=""）にする。
alt属性自体の省略は認めない。

箇条書きは<li>または<ol>、説明には<dl>を使用する

スクリーンリーダーがリストを認識できるよう、適切なリスト要素を用いてマークアップする。

データ送信や表示の切り替えなど、機能を有するボタンに<div>を使用しない

クリック/タップによってページ遷移以外の状態の変更を発生させる機能を持った要素には<button>要素など適切な要素を使う。

ボタンの装飾デザインのために<div>を使うケースがあるが、これはNGである。

入力フォームには入力されるデータの種別に応じたtype属性、autocomplete属性を指定する

入力フィールドについて、入力すべきデータの目的がマシンリーダブルであることが望ましい。
ユーザの入力を受け付ける要素は、原則type属性、autocomplete属性を使用する。

表示されるラベル（label）と実装上の名称（name）を揃える

視覚的に見える文字（label）と、実装上のテキスト（name）が異なることで、スクリーンリーダーの読み上げ時にユーザー操作が混乱する恐れがある。表示される項目名とコード上の名称は同じにする。

キーボードだけでサイト内のすべての操作ができるようにする

目と手の協調運動を必要とするデバイス（マウスなど）が利用できない全盲のユーザーでもサイトのコンテンツおよび機能がすべて利用できるよう、キーボードのみですべての操作がおこなえる必要がある。

関連項目：2.1.1（A）、2.4.3（A）、2.4.7（AA）、3.2.1（A）、3.2.2（A）

キーボードのフォーカス順序がコンテンツの理解や操作性を阻害しない

キーボード操作の際にコンテンツの理解が妨げられないよう、フォーカス順序はコンテンツの表示順および通常操作で想定される順と同じになっている必要がある。

キーボードトラップがない

キーボードトラップ（袋小路）があるとユーザーはそれ以上サイトの閲覧を継続できなくなってしまう。
特にモーダルやタブなど、動的にコンテンツを切り替える箇所でキーボードトラップが生じないようにする。

ダウンイベントで機能を実行しない

特定の要素に、押下しただけで実行される機能が存在しない、または存在する場合、押下した領域の外にポインタを移動して離すことにより実行をキャンセル・中止できる。

コンテンツの表示をデバイスの向きに依存させない

モバイル端末などデバイスの向きが複数想定されるデバイスの場合に、いずれの向きでもコンテンツの情報・機能に欠損が生じないこと。

傾け、振動などデバイスまたはユーザの動きで操作できる機能はUIでも同様の操作ができるようにする

デバイスを振ったり傾ける、またはデバイス（カメラ）に向かってジェスチャをすることで実行される機能が実装されている場合、特定の動作ができないユーザーのために機能自体を無効にできる、または動き以外の入力方法でも当該機能を利用できるようにする。

ただし、動きがその機能にとって不可欠な場合は除く。

文字サイズの拡大・縮小がユーザの任意できるようにする

ロービジョンのユーザーがコンテンツを最適化できるよう、ユーザーによるテキストサイズの拡大・縮小を妨げないようにする。

metaのuser-scalable-noで固定しない
フォントサイズの指定は相対的な単位を用いる（em, %）

文字サイズを200％、コンテンツ全体を400%まで拡大しても情報が読み取れるレイアウト制御をする

ロービジョンのユーザーが文字やコンテンツを拡大表示している際、横スクロールや見切れが発生していると閲覧体験を損なう。

文字サイズだけを拡大する場合は200%まで、コンテンツ全体を拡大する場合は400%までのズームをおこなっても、コンテンツに見切れや横スクロールが発生せず適切にリフローされるようにする。

ユーザがテキストサイズを任意に変更してもコンテンツが欠損しないようにする

ユーザーが自分に最適な文字間でコンテンツを閲覧できるよう、ユーザーによるテキスト間隔の上書きに対応することが望ましい。

具体的には、以下の条件でコンテンツに欠けや表示順の混乱、機能の喪失が出ないようにする。

line-height　1.5em以上
段落に続く空白を2em以上
letter-spacingを0.12em以上

コンテンツの変化を伴う要素はaria属性を用いてスクリーンリーダーにも伝達する

ユーザーの操作によって状態が変化する場合、スクリーンリーダーにもその情報が適切に伝わるようにする必要がある。
検索結果の読み込みや、ページネーションなどの画面の一部に発生する変更は、aria属性を用いてそれらがスクリーンリーダーで読み上げられるようにする。

チェックボックス、ラジオボタンのオンオフ
タブの操作
モーダルウィンドウの展開とフォーカス　など

関連項目：3.2.2（A）、3.2.5（AAA）

タブは展開の状態がスクリーンリーダーで解釈できるようにする

タブリストにはrole=“tablist”を付与する
タブボタンにはrole=“tab” を付与する
- 選択中のタブボタンにaria-selected=”true”を付与する
- 対応するタブパネルのidをaria-controlsで指定する
タブパネル側にrole=”tabpanel”を付与する
aria-labelledbyに「対応するタブボタンのID」を指定する
選択中以外のものはdisplay:none;で要素ごと非表示にする

関連項目：4.1.2（A）、3.2.5（AAA）

ステータスメッセージには適切なrole属性とaria-live属性を指定する

スクリーンリーダーでは、フォーカスを受け取らないコンテンツの変更＝ステータスメッセージの表示が検知できないと、ユーザーがそれ以上操作を継続できなくなる可能性がある。

あらかじめステータスが表示・変更されることを知らせたい要素にrole属性と aria-live 属性を指定しておくことで、スクリーンリーダーはその要素に変更があった際に読み上げでユーザーに変更を伝達できる。

この時、role属性と aria-live 属性を指定する要素は動的に埋め込まずhtml描画時に存在する必要がある。動的に処理する場合は内部のコンテンツのみを対象とすることに注意。

なお、ステータスメッセージには、コンテキストの変更により変化するものは含まれない。
サイト内検索ページを例にすると、検索結果はステータスではないが、検索結果が表示されるまでの「検索中」表示や、検索結果が0だった場合の「検索結果がありません」、不正な文字が入力された場合の「半角英数字は使えません」というテキストはステータスメッセージに該当する。

accesskey属性は使用しない

ユーザーによっては、独自のショートカットキーをキーボードに割り当てている場合がある。
accesskey属性でキーの割り当てをコンテンツ側で強制すると、ユーザーのショートカットキー操作を阻害する