プロジェクトの各段階で、誰が何をするか

W3Cの計画の手引きは、最初に決めておくこととして、次を挙げています。

• 目標： 方針には少なくとも、どのアクセシビリティの規格に、いつまでに適合するかを書きます。これを契約と完成の定義の両方に入れます。適合レベルは法令や契約で決まることもあります。レベルが何を求めるかは、ページがWCAGに適合するための条件で扱います。
• 責任者： W3Cは、アクセシビリティの実現を特定の人に割り当て、職務の内容に含めるよう勧めています。そうすれば、その人は作業の時間と研修を得られます。目標と日程がぶつかったときに決めるのは、指名された1人です。
• 予算： レビュー、研修、診断、利用者とのテストに、それぞれ日程上の時間を取ります。診断で見つかった問題を直す時間がなければ、手に入るのはレポートだけで、サイトは良くなりません。
• 研修： 役割ごとに必要なものを用意します。W3Cは、デザイナー向けのアクセシブルな視覚デザイン、開発者とテスト担当者向けのアクセシブルなコーディング、コンテンツの書き手向けのアクセシブルな文章の書き方を挙げています。
• 購入するもの： 購入したコンポーネント、ウィジェット、システムもサイトの一部です。契約の前にアクセシビリティを確かめます。方法は購入の前に、ベンダーのVPATをどう読み、何を尋ねるかで説明しています。

完成の定義は、目標をストーリーごとの確認に置き換えたものです。短く、すべてのストーリーで同じものを使います。

• デザインシステムのコンポーネントで作られている。新しいコンポーネントを足す場合は、そのアクセシビリティのテストも足している。
• CIの自動チェックで、新しい問題が報告されていない。
• すべてのコントロールをキーボードだけで操作でき、順番が画面と一致し、フォーカス表示が見える。
• チームで決めたスクリーンリーダーとブラウザーで、そのストーリーのタスクを最後まで行える。
• 200%の拡大表示と、幅320 CSSピクセルで使える。
• 見出し、リンクの文言、ラベル、代替テキストを確認している。

完成したサイトの診断で見つかる問題の多くは、少数のコンポーネントが全ページで同じように壊れているものです。だから、共通の部品を、それを使うページより先に作って確かめます。W3Cの実装の手引きは、アクセシブルなコンテンツを作りやすくするために、アクセシブルなテンプレートとコンポーネントの開発を優先するよう勧め、計画の手引きは、アクセシブルなコンポーネントのライブラリーを保つことを開発の役割としています。

• ボタン： コンポーネントライブラリーの標準をHTML標準の button にして、Tabキーで到達できないdivのボタンのような div がどのページにも入らないようにします。
• フォーカス： フォーカス表示をデザインシステムのトークンに1つ用意し、フォーカス表示が見えない独自デザインのボタンのように、リセットでページごとに消えることがないようにします。
• 入力欄： ラベルがない・表示と食い違うフォームの入力欄にあるように、共通の入力欄コンポーネントでラベルを必須のプロパティにし、for と id を一緒に生成します。
• ダイアログ、メニュー、タブ： 操作を伴う部品は、キーボードの動作をページではなくコンポーネントに組み込みます。

デザイナーが渡すのは絵だけではありません。W3Cの成熟度モデルは、開発者に渡すデザインの成果物にアクセシビリティの情報と注釈を含めることを挙げています。見出しの構造、フォーカスの順番、各コントロールの名前と状態などです。コンテンツの書き手は、部品では決められない見出し、リンクの文言、代替テキストを書きます。

W3Cは、リスクと費用を減らすために問題を早く見つけて直すこと、確認を別に行うのではなく、チームがすでに行っているテストに組み込むことを勧めています。確認をどこに置くかは、プロジェクトの進め方で変わります。

進め方	アクセシビリティを確認する時期	遅れて見つかったときの負担
ウォーターフォール	要件とデザインを目標に照らして確認し、制作のあとにテスト工程を1回	共通部品の問題が、全ページで使われてから見つかる。デザイン、コード、テストをやり直すことになる
アジャイル	ストーリーごとの完成の定義で毎スプリント、節目ではより広く	問題を作ったスプリントのうちに見つかり、コードが新しいうちに直せる
継続的デリバリー	変更ごとに自動チェック、リリースの間に決まった間隔で手作業の確認	変更は自動チェックを通って公開され、残りは手作業の確認で拾う

どの進め方でも、3種類のテストが別々の役割を担います。

• CIの自動チェック： プルリクエストごとに行います。名前の抜け、誤ったARIA、コード上のコントラストなどを、手間をかけずに毎回見つけますが、それ以外の多くは判定できません。その範囲は自動テストではカバーできないことで説明しています。
• 手作業の確認： 毎スプリント、新しいコンポーネントと主要なタスクについて、キーボードだけ、スクリーンリーダー、拡大表示とリフローで確かめます。フォーカスの順番、読み上げ、タスクを最後まで行えるかは、ここで確認します。
• 回帰テスト： すでに動いているものを守ります。コンポーネントのテストで、変更のたびに名前、ロール、状態、キー操作を確かめ、リリースの前には主要なタスクを手作業でもう一度試します。リリース判定を置けば、既知の先へ進めない問題が、誰も止めないまま公開されることはありません。

これらのどれでも見つからない問題は、障害のある人とのテストで見つかります。最初の試作から計画に入れておく価値があります。詳しくは障害のある人とのテストでわかること、監査ではわからないことで扱います。

W3Cの役割の対応表（ARRM）は、アクセシビリティに関わる役割を挙げています。計画の手引きは、購買と受け入れテストを加えています。プロジェクトでは、それぞれが次の部分を受け持ちます。

役割	受け持つこと
経営層と統括	方針、目標とその期限、予算、責任者の指名
プロダクトオーナー	受け入れ条件、アクセシビリティの不具合の優先度、チーム全体で合意する完成の定義
プロジェクトマネージャー	アクセシビリティの作業とテストを含めた見積もりと日程
UXリサーチャー	調査とテストへの障害のある参加者の参加
UXデザイナー	構造、フォーカスの順番、キーボード操作と、開発者向けの注釈
ビジュアルデザイナー	コントラスト、フォーカス表示、色だけに頼らない状態の表し方
コンテンツの書き手	見出し、リンクの文言、代替テキスト、キャプション、平易な言葉
フロントエンド開発者	意味に合ったHTML、アクセシブルなコンポーネント、名前と状態
バックエンド開発者	エラーメッセージ、制限時間、ページに出せる内容を左右するデータ
品質保証	自動と手作業のテスト、回帰テスト、アクセシビリティの不具合の管理
購買と契約	購入するものすべての契約に入れるアクセシビリティの要件
サポート	利用者がバリアを報告できる窓口と、直すチームへの連絡経路

公開後は、プロジェクトのチームがいないままサイトが変わり続けます。W3Cは、コンテンツの変更が新しい問題を生むことがあるとして、次のことを勧めています。

• 公開時に確認する： 公開の手順にアクセシビリティの確認を入れ、問題が出るリスクを減らします。CMSの機能でも、書き手自身の見直しでも確認します。
• 定期的に見直す： コンテンツが変わっていくのに合わせて定期的にレビューし、問題ごとに原因を探ります。研修が足りないのか、CMSの変更か、公開の手順が分かりにくいのか、などです。
• リリースのたびに試し直す： CIの自動チェックと回帰テストを、リリースごとに続けます。成熟度モデルの最も高い段階には、保守のためのリリースもアクセシビリティを確認し直すことが含まれています。
• 声を聞く： 利用者からの意見を求め、窓口の担当者が対応できるよう研修し、問題を伝えてくれた人には修正の見込み時期を知らせます。利用者がその窓口を探すのは、アクセシビリティ方針のページです。書き方は掲載されていない、または中身のないアクセシビリティ方針を参照してください。