企業サイトのアクセシビリティ、何から直す？使えない場面の見つけ方

問い合わせまで、マウスを使わず進んでみる

説明用の例として、サービスを探して相談を送る企業サイトを考えます。キーボードでリンクやボタンへ移動し、メニューを開き、フォームを入力します。途中で現在の位置が分からなくなる、開いたメニューから戻れない、送信へ進めない。その場所が、まず調べたい利用上の障害です。

WCAGにはキーボードで機能を扱えることを求める基準があります。またWCAG 2.2の基準には、フォーカスを受けた部品が作成者のコンテンツによって完全に隠れないこともあります。固定ヘッダーや同意バナーの下へ移動先が隠れていないか、画面の高さが小さい環境でも試すと問題を見つけやすくなります。

キーボード操作では、行けることに加えて、戻れることも試します。メニューを開いた後に閉じる、次の入力欄へ進む、前の欄を直すなど、用事の途中で必要な操作があります。画面上に印が出ても、移動の順番が見た目と大きく違えば迷う場合があります。説明用の例では、サービスを一つ選び直してから問い合わせる操作も試せます。決められた順番を一度なぞるだけでなく、実際に迷い直す場面も含めます。

参考：W3C Web Accessibility Initiative：Understanding SC 2.1.1: Keyboard ／ W3C Web Accessibility Initiative：Understanding SC 2.4.11: Focus Not Obscured (Minimum)

文字を大きくする人、読み上げで聞く人にも意味が届くか

文字を拡大したとき、文章やボタンが途中で欠けていないかを見ます。見出しを文字の大きさだけで表現すると、読み上げでは話のまとまりが分かりにくい場合があります。図に重要な条件を詰め込んでいるなら、本文でも同じ判断ができる説明を用意します。読む方法が変わっても、必要な情報を得られることが目的です。

画像の説明は、長く書けばよいわけではありません。W3Cの代替テキストの判断手順は、画像の役割と文脈を見て選ぶ考え方を示しています。情報を持つ図には意味を伝える説明を用意し、純粋な装飾なら空のaltにする場合があります。原稿の担当者が、その画像から何を知ってほしいかを制作側へ伝えると、適切な説明にしやすくなります。

添付資料にしか載っていない重要な条件も見直す候補です。サービスの対象や申込みに必要な情報を本文で説明できれば、資料を開きにくい環境の人も判断しやすくなります。PDFや動画そのものへの対応が必要な場合は、ページと別に対象へ含めます。また、動く演出が苦手な利用者に向け、動きを減らす設定で必要な情報が消えないかも確認します。情報の意味と、見せる方法を分けて考えると、改修の選択肢が広がります。

参考：W3C Web Accessibility Initiative：An alt Decision Tree

ブランドカラーと、読める文字は両立を考えられる

淡いブランドカラーは、ロゴや装飾では成立しても、小さな注記に使うと読みにくい場合があります。WCAGの文字コントラストは通常の文字で4.5対1以上、大きな文字で3対1以上が基本で、ロゴなどには例外があります。ブランドの色を一律に捨てるのでなく、本文・背景・ボタンごとの組み合わせを調整します。

実際のページでは、写真に重ねた文字や入力欄の説明も確かめます。入力エラーを赤い枠だけで示すと、色で状態を区別しにくい人には理由が伝わりません。「メールアドレスに@を含めてください」のように、直す箇所と方法を文章で知らせます。見た目と意味の両方を確認することで、修正の目的が明確になります。

参考：W3C Web Accessibility Initiative：Understanding SC 1.4.3: Contrast (Minimum)

フォームは、失敗してからが確かめどころ

正しく入力した一回の送信だけでは、使いやすさは分かりません。必須項目を空欄にする、形式を間違える、通信に失敗するなどの状態を検証環境で作ります。入力した相談文が消えず、問題の場所へ進み、修正して再送できるかを確かめます。送信できたかどうかの案内も必要です。

W3Cのフォーム資料は、エラーや成功を利用者へ知らせる方法を扱っています。読み上げでも通知や入力欄との関係が伝わるか、スパム対策の検証で失敗した後も再開できるかを確認します。外部のフォームを埋め込む場合も、訪問者には一続きの操作です。自社で直せる場所と提供元へ相談する場所を分けて進めます。

エラー文を読む順番も、使いやすさに関わります。ページの下にだけ説明が出て、利用者が気づかないまま同じ送信を繰り返す状態は避けたいところです。問題の概要と各入力欄の説明を結び付け、修正した後に何をすればよいかまで伝えます。利用者自身では直せない通信失敗は、入力形式の間違いと同じ案内にしません。再送するのか待つのかが分かる内容にすることで、連絡が届いたか分からない不安も減らせます。

参考：W3C Web Accessibility Initiative：User Notification

自動検査で問題ゼロなら、対応済みと言えるか

自動検査は、構造や属性の問題候補を探し、修正後の変化を確認するのに役立ちます。しかしW3C WAIは、ツールだけで適合を判断できないことを説明しています。画像の説明が目的に合うか、迷わず送信できるかといった部分には、人による判断が必要です。

発注時には、例えばWCAG 2.2のレベルAAなど、目標とする版と水準を示し、調べるページや操作の範囲を決めます。一部の点検を終えたことと、基準全体への適合を評価したことは別です。対象URL、確認した環境、再現手順、残る課題を受け取ると、次にどこを直すかを話し合えます。

表が収まらない場合は横にスクロールできます。

参考：W3C Web Accessibility Initiative：Evaluating Web Accessibility Overview ／ W3C：Web Content Accessibility Guidelines (WCAG) 2.2

全面刷新が難しいときは、止まる経路から直す

説明用の例で、共通メニューと問い合わせに問題があれば、その二つから調べると、多くのページに関わる障害へ取り組めます。過去のPDFをすべて同時に修正できない場合も、今のサービスの判断に必要な資料から優先します。残る問題と次に扱う対象を明らかにし、一部の改善を全体の対応完了として説明しないようにします。

費用は、初期調査、対象の修正、基準に照らした評価、更新担当への引き継ぎで変わります。候補会社には点数だけでなく、実際の操作と残った課題を説明してもらいましょう。公開後も、画像だけの本文や説明のないリンクが増えれば使いづらさは戻ります。CMSの入力欄と確認手順を整え、担当者が意味の伝わる原稿を追加できる状態を保ちます。

社内の更新担当には、禁止事項を長く並べるより、実際の記事を一件一緒に整える方法が考えられます。見出しをどう区切るか、リンク先をどう説明するか、写真に何を添えるかを確認します。その後に別の記事を担当者だけで追加してもらえば、引き継ぎの不足も分かります。新しい部品や外部サービスを入れたときは技術側へ確認を戻すなど、日常の編集と構造の変更で相談先を分けると継続しやすくなります。

検討・発注前のチェックリスト

担当者と確認状況を添えて、社内の検討メモや打ち合わせの議題にご活用ください。

確認日：________________ / 担当者：________________

• □重要なページまでキーボードで移動できるか試す。確認状況・メモ：
• □固定表示で操作中の部品が隠れないか確かめる。確認状況・メモ：
• □文字拡大と読み上げで必要な情報を得られるか確認する。確認状況・メモ：
• □画像の説明と色の組み合わせを内容に沿って見直す。確認状況・メモ：
• □入力ミス・通信失敗からフォームを再開できるか試す。確認状況・メモ：
• □目標の版・水準、評価対象、対象外を明らかにする。確認状況・メモ：
• □修正後の確認と、原稿更新の手順を決める。確認状況・メモ：

よくある質問

参考資料

製品の仕様・提供条件は変更されることがあります。採用時には公式資料と契約内容をご確認ください。

• Web Content Accessibility Guidelines (WCAG) 2.2W3C
• Understanding SC 2.1.1: KeyboardW3C Web Accessibility Initiative
• Understanding SC 2.4.11: Focus Not Obscured (Minimum)W3C Web Accessibility Initiative
• Understanding SC 1.4.3: Contrast (Minimum)W3C Web Accessibility Initiative
• An alt Decision TreeW3C Web Accessibility Initiative
• User NotificationW3C Web Accessibility Initiative
• Evaluating Web Accessibility OverviewW3C Web Accessibility Initiative