bug-reporting

アクセシビリティのバグ報告スキル

正規の情報源：mgifford/ACCESSIBILITY.md の examples/ACCESSIBILITY_BUG_REPORTING_BEST_PRACTICES.md このスキルはこのファイルをもとにしています。判断に迷った場合は、例を正としてください。

自動ツールの出力、手動テスト、ユーザーからの報告、障害のある人とのテストなど、あらゆる情報源からアクセシビリティのバグ報告を作成、レビュー、生成する際は、以下のルールを適用してください。

---

基本方針

有用な報告は、別の人が障壁を理解し、影響を受ける人を特定し、可能であれば再現し、その影響を判断し、原因となる箇所を特定して、修正を検証できるようにします。すべての項目がすべての問題に当てはまるわけではありません。セレクター、ツールのルール、WCAG との対応付け、またはコードレベルの修正方法が分からないことを理由に、有効な報告を遅らせないでください。

原則：

1. 基準より先に障壁を説明する — どのタスクや操作が、どのような条件で失敗するのかを示します
2. 影響を受ける人を特定する — 根拠がある場合は、アクセス上のニーズ、操作方法、支援技術（AT）を説明します。診断を推測したり、一人の経験が障害のある人全体を代表するかのように示したりしてはいけません
3. 根拠の種類を明記する — ユーザーからの報告、障害のある人とのテスト、手動評価、自動テストの結果、合理的な推論を区別します
4. 観察された事実を、推測、原因の疑い、修正案とは別に記録します
5. 相補的なテスト方法を使う — 自動テスト、手動テスト、障害のある人とのテストは、それぞれ異なる問いに答えます。どれも他の方法の代わりにはなりません
6. 関連する状況のみを収集する — ブラウザー、AT、ビューポート、設定が重要なのは、結果に影響するときだけです
7. 人とシステムを保護する — すべての添付ファイルから個人データ、認証情報、トークン、非公開の内容を削除します
8. ツールの出力は根拠として扱い、適合性の判断として扱わない
9. 深刻度と優先度を分ける — タスクへの影響と回避策の有効性は深刻度の判断材料です。影響範囲、頻度、期限、ビジネス上の状況は優先度の判断材料です
10. 可能な場合は原因箇所を修正する — 共有コンポーネント、テンプレート、トークンの修正は、通常、多数のページ固有のパッチより安全です
11. 検証の根拠を添えて完了する — コード変更、自動テストの合格、または見た目の確認だけでは、ユーザーが直面する障壁がなくなったことを証明できない場合があります

---

用語

用語	意味
問題の所見	観察された、または疑われるアクセシビリティ上の障壁、あるいはテスト結果
課題	1つ以上の関連する問題の所見を含む場合がある、追跡対象の作業
発生箇所	問題の所見が現れる場所または状態
根本原因	1つ以上の発生箇所を生み出している原因（例：共有コンポーネント）
影響を受ける人	タスクや体験への影響が確認されている、または合理的に予想される人 — 根拠が許す範囲でのみ具体的に説明します
手動によるアクセシビリティ評価	関連する入力、設定、AT を用いた人による評価 — 障害のある人とのテストとは異なります
障害のある人とのテスト	障害のある参加者が代表的なタスクを実行し、実体験に基づく根拠を提供するテスト
適合性の結論	定められた適用範囲、基準、適合レベル、評価方法に基づく結論

自動テストのルールに失敗しても、WCAG 違反が自動的に証明されるわけではありません。自動テストのルールに合格しても、適合性が証明されるわけではありません。 適合性を主張する前に、結果とその適用範囲を確認してください。

---

重大度の尺度（このスキル）

重大度	定義
ブロッカー	合理的な回避策がなく、主要なタスクを完了できない、または深刻な安全性／プライバシー／データ損失のリスクがある
重大	タスクが失敗する、信頼性に欠ける、または大幅な回避策が必要
中程度	タスクの実行は可能だが、多大な追加の労力や支援が必要
軽微	タスクに実質的な損失はないが、局所的な使いにくさがある
要確認	結果または影響が確認されていない

これは尺度の一例であり、普遍的な標準ではありません。障害のある人やプロダクトチームとともに、各現場に合わせて調整し、現地での定義を文書化してください。

重大度、優先度、影響範囲、発生頻度、確信度はそれぞれ異なる問いに答えるものです。混同しないでください。

項目	問い
重大度	今回の発生において、タスクにどの程度深刻な影響がありますか？
優先度	チームはいつ対応すべきですか？
影響範囲	影響を受ける可能性のある人、ページ、コンポーネントはどれくらいありますか？
発生頻度	どのくらいの頻度で発生しますか？
確信度	調査結果／影響／原因の理解はどの程度確かですか？

発生頻度や影響範囲によって優先度が上がることはありますが、1回の発生における重大度は変わりません。多くのページで発生するという理由だけで、重大度の低い問題を自動的に高い重大度へ引き上げないでください。代わりに、優先度に影響する要因として記録してください。

---

重要：有用な報告に必要な最低限の情報

報告は受付時点で有効でも、修正対応の準備が整っているとは限りません。この2つは異なる基準です。技術的な詳細が不足していることを理由に、ユーザーからの報告を却下しないでください。トリアージ担当者が後から、要素の特定情報、標準との対応付け、検証計画を収集します。各段階の全体像については、以下の実行可能な調査結果と再現性を参照してください。

受付時に有効な報告に必要なのは、タイトル、場所／状態（報告者が安全に伝えられる範囲でできるだけ正確に）、タスクと影響、実際の結果、根拠のみです。

評価と修正対応のための追加項目 — トリアージで収集するものであり、報告者に求める必要はありません。

項目	記録する内容
タイトル	コンポーネント／場所、問題、タスクへの影響
場所と状態	安全な URL／ルート、コンポーネント名、ビルド、問題が発生する状態
影響を受ける人	影響を受けることが確認済み、またはその可能性が高いアクセス上のニーズ／操作方法／支援技術（AT）。関連する場合は複数のグループ
根拠と確信度	ユーザー報告／障害のある人と行ったテスト／手動評価／自動テスト結果／推論、および不確実性
タスクと影響	その人が何をしようとしているか、障壁がどう影響するか、回避策の質／コスト
手順または条件	前提条件を含む、最短で確実な経路
期待される結果	ユーザーに提示されるべき動作
実際の結果	関連する支援技術の出力を含む、観察された内容
環境	結果に影響するブラウザー／OS／支援技術／入力方法／ビューポート／ズーム／設定／ロケールのみ
根拠資料	役立つ場合は、個人情報を削除した短い抜粋、またはアクセシブルな添付資料

---

重要：具体的なタイトルを書く

コンポーネント、問題、結果を明記してください。

良い例： Checkout: card error text is not associated with the field / Account menu: keyboard focus moves behind the open dialog

避ける例： Accessibility issue、Screen reader bug、WCAG failure — 影響を受ける動作が特定できません。タイトルに WCAG の達成基準を含めるかどうかは任意です。達成基準の番号を知らない人にも報告内容が理解できるようにしてください。

---

重要：記録の場所と状態を安全に扱う

Page or route: /checkout/payment
Build or commit: 2026.07.18.2
Component: Payment form
UI state: Form submitted with an invalid card number
Account role: Test customer

クエリやフラグメントの値が関連し、安全に共有できる場合に限り、正確な URL を使用してください。セッション識別子、アクセストークン、メールアドレス、名前、アカウント番号、その他の秘密情報や個人データは削除するか置き換えてください。

Unsafe: https://example.com/orders/847291?token=secret-value
Safe:   https://example.com/orders/[test-order-id]

本番環境の認証情報は決して含めないでください。組織の安全な手順を通じて、承認済みのテストアカウントを提供してください。

要素ロケーター： 人が理解しやすいコンポーネント名と場所から始め、役立つ場合は安定した技術的ロケーターを追加してください（[data-component="cookie-settings"] [data-action="close"]、ツール固有のセレクター、アクセシビリティツリーのパス、テスト ID、短い XPath など）。完全な絶対 DOM XPath を必須にしてはいけません。 ラッパー、リストの位置、または生成されたマークアップが変わると、絶対パスは不安定になるためです。信頼できるロケーターがない場合は、表示されているラベル、アクセシブルネーム、ロール、近くの見出し、操作状態を説明してください。該当する場合は、iframe や Shadow DOM の境界を記録してください。

---

重要：前提条件と再現手順

失敗に至るまでに必要な手順だけを記載してください。入力方法や AT コマンドが重要な場合は、それらも含めてください。

Preconditions:
- Signed in as a test customer
- Cart contains one item
- NVDA is running with Firefox

Steps:
1. Open the checkout payment step.
2. Leave the card number empty.
3. Move to the Submit order button with Tab.
4. Activate the button with Enter.
5. Listen for feedback without moving focus.

断続的に発生する事象については、再現を試みた回数、タイミング／ネットワーク／読み込みの状況、判明している最も古いビルドを記録してください。「再現できない」はトリアージの状態であり、報告が無効であることを示す証拠ではありません。 元の条件を保持してください。

---

重要：期待される結果と実際の結果を分ける

期待される動作は、必要な実装方法ではなく結果として記述してください。

Expected:
After submission, the card number error is associated with the field. When
focus moves to the field, its label, invalid state, and error are available.

Actual:
The visible error appears, but the card number field has no programmatic error
association. When focus moves to the field, NVDA announces only its label.

製品の仕様でその実装が求められている場合を除き、期待される結果に特定の ARIA 属性や JS メソッドを含めないでください。コードの変更案は、代わりに「修正案」の項目に記載してください。

---

重要：影響を受ける人を特定する — 診断を決めつけない

技術的な欠陥やツールのルールだけでなく、障壁がどのような人のどのタスクに関わるのかを示してください。証拠がある場合は、アクセスのニーズ／操作方法／AT に基づいて人について説明してください。診断を推測したり、その開示を求めたり、障害のある人が皆同じ経験をすると示唆したりしてはいけません。

証拠の状況	意味
影響を受けた人から報告または確認済み	障害のある人から報告があった、または障害のある参加者がタスクを実行する際に観察された
手動評価で観察済み	評価者が該当する方法／設定／AT を使って再現した。これは動作の証拠であり、障害のある人を対象にしたテストと同等ではない
可能性が高い	影響を受ける集団と影響を合理的に推測できるが、影響を受けた人による確認は取れていない
不明または要レビュー	自動化または技術的な調査によるもので、ユーザーへの影響はまだ確認されていない

役立つ例：「スクリーンリーダーを使用する人が影響を受ける可能性が高く、全盲の人や弱視の人も含まれます。NVDA と Firefox を使った手動評価では、送信の失敗が通知されないことが確認されました。障害のある参加者を対象としたテストによる影響の確認はまだ行われていません。」

役立たない例：「これは全盲の人に影響し、WCAG に違反しています。」

報告では、複数の影響対象集団を特定できます。WCAG の達成基準や自動化ルールと障害のある人の集団が一対一で対応すると決めつけないでください。

---

重大：関連する環境のみを記録する

環境の一覧は、結果をもたらした条件を説明している場合にのみ役立ちます。すべての課題に一般的なブラウザー／AT の一覧を貼り付けないでください。

Test date and time: 2026-07-18 14:30 EDT
Browser: Firefox 140
Operating system: Windows 11 24H2
Assistive technology: NVDA 2026.1
Input: Keyboard
Viewport: 1280 by 720 CSS pixels
Zoom or text size: 200% text size
Color scheme: Dark
Forced colors: Active
prefers-reduced-motion: reduce
prefers-contrast: more
Locale and language: en-CA

実際にテストした値を使用してください。ビューポート幅のブレークポイントからデバイスの種類を推測しないでください。 ビューポート、入力機能、ブラウザー、OS、物理デバイスはそれぞれ別の情報です。関連する CSS の設定値：prefers-color-scheme（light/dark）、prefers-reduced-motion（reduce/no-preference）、prefers-contrast（more/less/custom/no-preference）、forced-colors（active/none）。

---

重大：データを公開せずに技術的証拠を追加する

観察された動作がすでに明確な場合、技術的証拠は任意です。 自動検出や技術的な調査結果には、通常、コードレベルの修正に先立って、対象を絞った HTML／DOM／ アクセシビリティツリー／コンポーネントの抜粋が必要です — これを収集するのはトリアージ担当者であり、報告者ではありません。 障害のある人やその他の 報告者は、その取得方法を知らない場合があります。また、報告を受け付ける前に提出を求めると、 障壁に気づく可能性が最も高い人を排除してしまいます。ソース HTML が実際の DOM やアクセシビリティ ツリーを表していると決めつけないでください — クライアント側のレンダリングやハイドレーションにより、 両者が異なることがあります。調査結果が実行時の状態に依存する場合は、実際の DOM／ アクセシビリティツリーの出力を取得してください。

<label for="card-number">Card number</label>
<input id="card-number" name="card-number">
<p id="card-number-error">Enter a card number.</p>

抜粋が何を示しているかを説明してください — ここでは、表示されているエラーがフィールドに プログラム上関連付けられていないことを示しています。抜粋に計算後のアクセシビリティツリー全体が 表示されていると決めつけないでください。

HTML、DOM スナップショット、ログ、スクリーンショットを共有する前に、次の情報を削除してください： トークン／ Cookie／非表示の認証情報、氏名／住所／アカウント情報、非公開のフォームフィールド値、不要な 内部 URL や ID。スクリーンショット／録画の場合は、関連する内容を課題のテキストで説明してください。 矢印やマーカーを使い、色だけに頼らずテキストも添えてください。動画／音声にはキャプション／文字起こしを 付け、顔／氏名／非公開の内容を切り取るか、マスキングしてください。

---

重大：規格、ルール、テスト結果

WCAG へのマッピング — 判明している場合は、正確なバージョン、達成基準、レベルを記録してください。 不確かな場合は suspected／needs review を使用し、ツールがタグとして列挙しているというだけで 達成基準を追加しないでください：

Standard: WCAG 2.2
Success Criterion: 1.3.1 Info and Relationships
Level: A
Relationship: Confirmed failure

自動検出結果のツール／ルール情報：

Tool and version: axe-core 4.9.1
Rule ID and version: button-name
Configuration: wcag2a, wcag2aa tags
Test method: Automated
Raw outcome: failed
Human review: Confirmed / Rejected / Needs review

ツールの影響度／信頼度の値は、プロジェクトの重大度とは別に扱ってください — ツールのメタデータはヒューリスティックであり、タスク／コンテキスト／回避策／根本原因の評価では ありません。ACT Rules Format 1.1 を使用する場合は、その結果のいずれかを保持してください （inapplicable、passed、failed、cantTell、untested） — cantTell の結果は人によるレビューに回してください。passed／inapplicable の結果でも、 WCAG に関する結論を出す前に、ほかのテストが必要な場合があります。

義務と対応方法は、WCAG へのマッピングとは別に扱います。 重大度やライフサイクルの状態から 推測せず、規格へのマッピングごとに割り当ててください：

• obligation：required | aspirational | advisory | unmapped | not-applicable。 AA をベースライン目標とする場合、確認済みの AAA の調査結果は advisory ではなく aspirational です — 任意の提案ではなく、明示的なストレッチ目標として記録してください。 プロジェクトは特定の AAA 達成基準を required に引き上げることができます。その場合は、 obligation_basis にローカルポリシーまたは権限を引用してください。個々の AAA 達成基準を 満たすことを、WCAG AAA 準拠と表現しないでください。
• handling：report | review | suppress。未解決の自動検出結果は review に回し、 確認済みの失敗として直接 report にしたり、suppress にしたりしないでください。 suppress には、対象範囲、理由、証拠、担当者、レビュー日または期限を限定して記録した 例外が必要です。また、調査結果が解決済みまたは削除済みであることを意味するものではありません。

定義と具体例については、アクセシビリティ調査結果の追跡：ポリシー分類 を参照してください。

---

重大：補完的なテストと検証を計画する

自動テスト、手動評価、障害のある人によるテストは、それぞれ異なる 問いに答えます。どの方法が必要なのか、その理由と限界を示してください。

• **自動テスト：**機械的にテスト可能なパターンを特定し、再現可能な リグレッションテストを提供します。ただし、ユーザーへの影響、使いやすさ、 適合性のすべてを判断することはできません。生の結果と設定を保持し、 ユーザー向けの障壁として確定扱いする前に人によるレビューを必須としてください。 自動テストに合格したことだけを、問題を解決済みとする十分な根拠にしないでください。
• **手動のアクセシビリティ評価：**キーボード操作、フォーカス、スクリーン リーダーの出力、ズーム／リフロー、強制カラー、ラベル／エラー／ステータス メッセージ、関連する状態など、結果の判断に人の判断や操作が必要な場合に 必須です。問題ごとにあらゆる組み合わせを試すのではなく、リスクに基づいた 環境を選んでテストしてください。
• **障害のある人によるテスト：**実際のタスクと実体験に基づく操作を検証し、 標準に基づく評価では見逃される障壁を発見できます。次の場合は計画してください： タスクが重要である（認証、決済、健康、安全、公共サービスなど）、障壁や 修正の影響が大きい、または不確かである、コンポーネントが複雑または新規である、 回避策の有効性が不明確である、障害のある人からの報告と技術的な結果が食い違う。 先に修正すべき明らかな既知の不具合を再発見するために、障害のある参加者を 利用しないでください。参加者1人が確認できるのは、その人自身の体験です。 その人を障害のある人々全体の代表として扱わないでください。これは標準に 基づく評価の代わりにはならず、標準に基づく評価も障害のある人から直接学ぶ ことの代わりにはなりません。

検証計画を記録してください。自動チェックの必須／予定／完了状況、手動チェックの 必須／予定／完了状況、関連するサポート対象環境、障害のある人によるテストの 必須／予定／完了状況と、その理由を含めます。

---

中程度：対象範囲、頻度、根本原因を記録する

Observed occurrences: 7
Pages checked: 12
Pages affected: 5
States checked: Default, error, disabled
Likely source: Shared address form component
Unchecked scope: Mobile app and authenticated administrator flow

推定であることを明記せずに、サンプルから全体に当てはめないでください。 サイト全体で使われるテンプレートの不具合と、互いに無関係な7件のコンテンツの 誤りは、件数が同じでも必要な作業は異なります。指摘事項を慎重にグループ化 してください。同じ修正単位または確認済みの根本原因を共有する場合にのみ、 発生箇所をまとめます。同じルール ID や類似のセレクターを共有するというだけで 指摘事項をまとめないでください。

---

修正案と受け入れ基準

修正案の提示は任意です。提案であることを明記してください。担当チームは、 ソースレベルでより安全に修正する方法を把握している場合があります。

Suggested fix:
Associate the error message with the field and expose the invalid state after
validation.

受け入れ基準では、属性／セレクター／自動ルールの結果だけでなく、 ユーザーから確認できる動作を記述してください。

- Submitting the empty field identifies the card number error in text.
- The field exposes the error association and invalid state programmatically.
- Keyboard focus remains predictable.
- The original interaction is manually retested.
- Testing with disabled people is completed when required by the verification plan.

---

Markdown の課題テンプレート

## Accessibility finding

### Summary
[Component or location: failure and task effect]

### Location and state
- Page or route:
- Build or commit:
- Component:
- Preconditions and UI state:
- Safe locator (optional):

### Steps or conditions
1.
2.

### Expected result
[Describe the user-facing outcome.]

### Actual result
[Describe what was observed.]

### People affected and impact
- People confirmed or likely to be affected:
- Relevant access needs, interaction methods, or assistive technologies:
- Affected task:
- Consequence:
- Workaround and its cost, if any:
- Evidence basis: User report / Testing with disabled people / Manual evaluation / Automated result / Reasoned inference
- Confidence: Confirmed for reported scope / Observed / Likely / Unknown
- Scope limits or uncertainty:

### Relevant environment
- Test date:
- Browser and operating system:
- Assistive technology and version:
- Input method:
- Viewport, zoom, text size, and orientation:
- Active preferences or display modes:

### Evidence
[Small redacted excerpt, attachment description, or link to protected evidence.]

### Standards and tests (optional)
- WCAG version, success criterion, and level:
- Relationship: Confirmed / Suspected / Needs review
- Tool, rule, version, and configuration:

### Verification plan
- Automated checks: Required / Not required / Planned / Completed
- Manual checks: Required / Not required / Planned / Completed
- Testing with disabled people: Required / Not required / Not yet determined / Planned / Completed
- Rationale:

### Scope and source
- Occurrences and sample checked:
- Suspected or confirmed root cause:

### Suggested fix (optional)
[Describe a possible approach without replacing acceptance criteria.]

### Acceptance criteria
- [ ] The reported user-facing barrier is no longer present.
- [ ] The original environment and interaction have been manually retested.
- [ ] An automated pass was not treated as sufficient evidence on its own.
- [ ] Testing with disabled people was completed when required by the verification plan.
- [ ] The impact statement does not go beyond the available evidence.
- [ ] Appropriate regression coverage has been added or updated.

### Privacy and attachment check
- [ ] Secrets, personal data, and private content have been removed.
- [ ] Screenshots are described and recordings have captions or transcripts.

---

機械可読な検出結果スキーマ

機械可読な出力は、インポート、レポート作成、回帰分析に役立ちます。この JSON 形式は任意です。手動またはユーザー報告による検出結果に存在しないフィールドを必須にしてはなりません。

正式なバージョン管理済みのスキーマ検証対象形式は、schema_version: "2.0" または "2.1"（JSON Schema Draft 2020-12）です。mgifford/ACCESSIBILITY.md の examples/schemas/ で定義されています。schema_version: "1.1" は使用しないでください。これはこのスキルの以前のドラフトにおける例示的な形式であり、置き換えられています。"2.1" では、上記の義務／対応分類のための、任意のトップレベル policy オブジェクト（standards_obligations、handling、evidence_status、suppression）が追加されています。"2.0" のレコードにこれを設定してはなりません。policy はフィンガープリントの識別情報には一切含まれず、tracking.fingerprints を変更することもありません。現在のスキーマを使った簡潔な抜粋を以下に示します。

{
  "schema_version": "2.0",
  "title": "Checkout: card error text is not associated with the field",
  "reported_at": "2026-07-18T14:30:00-04:00",
  "source": { "method": "manual-evaluation" },
  "location": {
    "safe_url": "https://example.com/checkout/payment",
    "component": "Payment form"
  },
  "description": {
    "summary": "The visible card error is not programmatically associated with the field.",
    "expected": "The field exposes its label, invalid state, and associated error programmatically.",
    "actual": "A visible error appears, but the field has no error association."
  },
  "affected_people": [{
    "description": "People who use screen readers",
    "status": "likely",
    "evidence_basis": "manual-evaluation",
    "scope_limit": "Observed with NVDA and Firefox; not yet evaluated with disabled participants"
  }],
  "standards": [{ "standard": "WCAG", "version": "2.2", "requirement": "1.3.1", "level": "A", "relationship": "confirmed-failure" }],
  "verification": {
    "automated": { "required": true, "status": "planned" },
    "manual": { "required": true, "status": "completed-for-original-finding" },
    "testing_with_disabled_people": { "required": true, "status": "planned" }
  }
}

tracking.fingerprints、tracking.tracker_ids、tracking.lifecycle は、自動検出または相関付けされた検出結果向けの任意の追加項目です。これらを含まない検出結果については、完全な例、最小限の例を参照してください。また、8 つの obligation／handling／evidence_status のシナリオについては、ポリシー分類の例を参照してください。フィンガープリントを手作業で計算したり、ここにフィンガープリントのアルゴリズムを重複して記載したりしないでください。変更不可でバージョン管理された a11y/pattern/v1／a11y/occurrence/v1 の仕様については、フィンガープリントプロファイルを参照してください。公開済みのフィンガープリントプロファイルは変更できません。アルゴリズムを変更する場合は、既存プロファイルを直接編集せず、必ず新しいプロファイルバージョンを作成してください。

インポートは公開済みのスキーマに照らして検証し、null／省略値はスキーマ独自の規約に従って文書化してください。移行を計画する際は、アクセシビリティ検出結果の追跡にある equivalent／split／merged／unresolved の用語を使用してください。正確な往復再現性が重要な場合は、ツールの未加工の出力を別途保持してください（source.raw_result_reference／evidence.references）。

---

自動化と AI のガードレール

自動化によって証拠を収集・整理できますが、確実性、影響を受ける人々、または実体験を捏造してはなりません。

自動化または AI 支援のワークフローでは、次のことを行ってください。

1. 生の結果、ツール／ルールのバージョン、設定、時刻、テストした URL／ルートを保持します
2. 方法を明記します：自動／半自動／手動／ユーザーからの報告／障害のある人々とのテスト
3. ツールの元の結果を保持します。cantTell／不確かな結果はレビューキューに送ります
4. 証拠を別のシステムに送信する前に、認証情報と個人データを削除します
5. 証拠による裏付けがない場合、WCAG への対応付け、影響を受ける人々、影響に関する記述、重大度、根本原因を生成しないでください
6. 参加者から確認された証拠を、手動による観察や推論と区別します
7. 影響の大きい作業や適合性の主張を作成する前に、プロジェクトのリスク／トリアージルールに従って人間による検証を必須にします
8. 修正単位または根本原因が十分に確立されている場合にのみ、発生箇所をまとめます
9. 重複を黙って破棄するのではなく、新たな発生箇所を既存の issue に追加します
10. ツールの結果、評価者のレビュー、参加者からのフィードバックの間に意見の相違がある場合は、それを保持します
11. 自動化では結果を検証できない場合、クローズ前にユーザー向けの手動再テストを必須にします
12. 障害のある人々とのテストが必要／計画済み／完了のいずれかを、理由とともに記録します
13. 実際に行われていない限り、障害のある人々とのテストを実施したと決して主張しないでください
14. 各自動化結果を、アクティブな修正キュー、調査キュー、または観察履歴のいずれかに送ります。再現されていない生の自動化結果を、そのままアクティブな修正キューに入れてはなりません
15. 内部での再実行で再現されなかったという理由だけで、信頼できるユーザー報告や重大な影響を及ぼす可能性のある障壁を自動的に却下してはなりません。代わりに、範囲を限定した調査に送ります
16. 未レビューの自動化結果は evidence_status: automated-indicator と handling: review を付けて記録します。人間が確認するまでは、confirmed-standards-failure、confirmed-user-facing-barrier、または handling: suppress としてはなりません。1 つの対象でノイズが発生したからといって、ルールやエンジン全体を無効にしないでください。代わりに、範囲を限定して個別の検出結果を抑制します。

元の自動化ルールに合格したという理由だけで issue をクローズしないでください。実装によってセレクターが変更されたり、テスト対象のノードが非表示になったり、別の障壁が生じたりしている可能性があります。

対応可能な検出結果と再現性

チームが対応するのに十分な証拠を得る前でも、検出結果が有効であり、保持する価値がある場合があります。区別のない 1 つのキューではなく、3 つの送付先を使用してください。

• アクティブな修正キュー — 再現可能、またはその他の方法で十分な証拠があるもの：正確で安全な場所、該当する場合は技術的証拠、担当者、受け入れ基準、検証計画。WCAG への対応付け、重大度、頻度、フィンガープリントは有用ですが、必須ではありません。
• 調査キュー — 信頼できるものの、断続的に発生する、または証拠が不十分なもの：担当者、現在の証拠、次のアクション、昇格に必要な証拠、レビュー／期限日を必須とします。担当者のいない needs_review の検出結果を、いつまでも放置しないでください。
• 観察履歴 — 再現されていない自動化結果のための、保持期間を限定した簡潔な証拠（フィンガープリント、場所、ツール／ルールの識別情報、スキャン実行 ID、初回／最終確認時刻、昇格しなかった理由）。アクティブな人間対応の issue キューではありません。

自動化による検出結果の対応可能性ゲート — 自動化結果をアクティブな修正キューに入れる前に、次の点を確認してください。チームは結果を特定し、チェックを再実行または評価し、影響を受ける出力を調べ、何をもって修正完了と判断するかを特定できますか？ できない場合は、誰も対応できない issue を作成するのではなく、調査キューまたは観察履歴に送ります。このゲートは自動化による検出結果の件数を対象とするものであり、人間から報告された検出結果を有効なものとして受け入れる前に、再現や証拠を必須とするものではありません。 比較可能な実行と not_observed 対 not_tested： 結果の欠落が意味を持つのは、再実行が実際に比較可能な場合に限られます（同じリソース、読み込み成功、必要な認証／状態への到達、同じルール、スキャナーの完了、重大な除外変更がないこと）。タイムアウト、認証エラー、ルールの無効化、クロールの未完了は not_tested に分類し、決して不在として扱わないでください。比較可能な実行後に本当に不在である場合は not_observed に分類し、暗黙に resolved として扱わないでください。

直接再現することが望ましいですが、正確な再現が不可能な場合は同等の証拠を認めます。たとえば、対象を絞った HTML／DOM／アクセシビリティツリーの抜粋、設定／バージョンを含むツール出力、説明付きの記録、複数回の報告、または文書化された再現の試みなどです。Cannot reproduce は、チームが現在持っている証拠を表すものであり、報告者の信頼性を表すものではありません。

計画のない指摘を保持しないでください。担当者もレビュー日もない調査項目は、実質的に破棄された報告です。

完全なステージモデル、3 つの移行先、対応可能性の判定基準、比較可能な実行のルール、積極的なフィルタリングの影響／例外については、正規リポジトリの Accessibility Finding Tracking § Actionability を参照してください。ステージ昇格のしきい値やフィンガープリントのアルゴリズムをここで再説明せず、リンクしてください。

重複排除と追跡： トラッカー ID（課題トラッカー固有の ID）は、追跡対象の修正作業を識別する永続的な ID です。課題を登録またはリンクする担当者が割り当てるものであり、指摘の内容から計算されるものではありません。スキャンリクエスト ID はスキャンが実行された理由を識別するもので、スキャンによって生成されたすべての指摘に対するトラッカー ID になるわけではありません。フィンガープリント（1 つの場所に対する発生フィンガープリント、または複数の場所にまたがる相関候補に対するパターンフィンガープリント）は、繰り返し現れる結果の相関付けに役立ちますが、計算された相関キーであり、永続的なバグ ID ではありません。一致するフィンガープリントはグループ化と調査を裏付けますが、それだけで共通の根本原因を証明するものではありません。フィンガープリントから派生する短い表示 ID（例：A11Y-PAT-EA3B846C4F12）は、人が読みやすい別名であり、正式な値ではありません。フィンガープリントを使用する場合は、アルゴリズムとプロファイルにバージョンを付けてください。ツールとルールのバージョンは来歴情報として記録し、適用される固定済みフィンガープリントプロファイルで明示的に求められる場合に限り、フィンガープリントの識別情報に含めてください。URL／セレクターは慎重に正規化してください。フィンガープリントは新しいプロファイルバージョン内でのみ変更され、暗黙に変更されることがないようにしてください。フィンガープリントアルゴリズムが変更された場合は、従来の識別子を保持してください。幅のしきい値からモバイル／デスクトップを推測しないでください。ハッシュが一致するという理由だけで結果を統合しないでください。後続のスキャンで結果が見つからなくても、それだけでは解決を証明できません。対象範囲を実際に再テストしたか、ほかの方法で検証したのでない限り、not_observed として扱ってください。

スキャン実行 ID、従来の識別子の移行、公開テストベクトルを備えた固定済み a11y/pattern/v1 ／ a11y/occurrence/v1 フィンガープリントプロファイルを含む完全なモデルについては、正規リポジトリの Accessibility Finding Tracking および Fingerprint Profiles を参照してください。フィンガープリントのアルゴリズムをここで再説明せず、リンクしてください。

---

課題のライフサイクル

1. 記録： 障壁、場所、状態、影響を受ける人、影響、根拠、共有しても安全な証拠を記録します
2. トリアージ： 可能であれば結果を確認し、不足しているコンテキストを特定し、深刻度と優先度を分けます
3. 切り分け： 発生箇所を生み出しているソースコンポーネント／テンプレート／トークン／プロセスを特定します
4. 担当者の割り当て： 個別のページだけでなく、ソースを変更できる担当者を割り当てます
5. 定義： ユーザー向けの受け入れ基準、サポート対象環境、検証計画について合意します
6. 修正： ソースを修正し、ドキュメント／例／コンテンツガイダンスを更新します
7. 予防： 問題に応じた回帰テストを追加します
8. 再テスト： 元の操作と、関連する隣接状態／設定／環境を再度確認します
9. 障害のある人による評価： 必要な場合は、計画した参加者テストを実施します
10. 完了： 変更点、検証の証拠、残っている制限、フォローアップを記録します

修正が部分的な場合は、より広範な課題を解決済みとして閉じるのではなく、残っている発生箇所／環境を記録してください。

---

外部組織への報告

まず、アクセシビリティステートメント、accessibility@ の連絡先、またはフィードバックフォームを探してください。報告を受け取る人はアクセシビリティの専門家とは限らないため、その人に伝わるように書きます。ページ／機能、確認された障壁、影響を受ける人／方法（分かっており、安全に共有できる場合）、妨げられている作業、簡潔な手順と環境、受領確認の依頼を最初に記載します。WCAG の参照や修正案は任意です。パスワード、個人情報、機密文書は含めないでください。また、報告者に診断名の開示を求めないでください。普遍的な対応期限はありません。適切なフォローアップは組織／契約／管轄区域によって異なります（これは法的助言ではありません）。

Subject: Accessibility barrier in [page or feature]

Hello,

I encountered an accessibility barrier in [page or feature].

Location: [safe URL, route, or feature name]
Task: [what you were trying to do]
Barrier: [what happened]
People or interaction methods affected, if known: [description]
Impact: [how this affected the task]

Steps or conditions:
1. [Step]

Expected: [user-facing outcome]
Actual: [observed result]

Relevant environment: [only details that affect the result]
WCAG reference, if known: [version, criterion, and level]

Please acknowledge this report and let me know how I can follow its status.

Thank you.

---

よくある報告の失敗

• 報告を受け付ける前に、完全な DOM XPath、HTML の抜粋、ツールのルール、または WCAG 基準を必須にする
• トークンや個人データを含む正確な URL をコピーする
• ユーザー向けの挙動を説明せず、「WCAG に不適合」とだけ報告する
• WCAG 基準やツールのルールから、障害のある人のグループや集団全体への影響を推測する
• ツールの結果を、確認済みの欠陥や適合性の結論として扱う
• 評価者が支援技術を使用することを、障害のある人を対象としたテストと同等に扱う
• ツールの影響度フィールドから深刻度を割り当てたり、発生回数に応じて深刻度を自動的に引き上げたりする（これは優先度を示すものであり、深刻度ではありません）
• ビューポートの幅から物理的なデバイスの種類が分かると主張する
• 実際にテストした環境ではなく、すべての AT バージョンを列挙する
• ルール ID やセレクターが似ているというだけで、無関係な発生箇所をまとめる
• 挙動に基づく受け入れ基準なしに、コード変更を指示する
• 自動チェックに合格したことを理由に、手動テストを省略する
• コードのマージや自動チェックへの合格後、元の操作を再確認せずに完了とする
• 先に修正すべき既知の基本的な問題を再発見させるために、障害のある参加者を使う
• 1 人の参加者の経験を、障害のある人のグループ全体に一般化する
• 十分な説明に基づく許可なく、報告者や参加者の診断名、身元、非公開のコンテンツを開示する

---

提出前の品質チェックリスト

• URL からシークレット／トークン／個人データを削除したうえで、場所と状態を記録している
• タイトルにコンポーネント、障害、タスクへの影響を明記している（「アクセシビリティの問題」ではない）
• 再現手順に番号を付け、必要最小限かつ完全な内容にしている
• 期待される結果と実際の結果を、実装方法の指示ではなく、ユーザーに見える結果として記載している
• 影響を受ける人については、証拠から具体的に分かる範囲だけを記述している — 推測で診断しない
• 根拠と確信度を明記している（ユーザーからの報告／障害のある人とのテスト／手動／自動／推論）
• 関連する環境フィールドだけを記録している — 一般的なブラウザー／支援技術の一覧は含めない
• 技術的な証拠（HTML／スクリーンショット／ログ）からシークレットと個人データを削除している
• WCAG への対応付けを、適切に「確認済み／疑いあり／要確認」としている
• 重大度をタスクへの影響に基づいて割り当てている — ツールの出力や発生回数に基づいていない
• 発生頻度／影響範囲は優先度の要因として別途記録し、重大度に含めていない
• 検証計画に、自動／手動／障害のある人とのテストのうち何が必要で、その理由を明記している
• 修正対象の単位または根本原因が共通していると確認できた場合に限り、調査結果をまとめている

---

よく違反される WCAG 達成基準

SC	名称	レベル	よくある違反
1.1.1	非テキストコンテンツ	A	画像の alt がない、アイコンボタンにラベルがない
1.3.1	情報及び関係性	A	見出し構造が意味的でない、フォームのラベルがない
1.3.3	感覚的な特徴	A	形、色、位置だけに依存した指示
1.4.1	色の使用	A	状態を色だけで伝えている
1.4.3	コントラスト（最低限）	AA	テキストのコントラスト比が 4.5:1 未満
1.4.4	テキストのサイズ変更	AA	200% のズームでページが崩れる
1.4.11	非テキストのコントラスト	AA	UI コンポーネントの境界線のコントラスト比が 3:1 未満
2.1.1	キーボード	A	キーボードで要素に移動できない、または操作できない
2.4.3	フォーカス順序	A	論理的でないタブ順序、フォーカスが予期せず移動する
2.4.7	フォーカスの可視化	AA	フォーカスインジケーターが表示されない
3.3.1	エラーの特定	A	フォームのエラーがテキストで説明されていない
3.3.2	ラベル又は説明	A	表示されるラベルのないフォームフィールド
4.1.2	名前・役割・値	A	カスタムウィジェットに ARIA の名前、役割、または状態がない
4.1.3	ステータスメッセージ	AA	通知がスクリーンリーダーに伝わらない

完全な一覧については、WCAG 2.2 クイックリファレンスを参照してください。

---

参考資料

• ベストプラクティスの完全ガイド
• アクセシビリティ指摘事項の追跡 — トラッカー ID、スキャンのリクエスト ID／実行 ID、発生箇所とパターンのフィンガープリント、表示 ID、従来の識別子の移行、対応可能性ポリシー（ステージモデル、アクティブ／調査中／観察履歴の保存先、自動検出された指摘事項のゲート）
• フィンガープリントプロファイル — 固定された a11y/pattern/v1／a11y/occurrence/v1 の仕様とゴールデンテストベクトル
• アクセシビリティ指摘事項のスキーマ — schema_version: "2.0" の JSON Schema と検証済みの例
• ウェブサイトのアクセシビリティ適合性評価方法（WCAG-EM）
• ウェブアクセシビリティの評価におけるユーザーの参加
• 専門知識を組み合わせたウェブアクセシビリティの評価
• アクセシビリティに問題のあるウェブサイトについて組織に連絡する
• EARL 1.0 スキーマ — W3C ワーキンググループの非規範的なノートであり、通常の報告では必須ではありません
• ACT ルール形式 1.1
• WCAG 2.2 クイックリファレンス