WCAG 2.2の達成基準「1.3.2 意味のある順序」は、内容を理解するために順序が欠かせない場合、その読み順をプログラムが判定できるようにすることを求めています。
画面では自然に見えていても、HTMLの並びが「手順2、手順1」になっていれば、読み上げ時に意味が変わるおそれがあります。
この記事では、HTMLとCSSを学び始めた人に向けて、達成基準の対象、DOM順序の整え方、よくある失敗、確認手順を具体例とともに説明します。
スクリーンリーダーの仕組みや基本的な使われ方を先に確認すると、読み順が必要な理由をつかみやすくなります。
達成基準1.3.2が求める読み順
意味のある順序とは、並びを変えると内容の意味や理解に影響する順序です。
作業手順、章立てされた説明、前後関係のある会話などが該当します。
DOM(Document Object Model)は、ブラウザがHTMLを要素の階層として扱うための構造です。
HTMLでは、このDOM上の並びがプログラムから読み取れる順序の基礎になります。
ただし、「見た目の順序とDOM順序が少しでも違えば不適合」を意味するわけではありません。
順序が意味に影響しない独立した内容であれば、複数の読み順が成立する場合があります。
判定では、意味を保つ読み順を少なくとも一つプログラムが読み取れるかを確認します。
視覚的な配置だけに頼って関係や順序を伝えている場合は、その情報が読み上げや表示変更で失われないかを点検します。
順序が意味を持つ場面の見分け方
| 場面 | 順序を変えたときの影響 | 適した表現 |
|---|---|---|
| 申請や購入の手順 | 操作の前提が崩れ、次に何をすべきか分からなくなる | <ol>で手順を順番に記述する |
| 見出しと説明文 | 説明の対象が分かりにくくなる | 見出しの直後に、その見出しに属する内容を置く |
| データ表 | 見出しと値の対応が崩れる | <table>、<th>、scopeで関係を示す |
| 互いに独立した補足欄 | 前後を入れ替えても各内容の意味が変わらない | どの順序でも理解できる構造にする |
迷った場合は、CSSを外して内容を上から一列に読んでみます。
その状態で説明の前提、手順、見出しとの関係が崩れるなら、順序をHTML側で整える必要があります。
DOM順序を基準にHTMLを組み立てる
CSSで見た目だけを並べ替えない
FlexboxやGridのorderを使うと、DOMを変えずに要素の見た目だけを並べ替えられます。
次の例は画面上では「ステップ1、ステップ2」と見えますが、HTMLには逆順で記述されています。
問題のある例
<div class='steps'>
<p class='step-2'>ステップ2:内容を確認する</p>
<p class='step-1'>ステップ1:フォームに入力する</p>
</div>
.steps {
display: flex;
flex-direction: column;
}
.step-1 { order: 1; }
.step-2 { order: 2; }
CSSの並べ替えはHTMLの順序そのものを直しません。
手順のように順番が意味を持つ内容は、最初から論理的な順序でHTMLに記述します。
改善例
<ol>
<li>フォームに入力する</li>
<li>内容を確認する</li>
</ol>
<ol>を使うと、項目の並びが手順であることもプログラムに伝わります。
デザインを変更するときも、意味を持つHTMLの順序は保ちます。
JavaScriptで要素を動かした後もDOMを確認する
JavaScriptで項目を追加したり並べ替えたりする画面では、操作後のDOM順序も確認します。
見た目だけ目的の位置へ移し、DOM上では離れた場所に残すと、内容のつながりが伝わりにくくなります。
リストと表で関係を明示する
順番のある手順には番号付きリストを使う
順番どおりに進める操作は、段落を並べるだけでなく番号付きリストで表します。
番号と項目の関係をHTMLに残せるため、CSSを外しても手順が保たれます。
<h2>送信までの手順</h2>
<ol>
<li>必要事項を入力する</li>
<li>入力内容を確認する</li>
<li>送信ボタンを押す</li>
</ol>
表は行と列の関係がある情報に限る
表は、日付とイベントのように行と列の対応を読む必要がある情報に使います。
単に横並びに見せたいだけの内容を表にすると、存在しないデータの関係まで伝えてしまいます。
<table>
<caption>開催予定</caption>
<thead>
<tr>
<th scope='col'>日付</th>
<th scope='col'>イベント</th>
</tr>
</thead>
<tbody>
<tr>
<td>1月1日</td>
<td>新年のイベント</td>
</tr>
<tr>
<td>2月14日</td>
<td>季節のイベント</td>
</tr>
</tbody>
</table>
空白文字を重ねて列を作る方法では、列の関係をプログラムが判定できません。
データなら表を使い、単なる配置ならリストや<div>を論理的な順序で記述してCSSで整えます。
読み順とフォーカス順序を分けて考える
フォームでは、文章としての読み順と、Tabキーで移動するフォーカス順序の両方を確認します。
フォーカス順序はWCAGの別の達成基準とも関係するため、1.3.2だけで評価を終えないようにします。
通常のフォームは、ラベル、入力欄、ボタンを操作の流れに沿ってHTMLへ記述すれば、自然な順序でフォーカスが移動します。
正の値を持つtabindexで順番を付け直すと、項目の追加や削除によってDOM順序との対応が崩れやすくなります。
<form>
<label for='name'>名前</label>
<input type='text' id='name' name='name'>
<label for='email'>メールアドレス</label>
<input type='email' id='email' name='email'>
<button type='submit'>送信</button>
</form>
キーボード操作の判定やtabindexの扱いは、フォーカス順序の実装と確認方法で詳しく解説しています。
意味のある順序を確認する手順
- 順序が意味に影響する箇所を探す:手順、見出しと本文、会話、表などを抽出します。
- DOMを上から読む:開発者ツールやHTMLソースで、内容が論理的な順序になっているか確認します。
- CSSを外して確認する:一列に並べた状態でも、同じ意味で読めるか確認します。
- 読み上げを試す:スクリーンリーダーで連続して読み、説明や手順が前後しないか確認します。
- キーボードでも操作する:リンク、入力欄、ボタンの移動順が操作の流れを保つか、読み順とは別に確認します。
- 画面幅を変える:レスポンシブ表示で見た目が変わった後も、DOMの順序と内容の関係が保たれるか確認します。
自動チェックだけでは、順序を変えたときに文章の意味が保たれるかまでは判断しにくい場合があります。
最後は実際に上から読み、操作の前提や説明のつながりが崩れていないかを確認します。
実装の要点
- 順序を変えると意味が変わる内容は、論理的な順序でHTMLに記述する
- CSSの並べ替えだけで、意味を持つ順序を作らない
- 手順には番号付きリスト、行と列の関係がある情報には表を使う
- 読み順とフォーカス順序を分けて確認する
- CSSを外した状態、読み上げ、キーボード操作、画面幅の変更で検証する
達成基準1.3.2への対応は、見た目を固定する作業ではありません。
表示方法が変わっても意味を保てるよう、内容の順序をHTMLの構造に残す作業です。
当社では、ウェブアクセシビリティの導入と改善を支援するUUU ウェブアクセシビリティを提供しています。
サイトのアクセシビリティ向上をご検討の方は、サービスの詳細をご覧ください。

