プロンプトとコンテキスト
企業は、キーボードユーザー、スクリーンリーダーユーザー、ロービジョンの人々、認知障害を持つ人々がコアワークフローを利用できるようにしたいと考えています。フィードバックにはコントラスト、フォーカス順序、フォームエラー、動的ステータスが含まれていますが、共通のベースラインが存在しません。ユーザーや標準規格から監査範囲、リリースのガバナンスに至る2四半期の計画を設計してください。
面接官がテストしていること
面接官は、「コンプライアンス」をユーザーの成果へと変換するプロダクト上の意思決定を見ています。優れた回答は、WCAGの達成基準、法的な適用可能性、プロダクト体験を明確に区別し、自動スキャンを完了とみなしません。WCAG-EMは評価者に対してスコープ、代表的なページ、テスト環境の定義を求めており、Digital.govはプロダクトマネージャーに対し、要件定義、リサーチ、デザイン、受け入れ基準にアクセシビリティを含めることを推奨しています。
最初に確認すべき明確化のための質問
ユーザーと重要なタスク
影響を受けるユーザー、地域、支援技術を確認し、サインイン、作成、エクスポート、決済、その他の重要タスクをリストアップします。単なる欠陥数ではなく、タスクの妨げとなっている度合いと影響を受けるユーザーを優先します。
標準規格とオーナーシップ
WCAG 2.2 AAまたは契約で指定されたバージョン、適用されるSection 508や現地の法律、そしてプロダクト、デザイン、エンジニアリング、QA、法務、顧客対応の各オーナーを確認します。
現状とデリバリーの制約
デザインシステム、コンポーネントライブラリ、自動テスト、手動テストの予算、顧客の納期を確認します。ロードマップは、新機能のゲートとレガシーページの負債の両方を処理する必要があります。
30秒の回答フレームワーク
「私はターゲットユーザー、重要なタスク、適用される標準規格から着手し、代表的なページと支援技術を使用してベースラインを確立します。サインイン、フォーム、ナビゲーション、エラー、ステータスフィードバックを妨げる問題を優先し、新規開発のDoneの定義（Definition of Done）にアクセシビリティの受け入れ基準を追加します。成功指標には、タスク完了率、キーボードおよびスクリーンリーダーの欠陥解消、手動監査の合格率、クレームの推移が含まれます。自動スキャンはトリアージ用であり、証明ではありません。2四半期後、プロダクトは一度限りのレポートではなく、継続的なガバナンスメカニズムを維持します。」
ステップごとの詳細な回答
ステップ1：スコープと成果を定義する
「プロダクト全体」をユーザー、ページテンプレート、重要なタスク、目標とする標準規格へと分解します。まずは重要なワークフローの完了にコミットし、その後にトラフィックの少ないページへと拡大します。スコープ外のリスクも記録しておきます。
ステップ2：根拠となるベースラインを確立する
代表的なページと状態を選択し、自動スキャン、キーボード操作ウォークスルー、スクリーンリーダー、ズーム、コントラストチェック、ユーザーインタビューを組み合わせます。影響を伴わないスクリーンショットを並べるのではなく、達成基準、環境、再現手順、影響、深刻度を記録します。
ステップ3：ブロックリスクを順位付けする
サインインや送信ができない問題、フォーカスの喪失、通知されないエラー、動的ステータスの無音、調整不可能な制限時間を優先します。法定制限や契約上の期日は制約条件として扱い、ユーザーへの影響の唯一の代用にはしません。
ステップ4：デザインとエンジニアリングの変更を計画する
ページ個別の例外に対処する前に、共通コンポーネントとデザイントークンを修正します。キーボードの動作、可視フォーカス、アクセシブルな名前、エラーの関連付け、ステータスの通知を追加します。新しいコードには、静的解析（lint）、自動チェック、手動サンプリングの通過を義務付けます。
ステップ5：受け入れ基準をデリバリーに組み込む
要件にユーザータスクと達成基準を追加し、デザインレビューでインタラクションを検証し、プルリクエストやステージング環境で自動テストと手動テストを実行します。高リスクな作業にはアクセシビリティの承認が必要です。例外にはオーナーと有効期限を設定します。
ステップ6：指標とコミュニケーションを定義する
ブロッキング欠陥、修正時間、リグレッション、手動監査のカバレッジ、クレーム、サポートチケットを、タスク、支援技術、リリースごとに追跡します。根拠を超えて「完全にアクセシブル」と主張するのではなく、対応範囲、既知の制限事項、フィードバック手段を公開します。
ステップ7：継続的にガバナンスを実施する
四半期ごとにサンプリング監査を実施し、コンポーネントのベースラインとトレーニングを刷新し、新しいブラウザや支援技術をレビューします。アクセシビリティの負債をプロダクト計画とリスクレビューに組み込み、ロードマップ終了後も予算、オーナー、エスカレーション体制が維持されるようにします。
高品質な回答例
私は、サインイン、コアフォーム、ナビゲーション、エラー、動的ステータスを対象の支援技術で完了させ、その後にページの網羅率を拡大するという2四半期の目標を設定します。第1週にWCAG 2.2 AA、法的および契約上の境界を確認し、自動スキャン、キーボード、スクリーンリーダー、ズーム、ユーザーフィードバックを用いて、代表的なテンプレートとタスクからベースラインを作成します。
優先順位付けには、スキャナーのカウントではなく、タスクの妨げ度合い、影響を受けるユーザー、修正のレバレッジを用います。共通コンポーネントを最初に修正し、新規作業に受け入れゲートを追加します。高リスクな例外にはオーナーと有効期限が必要です。週次の指標ではブロッキング欠陥、修正時間、リグレッション、手動カバレッジ、タスク完了をカバーし、月次の顧客コミュニケーションではサポート範囲と制限事項を明示します。成果物は一度限りの「スキャン合格」レポートではなく、持続可能なガバナンスです。
よくある間違い
- 間違い： 自動スキャン100%を適合と見なす。 → 失敗の理由： スキャナーはキーボードの順序、セマンティックな体験、タスクの妨げを見逃します。 → 解決策： 自動化を手動テスト、支援技術テスト、ユーザーテストと組み合わせます。
- 間違い： タスクへの影響度ではなく欠陥数で順位付けする。 → 失敗の理由： 多数の軽微な問題の陰に、サインインを完全に阻害する重大なブロッカーが隠れてしまうことがあります。 → 解決策： 重要なタスク、影響を受けるユーザー、修正のレバレッジを評価します。
- 間違い： 新しいページのみを修正する。 → 失敗の理由： 共通コンポーネントの不具合はワークフロー全体で繰り返し発生します。 → 解決策： ページごとの例外に対処する前に、デザインシステムとコンポーネントを修復します。
- 間違い： 社外に対して「完全にアクセシブル」と約束する。 → 失敗の理由： 標準規格、支援技術、テストされていないスコープは変化します。 → 解決策： サポート範囲、根拠、制限事項、フィードバック窓口を公開します。
フォローアップの質問と回答
フォローアップ1：キャパシティが1種類のエラーしかカバーできない場合、何を選択しますか？
キーボードによるフォーム送信や知覚可能なエラーなど、最も重要なタスクをブロックしている共通の問題を選択します。ユーザーの証拠、契約期日、修正範囲を考慮してトレードオフを説明し、残りのリスクを次の四半期に登録します。
フォローアップ2：エンジニアリングチームが「手動監査は遅すぎる」と主張した場合はどうしますか？
自動化を再現性のあるトリアージに使用し、手動の工数は高リスクなテンプレートや実際のタスクに集中させます。コンポーネントの修正とサンプリングを並行して実行し、手動対自動の議論をするのではなく、発見率、リグレッション率、タスク完了率を通じて価値を示します。
フォローアップ3：WCAGへの適合は法的な安全性と同等ですか？
いいえ。WCAGは技術標準であり、法的な適用範囲、契約上の義務、その解釈には異なる境界が存在します。標準規格とユーザーからの証拠がプロダクトの優先順位を導く一方で、法務チームが法的義務を確認する必要があります。
フォローアップ4：ロードマップ完了後のリグレッションをどのように防ぎますか？
コンポーネントのベースライン、PRチェック、手動サンプリング、四半期監査、オーナー、例外の有効期限を通常のデリバリープロセスの一部に組み込みます。承認された改修期日が存在しない限り、アクセシビリティゲートを通過せずに新しい作業を安定版リリースに含めることはできません。