ウェブアクセシビリティの要件定義｜発注前に決める5項目

はじめに

「画面はきれいにできた。でも、キーボードだけでは申請を完了できない」。公開前にこうした問題が見つかると、見た目だけでなく、入力の仕組みや画面の構造から見直すことになります。

ウェブアクセシビリティの要件定義では、誰が、どんな環境で、どの業務を完了できるようにするかを、発注前に具体化することが大切です。「アクセシビリティに配慮する」という一文だけでは、開発会社と発注側で完成の判断が揃いません。

W3C WAIの計画ガイドは、目標、対象範囲、責任を文書にする考え方を示しています。この記事では、その考え方を踏まえ、業務部門やDX推進の担当者が、発注前に決めたい5項目を整理します。以下の社内申請フォームは説明用の例です。

「使いやすい」と「利用できる」を分けて考える

画面の印象がよくても、必要な情報を受け取れなかったり、操作を完了できなかったりすれば、業務には使えません。たとえば、必須項目を赤色だけで示すフォームや、マウスを重ねないと開かないメニューは、利用環境によって障壁になります。

要件を検討するときは、障害名だけで利用者を分類するのではなく、具体的な操作条件へ置き換えてみましょう。「音声で画面の情報を受け取る」「文字を拡大して読む」「マウスを使わずに入力する」といった条件なら、業務担当者も完了までの手順を考えやすくなります。

ただし、担当者が想像した条件だけで、すべての利用者を代表できるわけではありません。可能な範囲で当事者の意見を取り入れ、評価方法は専門家とも相談します。社内向けだから不要、利用者から申告がないから問題がない、と判断しない進め方が重要です。

発注前に決めたい5つの項目

1. 対象ページと業務の開始・終了を決める

最初に、今回の対象を一覧にします。トップページや入力画面だけでなく、ログイン、確認画面、完了通知、エラー表示、ヘルプ、PDFなどの関連文書も確認してください。

社内申請なら、「ログインし、必要事項を入力し、確認後に送信して、受付結果を確認する」までを一つの業務として追います。入力画面だけが操作できても、確認画面で先へ進めなければ申請は終わりません。

対象外を決める場合も、一覧から消すのではなく、理由と利用者への影響を残します。対象範囲を狭めたことと、サイト全体で利用可能になったことは別です。外部サービスで自社だけでは直せない部分は、提供元への確認や代替手段の検討をタスクにします。

2. 基準の名前・版・目標を明記する

「JISに対応」「WCAGを参考にする」だけでは、どの版の、どの水準を求めるのか分かりません。規格やガイドラインの名称、版、目標とする適合レベル、対応状況をどう示すかを、発注書類へ明記します。

国内向けの企画や発注条件を整理する際には、プロメトリックのアクセシビリティガイドライン「企画・要件定義」が参考になります。国際的な達成基準を確認するときは、W3CのWCAG 2.2など、版を特定した原文へ立ち戻ります。

ここで大切なのは、規格名を並べて終えないことです。たとえばJIS X 8341-3:2016を軸にし、WCAG 2.2の追加項目も求めるなら、追加分の一覧と確認方法を別に整理します。両者を同じものとして扱うと、試験項目や報告範囲が曖昧になります。

目標は発注側が一方的に書くのではなく、現状、対象範囲、予算、確認体制を踏まえて合意します。本記事は個別案件の法的義務を判定するものではありません。適用条件や対外的な表記が不明な場合は、法務・調達担当とアクセシビリティの専門家に確認してください。

3. 重要な操作を受入条件へ変える

基準を指定したら、業務側でも確認できる具体例を添えます。規格のすべてを独自のチェックリストに置き換えるのではなく、業務上重要な場面を開発会社と共有するためです。

社内申請フォームなら、次のように書けます。

• キーボードだけで入力欄、確認、送信へ移動できる
• 現在どの操作対象を選んでいるか、画面上で分かる
• 必須項目や入力エラーが色だけに依存せず伝わる
• 入力欄の名前と説明を、読み上げでも識別できる
• 文字を拡大しても、必要な内容や操作が失われない
• エラーを直した後、申請を完了して結果を確認できる

WCAGにはキーボード操作、フォーカス、ラベル、エラーの識別などに関する達成基準があります。実際の試験では各基準の条件や例外も確認し、上の例だけで適合を判定しないでください。

「入力エラーが分かる」も、もう一段具体化できます。たとえば「数量が未入力で送信したとき、対象項目と修正に必要な説明を確認でき、数量を入力して再送信できる」と書けば、業務側も何を確かめるかが分かります。完成条件から逆算する考え方は、受け入れ条件の整理とも共通します。

4. 自動チェックと人の確認を分ける

検査ツールの点数や「エラー0件」だけを、合格条件にしないでください。W3C WAIの評価ガイドは、ツール単独では基準を満たすか決定できず、知識を持つ人の評価が必要だと説明しています。

発注前に、自動チェック、キーボード操作、スクリーンリーダーによる確認、必要に応じた利用者評価をどう組み合わせるか決めます。スクリーンリーダーは、画面の情報を音声などで利用者へ伝える支援技術です。

確認環境は「主要ブラウザで実施」だけで済ませず、OS、ブラウザ、支援技術の種類と版、画面サイズなどを記録します。また、通常画面だけでなく、入力エラー、確認ダイアログ、送信後の結果など、状態が変わった場面も対象へ含めます。

確認時期も重要です。デザイン段階では見た目や説明、試作段階では操作と構造、公開前には業務全体というように、段階ごとに見ます。最後に一度だけ検査する計画では、修正が大きくなる問題を発見する時期も遅くなります。

5. 証跡・修正・公開後の担当を決める

納品物には、対象一覧、評価方法、確認環境、結果、不具合と修正状況を含めます。「対応済み」という結論だけでは、どの画面をどう確認したのか追えません。

問題が残る場合は、影響を受ける操作、暫定対応、修正担当、期限、再確認の方法を残してください。重大な操作不能を見つけたのに、全体の平均点で合格にするような扱いは避けます。公開可否を誰が判断するかも、先に決めておきます。

公開後には、記事更新、画像差し替え、入力項目の追加で状態が変わります。制作会社だけでなく、CMSを操作する担当者や文書の作成者も、運用の責任に含めて考えましょう。定期点検と、利用者から困りごとを受け取る窓口を用意すると、納品時の確認で終わらない運用につながります。

見積もり時の5つの確認事項

同じ「アクセシビリティ対応」という見積項目でも、範囲は揃っているとは限りません。金額だけを比較する前に、次の点を確認します。

• 設計時のレビューと公開前の試験の両方を含むか
• 手作業の確認や支援技術を使う検査を含むか
• 外部サービス、PDF、既存コンテンツはどこまで対象か
• 発見した問題の修正と再試験を何回、どの条件で行うか
• 報告書、チェックリスト、運用担当者向けの説明を納品するか

検査だけの費用と、設計・修正・再確認までの費用を分けると、比較の前提が見えます。対象未定の項目は概算の根拠と追加費用の条件を明記し、発注後の「含まれていない」を減らしてください。

まず一つの業務で合意を作る

最初からすべての画面の詳細を書き切るのが難しければ、申請や問い合わせなど、利用者が結果まで到達すべき業務を一つ選びます。対象、基準、受入条件、確認方法、担当と証跡の5項目を揃え、ほかの業務へ展開しましょう。

上流工程AIワークスペース「Kakusill」は、散在する仕様書や業務の暗黙知をAIが使える形に整理し、要件定義から仕様管理までを支えます。既存資料の中に利用条件や対象外の判断が散らばっているなら、まず判断の所在と未決事項を整理するところから始められます。アクセシビリティ試験や適合の判断そのものは、必要な専門性と実際の確認を伴う別の工程として計画してください。