注文システムのアクセシビリティはどう試す？検査範囲と結果の確かめ方

注文の仕事を、検査の依頼に変える

アクセシビリティは、見る・読む・操作する方法が異なる人も、必要な情報を得て仕事を進められるようにする考え方です。この例では、見た目の画面を点検するだけでなく、取引先が入力し、誤りに気付き、直して確認するまでを、検査の目的へ結びます。

相談に関わるのは社内IT発注担当、注文する取引先、開発会社、検査担当です。IT発注担当は取引先が終えたい仕事を、開発会社は画面・状態・動きの関係を、検査担当は確かめる方法と限界を説明します。この役割の一覧だけで、検査担当や判断者が了承済みとは決まりません。

注文の仕事と、検査担当へ渡す対象の説明が、つながっているでしょうか。

「ツールで点検する」の中身を、作業に戻して聞く

自動ツールが何を対象にし、どの問題候補を出すのか、結果を誰が確かめるのかを聞きます。注文の入力欄へ到達できるか、エラーの案内から直す場所が分かるか、確認へ戻れるかは、それぞれの画面の状態と操作を説明して初めて依頼できます。ツール名だけで対象や完了条件を決めないようにします。

W3C WAIは、単独のツールだけではアクセシビリティ基準を満たすか判断できず、知識を持つ人の評価が必要だと説明しています。まず依頼したい仕事を示し、ツールと人の確認をどう組み合わせるか、検査担当へ具体化してもらいます。

自社の企業サイトを簡易点検し、制作担当へ問題箇所を渡したい場合は、企業サイトのキーボードと表示を点検する方法が入口です。本稿は、これから発注する注文システムの検査を、どんな範囲・方法・報告条件で頼むかに絞ります。

入力・エラー修正・確認を、同じ注文で追う

同じ画面でも、最初に開いた状態、数量を入力した状態、エラーが出た状態では、読む情報や操作が変わります。URLの数だけを数えず、何をするとその状態になり、どこへ戻って何を直すかを、開発会社へ説明してもらいます。

入力から、数量エラーの修正、送信前確認まで、同じ注文の状態を追えるでしょうか。

この節の解説図を原寸で見る

注文品と数量を入力

対象の画面・状態は「注文入力画面」、利用者の作業は「品目を選び数量を入力」です。品目の選択から数量の入力へ進むために、どの欄と操作が必要かを開発会社へ聞きます。画面を開けたことと、必要な項目へ到達して入力できたことを分けて確かめられるようにします。

数量の入力エラーを直す

対象の画面・状態は「数量エラー表示と元の入力欄」、利用者の作業は「案内を読み数量を直す」です。どんな条件で数量エラーを出すかは、実際の入力規則を開発会社へ聞いて決めます。本稿では数量の上限・下限や実際のエラー文を作っていません。検査担当へは、案内を認識し、対象の欄を見付け、必要な内容を保って直せるかを確かめる依頼へつなぎます。

送信前の注文内容を確認

対象の画面・状態は「確認画面」、利用者の作業は「品目・数量を読み、必要なら前へ戻る」です。確認する品目と数量、前へ戻る操作、戻った後に何が保持されるかを示します。「確認画面を表示した」だけで終わらせず、内容を理解して必要な修正へ戻れるかを検査担当と相談します。実際の注文送信が必要な場合の試験先や扱いは、別途決める条件です。

実システムにログイン、選択肢の追加、画面内のダイアログ、通信後に変わる表示などがあるなら、それらが注文の仕事にどう関わるかも聞きます。この架空例に存在すると決め付けず、確認して対象に含めるか、扱いを保留するかを明記します。

操作方法を、注文の各状態へ結ぶ

画面と状態ごとに、何をどんな手段で確かめるかを相談します。キーボードの確認、拡大時の確認、読み上げなどの支援技術による確認は、同じ操作の別名ではありません。ツールで出た候補と、人がどの条件で観測したかを対応させる必要があります。

同じ注文の各状態に、キーボード・拡大・読み上げの確認条件が対応しているでしょうか。

この節の解説図を原寸で見る

キーボードは、移動だけでなく、選び直しと修正まで頼む

この計画では、三つの状態ともキーボード確認を行う案です。実施や到達、合格を示す値ではありません。今の操作対象を示す印をフォーカスと呼びます。検査担当には、必要な欄や操作へ進めるか、順序とフォーカスが分かるか、選択・修正・前へ戻る操作をどう確かめるかを聞きます。

数量エラーが出た場面では、エラーの案内からどの欄へ移動し、どの操作で直すかを具体化します。矢印キーなど別の操作が必要な部品があるなら、その部品の説明と操作方法を開発会社へ確認します。本稿の静的な説明図を、実画面でキーボード操作が成功した証拠にはしません。

拡大は、見える大きさと、読んで操作できる状態を確かめる

三つの状態とも拡大表示を確認する案です。どの端末・ブラウザで、文字だけか画面全体か、どの条件まで確かめるかは、適用する基準と利用状況を踏まえて検査担当と決めます。ここで実施済みの拡大率や測定値は示していません。

品目名と数量、エラーの案内、確認画面の説明や操作が欠けたり重なったりしないかを、同じ仕事に沿って聞きます。文字が大きく見えたことだけで、エラーを直すための欄や操作も使えるとは判断しません。表示が変わったときの画面幅や設定を、結果と一緒に読めるようにします。

読み上げの確認は、条件が未合意なら質問を残す

三つの状態の読み上げ確認の計画は未確認です。「試さない」「不要」とは決まっていません。どんな支援技術とブラウザの組合せが必要か、項目名・入力値・エラー・状態の変化をどう確かめるかを検査担当へ聞きます。実際の利用者による確認を行うかも、目的と体制を分けて相談します。

各状態の確認方法について、関係者の合意も三つとも未確認です。予定の丸印を増やすのでなく、何を確かめ、何を報告する方法かを読み合わせます。未合意の方法を、実施済みや合格の欄へ移さないようにします。

検査環境と、今回の評価の目的をそろえる

同じ画面でも、対象の版、端末、ブラウザ、支援技術の組合せが違えば、結果の適用範囲が変わります。検査の前に条件をそろえ、報告ではどの組合せの結果かを読めるようにします。未知の組合せを、成功した条件へ補いません。

今回知りたいことは、選んだ仕事の確認ですか。製品全体の適合についての評価ですか。

対象版と、端末・ブラウザ・支援技術をそろえる

この例では対象版、対象端末、ブラウザの版、支援技術との組合せが、いずれも未確認です。IT発注担当は取引先の利用状況を業務側へ聞き、開発会社の対応条件と照らし合わせます。その材料を検査担当へ渡し、今回確かめる組合せと残る範囲を決めます。

試験用の内容と、検査する人・方法を決める

試験用データ、検査担当、自動ツール、手動の確認方法も、いずれも未確認です。どの入力条件でエラーを出すか、何を観測すれば判断できるかを相談します。実在の取引先情報や本番の注文を、そのまま試験用へ使う前提にはしません。

実送信を含む確認が必要なら、送信先、試験環境、記録の扱いなどを開発会社と管理する担当へ確認します。本稿は注文の送信や実顧客への連絡、実システムの操作を行う指示ではありません。説明用の画面・状態と、許可された実試験の場所を分けて計画します。

限定した確認と、適合の目標を混ぜない

この例の適合目標は未確認です。WCAGはWebコンテンツのアクセシビリティに関するガイドラインです。どの版と目標レベルを求めるかを、記事側で決めたことにはしません。適合の表明を行う場合の対象や条件は、検査担当へ確認してください。

WCAG 2.2の適合要件は、ページ全体と一連のプロセスを扱います。WCAG-EM 2.0は、製品の範囲と評価の前提を定め、代表的な標本や一連の操作を含めて評価・報告するための参考方法です。選んだ部分だけを評価することと、製品全体の適合を表明できることを同一には扱いません。

実施した範囲と、結果・未確認を報告で読む

報告書では、合否や点数より先に、何を対象にし、どの条件と方法で実施したかを読みます。注文の入力画面と数量エラー、確認画面の説明が、依頼した版・状態・方法に対応しているかを照合してください。

注文のどの状態を試し、何を観測し、何が未確認かを、報告書でたどれるでしょうか。

この節の解説図を原寸で見る

観測を、画面・状態・方法・環境へ結ぶ

実施された確認については、対象の版、画面と状態、利用した方法と環境、入力や操作、期待したことと観測したこと、判断の根拠を対応させます。再現に必要な情報を受け取る範囲と共有方法も合わせます。機密性のある入力内容や認証情報を、公開資料へ記載する必要はありません。

この例の三つの状態では、実際の試験結果は未確認、発見事項の件数も未確認です。把握できている結果の記録がないことを、指摘0件や試験完了と読み替えません。実施の有無と結果が記載されていないなら、どこまで確認したかを検査担当へ質問します。

「未実施」と確認できた範囲と、記載が不明な範囲を分ける

ある方法が実施されていないと確認できたなら、対象と理由、残る確認を記録します。報告に記載がないだけなら、まず実施したかどうかを確かめます。この例の読み上げ確認の未合意を、非実施確定の記録へ変えません。

報告を取りまとめる担当は未確認です。IT発注担当は、誰が説明を受け、開発会社へ修正や追加説明を返すかを決めます。依頼した状態が抜けていた場合と、実施した結果で困る操作が見つかった場合では、次に依頼する仕事が違います。

この例の受入判断は未確認です。検査の実施範囲、残る問題と未確認、修正と再確認の扱いを、判断する人へ返します。報告書が作られたことや、ツールの警告がなかったことだけで、取引先が注文を終えられる、全体が適合したとは決めません。

修正した版と、同じ条件での再確認を結ぶ

修正したという連絡を受けたら、対象版と変えた箇所を開発会社へ確認します。元の指摘が、どの状態・操作・環境の問題だったかを照合し、新しい版で何を確かめるかを検査担当と決めます。修正の連絡と、再確認の結果は別の情報です。

元の報告のどの問題を、どの変更と再確認へつなげるでしょうか。

三つの状態の再確認の結果は、いずれも未確認です。再確認の条件も未確認です。元の版と変更後の版を分け、どの端末・ブラウザ・支援技術と操作をそろえるか、何をもって対応を確認したと判断するかを合わせます。

同じ部品が別の画面で異なる動きをする場合や、画面の追加で注文の道筋が変わった場合は、影響を踏まえて範囲を見直します。変更の説明を受けずに、前の結果をそのまま新しい版へ移したり、毎回無条件に全体をやり直すと決めたりしないようにします。

利用者による確認を計画する場合は、誰にどんな目的で協力してもらい、何を観測するかを別に相談します。一人の操作結果をすべての利用者の結果へ広げません。全体の試験目的や開始・終了条件は、試験を始める前の計画をそろえる方法とも対応させてください。

まとめ：同じ注文の状態から、範囲と報告を相談する

アクセシビリティ検査を頼むときは、注文入力から数量エラーの修正、送信前確認までを一つの仕事として説明します。画面と状態、操作方法、環境、結果の読み方をそろえると、どこを検査し、何が残るかを担当者と相談できます。

最初に、注文のどの状態を開発会社と検査担当へ見せるでしょうか。

三つの場面は、一つの架空注文を説明する計画です。キーボード確認の予定を実施・到達・合格に変えず、読み上げ確認の未合意を「試さない」と決め付けません。実画面・実試験・修正・利用者の成功・全製品のWCAG適合を示す記録ではありません。