適応可能のガイドライン

1.3.1 情報及び関係性 (レベル A)

コンテンツを適切に構造化する

作成日: 2024.4.10 / 最終修正日: 2026.3.26

この達成基準は、視覚的なデザイン（フォントの大きさ、太さ、配置など）に頼らず、ソースコードを通じて「情報の構造（見出し、リスト、表など）」や「項目間の関係（ラベルと入力欄など）」を正しく伝えることを目的としています。これにより、スクリーンリーダーの利用者もページ構成を正確に把握できます。

実践すべきこと

適切なHTML要素の使用

• 見出しは h1 〜 h6 を使い、階層構造（親子関係）を正しく保つ。デザイン（文字の大きさ）のために見出しレベルを選ばない。
• 箇条書きには ul、ol、li を使用する。「・（中黒）」や改行だけで箇条書きを表現しない。
• 引用文には blockquote、表データには table を使用するなど、情報の意味に合ったタグを選ぶ。

フォームと情報の関連付け

• フォームの入力項目と説明テキストを label 要素で正しく関連付ける（for属性とid属性の一致）。
• 「※必須」などの注釈が、どの入力項目に対するものかをプログラム的に明示する。

視覚的な手がかりの補足

• 「赤文字の項目は必須です」のように、色や形、位置だけで情報を伝えない。必ず「（必須）」といったテキストによる補足を併記する。

運用者への注意

装飾目的のタグ使用を避ける

• 見出しタグ（hタグ）を、単に文字を大きく見せるための装飾として使わない。
• 段落（p要素）の間に、スペースを空ける目的で空の改行（br要素）を連続して使用しない。余白はCSSで制御する。

構造の整合性

• リスト（箇条書き）の中に、リストに関係のない説明文などを無理やり混ぜ込まない。
• 表（table）をレイアウト目的（要素を横に並べるためだけ）に使用しない。

開発者への注意

WAI-ARIAの適切な活用

• HTML標準タグだけでは表現できない複雑な構造（タブメニューやアコーディオンなど）には、WAI-ARIA（role="tablist" 等）を使用して構造を補完する。
• ただし、可能な限りHTMLの標準要素（native elements）を優先して使用する。

複雑な表（テーブル）のマークアップ

• 表には必ず th（見出しセル）と td（データセル）を使い、scope属性などでその関係を明確にする。

今のWeb環境で気をつけたい点

• レスポンシブデザインでの順序：スマホ表示などでCSS（flexboxのorderやgrid）を使って見た目の順序を入れ替えても、スクリーンリーダーは「HTMLの記述順」に読み上げる。視覚的な順序と読み上げ順序が矛盾し、文脈が壊れないよう注意する。
• 入力エラーの通知：エラーメッセージを表示する際、単に赤字にするだけでなく、aria-describedby などを使って「どの項目にエラーが出ているか」を直接関連付ける。
• コンポーネントライブラリの利用：ReactやVueなどのコンポーネントを利用する場合、生成されるHTMLが正しい構造（適切な見出しレベルやラベルの関係）になっているか、開発ツールで最終的な出力を確認する。

参考リンク

解説書 達成基準 1.3.1: 情報及び関係性

1.3.2 意味のある順序の達成基準（レベルA）

コンテンツを理解しやすい順序で提供する

作成日: 2024.4.10 / 最終修正日: 2026.3.26

この達成基準は、支援技術（スクリーンリーダーなど）がコンテンツを読み上げる際、制作者が意図した正しい「情報の流れ」が維持されることを目的としています。見た目の配置を優先してHTMLの記述順がバラバラになると、利用者が内容を誤解したり、操作ができなくなったりする恐れがあります。

実践すべきこと

論理的な記述順の維持

• HTMLのソースコードは、人間が自然に読んで理解できる順番（上から下、左から右など）で記述する。
• 見出しとそれに関連する本文や画像は、必ずソースコード上で連続して配置する。

階層構造の整合性

• 見出しレベル（h1〜h6）をスキップしたり（例：h2の次にh4がくる）、順序を逆にしたりしない。文書の論理的な階層を保つ。

運用者への注意

単語内の不要なスペースを避ける

• 「日　時」のように単語の間に全角スペースを入れない。スクリーンリーダーが「にち、とき」と別々の単語として認識し、検索性も低下するため、余白はCSSで制御する。

読み上げを意識した表記

• 記号に頼りすぎない。「9:30〜17:00」は「9時30分から17時」と表記する方が、読み上げソフトでも正確に伝わりやすく、誰にとっても親切。
• 装飾文字（特殊なフォント記号など）だけで意味を伝えない。

脚注や注釈の明示

• 脚注がある場合は、本文からリンクを貼るか、「※注1」のようにテキストで対応関係を明確にする。

開発者への注意

見た目とソース順の不一致（CSS注意）

• Flexboxの order プロパティや CSS Grid を使用して見た目の順序を入れ替える際は、スクリーンリーダーの読み上げ順（HTMLの記述順）と視覚的な順序が矛盾し、利用者が混乱しないか確認する。

支援技術への配慮

• ナビゲーションなどのランドマークに aria-label をつける際は、「ページネーション」といった専門用語より「ページ切り替え」など、直感的に役割が伝わる言葉を選ぶ。
• 画像とテキストが同じ要素内に密集すると読み上げが不自然になる場合があるため、画像（img）と説明文（p）を適切に構造化して分けることが望ましい。

今のWeb環境で気をつけたい点

• レスポンシブでの要素移動：PC版では右カラムにある要素を、スマホ版で最上部に移動させるような実装をCSSのみで行うと、読み上げ順序が不自然になることがある。コンテンツの重要度に基づいたHTML構造を優先する。
• 自動翻訳への配慮：単語内にスペースを入れる（例：アクセシビリティ → ア ク セ シ ビ リ ティ）と、ブラウザの自動翻訳機能が正しく動作しなくなるため、アクセシビリティだけでなく多言語対応の観点からも避けるべきである。

参考リンク

解説書 達成基準 1.3.2: 意味のある順序

1.3.3 感覚的な特徴 (レベル A)

形や位置などの「見た目」だけに依存した指示をしない

作成日: 2024.4.10 / 最終修正日: 2026.3.26

この達成基準は、視覚的な情報を利用できない利用者や、画面を拡大して一部しか見えていない利用者でも、コンテンツを正しく操作・理解できるようにすることを目的としています。「右のボタン」や「丸いアイコン」といった、形状、大きさ、位置、方向、音などの感覚的な特徴だけに依存した指示を避け、テキストによる補足を提供します。

実践すべきこと

具体的な言葉による指示

• 形状（丸、四角）、位置（右、左、下）、方向（上、下）などの情報を使う際は、必ず項目名などのテキスト情報を併記する。（例：「右の送信ボタンをクリック」ではなく「右にある『送信』ボタンをクリック」とする）
• 音による通知を行う場合は、視覚的な通知（画面上のメッセージ表示など）を同時に行う。

リンクテキストの具体化

• 「こちら」や「ここをクリック」といった曖昧な表現を避け、リンク先の目的地や内容がわかるテキストにする。（例：「詳細はこちら」ではなく「サービスの詳細を見る」）

運用者への注意

空間的な表現の補足

• 「下記」や「左記」といった表現自体は禁止されていませんが、スマホ表示で位置が変わったり、スクリーンリーダー利用者が場所を特定できなかったりすることを考慮し、「下記の『お問い合わせフォーム』」のように対象の名前を必ず添える。

色や形に頼った説明の回避

• 「赤色のボタンを押してください」ではなく「赤色の『削除』ボタンを押してください」のように、色や形がわからなくても操作できるように記述する。

開発者への注意

セマンティックな構造の維持

• 特定の場所を指し示す際、HTMLの構造（DOM順序）が視覚的な配置と一致していることを確認する。

アイコンフォントの代替テキスト

• 「＋」や「⚙」などのアイコンだけで機能を説明する場合、aria-labelなどを使用して「新規作成」「設定」といったテキスト情報をプログラムから参照できるようにする。

今のWeb環境で気をつけたい点

• レスポンシブデザインの影響：PCでは「右側」にある要素も、スマホでは「下側」に移動することが一般的。そのため「右側のメニュー」という表現は、閲覧デバイスによって事実と異なる指示になるリスクがある。位置関係に頼らない表現（「メインメニュー」など）を優先すべきである。
• ダークモードや高コントラストモード：ユーザーの設定によっては「赤色のボタン」が赤色に見えない（あるいは色が反転している）場合がある。色の名前だけで指示を行うことは、アクセシビリティだけでなくユーザビリティの低下を招く。

参考リンク

解説書 達成基準 1.3.3: 感覚的な特徴

1.3.4 表示の向き (レベル AA)

利用者がデバイスの向き（縦・横）を自由に選べるようにする

作成日: 2024.4.10 / 最終修正日: 2026.3.26

この達成基準は、Webサイトやアプリの画面が「縦向き（ポートレート）」または「横向き（ランドスケープ）」のどちらかに固定されず、利用者の好みの向きで閲覧・操作できることを目的としています。特に、車椅子にデバイスを固定して使っている利用者など、物理的にデバイスを回転させることが困難な方にとって非常に重要な基準です。

実践すべきこと

表示の向きを固定しない

• 特定の向き（例：スマホは縦向きのみ）でしか表示できないような制限をかけない。
• OSやブラウザの回転機能に従って、コンテンツのレイアウトが適切に切り替わるようにする。
• 「画面を回転させてください」といったメッセージを表示して操作をブロックしない。

運用者への注意

例外事項の理解

• ピアノアプリの鍵盤、銀行の小切手のスキャン、スロットゲーム、プロジェクターでのプレゼンテーションなど、その向きでなければ「機能自体が成立しない」場合のみ例外として認められる。
• 一般的な情報の閲覧や入力フォームなどにおいて、デザイン上の理由だけで向きを固定することは認められない。

開発者への注意

CSSメディアクエリの活用

• @media (orientation: landscape) や (orientation: portrait) を使用し、どちらの向きでもコンテンツが画面内に収まり、スクロールしてすべての情報にアクセスできるように実装する。

JavaScriptによるロックの回避

• `Screen Orientation API` などを使用して、強制的に画面の向きをロックするような実装を避ける。

柔軟なユニット（単位）の使用

• 幅や高さを固定値（px）で指定しすぎず、%、vw、vh、flexbox、grid などを使用して、画面の比率が変わってもレイアウトが壊れないようにする。

今のWeb環境で気をつけたい点

• 折りたたみスマホやタブレットへの対応：画面サイズやアスペクト比が動的に変わるデバイスが増えている。縦横の切り替えだけでなく、画面分割（スプリットビュー）などの特殊な表示状態でも、コンテンツが隠れたり操作不能になったりしないか確認が必要である。
• 動画プレイヤーの全画面表示：動画を全画面にした際に、強制的に横向きにする挙動は一般的だが、これも「向きを固定して利用しているユーザー」を排除していないか、閉じるボタンなどの操作系が維持されているか注意を払うべきである。

参考リンク

解説書 達成基準 1.3.4: 表示の向き

1.3.5 入力目的の特定 (レベル AA)

入力フィールドは自動入力（オートコンプリート）できるようにする

作成日: 2024.4.10 / 最終修正日: 2026.3.26

この達成基準は、利用者がフォームに「自分の情報（名前、メールアドレス、電話番号など）」を入力する際、ブラウザの自動入力機能を使えるようにすることを目的としています。入力の手間を省くことで、タイピングが困難な利用者や、記憶力・認知機能に障害のある利用者が、間違いなくスムーズに手続きを完了できるようになります。

実践すべきこと

autocomplete属性の適切な設定

• 利用者の個人情報を求める入力欄（input要素など）には、HTMLの autocomplete 属性を使用して、入力すべき情報の種類（目的）をプログラムが判別できるようにする。

運用者への注意

フォーム作成ツールの選定と確認

• WordPressのプラグインや外部のフォーム作成ツールを導入する際、各入力項目に autocomplete 属性を設定できる機能があるかを確認する。
• 設定可能な場合は「氏名」「メールアドレス」「郵便番号」などの項目に対し、適切な自動入力の割り当てを行う。

開発者への注意

正確な属性値の指定

• HTML5の仕様に基づき、正しい値を指定する。（例：名前には autocomplete="name"、メールアドレスには autocomplete="email"、電話番号には autocomplete="tel"）

type属性との併用

• autocomplete 属性だけでなく、適切な type 属性（type="email" や type="tel" など）も併せて指定することで、スマートフォンで適切なキーボード（数字キーボードなど）が表示されるようにする。

今のWeb環境で気をつけたい点

• スマートフォンの小さな画面での文字入力は誰にとっても負担が大きく、autocomplete 属性による自動入力は、すべてのユーザーのコンバージョン率（CVR）向上に直結する。アクセシビリティ対応がそのままビジネス上のメリットになる代表的な例である。
• 近年普及しているパスワードマネージャー（1Passwordなど）や、OS標準の生体認証（FaceIDや指紋認証）による自動入力も、この属性が正しく設定されているかに依存しているため、ログインフォームや決済フォームでの設定は必須と言える。
• WCAG 2.2で新設された「3.3.7 冗長な入力（再入力の省略）」に対応する上でも、ブラウザの自動入力を有効にしておくことは有効な手段となる。

参考リンク

解説書 達成基準 1.3.5: 入力目的の特定

1.3.6 目的の特定 (レベル AAA)

WCAG 2.2 解説書

目次へ戻る