HTMLの構文チェックは、ブラウザが意図した文書構造を組み立てられるように、要素の入れ子や属性の書き方を確認する作業です。
構文エラーを減らすことは、実装の予測しやすさと保守性を高めます。
ただし、構文エラーがゼロであることと、ページがアクセシブルであることは同じではありません。
構文チェック、自動アクセシビリティ検査、キーボードやスクリーンリーダーを使う手動確認には、それぞれ異なる役割があります。
HTMLの構文解析とアクセシビリティの関係
構文解析とは、ブラウザがHTMLを読み取り、要素同士の関係を文書構造として組み立てる処理です。
スクリーンリーダーなどの支援技術は、そのブラウザが解釈した構造やアクセシビリティ情報を利用します。
HTMLに誤りがあると、ブラウザがコードを補正した結果、開発者が想定した構造と実際の構造が異なる場合があります。
その差が見出し、フォーム、ボタンなどの意味や操作に影響すると、利用者が内容を理解しにくくなったり、操作しにくくなったりします。
WCAG 2.2で変わった「4.1.1 構文解析」
WCAG 2.0と2.1には、達成基準4.1.1「構文解析」がありました。
しかし、W3Cの「Understanding Success Criterion 4.1.1」は、この達成基準がWCAG 2.2で廃止されたと説明しています。
ブラウザが構文エラーを処理できるようになり、支援技術もHTMLを直接解析せず、ブラウザが提供する情報を利用するようになったためです。
サイト内のWCAG 2.2で「4.1.1 構文解析」が廃止された背景でも、この変更を詳しく扱っています。
達成基準が廃止されても、仕様に沿ったHTMLを書く価値は失われません。
一方で、「構文検証に合格したからアクセシビリティ対応は完了した」とは判断できません。
要素の名前、役割、状態が支援技術へ伝わるか、キーボードで操作できるか、読み上げ順が自然かといった確認が別に必要です。
構文エラーとアクセシビリティの問題を分ける
問題の種類を分けると、適切な検査方法と修正方法を選びやすくなります。
| 確認対象 | 問題の例 | 主な確認方法 |
|---|---|---|
| HTMLの構文 | 許可されていない入れ子、重複した属性、引用符の不足 | HTMLチェッカー |
| HTMLの意味 | 見出しではない要素を見た目だけ見出しにする | コードレビューと手動確認 |
| ARIA | 実際の動作と異なる役割や状態を指定する | 自動検査と支援技術による確認 |
| 操作性 | キーボードではボタンへ移動できない | キーボードによる手動確認 |
ARIA属性の誤用は、構文として正しくても起こります。
逆に、HTMLチェッカーが示すエラーのすべてが、直ちに利用者の障壁になるとは限りません。
検査結果は問題の入口として使い、実際の構造、意味、操作への影響を確認します。
よくある問題と直し方
許可されていない入れ子
HTML要素には、内側に置ける要素の種類が決まっています。
例えば、段落を表すp要素の中にdiv要素を置くと、ブラウザはdiv要素の前で段落を閉じたものとして解釈します。
ソースコードの見た目と、ブラウザ内の文書構造が一致しない例です。
誤った例
<p>申込方法を説明します。
<div>申込ボタン</div>
</p>修正例
<p>申込方法を説明します。</p>
<div>申込ボタン</div>見た目だけで判断せず、開発者ツールでブラウザが組み立てた要素の関係も確認します。
閉じタグや引用符の不足
HTMLには終了タグを省略できる要素もあるため、「すべての開始タグを必ず明示的に閉じる」という説明は正確ではありません。
ただし、省略が認められていない要素の閉じタグや、属性値を囲む引用符が欠けると、後続の要素まで意図と異なる形で解釈されるおそれがあります。
チーム内で明示的な書き方をそろえ、コードレビューとHTMLチェッカーで確認すると、修正時の読み違いを減らせます。
ARIAでHTMLの問題を隠さない
ARIAは、要素の名前、役割、状態などを支援技術へ伝えるための属性群です。
ARIAを追加しても、不正な入れ子やキーボード操作の不足は直りません。
まず標準のHTML要素を適切に使い、HTMLだけでは伝えられない情報があるときにARIAを補います。
例えば、文字のないアイコンボタンには、操作の目的がわかる名前が必要です。
<button type="button" aria-label="検索">
<span aria-hidden="true">🔍</span>
</button>ボタンの名前、役割、状態を扱う実装は、WCAG 4.1.2「名前、役割、値」の実装方法も参考になります。
検証ツールの役割
一つのツールですべてを判定しようとせず、目的に合わせて使い分けます。
- W3C HTML Checker：HTMLの入れ子、属性、要素の使い方など、構文と仕様への適合を確認します。
- Lighthouse：Chrome DevToolsなどからページを自動監査し、検出した問題と改善の手がかりを示します。
- axe DevTools：ブラウザ上で自動アクセシビリティ検査を実行し、検出した問題の箇所と修正情報を確認できます。
W3Cは、アクセシビリティ評価ツールだけではすべての項目を自動判定できず、人の判断が必要だと説明しています。
自動検査の後に、キーボード操作、フォーカスの移動、見出し構造、フォームの説明、スクリーンリーダーでの読み上げを確認します。
自動検査と手動検査の組み合わせは、アクセシビリティテストの実践手順で詳しく確認できます。
公開前の確認手順
- HTMLチェッカーを実行する
エラーの行番号だけでなく、ブラウザ内でどの要素関係になっているかを確認します。 - 自動アクセシビリティ検査を実行する
Lighthouseやaxe DevToolsの指摘を確認し、対象の要素と利用者への影響を特定します。 - キーボードだけで操作する
リンク、ボタン、フォームへ順番に移動でき、現在位置が見えるかを確認します。 - 見出しとフォームを確認する
見出し階層が内容の構造に合い、入力欄の名前と説明が伝わるかを確認します。 - 支援技術で主要な操作を試す
スクリーンリーダーで、ページの主要部分と重要な操作を確認します。 - 修正後に再検査する
一つの修正が別の構造や操作を壊していないかを確かめます。
構文チェックをアクセシビリティ改善につなげる
HTML構文チェックは、意図した文書構造を保つための基礎的な品質管理です。
ただし、その結果だけでアクセシビリティへの適合や使いやすさを保証することはできません。
HTMLの意味、ARIA、キーボード操作、支援技術での確認までを一つの検証工程として扱うことで、構文上の正しさを利用者の使いやすさにつなげられます。
当社では、ウェブアクセシビリティを簡単に導入できるUUU ウェブアクセシビリティウィジェットツールをリリースしております。
アクセシビリティ向上にご興味がある方は、サービスの詳細をご覧ください。