役割で回すWebアクセシビリティ試験プログラムの作り方

アクセシビリティ試験は、公開直前に専門家へ渡す監査ではなく、変更ごとに必要な証拠を設計、制作、実装、QA、公開判断へ配る運用プログラムにします。自動スキャンの結果があっても、キーボードで主要タスクを完了した人、リフローを確認した人、ラベルの意味を判断した人、修正後の再試験者が不明なら、公開判断に必要な証拠はそろっていません。

最終監査ではなく「試験プログラム」にする条件は何か

試験プログラムとは、異なる問いに答える証拠を工程全体へ配置し、最終的な受入責任を明確に保つ仕組みです。W3Cは、問題を修正しやすい開発・再設計の早期から、アクセシビリティを継続して評価するよう勧めています。同じ資料は、評価ツールだけでは標準への適合を判断できず、知識を持つ人の評価が必要だと明記しています。Section508.govのRACI例も、アクセシビリティ活動を企画、設計、開発、QA、専門家、コンテンツ、監督の各役割へ工程全体で分配しています。これは日本企業の法的要件ではなく、責任分配の参考例です。

• 自動検出：プログラムで検出可能な条件を反復して探す。
• 手動適合確認：操作、構造、文脈上の意味を人が確かめる。
• 支援技術試験：代表的タスクで特定環境との互換性を確かめる。
• 障害のある人による評価：実利用上の使いにくさや未充足ニーズを調べる。

公開する変更に応じて試験の深さをどう変えるか

深さは、影響するインタラクション、再利用範囲、新規性、重要な利用者経路、想定される影響に合わせて増やします。選定前に、影響する経路、コンポーネント、テンプレート、コンテンツ種別、文書、メディア、操作部品、対応技術を棚卸しします。Section508.govのプログラム指針は、自動確認やスポット確認からコンポーネント試験、包括的試験まで深さを分け、継続監視と障害のある人によるユーザビリティ評価も別に扱っています。WCAG-EMは、範囲と目的を定義し、主要な画面と機能を調査し、必要なら代表的な対象を選び、評価して結果を報告する流れを示します。

• コンテンツのみ：人による内容確認と適用可能な自動確認。構造、メディア、文書、操作、タスクの意味が変わる場合は関連する手動試験を追加する。
• 視覚・配置：設計確認、自動確認、ズームとリフロー。操作へ影響する場合はフォーカスも確認する。
• 部品・操作：実装前の受入条件、開発者の局所確認、QAの独立試験、全状態と代表的タスク、再利用箇所の回帰試験を行う。
• 新テンプレート・重要経路・大型公開：適用可能な全層、訓練された支援技術試験、代表的な適合性評価、変更可能な段階での障害当事者評価を組み合わせる。

試験所有マトリクスには何を記し、誰へ引き渡すか

マトリクスには、試験層、変更の発動条件と範囲、最初に有効な工程、実施者、承認者、必要能力と環境、保存証拠、公開停止条件、修正・再試験責任者を一行で結びます。Section508.govのRACI例では、UXが設計確認、開発者が実装とコード確認、著者がアクセシブルなコンテンツの作成・確認、QAが自動・手動試験の計画と実行を担い、承認や監視にも責任者を置いています。同サイトのアジャイル工程表は、アクセシビリティ受入条件、手動単体確認、自動回帰試験、CI/CD、受入試験、欠陥記録、公開準備、証拠ログ、公開後のフィードバックを通常の成果物へ組み込んでいます。Section508.govのプログラム指針は、試験時期、実施者、深さ、必要な能力、環境、方法、結果追跡を定めるよう勧めています。

すべての変更に、担当者名、証拠、再試験経路が付いたとき、アクセシビリティは「誰かの最後の確認」ではなくなります。

中核となるアクセシビリティ確認では何を見るか

中核確認は、チェック項目の有無ではなく、代表的タスクを完了でき、情報と状態を理解できるかを調べます。WCAG 2.2は、経路に依存する入力の例外を除き、機能をキーボードインターフェースで操作でき、フォーカスしたコンポーネントから離脱できることを求めます。レベルAAではキーボードフォーカスが見え、作成者が追加した内容でフォーカス対象が完全に隠れないことも必要です。文字は、規定された例外を除き、内容や機能を失わずに200％まで拡大できるかを確認します。リフローは、二次元配置が意味や利用に不可欠な場合を除き、320 CSSピクセル相当の幅で横スクロールを、256 CSSピクセル相当の高さで縦スクロールを生じさせず、情報と機能を保つ条件です。WCAG 2.2には、ページタイトル、見出しとラベル、文脈上のリンク目的、入力指示など、人が意味を判断しなければならない要件もあります。

• キーボード：全操作、順序、見えるフォーカス、部品への出入り、状態変化、エラーからの復帰をタスク単位で確認する。
• コンテンツ：見出し、ラベル、リンク、指示、エラー、字幕、書き起こし、代替テキストが文脈上役立つかを人が判断する。
• ズーム・リフロー：画素の一致ではなく、情報・機能の欠落、遮蔽、フォーカス隠れ、画面外の変化、条件外のスクロールを探す。
• 自動確認：反復可能な検出へ使い、対象範囲と除外を記録する。検出ゼロを適合判断にはしない。

支援技術、障害当事者、適合性評価をいつ追加するか

新しい操作、再利用範囲の広い部品、重要経路、大型変更には、訓練された支援技術試験、障害のある人による評価、代表範囲の適合性評価を目的別に追加します。GOV.UKは、支援技術試験を開発中、特に大きな機能や変更の後に、代表的なタスクで行うよう案内しています。同指針は、問題、影響を受ける利用者、ブラウザー、OS、支援技術と版、優先順位付けと再試験に足る証拠を記録するよう求めています。環境は固定表をコピーせず、利用者の根拠、製品技術、サポート方針、既知のリスクから選びます。W3Cは、障害のある人による評価が適合性評価だけでは見つからない使いにくさを発見できる一方、それだけでWebサイトがアクセシブルかを判断できないとしています。また、一人の参加者の経験を障害者全体へ一般化せず、試作段階の意見聴取から正式なタスク型調査まで、工程に合う方法を選ぶよう助言しています。WCAGも、最高レベルへ適合しても、障害の種類、程度、組合せが異なる全員にアクセシブルになるとは限らないと注記しています。

証拠で公開を管理し、試験プログラムをどう改善するか

公開判断は一つの点数ではなく、その変更区分で必要な試験が完了し、停止対象が修正・再試験され、範囲、方法、環境、結果、所有者、処置、再試験状態を追跡できるかで行います。決定者は権限を持つプロダクトまたは公開責任者、証拠提供はQAと専門家、修正責任は作成者です。Section508.govのアジャイル工程表は、試験計画、欠陥記録、キーボードとスクリーンリーダーの確認、報告、ログ、公開準備、公開後のフィードバックをつなぐ公的機関の例です。同サイトのプログラム指針も、試験深度、時期、役割、能力、環境、追跡、公開前条件を含む一貫した反復可能な方法を推奨しています。例外を認める方針なら、承認者、理由、影響を受ける利用者、緩和策、期限、追跡事項を残します。例外は元の不合格を変えず、適合の根拠にもなりません。W3Cが開発全体での評価を勧めるとおり、公開後の報告と再発傾向も次の設計、テンプレート、教育、回帰試験へ戻します。

1. 重要な利用者経路を一つ選び、証拠の流れを最後まで完成させる。
2. 各役割の担当者を指名し、必要な操作と判断を訓練する。
3. 証拠テンプレートと適切な自動確認を通常工程へ追加する。
4. 実際の所見を使って公開停止条件を調整する。
5. 再発する欠陥を設計、部品、テンプレート、教育へ反映する。
6. 運用できた範囲から他の経路と変更区分へ広げる。