講評資料

講評の枠組み(裁定の分類)と研修の進め方をまとめたページです。解答表に戻る

裁定の 4 分類

本教材の裁定は内部的には3軸(validity / provenance / disposition)で行われますが、参加者向けには次の4分類に畳んで表示します。

意図した障壁(Intended): 教材が意図して仕込んだ障壁、またはその観測箇所に対する指摘。本課題の主たる採点対象です。
既知の制約(Known limitation): 教材の既知の制約(NVDA 実機検証省略などの provenance: environment、または provenance: specification で spec 更新が必要と判断された事項)に起因する事実として妥当な指摘です。減点対象にはしませんが、意図した障壁(Intended)としては扱いません。
追加発見（有効）(Accepted additional finding): 教材が意図していなかったものの、有効性(validity: valid)が確認された追加発見です(provenance: new が昇格 gate を通過したもの等)。加点方向にのみ働きます(見つけられなかった参加者の coverage 分母には加えません)。
無効(Invalid): 有効性が確認できない指摘(validity: invalid、または誤検出)です。

研修進行ガイド

解答表と参加者の finding を突き合わせ、1 finding あたり6軸のルーブリック (観測・再現性/ユーザー影響/原因と影響範囲/根拠・検証手段/修正/基準マッピング)で採点する。WCAG 番号の一致は1点に抑え、原因の特定と影響範囲の把握、修正の妥当性を重視する(docs/a11y-training-design-v0.3.1.md §8.3)。

観測・再現性の確認: finding に書かれた操作手順で症状が再現できるかを解答表の再現手順と突き合わせて確認する(ルーブリック①)。
ユーザー影響の確認: 申請・承認タスクで誰が何をできなくなるかを finding が説明できているかを確認する(ルーブリック②)。
原因と影響範囲の確認: instance か component 実装かを特定し、他画面への伝播を finding が捉えられているかを確認する(ルーブリック③)。
根拠・検証手段の確認: 検証環境・手順・支援技術・期待/実際の証拠が十分かを確認する (ルーブリック④)。
修正方針の確認: 症状への ARIA 追加ではなく原因を直す修正になっているか、他 instance への regression が考慮されているかを確認する(ルーブリック⑤)。
基準マッピングの確認: WCAG 等への対応づけが妥当かを確認する。ただし配点は1点に留め、 ③⑤の評価を優先する(ルーブリック⑥)。

障壁の系統ごとの講評ポイント(本課題で選択された系統)

keyboard-focus

講評ポイント

dialog-no-focus-return: キャンセルで閉じた後のフォーカス想定(spec 5.5)は明記されているが、確定で閉じた後の挙動は仕様未定義であり、fault として成立するのはキャンセル経路のみである(catalog/faults.yaml notes)。
error-summary-not-focused: spec 6章への違反ではあるが WCAG の特定達成基準の失敗と断定できない指摘であり、ルーブリック⑥(基準マッピング)の配点が 1点に留まる理由の実演になる(catalog/faults.yaml notes)。
outline-none-global: composed gate の toBeFocused によるプログラム的観測は dialog-no-focus-return の欠陥を塞がないが、フォーカスインジケーターが消えていることで参加者の目視発見が難しくなる、gate と人間の観測のズレがある(catalog/faults.yaml notes)。

よくある誤読

outline-none-global を「各ボタンにフォーカススタイルがない」と部品ごとの指摘に分解してしまい、リセット CSS 1 箇所という原因に集約できない。
dialog-no-focus-return を確定(承認・取り下げ)で閉じた経路でも指摘する。確定後のフォーカス先は spec 未定義なので、その指摘は fault ではない。
error-summary-not-focused に無理に WCAG 番号(2.4.3 や 3.3.1)を当ててしまう。spec 違反として番号なしで書くのが正しい。
dialog-background-operable を「aria-modal がない」という属性の欠落だけで指摘し、実際に Tab で背後へ到達できるという観測を伴わない。

name-label

講評ポイント

rowmenu-trigger-no-name: コンポーネント自体(MenuButton)は正しく実装されており、承認一覧側の呼び出しで label prop を渡し忘れたという利用側の問題である。同じ部品でも申請一覧側は問題がない、という instance 単位の fault である (catalog/faults.yaml notes)。
datatable-row-checkbox-no-name: rowmenu-trigger-no-name と症状(名前がない)は同じだが、原因は部品(DataTable)側にある。修正先が利用側か部品側かで影響範囲が変わることを、 rowmenu と対比して整理する。
login-email-autocomplete-missing: 名前(label)も関連付けも正しいのに、入力目的 (autocomplete)だけが欠けている。「名前がある = 1.3.5 を満たす」ではないこと、自動検査(axe autocomplete-valid)は欠落を検出しないことを確認する。
submit-button-name-mismatch: 名前は「ある」が可視ラベルと一致しない型。 rowmenu-trigger-no-name(名前が無い)/ amount-label-not-associated(関連付けが無い) と並べ、自動検査(button-name)が通っても 2.5.3 は満たさないことを確認する。
amount-error-no-suggestion: 関連付け(field-errors-not-associated)やフォーカス (error-summary-not-focused)は正しいのに、文言の内容だけが欠陥。3.3.1(存在と場所)と 3.3.3(直し方)を分けて評価できているか、spec 6 章の文言仕様を根拠に指摘できているかを見る。
error-messages-generic: 関連付け(field-errors-not-associated)もフォーカス (error-summary-not-focused)も正しく、自動検査にも出ない。文言を読んで初めて分かる欠陥を、受講者が読み上げ確認や目視で拾えているかを見る。

よくある誤読

rowmenu-trigger-no-name を MenuButton コンポーネントの欠陥として報告する。申請一覧では正しく動いているため、承認一覧側の呼び出しの問題と切り分けられていない。
amount-label-not-associated の修正として aria-label を入力要素に足す。可視ラベルが既にあるので for/id の関連付けが原因への修正であり、 aria-label 追加は二重管理を生む。
field-errors-not-associated を「エラーメッセージが表示されない」と誤読する。視覚的には表示されており、フィールドとの関連付けの欠落が問題。
datatable-row-checkbox-no-name を承認待ち一覧の実装(利用側)の問題として報告する。 DataTable の行チェックボックスの設計欠陥であり、選択列を使う画面すべてに伝播する。
login-email-autocomplete-missing の修正として autocomplete="email" を提案する。ログイン ID の欄は username トークンが正しく(clean base と同じ)、email は連絡先メールアドレス欄用。
submit-button-name-mismatch を「aria-label があるので名前は問題ない」で終える。音声操作の利用者は可視ラベルを発話するため、accessible name が可視ラベルを含まないと操作できない(2.5.3)。
可視ラベルを短縮しただけの名前(例: 「申請を送信」に対する「送信」)は基準の文言には反するが障壁としては薄く、争いになりやすい。submit-button-name-mismatch はそれを避け、可視ラベルと共通する語を持たない値(「確定」)にしてある。
amount-error-no-suggestion を 3.3.1(エラーの特定)として報告する。要約とフィールド直下でエラーの存在と場所は特定できており、欠けているのは修正方法の提案(3.3.3)。
error-messages-generic を 3.3.3(修正方法の提案)として報告する。3.3.3 は「エラーの内容は分かるが直し方が示されない」場合。ここでは何が誤りか自体が示されていないので 3.3.1 を当てる。

state-announcement

講評ポイント

combobox-async-status-silent: fault はコンポーネント型単位で仕込まれているが、実際に症状が現れるのは非同期モードのインスタンス(request.payee)のみであり、「型に当てても全インスタンスで観測できるとは限らない」(catalog/faults.yaml notes)。
notification-no-live-region: 視覚的には表示されるが読み上げられず、申請受付・承認完了・エラー通知のすべてに影響する blast-radius 最大級の fault である(catalog/faults.yaml notes)。

よくある誤読

notification-no-live-region と notification-auto-dismiss を「通知の問題」として 1 件にまとめてしまう。前者は読み上げられない (実装の欠陥)、後者は消えてしまう(設計判断の欠陥)で原因も修正責任も異なる。
成功通知の自動消去をトーストの標準挙動とみなして欠陥として報告しない。 spec 5.7 は成功・エラーとも until-dismissed(閉じるまで残る)を明示しており、「消えるのが普通」という思い込みで見逃されやすい。
combobox-async-status-silent を全 Combobox の問題として報告する。症状が出るのは非同期モードのインスタンス(取引先)のみで、影響範囲の特定が不正確になる。
datatable-sort-state-missing を「矢印アイコンに代替テキストがない」 (1.1.1)として指摘する。列ヘッダーの状態(aria-sort)の欠落として捉えるのが正しい。
修正方針が「aria-live を足す」で止まり、コンテナを常設して内容更新で通知する、という実装上の要点に触れない。

visual-presentation

講評ポイント

secondary-text-low-contrast: デザインシステムのカラートークン1箇所の不足が全画面の補足テキストに波及する。axe で大量の違反箇所が検出されるが、原因はトークン1つに集約できるという原因集約の視点を確認する (catalog/faults.yaml notes)。
rowaction-icons-undersized: 2.5.8 は「24×24 未満」だけでは失敗にならない。両方が小さい場合は中心どうしが 24px 以上離れているかで判定する。寸法と間隔の両方を測っているか、同じ行の三点リーダーが適合していること(= 部品ではなくこの画面の CSS が原因)に気づけているかを見る。
request-input-border-low-contrast: 文字のコントラストは合格で axe も違反を出さない。自動チェックの結果だけで「コントラストは問題なし」と判断せず、部品の境界(1.4.11)を目で確かめているかを見る。エラー時の赤枠は見えるので、「エラーが出ていない状態」で確かめたかどうかも論点になる。

よくある誤読

secondary-text-low-contrast を axe の出力どおり数十件の個別違反として列挙し、トークン 1 つに集約できない。修正方針も画面ごとの色指定になりがちで、取り残しが出る。
status-color-only は「ドットに aria-label が付いているから 1.1.1 は問題ない」で終える。実際のドットには既に role=img + aria-label が付いており(1.1.1 は満たしている)、それでも色覚特性のある晴眼者には伝わらないため 1.4.1 の失敗は解消していない。ステータス列を復元し、テキストで表示する必要がある。
rowaction-icons-undersized を「アイコンボタンは小さいものだから仕方ない」と見逃す、あるいは逆に「24px 未満」だけを根拠にして間隔の例外を検討しない。どちらも基準の適用としては不完全。
request-input-border-low-contrast を 1.4.3(文字のコントラスト)として報告する。文字は十分なコントラストがあり、足りないのは入力欄の境界(非テキスト、1.4.11)。