自動アクセシビリティテストが問題の半分を見逃す理由

自動アクセシビリティテストに関する不都合な真実

自動アクセシビリティテストは、Webチームが身につけられる最良の習慣のひとつです。フォームラベルの欠落、低コントラストのテキスト、不正なARIA、重複ID、空のボタン、その他本番環境に到達すべきではない欠陥を検出できます。

同時に、日常的に誤解されてもいます。

自動アクセシビリティレポートに合格したからといって、そのページがアクセシブルであるとは限りません。それは、ツールが検出方法を知っている問題の一部を見つけなかった、という意味にすぎません。その一部は有用ですが、限界があります。多くのアクセシビリティ上の失敗は、意味、順序、意図、文脈、人間の操作に依存します。ソフトウェアはマークアップを検査できます。しかし、スクリーンリーダー、キーボード、拡大表示、音声操作、キャプション、認知支援を使う人にとって体験が機能しているかどうかを、信頼できる形で理解することはできません。

だからこそ、自動テストは問題の約半分を見逃すという主張は、冷笑的ではありません。むしろ控えめです。高度に自動化できる問題カテゴリもあります。一方で、ほとんど自動化できないカテゴリもあります。

実践的な答えは、自動ツールを捨てることではありません。早い段階で、頻繁に、より広いテストワークフローの一部として、適切な場所に置くことです。

自動テストが得意なこと

自動ツールは、決定論的な失敗を見つけるのに優れています。ルールを機械可読な条件として表現できるなら、スキャナーは通常、それを迅速かつ一貫してチェックできます。

一般的な例は次のとおりです。

• alt属性がない画像
• 関連付けられたラベルのないフォーム入力
• アクセシブルネームのないボタン
• コントラスト基準を満たさないテキスト
• 不正なARIA属性またはロール
• 不自然な形で飛んでいる見出しレベル
• 欠落または重複しているランドマーク
• 空のアクセシブルネームを持つリンク
• 基本構造のないテーブル

これらのチェックは自動化する価値があります。人間は反復的な検査が得意ではないからです。ツールがミリ秒で見つけられるのであれば、誰もすべてのページを手作業で走査してラベルの欠落を探すべきではありません。

自動チェックは、エンジニアリングワークフローの中でアクセシビリティを議論しやすくもします。CIで失敗するテストは具体的です。プルリクエスト内の警告はタイムリーです。テンプレート全体のトレンドラインは、チームに改善対象を示します。

問題は、チームがこれらのチェックを基本的な衛生管理の証明ではなく、アクセシビリティの証明として扱い始めるときに起こります。

自動化が破綻する場所

アクセシビリティはコードだけの性質ではありません。利用の性質でもあります。

ツールは、画像に代替テキストがあるかどうかを教えてくれます。しかし通常、その代替テキストが有用かどうかまでは判断できません。商品の画像は、商品ページでは詳細な説明が必要かもしれません。装飾的なヒーローでは説明不要かもしれません。ヘルプ記事ではまったく別の説明が必要かもしれません。正しい答えは文脈に依存します。だからこそチームには、リンタールールだけでなく、画像の代替テキストへの実践的なアプローチのような編集上の指針が必要です。

同じ問題は至るところに現れます。

スキャナーは、すべてのボタンにアクセシブルネームがあることを確認するかもしれません。しかし、その名前が意味をなしているかどうかを常に判断できるわけではありません。5つのボタンがすべて「送信」という名前のページは、基本ルールには合格しても、スクリーンリーダーユーザーにとっては非常に使いづらい可能性があります。モーダルに正しいARIA属性があっても、フォーカスの閉じ込め方が誤っている場合があります。カスタムドロップダウンは静的なマークアップでは準拠しているように見えても、誰かがキーボードで使おうとした瞬間に失敗することがあります。

自動化は、次のような問いを苦手とします。

• フォーカス順序は視覚的および論理的な順序と一致しているか？
• すべてのタスクをキーボードだけで完了できるか？
• エラーメッセージは具体的で、タイミングが適切で、フィールドに関連付けられているか？
• テキストを拡大またはズームしてもページは機能するか？
• 支援技術にとって読み上げ順序は妥当か？
• 指示は色や位置に依存せず理解できるか？
• キャプション、文字起こし、ラベルは実際に内容を伝えているか？
• コンポーネントは状態をまたいで予測可能に振る舞うか？

これらはエッジケースではありません。アクセシビリティの中核です。

高スコアがもたらす誤った安心感

アクセシビリティスコアは、複雑な主題をひとつの数値に圧縮するため魅力的です。ダッシュボードには98と表示されます。レポートには緑のチェックが並びます。リリースはより安全に感じられます。

しかし、そのスコアが測っているのは、ツールが測れるものだけです。

これはパフォーマンステストにも似ています。Lighthouseレポートは重要な問題を明らかにできますが、中程度の性能のスマートフォンで、実際のユーザーが遅いチェックアウトに苦労している様子を見ることとは同じではありません。チームがすでにパフォーマンス監査を使っているなら、同じ考え方が当てはまります。レポートを注意深く読み、そのうえで実際のユーザーに影響する発見事項を優先します。この違いについては、慌てずにLighthouseレポートを読む方法で書いています。

アクセシビリティレポートにも同じ節度が必要です。自動スキャンがきれいであることは出発点です。証明書ではありません。

チームが静的ページだけを対象にスキャンを実行している場合、このリスクは特に高くなります。現代のインターフェースは状態を持っています。メニューが開き、ドロワーがスライドし、トーストが表示され、バリデーションメッセージが更新され、タブがパネルを切り替え、フィルターがコンテンツを書き換え、認証がすべてを変えます。重大なアクセシビリティ欠陥の多くは、こうしたインタラクションの中に存在します。

スキャナーが初期DOMしか見ていないなら、それはプロダクトを見逃しています。

見逃されやすいカテゴリ

1. キーボードとフォーカスの挙動

キーボードアクセスは、自動化が不十分である理由を示す最も明確な例のひとつです。

ツールは、要素がフォーカス可能かどうかを検出できます。正のtabindex値や明らかなフォーカストラップを見つけることもあります。しかし、タブ順序が一貫して感じられるか、アクション後にフォーカスが適切な場所へ移動するか、閉じたコンポーネントがトリガーへフォーカスを戻すかを、信頼できる形で判断することはできません。

実際のワークフローを通して、人間がTab、Shift+Tab、Enter、Space、Escape、矢印キーを押す必要があります。

これはカスタムコントロールでは特に重要です。ネイティブHTML要素には、長年にわたって積み重ねられたアクセシビリティ上の挙動が無料で備わっています。ボタン、セレクト、チェックボックス、メニュー、ダイアログをdivで作り直すということは、その挙動をチームが所有するということです。インタラクティブなコンポーネントをレビューするなら、アクセシブルなWebボタンのための短いチェックリストから始め、同じ規律をすべてのカスタムコントロールに広げてください。

2. 意味のある名前と説明

自動ツールは欠落の検出には向いています。品質の検出ははるかに苦手です。

「続きを読む」という名前のリンクは、技術的にはアクセシブルネームを持っているかもしれません。「OK」というラベルのボタンは妥当かもしれません。フォームのヒントは存在しているかもしれません。しかし、それらは文脈の中で意味がありますか。多くの場合、そうではありません。

アクセシブルネームは、何が起こるのか、またはその要素が何を表すのかをユーザーに伝えるべきです。それには判断が必要です。また、コードだけでなくインターフェースを使ったテストも必要です。

3. エラー処理

フォームには、スキャナーでは部分的にしか捉えられないアクセシビリティ上の失敗が数多くあります。

ツールはラベルのないフィールドを指摘するかもしれません。しかし、バリデーションメッセージの表示が遅すぎる、消えるのが早すぎる、スクリーンリーダーに通知されない、または「無効な入力」ではなく「パスワードは12文字以上である必要があります」と言うべきである、といった問題は見つけられないかもしれません。

良いエラー処理はインタラクションデザインです。手動テストが必要であり、理想的にはユーザーテストも必要です。

4. 視覚的な適応

WCAGには、テキストのリサイズ、リフロー、コントラスト、間隔、単一の感覚的手がかりに依存しないことに関する要件が含まれています。この一部は自動的にチェックできますが、本当の問いは、条件が変わってもインターフェースが使えるままであるかどうかです。

200%ズームを試してください。ブラウザーのテキストサイズ変更を試してください。高コントラストまたは強制色モードを試してください。狭いビューポート幅を試してください。動きの低減を試してください。デフォルト設定では洗練されて見える多くのサイトが、ユーザーが自分の設定を反映した途端にすぐ壊れます。

5. コンテンツの明確さ

自動アクセシビリティツールは、コンテンツが理解しやすいかどうかを完全に評価することはできません。

見出しの欠落や曖昧なリンクテキストは指摘できます。しかし、ページがプロセスを明確に説明しているか、ラベルがユーザーの期待と一致しているか、密度の高い文章が避けられる認知負荷を生んでいるかは分かりません。

アクセシビリティは、支援技術との互換性だけではありません。ストレス下にある人、なじみのない言語を使う人、注意の制約に対処している人、複雑なタスクを進めている人の摩擦を減らすことでもあります。

より良いテストワークフロー

バランスの取れたアクセシビリティワークフローには層があります。

自動チェックを継続的に実行する

開発、プルリクエスト、コンポーネントプレビュー、CIで自動テストを使います。それらは退屈で、高速で、交渉の余地がないものであるべきです。新しいラベル欠落や不正なARIAを見つけるために、四半期ごとの監査を待つべきではありません。

これらの失敗はリンティングの失敗と同じように扱います。目標は英雄的な対応ではなく、回帰を防ぐことです。

手動のキーボードテストを追加する

意味のあるすべてのユーザーフローについて、マウスなしでテストします。これにはナビゲーション、検索、アカウント作成、チェックアウト、フィルタリング、モーダル、メニュー、フォーム送信が含まれます。

最低限、次を確認します。

• すべてのインタラクティブ要素に到達できる
• フォーカスが常に見える
• フォーカス順序が論理的である
• 期待されるキーが機能する
• Escapeで閉じられるオーバーレイが閉じる
• コンポーネントの開閉後にフォーカスが管理される
• キーボードトラップが存在しない

このひとつの習慣だけで、自動スキャンが見逃す大きな問題群を見つけられます。

少なくとも1つのスクリーンリーダーでテストする

有用なことを学ぶために、スクリーンリーダーの専門ユーザーになる必要はありません。ただし謙虚さは必要です。スクリーンリーダーテストには学習曲線があり、初心者は問題を誤診することがあります。

それでも、VoiceOver、NVDA、JAWSを使った基本的なテストは、壊れた名前、混乱を招く読み上げ順序、通知されない更新、スキャナーでは見つけられないランドマークの問題を明らかにできます。

これをセマンティックHTMLと組み合わせてください。ネイティブ要素を多く使うほど、アクセシビリティは壊れにくくなります。

コンテンツと状態をレビューする

空の状態、読み込み状態、エラー状態、無効状態、成功メッセージ、権限エラーを確認します。アクセシビリティのバグは、ハッピーパスの外側に隠れていることがよくあります。

実際の言葉もレビューしてください。ラベル、見出し、指示、エラーメッセージはインターフェースの一部です。

重要度が高い場合は障害のあるユーザーを含める

重要なフローでは、専門家による手動レビューだけでは十分ではありません。障害のある参加者とのユーザーテストは、チームが予期しない問題を見つけます。これは公共サービス、医療、金融、教育、そして排除が重大な結果をもたらすあらゆるフローで特に重要です。

自動テストはスケールします。人間によるテストは理解します。

自動結果を責任を持って解釈する方法

「合格したか」と尋ねないでください。

より良い問いを立ててください。

• このツールはどの問題カテゴリを検出できるか？
• どのテンプレートと状態をスキャンしたか？
• インタラクション後に実行されたか、それとも初期読み込みだけか？
• 違反は根本原因ごとにまとめられているか、それとも繰り返し数えられているか？
• どの失敗が、ユーザーのタスク完了を妨げるか？
• 何がまだ手動レビューを必要としているか？

この枠組みは会話を変えます。自動ツールは証拠であって、権威ではありません。

これはチームが無駄な作業を避ける助けにもなります。ひとつのコンポーネントを修正すれば、繰り返し報告されている何百もの違反が消えるかもしれません。逆に、報告された問題が1件だけのページにも、重大なキーボードトラップが含まれている可能性があります。件数は影響度ではありません。

実践的な基準：明らかなものは自動化し、体験は手動でテストする

優れたアクセシビリティチームは、ツールに反対しているわけではありません。幻想に反対しているのです。

機械が信頼して検出できるものは自動化します。挙動と意味に依存するものは手動でテストします。WCAGのような標準は共通の基準線として使い、プロダクトを実際に使うことの代替にはしません。

現在のプロセスがローンチ前の自動スキャンだけなら、次の順序で改善してください。

1. 開発のより早い段階に自動チェックを追加する。
2. 主要フローを手動でキーボードテストする。
3. 名前、ラベル、エラー、指示をレビューする。
4. 一般的なコンポーネントをスクリーンリーダーでテストする。
5. 高リスクのジャーニーには専門家レビューとユーザーテストを取り入れる。

これは完璧なプロセスではありません。現実的なプロセスです。そして、緑色のアクセシビリティスコアだけでは決して見つからない多くの問題を見つけることができます。