ウェブアクセシビリティを正しく行うポイントとは？その1

以前の「ウェブアクセシビリティチェックが必要な理由」では、ウェブアクセシビリティの概要とその重要性についてご紹介しました。今回はそこから1歩踏み込み、ウェブアクセシビリティの具体的なチェック方法について、実際に当社が対応したプロジェクトの事例を交えながら解説します。

アクセシビリティのチェック方法

ウェブアクセシビリティチェックは、Webで使用される技術の標準化を目標とする国際的な非営利団体「World Wide Web Consortiuｍ」（通称：W3C）が勧告する国際的なガイドラインである「WCAG（Web Content Accessibility Guidelines）」に基づいてチェックを行います。
チェックには「目視チェック（手動チェック）」と「自動チェック」の2つの方法があり、相互に補完し合う関係として、必ず両方のチェックを行います。

目視チェック（手動チェック）

人間の視覚的なチェックまたは手動で確認を行うプロセスです。具体的には、画像の代替テキストが正確な内容であるか、フォーカスの順序が違和感を与えないかなど、後述の自動化ツールでは判断しきれない要素を対象としています。

アクセシビリティにおける「フォーカス」とは、ウェブサイトやアプリケーションのユーザーインターフェースで、ユーザーが現在操作している要素やコントロールがどれであるかを示す視覚的な強調を指します。通常、ユーザーはキーボードやその他の入力デバイスを使用してウェブページやアプリ内のさまざまな要素（リンク、ボタン、フォームフィールドなど）を操作します。フォーカスは、ユーザーがどの要素に焦点を当てているかを示すため、視覚障害者やキーボードユーザーにとって非常に重要です。

自動チェック

「axe devtools」などのアクセシビリティ自動チェックツールを用いて、ソースコードなどに基づき、機械的にウェブサイトやアプリのアクセシビリティを評価します。このツールは、目視での検査では見逃しやすい微細な問題を見つけるのに適していますが、文章の内容の正確性など、人間による判断が必要な要素に関しては対処できません。

アクセシビリティチェックの具体例「サービス紹介・お問い合わせページ」

今回は、ウェブアクセシビリティの中でも企業の課題となりやすい、視覚的なチェック（目視チェック・手動チェック）に焦点を当てて、事例と具体的なチェック内容を説明します。

【チェック対象】

サービス紹介ページおよびそのサービスの問い合わせページに対してアクセシビリティチェックを実施しました。サービス紹介ページには、サービスの紹介文だけでなく、サービス利用の手順などが画像と文章で説明されています。問い合わせページは、問い合わせ内容の入力、入力内容の確認、送信完了の3ページで構成されていました。

【チェック内容・結果・改善策】
WCAG2.1の各項目とともに行ったチェック内容・チェック結果・改善策をご紹介します。
※実際は本記事で紹介した項目以外のチェックも行っております。

◇チェックその１「非テキストコンテンツ」　（WCAG2.1　項目番号1.1.1）

チェック内容）

サービス紹介ページにあるサービス利用手順について、手順の順番が「STEP1」など画像を用いて表記されており、各手順はイメージ画像を用いて説明されていました。
そこで、HTMLソースコードにおいて、Webページ上に画像を表示するためのimg要素に設定されるalt属性に適切な代替テキストが記述されているかをチェックしました。alt属性とは、何らかの理由で画像が表示できない場合などに表示する代替テキストを設定する為の属性となります。alt属性はスクリーンリーダーで画像を読み上げる場合も使用します。

チェック結果）

「STEP1」等のalt属性は単に「ステップ」とのみ記述されており、このままでは画像を見ることが出来ないユーザーに、どのステップなのか正しい情報が伝わりません。その為、ウェブアクセシビリティとしては完全ではありません。

改善策）

alt属性を画像と同じ「STEP1」などに記述する修正が必要です。
各手順のイメージ画像については、「手順1のイメージ」などの代替テキストが設定されていましたが、手順の詳細は通常のテキストで記載されていました。
この場合は、情報として意味をなさない画像（装飾目的の画像）であり代替テキストは不要である為、スクリーンリーダー（画面上のコンテンツを読み上げるツール）がこの画像を読み飛ばせるように空のalt属性(alt="")を設定する必要があります。何らかの理由で文字が読めないユーザーはスクリーンリーダーの読み上げを頼りにWebページを閲覧します。

◇チェックその２「キーボード」　（WCAG2.1　項目番号2.1.1）

チェック内容）

サービス紹介ページ内にあるサービス紹介文部分はディスクロージャー（長い文章などを「折り畳み/展開」するパーツ）で開閉して説明されていました。そこで、サービス紹介ページ内にあるリンクやボタンなどのコントロールパーツについては、何らかの理由でキーボードのみで操作するユーザーがTabキーによるフォーカスやEnterキーでの押下などキーボード操作ができるかをチェックしました。キーボード操作はPCだけでなくスマホやタブレットの場合も、スマホ用キーボードなどを使用する想定でチェックを行います。

チェック結果）
ディスクロージャーの開閉ボタンにTabキーでフォーカスをあわせることが出来ませんでした。

改善策）
TabキーでのフォーカスとEnterキーでの押下に対応できるようにするなどの修正が必要です。

◇チェックその３「エラーの特定」　（WCAG2.1　項目番号3.1.1）

チェック内容）
お問い合わせの入力ページにて、必須項目が未入力、または入力内容が不適切であるなど、入力内容に不備がある状態でボタン「入力内容を確認する」を押下した場合、一律「入力内容に問題があります」というエラーが表示されました。

チェック結果）
このエラー内容では、入力内容のどこに問題があるのか分かりません。

改善策）

未入力であれば「〇〇の項目が未入力です」、入力内容が不適切な場合は「メールアドレスは半角英数で入力してください」など入力項目の内容や不備の内容に応じたエラーを表示するように修正が必要です。

◇チェックその４「ラベル・説明」　（WCAG2.1　項目番号3.3.2）

チェック内容）
お問い合わせの入力ページにて、例えば氏名など、スクリーンリーダーでフォーム部分を読み上げた際、何のためのフォームか正しく読み上げることができるか、テキスト入力フォームのソースコードをチェックしました。

チェック結果）
ラベルテキストとフォームが関連付けられていませんでした。

改善策）
Label要素を用いてラベルテキストとフォームを関連付けるよう修正しました。

（Label要素：HTMLにおいて、ラベルテキストと<input> や <textarea> のフォーム要素との関連付けに使用される）
また、メールアドレスの入力フォームについて、半角英数記号以外は入力できないにもかかわらず、実際に入力を試みたところ、半角英数記号以外は入力できないことが注意事項として記載されていませんでした。
入力内容に関するルールがある場合は、そのことを明記しなければならない為、フォームより前に「半角英数、半角記号で入力してください。」という注意事項を記載する必要があります。これは、スクリーンリーダーで読み上げた際、読み上げ順序として入力に関する注意書きはフォーム部分より先に読み上げる必要がある為、フォームより前に注意書きを記載する必要があります。

◇チェックその５「名前・役割・値」　（WCAG2.1　項目番号4.1.2）

チェック内容）

サービス紹介ページにあるサービス紹介文のディスクロージャーについて、スクリーンリーダーによる読み上げを頼りに操作するユーザーが、ディスクロージャーを開くことが出来るかどうか、スクリーンリーダーの使用中にディスクロージャーの開閉を試みました。

チェック結果）

開閉状況がスクリーンリーダーに通知されませんでした。

改善策）

開閉ボタンにaria-expanded属性を使用し、開閉状況が通知されるように設定する必要があります。aria-expanded属性とは、button要素などで作られた開閉するパーツの開閉ボタンに設定すると開閉状況が通知されるようになる属性です。

まとめ

ウェブアクセシビリティチェックは、ウェブサイトの使いやすさとアクセスの向上に不可欠なプロセスです。本記事の事例を通じてその重要性と具体的な方法について理解を深め、ユーザーの多様なニーズに対応し、適切なウェブデザインとコンテンツ作成を行いましょう。
その他当社が対応したプロジェクトのウェブアクセシビリティチェック事例と注意すべきポイントは以下の記事でご紹介しております。是非ご覧下さい。

>>​​​​​​​ウェブアクセシビリティを正しく行うポイントとは？ その2を読む