eng-docs

実装時の検証

10 min read

実装時の検証

W3C WAI の Easy Checks と Selecting Web Accessibility Evaluation Tools を取得して読み、 理解した内容を自分の言葉で書いたもの。本文の引用はしていない。

アクセシビリティが何を満たすべきかなら、こちらは満たしているかをどう確かめるか。

先に、道具の限界

アクセシビリティ評価ツールはアクセシビリティを判定できない。判定を助けるだけ。

W3C 自身がそう書いている。ここを最初に置く理由は、 CI に自動チェックを入れた時点で「対応した」と見なすのが、この領域で最も起きやすい失敗だから。

すべての側面を自動で検査することはできない
誤検知と見逃しの両方が出る
人間の判断が要る

ツールの出力を、実際の利用者の体験より優先しない。 自動チェックが全部緑でも、キーボードだけで注文を完了できないサイトは作れる。

道具は「機械的に判定できるものを機械に任せて、人間の時間を残りに使う」ためにある。 静的解析と同じ位置づけ。

道具なしでできて、効果が大きい3つ

新しい画面を作ったら、まずこれをやる。準備がいらず、重い障壁がここで出る。

1. キーボードだけで通す

マウスを片付けて、Tab だけで最初から最後まで操作する。

すべての機能に到達できるか
Tab の順序が、見た目の読み順と一致しているか
いまどこにいるかが見えるか(フォーカスの表示)
Tab で抜け出せない場所がないか(キーボードトラップ)
Enter / Space で実行できるか。ドロップダウンを矢印キーで送れるか
hover しないと出ない機能がないか

macOS では先に設定が要る。 システム設定 → キーボード → ショートカット → 「Tab キーでの移動先」を「すべてのコントロール」にしないと、 Tab がリンクやボタンを飛ばすので、検証にならない。 Windows は設定不要。

これがREADMEで 「実装時に最も早く検証できる指標」と書いたものの手順。

2. 文字を200%に拡大する

文字だけを拡大する(ページ全体のズームではない)設定にして、200% まで上げる。

文字が消える・切れる
要素が重なる
ボタンや入力欄に届かなくなる
文を読むのに横スクロールが要る(節と節の間の横スクロールは可)
画像の中の文字は拡大されない

3. CSS と画像を切る

スタイルと画像を無効にして、上から順に読んで意味が通るか。

ナビゲーションが中ほどや末尾に現れる
見出しと本文が離れる
ラベルと入力欄が離れる
情報のかたまりに見出しがない
代替テキストだけで内容が足りているか

支援技術が読む順序がここに出る。 見た目で整えていたものが崩れる。

その場でできるチェック

上の3つを含め、W3C が挙げているのは10項目。

項目見るところ
ページタイトル内容を表しているか。サイト内で重複していないか。重要な語が先頭にあるか
画像の代替テキスト機能として等価か。見た目の説明ではない。装飾なら alt=""
見出し見出しに見えるものが見出しとしてマークアップされているか。階層が飛んでいないか
コントラスト比通常サイズの文字で 4.5:1 以上
文字の拡大200% で崩れないか
キーボードとフォーカス上記1
フォーム・ラベル・エラー下記
動く・点滅する要素下記
マルチメディア下記
基本構造上記3

フォーム

すべてのコントロールにラベルが対応づけられている
<label for="x"> と、コントロールの id="x" が一致している
必須の印(*)がラベルのマークアップの中にある
必須であることを色だけで示していない
書式(日付など)の指示が、必要になる前に出ている
エラーは具体的で、見つけやすい位置にある
送信に失敗しても、入力した内容が残る(機微な情報は除く)

必須の印をラベルの外に置くと、支援技術では必須だと分からない。 見た目には同じに見えるので、目視では気づけない類の欠陥。

動く・点滅する要素

自動で始まって5秒を超えるものに、停止・一時停止・非表示の手段があるか
自動更新される内容(株価など)を止められるか、頻度を変えられるか
1秒に3回を超えて点滅していないか

1秒に3回は発作を誘発しうる境界。ここは好みの問題ではない。

マルチメディア

プレイヤーの操作がキーボードで届き、名前が付いているか
自動再生しないか(するなら3秒で止まるか、音量・一時停止の操作があるか)
キャプションがあるか。話者が識別できるか。台詞以外の音も入っているか
書き起こしが media の近くにあるか。映像は視覚情報の説明も含むか

自動生成のキャプションだけでは足りない。 同期のずれと誤変換が残る。

これを全部通しても、適合ではない

通っているように見えても、重大な障壁が残っていることがある。

上の項目が扱っていない領域がある。

リンク(文脈から目的が分かるか)
データテーブルのマークアップ
色だけに依存した情報伝達

適合の5要件にあるとおり部分的な適合は認められないので、 「主要な画面でチェックを通した」は適合の主張にならない。

本格的に評価するなら、次が要る。

  • WCAG-EM — 適合性評価の方法論。標本の選び方まで含めて決まっている
  • スクリーンリーダーの熟練利用者による確認 — 慣れていない人が触っても、 操作方法の問題と実装の問題が区別できない
  • 実際に障害のある利用者に使ってもらう

自動化との切り分け

テストの「自動化しないもの」と同じ線がここにも引ける。

機械に任せるalt の有無、ラベルの対応、コントラスト比、見出しの階層、妥当なマークアップ
人が見る代替テキストが内容として適切か、Tab の順序が意味として自然か、エラー文言が助けになるか

機械が見られるのは「形式が整っているか」までで、 alt="画像" は形式上は通る。ここを取り違えると、チェックを通すことが目的になる。

回帰を防ぐ意味では自動チェックを CI に入れる価値がある。 壊れてほしくないものは CI に入れるの対象として扱い、 「これで十分」という意味にしない。

関連

バックリンク