どの指摘から直すか、いつ作り直しを選ぶか

指摘ごとに利用者への影響を見て、次に1回の修正でどれだけ解消できるか、どれだけ手間がかかるかで並べます。W3Cの実装の手引きも、影響が大きく解決しやすい問題から取り組むよう勧めています。

1. タスクへの影響を見る。 指摘ごとに、その問題に出会った人がどうなるかを考えます。

   • 進めない：最後まで進めず、ページにほかの手段もない。パズルを解く以外に通れないCAPTCHAのようなログインや、フォーカスが抜け出せないエディターや入力欄は、先へ進めない問題です。
   • 手間が増える：最後までは進めるが、余計な操作や推測、人の手助けが要る。背後にフォーカスが残るモーダルでは、閉じたときにフォーカスがページの先頭に戻り、キーボード利用者はナビゲーションをTabキーでたどり直すことになりますが、目的の場所には戻れます。
   • 煩わしい：最後まで進めるが、余計な読み上げなどが挟まる。リンクの横のアイコンの文字が、リンクと同じ内容でもう一度読まれる場合などです。

2. 影響を受ける人を確かめる。 その問題にどの利用者が出会うかを、影響を受ける利用者の区分で書き出します。EN 301 549の附属書Bは、各要件がどの機能的性能基準を支えるかを対応付けているため、満たしていない要件の行を見れば、影響を受ける人が分かります。複数の区分に影響する問題や、ほかに頼れる手段がない人に影響する問題は、順位を上げます。

3. 場所で重みを付ける。 同じ問題でも、主要なタスクの中にあれば、過去のお知らせのページにあるより優先します。W3Cの暫定修正のページは、登録、検索、送信、購入などの主要なタスク（途中の手順をすべて含む）、トップページのようによく使われるページ、障害のある人に関係の深い内容、利用者から指摘を受けた内容を挙げています。「よく使われる」は推測でなく、アクセス解析の数字で判断します。

4. 原因の場所をたどる。 問題のあるコードがどこにあるかを確かめます。ラベルのない入力欄が30か所あっても、ラベルがない・表示と食い違うフォームの入力欄のように、原因は入力欄のコンポーネント1つかもしれません。そのコンポーネントを直せば、30か所も、これから作るフォームもまとめて直ります。件数を数える前に原因ごとにまとめ、1回の修正で何件が解消するかを数えます。

5. 修正の規模を見積もる。 修正が何を変えるかで分けます。

   • スタイル：CSSだけの変更。フォーカスの枠や色など。修正も再確認も、たいてい最も手軽です。
   • マークアップ：HTMLやARIAの変更。ラベルと入力欄の関連付けなど。画面上は変わらないことが多く、デザインの承認が要りません。
   • 動作：スクリプトやサーバーの変更。フォーカスの管理や、CAPTCHAをやめてサーバー側で試行回数を制限する変更など。確認に手間がかかり、別のチームが必要になることもあります。

   そのうえで、修正が利用者の見る画面を変えるかを確かめます。見えるラベルの追加、ボタンの移動、手順の削除は、デザインや文言の承認が要り、利用者への告知が必要な場合もあるため、コードの量から想像するより時間がかかります。

6. 外からの要請を加える。 診断の外にある、急ぐべき理由を書き添えます。利用者からの苦情や問い合わせ、契約の期日、特定の問題を挙げた通知、公開が求められている方針などです。日本では、障害のある人から申し出があれば、負担が過重でない範囲で合理的配慮を提供することが、事業者にも義務付けられています（障害者差別解消法の改正とWebサイト）。事実と日付を記録し、法的に何を意味するかの判断は弁護士に任せます。

7. 順番と期日を決める。 主要なタスクで先へ進めない問題を最初に置き、サイト全体に効く手軽な修正をその横に並べます。どちらも、作業1日あたりで取り除けるバリアが最も多いからです。次に主要なタスクの手間を増やす問題、その他の手間を増やす問題と続け、煩わしいだけの問題は最後にまとめて直します。作り直しまで待つ問題には、暫定修正と期日を付けます。修正すれば残りの状況も変わるため、リリースのたびに順番を見直します。