Webアクセシビリティ対応を外部に依頼するとき、失敗の多くは「何を満たせば完了なのか」があいまいなまま発注することから起きます。見た目を少し直すだけなのか、フォームや検索、会員機能まで含めて改善するのか。自動チェックだけでよいのか、スクリーンリーダーやキーボード操作まで確認するのか。ここを決めずに進めると、納品直前に認識のずれが表面化します。
Webアクセシビリティとは、障害のある人、高齢者、スマートフォンだけで利用する人、支援技術を使う人などが、情報や機能をできるだけ同じように利用できる状態を目指す考え方です。詳しい基本整理は、関連するWebアクセシビリティの実務ポイントも参考になります。本記事では、発注者が事前に決めるべき項目、発注書に入れたい要件、検証と進行管理の考え方を整理します。
発注時にアクセシビリティ要件を明文化する理由
アクセシビリティ対応は、単にチェック項目を後から足す作業ではありません。設計、デザイン、実装、コンテンツ、運用がつながって初めて成果が出ます。そのため、発注段階で要件を明文化しておくことが重要です。
| 観点 | 発注時に決めること | 確認例 |
|---|---|---|
| 利用者 | 誰が、どの機能を、どの環境で使うのか | スマートフォン、キーボード操作、スクリーンリーダー利用を想定する |
| 基準 | どのアクセシビリティ基準を目安にするのか | WCAG 2.1のレベルAAなど、対象とする版とレベルを明記する |
| 責任範囲 | 誰が設計、実装、検証、修正判断を担当するのか | 発注者、制作会社、開発会社、運用担当の役割を分ける |
| 検証 | どの方法で合否を確認するのか | 自動チェック、手動確認、支援技術での確認、ユーザーテストを組み合わせる |
また、国内外にはアクセシビリティに関係する法制度やガイドラインがあります。たとえば日本では障害者差別解消法に関する理解も欠かせません。ただし、発注書だけで法的な適否を判断するのではなく、必要に応じて所管官庁の情報や専門家の確認を受ける前提で進めると安全です。
発注前に準備すること
1. 対象範囲を具体的に決める
まず、どのページや機能を対象にするのかを決めます。サイト全体なのか、問い合わせフォーム、資料請求、予約、検索、会員登録などの重要導線だけを優先するのかで、必要な工数と検証方法は変わります。
発注書では、「トップページと主要下層10ページ」「問い合わせフォーム一式」「ログイン後の管理画面は対象外」のように、含める範囲と含めない範囲を分けて書くと認識がそろいやすくなります。
2. 達成したい基準を決める
次に、どの基準を目安にするかを決めます。原稿ではWCAG 2.1のレベルAAを例にしていますが、案件によって求める版やレベルは変わります。大切なのは「アクセシビリティ対応をする」とだけ書かず、対象とする基準、対象ページ、確認方法をセットで示すことです。
3. 現状の問題を把握する
既存サイトを改修する場合は、発注前に現状を確認します。自動チェックツールで見つかる問題もありますが、それだけでは読み上げ順、キーボード操作、フォームのエラー表示、文章のわかりやすさまでは十分に判断できません。Webアクセシビリティチェックツールによる確認と、専門家や利用者視点の確認を組み合わせると、発注内容を具体化しやすくなります。
4. 関係者の合意を取る
アクセシビリティ対応は、制作担当だけで完結しません。経営層、広報、マーケティング、システム、カスタマーサポートなど、サイトに関わる部門が影響を受けます。発注前に目的、優先順位、スケジュール、公開後の運用方針を共有しておくことで、途中の判断が速くなります。
発注書に入れたい具体的な要件
発注書では、抽象的な表現を避け、確認可能な要件に落とし込みます。以下のような項目を、対象範囲に合わせて記載するとよいでしょう。
- 情報を伝える画像には、内容を説明する代替テキストを設定する。
- 見出しはページ構造に沿って順序どおりに設定し、見た目だけで見出しを作らない。
- フォームの入力欄には、対応するラベルとエラー説明を関連付ける。
- 主要な操作は、マウスを使わずキーボードだけでも完了できるようにする。
- リンク文言は「こちら」だけにせず、移動先や目的がわかる表現にする。
- 色だけで状態を伝えず、テキストやアイコンなど別の手がかりも用意する。
- モーダル、メニュー、タブなどの操作部品は、フォーカス移動と読み上げ順を確認する。
- 検証結果、未対応項目、修正方針を納品物として提出する。
特に、支援技術での確認は発注書に明記しておくと安心です。たとえばスクリーンリーダーで読み上げたときに、見出し、フォーム、ボタン、エラー内容が自然な順序で伝わるかを確認します。
テストと検証は複数の方法で行う
アクセシビリティ検証は、自動チェックだけで完了とは考えないほうが現実的です。自動チェックは早く広く確認できますが、文脈に合った代替テキストか、リンク文言が利用者に伝わるか、操作の流れが自然かといった判断は人の確認が必要です。
| 検証方法 | 確認しやすいこと | 注意点 |
|---|---|---|
| 自動チェック | 代替テキストの欠落、フォームラベルの不足、構文上の問題 | 意味の適切さまでは判断しにくい |
| 手動レビュー | 見出し構造、リンク文言、入力エラー、キーボード操作 | 担当者の知識によって品質に差が出る |
| 支援技術での確認 | 読み上げ順、フォーカス移動、操作部品の伝わり方 | 対象環境を事前に決めておく必要がある |
| ユーザーテスト | 実際の利用場面で迷う箇所、説明不足、完了しにくい導線 | 対象者、シナリオ、評価方法を設計しておく |
検証結果は、単なる合否だけでなく、問題箇所、影響範囲、修正優先度、再確認の方法まで残します。これにより、納品後の運用改善にもつなげやすくなります。
進行管理で見るべきポイント
発注後は、最後にまとめて確認するのではなく、設計、デザイン、実装、テストの各段階でレビューを入れます。アクセシビリティの問題は、後工程になるほど直しにくくなるためです。
- 初回キックオフ：対象範囲、基準、納品物、検証方法を確認する。
- 設計レビュー：ページ構成、見出し、フォーム、導線、エラー表示の方針を確認する。
- デザインレビュー：文字サイズ、色の使い方、操作部品、状態表示を確認する。
- 実装レビュー：キーボード操作、読み上げ順、ラベル、フォーカス管理を確認する。
- 受け入れ確認：発注時に定めた要件を満たしているか、証跡とともに確認する。
フィードバックの回数と期限も、事前に決めておきます。アクセシビリティ対応は細部の調整が多いため、「1回の確認で終わり」と想定するより、修正と再確認の時間を最初から組み込むほうが現実的です。
避けたい曖昧な発注表現
発注書の表現が曖昧だと、制作側も判断に迷います。次のように、抽象的な依頼を確認可能な表現へ置き換えましょう。
| 曖昧な表現 | 置き換え例 |
|---|---|
| アクセシビリティに配慮すること | 対象ページについて、指定した基準と検証方法に沿って確認し、未対応項目を一覧で提出すること |
| 画像をわかりやすくすること | 情報を伝える画像には代替テキストを設定し、装飾画像は読み上げ対象にしないこと |
| フォームを使いやすくすること | 各入力欄にラベルを関連付け、エラー内容と修正方法をテキストで示すこと |
| 公開前にチェックすること | 自動チェック、キーボード操作、支援技術での確認結果を納品前に共有すること |
まとめ
Webアクセシビリティ対応の発注では、目的、対象範囲、基準、検証方法、責任分担を最初にそろえることが重要です。発注内容が具体的であれば、制作側は作業範囲を判断しやすくなり、発注側も納品物を確認しやすくなります。
アクセシビリティは、単なる追加要件ではありません。すべての人にとって使いやすいWebサイトを育てるための品質管理です。最初の発注書に検証と改善の流れまで組み込んでおくことが、公開後の運用にも効いてきます。
当社では、Webアクセシビリティを簡単に導入できるUUU ウェブアクセシビリティウィジェットツールを提供しています。アクセシビリティ向上に関心がある方は、詳細をご覧ください。