【ITニュース解説】Fix the 4 Lighthouse accessibility failures that show up on almost every site

ウェブサイトを開発する際、多くの人々が快適に利用できる状態にすることは非常に重要である。これを「ウェブアクセシビリティ」と呼ぶ。Lighthouseは、Googleが提供するオープンソースの自動化ツールで、ウェブサイトの品質を様々な観点から評価し、特にアクセシビリティの問題点を見つけ出すのに役立つ。一般的なマーケティングサイト、ECサイトのテーマ、ブログなどでLighthouseを実行すると、頻繁に同じ4つのアクセシビリティルールが違反として指摘されることがある。これらの問題は、比較的簡単に修正でき、ウェブサイトをより多くの人にとって使いやすいものにする第一歩となる。

まず、ウェブサイトのアクセシビリティ違反を特定する方法について説明する。LighthouseはGoogle Chromeの開発者ツールに組み込まれているほか、コマンドラインツールとしても利用できる。例えば、ターミナルで「npx lighthouse https://example.com --only-categories=accessibility --view」というコマンドを実行すると、指定したウェブサイトのアクセシビリティに関する詳細なレポートをブラウザで確認できる。また、axe-core CLI（「npx @axe-core/cli https://example.com」）を使う方法や、ウェブサイトを開いたChromeの開発者コンソールに特定のJavaScriptコードを貼り付けて実行する方法でも、違反しているルールIDとその影響度、問題のある要素の数などを一覧で取得できる。これらのツールを使うことで、ウェブサイトが抱える具体的なアクセシビリティ問題を効率的に特定できる。

最も頻繁に指摘される問題の一つが「color-contrast」、つまりテキストと背景の色のコントラスト不足である。この問題は、視覚に障がいを持つ人々や高齢者、一時的に視力が低下している人々にとって、テキストが読みにくくなる原因となる。ウェブコンテンツアクセシビリティガイドライン（WCAG）の1.4.3「コントラスト（最小限）」レベルAAでは、通常サイズのテキストでは背景に対して最低4.5:1のコントラスト比が、大きなテキスト（約24px以上、または18.7px以上の太字）では3:1のコントラスト比が必要と定められている。例えば、ウェブサイトで薄いグレーのテキスト（#999）を白い背景（#fff）に配置した場合、コントラスト比は約2.8:1となり、この基準を満たさない。これを改善するには、テキストの色を濃いグレー（#595959）に変更するなどして、コントラスト比をWCAGの基準を満たす値まで上げる必要がある。Chromeの開発者ツールでは、要素を選択し、スタイルのカラープロパティの隣にある色の見本をクリックすると、カラーピッカーが表示され、そこで現在のコントラスト比とWCAGの基準線を確認しながら、色を調整できる。この問題は、フッターの著作権表示や「詳細はこちら」といった補助的なテキスト、背景に写真が配置されたヒーローセクションのテキスト、フォームのプレースホルダーテキストなど、目立たない部分で発生しやすい。

次に、「image-alt」は、ウェブサイト上の画像に適切な代替テキストが設定されていない場合に指摘される。WCAG 1.1.1「非テキストコンテンツ」レベルAは、非テキストコンテンツには、そのコンテンツが果たす目的と同等のテキストによる代替情報を提供することを求めている。スクリーンリーダーを使用する人々は、この代替テキストを読み上げることで画像の内容を理解する。例えば、ウェブサイトに掲載されている「チームがパン生地をこねている写真」には、「Our three bakers shaping dough at 5 a.m.」（午前5時にパン生地をこねる3人のパン職人）のように、画像が伝える情報を具体的にテキストで記述するべきである。一方で、純粋に装飾的な目的で使用される画像、例えばデザインの一部として配置された抽象的な模様などには、「alt=""」のように空の代替テキストを設定する。これにより、スクリーンリーダーはその画像を読み飛ばし、ユーザーの邪魔にならないようにする。代替テキストを記述する際は、「Image of」（〜の画像）といった冗長な表現から始めないことや、リンクとして機能する画像（例：ロゴ画像がホームページへのリンクになっている場合）には、リンク先の情報（例：「Rosa's Bakery home」）を代替テキストに含めることが重要である。WordPressのメディアライブラリやShopifyの商品画像設定画面など、多くのコンテンツ管理システム（CMS）には、代替テキストを入力するためのフィールドが用意されている。

三つ目の問題は、「link-name / button-name」で、リンクやボタンにアクセシブルネームが不足している場合である。WCAG 2.4.4「リンクの目的」と4.1.2「名前、役割、値」レベルAは、リンクやボタンが、その目的を明確にユーザーに伝える必要があると定めている。特に、ソーシャルメディアアイコン、ハンバーガーメニューアイコン、閉じるボタン（「×」アイコン）、検索アイコン、カルーセルの左右の矢印など、テキストがなくアイコンのみで構成されているコントロールは、スクリーンリーダーで「リンク」や「ボタン」としか読み上げられないため、ユーザーはその機能や目的を理解できない。このような状況を避けるためには、HTMLのaria-label属性を使用して、「Rosa's Bakery on Instagram」（ローザズベーカリーのInstagram）や「Open menu」（メニューを開く）のように、そのリンクやボタンの目的を説明するテキストを設定する必要がある。もし画面上にテキストが明示的に表示されているリンクやボタンの場合は、その表示テキストをアクセシブルネームとして優先するべきである。また、aria-labelを設定する場合でも、そのaria-labelが画面上の可視テキストを含むようにすることが推奨される（WCAG 2.5.3「ラベル内の名前」）。これにより、音声コントロールの利用者も、画面上のテキストをそのまま発話してコントロールを操作できるようになる。

最後の問題は、「label」、フォームフィールドに適切なラベルが関連付けられていない場合である。WCAG 1.3.1「情報と関係性」と3.3.2「ラベルまたは説明」レベルAは、フォームコントロールには、その目的を説明するラベルを提供する必要があることを示している。多くのウェブサイトでは、入力フィールド内に表示されるプレースホルダーテキスト（例：「メールアドレスを入力してください」）をラベルの代わりとして使用しているが、これは不適切である。プレースホルダーはユーザーが文字を入力し始めると消えてしまう上、多くの場合、コントラストが低く読みにくい場合がある。正しい方法は、<label>要素と<input>要素をfor属性とid属性で明示的に関連付けることである。例えば、「<label for="email">メールアドレス</label><input id="email" type="email" name="email">」のように記述する。これにより、スクリーンリーダーが入力フィールドを読み上げる際に、関連するラベルも同時に読み上げ、ユーザーが何をどこに入力すればよいかを正確に理解できるようになる。デザイン上、視覚的なラベルを非表示にしたい場合でも、aria-label属性を使ってアクセシブルネームを提供する必要がある。この問題は、ウェブサイトのフッターに設置されたニュースレター登録フォーム、ヘッダー部分の検索ボックス、オンラインストアの商品詳細ページにある数量入力欄など、様々な場所で頻繁に発生する。

これらのアクセシビリティ問題を修正した後には、再度Lighthouseなどの自動ツールでチェックを実行し、改善が反映されていることを確認する。しかし、自動化ツールだけではウェブサイトのアクセシビリティ問題の全てを検出することはできないため、手動での確認も非常に重要である。具体的には、キーボードのTabキーを使ってページ内を移動し、すべてのインタラクティブ要素（リンク、ボタン、フォームフィールドなど）にフォーカスが当たるか、またそのフォーカスの順序が論理的であるかを確認する。さらに、ウェブブラウザのズーム機能を200%に設定して、レイアウトが崩れずに情報が読み取れるかどうかも確認することが推奨される。これらの基本的なアクセシビリティ改善は、ウェブサイトをより多くの人々にとって使いやすいものにするための重要なステップであり、システムエンジニアを目指す者にとって、ウェブサイト開発の初期段階から意識すべき実践的なスキルである。