【ITニュース解説】A pragmatic accessibility checklist for teams with no a11y specialist

システムエンジニアを目指す上で、Webサイトやアプリケーションを開発する際、多くの人が利用しやすいように配慮する「アクセシビリティ」の概念は非常に重要だ。しかし、Webコンテンツのアクセシビリティガイドライン（WCAG）2.2には87もの成功基準があり、特に少人数のチームで開発を進める場合、これらすべてに対応するのは現実的ではない。そこで、限られたリソースでも最大限の効果を得られるよう、最もユーザーに影響を与えやすい、実用的なアクセシビリティのチェックポイントを理解しておくことが推奨される。この解説では、その特に重要な項目について詳しく説明する。

まず一つ目は、「キーボード操作で全ての対話可能な要素に到達できること」である。マウスを使わずに、キーボードのTabキーなどを使ってウェブサイト上の全てのボタン、リンク、フォーム入力欄といった操作可能な要素に順序良く移動できるかを確認する。さらに、現在どの要素にフォーカスが当たっているか視覚的にわかること、そして、モーダルウィンドウのように一度開いた要素からキーボード操作で確実に閉じたり抜け出したりできることも重要だ。よくある失敗例として、HTMLのdiv要素にクリックイベント（JavaScriptのonclickなど）を設定してボタンのように見せるケースがある。div要素は汎用的なコンテナであり、デフォルトではキーボードでフォーカスしたり、スクリーンリーダーに「ボタンである」と伝えたりする機能を持っていないため、アクセシビリティを損なう原因となる。このような場合は、セマンティックな意味を持つbutton要素を使用すべきである。buttonは最初からキーボード操作に対応しており、スクリーンリーダーにもその役割が正しく伝わるため、追加の工夫が不要になる。

二つ目は、「全ての入力フィールドに適切なラベルがあること」だ。例えばメールアドレスを入力するフォームで、単に「Email」というテキストをspan要素などで入力欄の近くに表示するだけでは不十分である。視覚的には認識できても、スクリーンリーダーのユーザーはそれが何の入力欄であるかを正確に把握できない可能性がある。正しい方法としては、labelタグを使い、そのfor属性で入力フィールドのidと紐づける必要がある。例えば、<label for="email">Email</label><input id="email" type="email">のように記述することで、スクリーンリーダーが「Emailの入力欄」と正しく読み上げ、ユーザーがフォームを操作しやすくなる。また、入力フィールド内に薄く表示されるプレースホルダーテキストは、入力例を示すものであり、ラベルの代わりにはならない。なぜなら、ユーザーが文字を入力し始めるとプレースホルダーテキストは消えてしまい、入力内容を確認する際に何の情報を入力しているのかが分からなくなるため、特に認知負荷が高いユーザーにとっては大きな障壁となるからだ。

三つ目は、「画像は有用な情報を提供するか、または何も伝えないかのどちらかであること」である。画像にはalt属性（代替テキスト）を設定するが、その内容には配慮が必要だ。 もし画像が何らかの情報を伝える役割を持つ場合（例：グラフ、図解、特定の商品写真など）、alt属性にはその画像が「何を伝えているか」を具体的に記述する。単に「画像」や「ロゴ」といった内容ではなく、その情報の内容を説明するのだ。 逆に、画像が純粋な装飾目的で、ページの内容に影響を与えない場合（例：背景のパターン、区切り線など）、alt属性はalt=""のように空に設定する。これは、スクリーンリーダーがその画像を無視し、不要な読み上げでユーザーを混乱させないようにするためである。alt属性自体を省略してしまうと、スクリーンリーダーはファイル名を読み上げてしまうことがあり、かえって情報の邪魔になるため注意が必要だ。 また、テキスト情報を含む画像（例：文字が書かれたバナー画像）は、画像としてではなく、HTMLのテキストとして直接ページに記述するべきである。これにより、検索エンジンも内容を認識しやすくなり、スクリーンリーダーユーザーもテキストを容易に読み取れるようになる。

四つ目は、「本文テキストのコントラスト比は4.5:1を確保すること」である。テキストとその背景色のコントラスト（明度差）が十分でないと、視覚に障害のあるユーザーだけでなく、健常者にとっても読みにくく、目の疲れの原因となる。WCAG AAレベルでは、通常のサイズのテキストには4.5:1以上、大きなサイズのテキスト（18ポイント以上、または太字で14ポイント以上）には3:1以上のコントラスト比が求められる。よくある失敗例として、デザインシステムでデフォルト設定された薄いグレーのテキストが使われている場合が挙げられる。開発者ツール（デベロッパーツール）のカラーピッカー機能を使えば、簡単に現在のコントラスト比を確認できるため、開発の初期段階でチェックすることが重要だ。

五つ目は、「見出しのアウトラインがそれだけで意味をなすこと」である。スクリーンリーダーのユーザーは、キーボードでページを移動するだけでなく、見出しをスキップしてページ構造を把握し、目的のセクションに素早く到達することが多い。このため、h1、h2、h3といった見出しタグは、ページのコンテンツ構造を論理的に示すために使用すべきである。原則として、ページには主要なタイトルとしてh1タグを一つだけ使用し、見出しレベル（h1の次はh2、h2の次はh3など）を飛ばさずに階層を構築することが重要だ。また、見出しタグは単に文字を大きく見せるためだけに使用するのではなく、コンテンツの区切りや主題を示すために用いる。ページの見出しだけを順に読んでみて、その見出しだけでページの全体像や内容が理解できるかを確認すると良いだろう。

六つ目は、「色を唯一の情報伝達手段にしないこと」だ。例えば、入力フォームのエラーを赤い枠線だけで示すデザインは、色覚特性を持つユーザーには認識できない可能性がある。また、太陽光の反射で見えにくい画面や、低品質なディスプレイを使用しているユーザーにとっても、色の違いは判別しにくい場合がある。重要な情報（エラー、成功、警告など）を伝える際には、色だけでなく、アイコンや追加のテキストメッセージなど、複数の手段を組み合わせて情報を提示する必要がある。これにより、より多くのユーザーが情報を確実に受け取れるようになる。

そして七つ目は、「フォーカスが視覚的に認識できること」である。キーボードを使ってウェブサイトを操作する際、現在どの要素が選択されているか、つまり「フォーカス」が当たっているかを視覚的に示すインジケーター（通常はアウトライン）が非常に重要だ。CSSでoutline: none;のような記述を使って、このデフォルトのアウトラインを消してしまうと、キーボードユーザーは自分が現在どの要素を操作しているのかがわからなくなり、盲目的にナビゲーションすることになる。これはWCAG 2.4.7の基準違反となるため、もしアウトラインを消す必要がある場合でも、それに代わる明確な視覚的フィードバック（例：背景色の変更、ボーダーの追加など）を必ず提供する必要がある。

これらのチェックリストは、アクセシビリティの非常に広範な領域のごく一部に過ぎない。ライブリージョン（動的に更新されるコンテンツをスクリーンリーダーに通知する機能）や複雑なウィジェットのセマンティクス、モーションの削減、ユーザーの認知負荷の軽減といった、より高度なアクセシビリティの側面には触れていない。また、altテキストが本当に適切かどうかの判断など、専門的な知識や判断が必要な部分もある。

しかし、アクセシビリティの専門家がいないチームにとって、このチェックリストと自動監査ツールを組み合わせることで、比較的少ない労力で、ユーザーにとって最も「害」となる可能性の高い問題を効果的に解消できる。自動監査ツールは多くの問題を検出してくれるが、すべてのアクセシビリティ問題を網羅できるわけではないことを理解しておく必要がある。実際、自動ツールで検出できるのは問題全体の約3分の1程度だと言われている。そのため、自動ツールでのチェックを行った後も、必ずキーボード操作による手動テストを自分で行い、実際にユーザーになったつもりでサイトやアプリを操作してみることが、アクセシビリティを向上させるための重要なステップとなる。