# 重篤度の判定

アクセシビリティチェックの結果は、その修正がどれだけ重要であるかが伝わりにくい場合が多い。
そのため「重篤度」をもとに課題を整理して伝え、優先的に修正するべきものをトリアージ可能にする。

## 定義

| 重篤度 | 定義 |
| --- | --- |
| **Critical** | その問題があることで、そのページの閲覧に留まらない問題を生じる |
| **Major** | その問題があることで、そのページの主要な目的を達成することができない |
| **Normal** | その問題があっても、そのページの主要な目的を達成することができる。ただし、利用者は不便を被る |
| **Minor** | その問題を解消することで、利用者はより快適にそのページを利用することができる |

## 判定の手順

上から順に判定し、最初に該当したものを採用する。

1. その問題は、**このページ以外にも影響するか**（サイト全体が操作不能になる、光感受性発作を
   誘発する、取り消せない誤操作でデータが失われる、認証を完了できず一切利用できない、など）
   → **Critical**
2. その問題があるとき、**このページの主要な目的を達成できるか**。達成できない
   （フォームを送信できない、コンテンツを読めない、機能を実行できない）→ **Major**
3. 目的は達成できるが、**利用者が不便を被るか** → **Normal**
4. 解消すればより快適になる程度か → **Minor**

「このページの主要な目的」が何であるかは、チェックの最初の手順で把握した対象の目的に基づいて
判断する。目的を把握せずに重篤度を判定してはならない。

## 影響するユーザーの多さを考慮に入れてはならない

**これは厳守する。**

アクセシビリティの問題により影響を受けるのは、常にマイノリティである。「影響を受ける利用者が
少ないため Minor」「一般的な利用者には影響がないため Normal」といった判断は、してはならない。
重篤度は、**影響を受ける利用者にとってその問題がどれだけ深刻か**のみで判断する。

たとえば以下のような人たちが、1人でも不便を感じ、ページの目的を達成できない状況になるので
あれば、問題として指摘されなければならない。

- 手や腕に障害があり、すべての操作をキーボードに頼っているユーザー
- 弱視で、画面を拡大して使用しているユーザー
- 高齢で、コントラスト比の低い色の識別が難しいユーザー
- 発達障害で、集中力を保ちづらいユーザー
- 視覚障害で、スクリーンリーダーを使用しているユーザー
- 聴覚障害で、音声を聞き取れないユーザー

これらはあくまで例であり、状況は一人一人によって異なる。ここに挙げられていない障害のある
ユーザーも存在する。WCAG のようなガイドラインに基づいたチェックだけでなく、彼らが実際に
困っている場合には、その事実に対して向き合わなければならない。

同様に、以下の理由で重篤度を下げてはならない。

- 修正が技術的に難しい、コストがかかる
- ライブラリや外部サービスに起因し、自分たちでは直せない
- 利用者からの問い合わせが来ていない
- WCAG の達成基準に明示的には違反していない

修正の難しさは、重篤度とは独立した情報としてレポートに書く。トリアージは、重篤度と
修正コストの両方を見て、報告を受けた側が行う。

## 観点表の「重篤度の目安」の扱い

観点表の各項目に書かれている「重篤度の目安」は出発点であり、機械的に適用してはならない。
たとえば同じ「コントラスト比不足」でも、本文テキストであれば Major、装飾的な補足文言で
あれば Normal になりうる。実際の重篤度は、対象ページの目的とその問題が利用者に与える影響から
判断する。

目安と異なる重篤度を付ける場合は、その理由をレポートに書く。

## 問題の原因フェーズ

アクセシビリティの問題が混入する原因は、企画・設計・実装の各フェーズにある。そのため、
これらの問題をそれぞれのフェーズの関係者に伝える必要がある。各指摘には、可能であれば
原因フェーズを付記する。

| フェーズ | 例 |
| --- | --- |
| **企画** | 動画にキャプションを用意する計画がない。認証手段が CAPTCHA のみと決められている。時間制限のある仕様 |
| **設計** | 配色の組み合わせがコントラスト比を満たさない。ドラッグ操作前提の UI。色のみで状態を表す設計 |
| **実装** | `alt` の欠落、`lang` の指定漏れ、`div` にクリックハンドラ、`outline: none`、ラベルの未関連付け |

実装フェーズの問題は実装者が単独で直せるが、設計・企画フェーズの問題は実装者だけでは
直せない。この区別が付いていると、報告を受けた側が対応を進めやすい。