適応可能のガイドライン

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 の標準要素を優先して使用する。

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

• 表には 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環境で気をつけたい点

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

参考リンク

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

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

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

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

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

実践すべきこと

具体的な言葉による指示

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

リンクテキストの具体化

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

運用者への注意

空間的な表現の補足

• 「下記」や「左記」といった表現は、狭い画面で位置が変わったり、スクリーンリーダー利用者が場所を特定しにくかったりすることを考慮し、「下記の『お問い合わせフォーム』」のように対象の名前を添える。

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

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

開発者への注意

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

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

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

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

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

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

参考リンク

解説書 達成基準 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)

アイコンやボタン、画面の領域が「何の役割を持っているか」をプログラムで判別できるようにする

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

この達成基準は、記憶や学習のハードルなどのある利用者が、ウェブサイトをより直感的に操作できるようにすることを目的としています。ページ上のボタンやアイコン、ヘッダーなどの画面領域に「これが何の目的を持った要素か」という目印を裏側のコードでつけておきます。そうすることで、利用者の支援ツールがその目印を読み取り、「よく知っているお馴染みのアイコンに自動で差し替える」「迷わないように不要なメニューを隠す」といった、使いやすい画面への自動アレンジが可能になります。

実践すべきこと

役割のプログラムによる明示

• ウェブページ内のリンク、ボタン、アイコン、およびページのメインコンテンツなどに対して、支援技術がその「機能や目的」を正しく解釈できるようにマークアップを行う。

運用者への注意

設計段階での意味の整理

• サイト内で使われているアイコンやボタンが、そもそもどのような目的（「ホームに戻る」「検索する」「設定を開く」など）で置かれているかを整理し、システム側に共通のデータとして組み込めるように設計段階から意識する。

開発者への注意

WAI-ARIAランドマークの活用

• ページの主要な領域を示すために、HTMLのセマンティックタグ（<header>、<main>、<nav> など）を使用し、必要に応じてARIAランドマーク（role="banner"、role="main" など）を適用して領域の目的をはっきりと示す。

利用者の状況や好みに合わせて、デザインを変えられる仕組み

• 利用者のブラウザや支援ツールが、「ホームボタンを使い慣れたアイコンに置き換える」「不要なメニューを隠す」といった画面のカスタマイズを自動で行えるように、専用の属性（メタデータ）を使って要素の目的をコードに埋め込む。

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

• レベルAAAの難易度と優先度： すべてのボタンやアイコンに対してメタデータを設定することは開発コストが高く、対応するブラウザや支援技術もまだ少ないため、「レベルAAA」に設定されています。まずは 1.3.1（情報と関係性）や 1.3.5（入力目的の特定）を満たすことが優先ですが、記憶や学習にハードルがある利用者が多いポータルサイトや学習アプリなどにおいては、この対応が利用者の自立した操作を支えます。
• 1.3.5（入力目的の特定）との違い： レベルAAの 1.3.5 は「フォームの入力欄（名前や住所など）」に対してブラウザの自動入力（オートコンプリート）を効かせるための基準でした。一方、この 1.3.6 はフォームに限らず、「リンク、ボタン、アイコン、画面のブロック」など、ページを構成するあらゆる要素の役割をプログラムに伝え、画面デザインのパーソナライズ（個別最適化）を可能にする、より広範で高度な基準です。

参考リンク

解説書 達成基準 1.3.6: 目的の特定

目次へ戻る