INSIGHT
画面は完成。でも、その操作をできない人がいませんか？——利用者の条件を確かめる
マウスや見た目で確認しただけでなく、異なる条件でも仕事を終えられるか。
AIで社内申請画面を作り、担当者がマウスで一通り操作した。見た目は整い、登録も完了したので公開日を決める。ところが、キーボードだけでは日付欄から次へ進めない。画面を拡大すると送信ボタンが隠れる。読み上げでは三つの「入力してください」が区別できない。画面が表示されることと、利用者が仕事を完了できることは別です。
アクセシビリティは、公開直前に色や文字サイズを調整するだけの仕事ではありません。誰が、どの環境で、どの業務を完了する必要があるかを決め、発注、設計、実装、受入れ、公開後の修正へつなげます。
作った人が操作できたという確認を、利用者が必要な仕事を完了できたという確認へ変えます。
画面一覧より先に、利用者の仕事を一本選ぶ
最初からすべての画面を同じ深さで調べると、重要な操作が埋もれます。まず、利用者が失敗すると申請、購入、予約、問い合わせなどを完了できない流れを一本選びます。たとえば経費申請なら、ログイン、明細入力、領収書添付、エラー修正、送信、受付確認までです。
その流れについて、利用者、端末、ブラウザー、入力方法、支援技術、通信環境を確認します。「高齢者向け」「障害のある人向け」と大きく括らず、キーボードで操作する、画面を200％まで拡大する、読み上げを使う、色を見分けにくい、音声を聞けない、といった操作条件へ落とします。
業務の完了条件も決めます。ボタンへ到達できるだけでなく、必須項目を理解し、誤りを直し、送信結果を確認できるところまでを一つの流れとして扱います。途中で別の窓口へ切り替えられるなら、その窓口の営業時間、待ち時間、担当も確認します。
キーボードでは、順序と現在地を確かめる
マウスを使わず、Tabキーなどで最初から最後まで進みます。すべての入力欄、ボタン、リンク、メニューへ到達できるか。選んだ項目から抜けられるか。操作の順序が画面の意味と合うか。現在選ばれている場所を目で確認できるかを見ます。
よくあるのは、開いたメニューから出られない、カレンダーで日付を選べない、見た目だけを整えたボタンが操作対象にならない、ポップアップを閉じた後に現在地を失う、といった状態です。順序が左から右へ進んでも、確認画面やエラー欄を飛び越えれば仕事は終わりません。
結果は「キーボード対応済み」と一語で残さず、使用環境、操作した経路、できなかった手順、回避手段、修正担当を記録します。初期点検で通っても、実際の支援技術や別のブラウザーで同じ結果になるとは限りません。
キーボード確認では、押せたキーの数ではなく、順序を理解し、現在地を見失わず、仕事を完了できたかを見ます。
名前、説明、エラーを、画面の外でも伝える
画面上で「氏名」「住所」と並んでいても、読み上げでは入力欄の名前が登録されていなければ、すべて「テキストフィールド」としか伝わらない場合があります。アイコンだけのボタン、見た目の位置だけで結び付けた説明、色だけで示した必須・任意も、意味が届きません。
各入力欄と操作に、目的が分かる名前と説明を結びます。見出しと読み順を整え、画像には用途に応じた代替情報を置きます。装飾画像へ長い説明を付けることや、図の意味をファイル名だけで済ませることも避けます。
エラーは、赤色だけで示さず、何が起き、どの項目をどう直せるかを文章で伝えます。送信後に処理中、完了、失敗が切り替わる場合は、画面を見ていない利用者にも状態変化が分かるかを確認します。同じ誤りを繰り返さないよう、入力値を不必要に消さず、該当箇所へ戻れるようにします。
拡大、色、画面幅を変えても、仕事を隠さない
文字を拡大したときに、本文が読めても、保存ボタンが画面外へ固定され、横へ動かさなければ押せないことがあります。スマートフォン幅では表の右側やエラー表示が消えることもあります。拡大率と画面幅を変え、文字、入力、操作、エラー、確認画面が重ならず、順序を保つかを試します。
色は、コントラストだけでなく、色だけが唯一の情報になっていないかを見ます。「赤は未処理、緑は完了」であれば、文字や記号でも状態を示します。画像内の文字、薄いプレースホルダー、無効に見えるボタンも確認します。音声や動画には、業務上必要な情報を別の方法で受け取れるかを見ます。
W3C WAIのEasy Checks – A First Review of Web Accessibility は、ページタイトル、画像の代替情報、見出し、コントラスト、文字拡大、キーボード操作など、初期確認の入口を示しています。同ページは、簡易確認だけでは包括的な評価にならないことも明記しています。AI生成画面の欠陥率や、個別サイトの適合を示す資料ではありません。
初期点検、専門評価、実利用者の確認を分ける
作成チームの初期点検は、明らかな問題を早く見つけるのに役立ちます。ただし、簡易チェックをすべて通過しても、特定の規格への適合や、実利用者が業務を完了できることを自動で証明しません。求める水準に応じて、支援技術を使った確認、専門家による評価、実利用者による業務試験を組み合わせます。
自動検査でエラーがゼロでも、ボタンの名前が利用者に通じるか、説明を読んで誤入力を直せるかまで確かめたとは限りません。自動検査の結果には対象と方法を付け、人が操作して分かったこと、まだ試していない環境を別に残します。
デジタル庁のウェブアクセシビリティ導入ガイドブック は、専門家でない人にも分かる形で、ウェブアクセシビリティの必要性や、発注・受託を含む導入の考え方を案内しています。個々の事業者へ特定の規格を一律に義務付ける資料としては扱いません。対象サービスに適用される法令、契約、調達条件、社内基準は別に確認します。
問題票には、該当する業務、影響を受ける操作条件、再現手順、代替手段、優先度、修正担当、再確認者を記録します。重要業務を完了できない問題は、見た目の調整より先に直します。修正後は、その部品だけでなく、開始から完了までを再び通します。
初期点検は合格証ではなく、専門評価と実利用者の確認へ渡す問題と条件を見つける入口です。
自分の初期点検と、専門家・実利用者へ頼む確認を分ける
自分でできる初期点検の結果を、試した環境と経路ごとに残します。名前や説明の実装、支援技術との組合せ、規格への適合など、自分で判定できないことは専門家へ渡します。実利用者の試験は目的と方法を担当と決め、本人の協力を得て行います。
自分の点検を業務・制作・運用の担当へ渡す一枚には、対象業務、利用条件、初期点検結果、専門評価の要否、未解決問題、代替手段、修正担当、公開判断者、再確認日を載せます。その場で合意するのは「配慮する」という方針だけではありません。誰がどの環境で何を試し、どの問題を公開前に直し、残る問題をどう利用者へ伝え、いつ再確認するかです。
公開後の窓口では、利用者が支援技術の詳しい説明をしなくても、「どの画面で、何を完了できなかったか」を伝えられるようにします。報告を個別対応で閉じず、同じ部品を使う画面への影響も調べます。
見た目だけでなく、異なる操作条件でも利用者が仕事を完了できるか確かめる
AIで画面を速く作れても、利用者の操作条件までは自動で確認されません。重要な業務を一本選び、キーボード、名前と説明、エラー、拡大、色、画面幅を変えて試すと、見た目だけでは分からない障壁が見えます。
まず、自分が作った重要な操作を一本、キーボードだけで通してみてください。できなかった手順と環境を記録し、直したら完了まで再び試します。通った範囲だけを確認済みとし、専門評価と実利用者の確認が必要な条件は、担当へ引き継ぎます。