WCAG 2.2では、達成基準「4.1.1 構文解析（Parsing）」が廃止され、適合要件から削除されました。
ただし、これは「HTMLの誤りを放置してよい」という変更ではありません。
構文エラーそのものを一律に判定するのではなく、利用者や支援技術に生じる問題を、該当する別の達成基準で評価するという整理です。
この記事では、4.1.1が削除された理由と、Web制作やアクセシビリティ監査で何を確認すべきかを説明します。
WCAG 2.2全体の変更点を先に確認したい場合は、関連記事も参照してください。
先に確認したい結論
| 確認事項 | 実務上の扱い |
|---|---|
| WCAG 2.2の監査 | 4.1.1を独立した合否項目として判定しません。 |
| WCAG 2.0または2.1の監査 | 対象規格を明記したうえで扱います。W3Cは、HTMLまたはXMLのコンテンツでは4.1.1を常に満たすものと考える旨の注記を示しています。 |
| HTMLの構文チェック | 品質管理として続けます。ただし、検証結果だけでアクセシビリティの適合や不適合を決めません。 |
| 利用者に影響する不具合 | 見出しやラベルの関係、UIの名前、役割、状態など、実際に損なわれた情報や操作に対応する達成基準で評価します。 |
4.1.1 構文解析が求めていたこと
構文解析とは、HTMLやXMLなどのマークアップをブラウザなどが読み取り、要素の関係をデータ構造として組み立てる処理です。
旧来の4.1.1は、この処理を利用者エージェントや支援技術が安定して行えるようにするためのレベルAの達成基準でした。
旧基準は、仕様で例外が認められている場合を除き、マークアップに次の状態を求めていました。
- 開始タグと終了タグが必要な形でそろっている
- 要素が仕様に従って入れ子になっている
- 一つの要素に同じ属性が重複していない
idの値が一意である
当時は、支援技術がHTMLを直接解析する場面があり、構文の崩れによって内容を正しく解釈できない可能性がありました。
そのため、構文上の条件を独立した達成基準として設ける意味がありました。
4.1.1が削除された理由
W3Cの4.1.1解説は、HTMLなどの仕様とブラウザによる構文エラー処理が改善され、支援技術もHTMLを直接解析するのではなく、ブラウザの処理結果を利用するようになったと説明しています。
この変化により、旧基準が想定した問題は現在では生じなくなったか、別の達成基準で扱えるようになりました。
削除の理由を「ブラウザがすべての誤りを安全に直してくれるから」と理解するのは正確ではありません。
ブラウザがHTMLから文書構造を作れても、その結果が制作者の意図どおりであり、支援技術に正しい情報を渡せるとは限らないためです。
同様に、「4.1.2 名前、役割、値と内容が重複したため、4.1.1を統合した」という単純な変更でもありません。
W3Cは、旧基準で問題になった事象の多くが、1.3.1「情報及び関係性」や4.1.2「名前、役割、値」などで評価されると説明しています。
削除後もHTMLの品質を保つ理由
4.1.1の削除によって変わるのは、WCAGにおける合否判定の方法です。
HTMLの構文品質が、保守しやすい実装や意図した表示のために必要であることは変わりません。
たとえば、同じidが二つ存在するだけで、WCAG 2.2の4.1.1違反と判定することはありません。
しかし、その重複によってフォームのラベルが別の入力欄を参照したり、説明文と対象の関係が失われたりすれば、利用者に届く情報が変わります。
その場合は、重複という構文エラーだけを見るのではなく、どの情報や操作が損なわれたかを確認します。
タグの閉じ忘れや不正な入れ子についても同じです。
ブラウザが生成したDOM（ページを要素の階層として表した構造）を確認し、見出し、リスト、表、フォームなどが意図した関係になっているかを調べます。
監査と実装での確認手順
- 対象とするWCAGの版と適合レベルを明記する。
WCAG 2.2の監査なのか、調達要件などにより2.0または2.1を対象にするのかを最初に決めます。 - HTMLの構文エラーを品質上の手掛かりとして調べる。
W3C Nu Html Checkerなどを使い、タグ、属性、入れ子、idの問題を見つけます。 - ブラウザが生成した構造を確認する。
開発者ツールでDOMやアクセシビリティツリーを確認し、見出し階層、ラベルとの関連付け、名前、役割、状態が意図どおりかを調べます。 - 利用者への影響を該当する達成基準で評価する。
構文エラーを見つけただけで判定を終えず、情報の関係やUIの操作にどのような問題が起きるかを確認します。 - 自動チェックを手動確認で補う。
キーボード操作や支援技術による確認を組み合わせ、ツールだけでは判断できない問題を調べます。
構文検証は、原因になり得るコードを効率よく見つける工程です。
一方、アクセシビリティ評価では、利用者が情報を理解し、UIを操作できるかまで確かめる必要があります。
両者の役割を分けると、検証エラーの件数だけを減らす作業に偏らず、影響の大きい問題を優先できます。
実務で押さえるポイント
- WCAG 2.2では、4.1.1を独立した適合判定に使わない
- 構文エラーを放置せず、品質管理と不具合の早期発見に生かす
- エラーの有無だけでなく、生成されたDOMとアクセシビリティツリーを確認する
- 問題があれば、1.3.1や4.1.2など、実際の影響に対応する達成基準で評価する
- 自動検証だけでアクセシビリティへの適合を断定しない
4.1.1の削除は、HTML品質を軽視するための変更ではありません。
構文上の形式だけを一律に数える評価から、利用者に伝わる構造と操作を確認する評価へ移ったと捉えると、実装と監査の判断を整理できます。
参考資料
- W3C「Web Content Accessibility Guidelines (WCAG) 2.2」4.1.1 Parsing
- W3C「Understanding Success Criterion 4.1.1: Parsing」
- W3C「WCAG 2 FAQ」4.1.1 Parsing
当社では、Webアクセシビリティの導入と運用を支援するUUU ウェブアクセシビリティを提供しています。
アクセシビリティ改善を進めたい方は、サービスの詳細をご覧ください。