Webコンテンツのわかりやすさは、文章だけでなく、情報の順序、操作の一貫性、入力後の案内まで含めて決まります。
認知特性や発達特性によって、注意を保つこと、手順を覚えること、抽象的な表現を理解することに難しさを感じる人もいますが、困り方や必要な支援は一人ひとり異なります。
このガイドでは、利用者を一括りにせず、ページの目的を理解して次の行動を選びやすくするための設計を、制作と運用の両面から整理します。
認知アクセシビリティとは
認知アクセシビリティとは、情報を見つけ、理解し、覚え、判断し、操作を完了するまでの負担を減らす考え方です。
対象は文章表現に限らず、画面構成、ナビゲーション、ボタン名、フォーム、通知、ヘルプにも及びます。
同じ診断名や特性名が付いていても、読みやすい表現や使いやすい操作は同じとは限りません。
想定だけで設計を確定せず、可能な範囲で当事者を調査、設計、利用テストに含めることが、実際の困りごとを見つける近道です。
| 利用時のつまずき | 確認する設計 | 改善例 |
|---|---|---|
| 目的がつかめない | ページ冒頭と見出し | 誰が何をできるページかを最初に示す |
| 次の操作がわからない | ボタン名と配置 | 「次へ」ではなく「入力内容を確認する」と書く |
| 手順を覚えきれない | 工程の分け方 | 一画面の主要な行動を絞り、現在地を示す |
| エラーを直せない | エラー通知 | 場所、原因、直し方を項目の近くに示す |
ページの目的と主要な行動を先に示す
ページを開いた直後に、扱う内容と利用者ができることを短く示します。
申し込みが目的なら、関連情報を同じ強さで並べず、申し込みに必要な説明と操作を中心に置きます。
補足資料や関連サービスは、主要な手順の途中へ割り込ませず、必要な人が後から参照できる位置に分けます。
見出しと情報の順序
見出しは内容を予測できる具体的な句にし、見た目の大きさではなくHTMLの階層で関係を示します。
本文では、結論、理由、具体例の順に置くと、前の段落を覚えたまま読み進める負担を抑えられます。
段落の行数や項目数を一律に制限するのではなく、一つの段落には一つの話題を置き、情報が多い場合は意味のまとまりで分けます。
一貫したナビゲーション
同じ役割のメニュー、検索、ヘルプは、ページが変わっても名前と働きをそろえます。
レスポンシブ表示で位置が変わる場合も、ラベル、並び順、操作後の結果をできるだけ一貫させます。
パンくずリストは現在地と上位階層を短く伝える手段になります。
<nav aria-label="パンくずリスト">
<ol>
<li><a href="/">ホーム</a></li>
<li><a href="/guide/">ガイド一覧</a></li>
<li aria-current="page">コンテンツ設計</li>
</ol>
</nav>文章を短くする前に意味を明確にする
読みやすい文章は、文字数だけで決まりません。
一文に一つの要点を置き、専門用語は初出で説明し、比喩や慣用句よりも具体的な動詞を選びます。
操作説明では、行為、対象、操作後の結果が読み取れるようにします。
改善前：「必要事項を入力し、適宜確認したうえで進んでください。」
改善後：「氏名とメールアドレスを入力し、『入力内容を確認する』を押してください。確認画面では、送信前に内容を修正できます。」
手順に順番があるときは番号付きリストを使い、順番がない選択肢や特徴は箇条書きにします。
すべてをリストに変えると文脈が失われるため、理由や条件は段落で補います。
文章編集の具体例は、同サイトの見出し、要約、やさしい日本語を整える方法でも確認できます。
画像とアイコンは本文を補う役割にする
図解やスクリーンショットは、文章だけでは把握しにくい位置関係や手順を示す場合に役立ちます。
図中の番号と本文の番号を対応させ、どこを見ればよいかを本文でも説明します。
意味のある画像には目的に合う代替テキストを付け、装飾画像は支援技術が読み飛ばせるようにします。
アイコンだけで状態や操作を伝えず、「保存」「削除」「警告」のようなテキストを添えます。
色だけに意味を持たせず、文字、形、配置など別の手がかりも組み合わせます。
操作の結果を予測できるようにする
ボタン名は「こちら」「次へ」だけで済ませず、押した後に何が起こるかを表します。
入力中に別ページへ移動したり、新しい画面を突然開いたりする設計は避け、変更が必要なら事前に説明します。
自動で切り替わる表示や時間制限がある操作には、停止、延長、再開など、内容に応じた制御手段を用意します。
キーボードで操作したときのフォーカスは見える状態にし、表示中の要素に隠れないかも確認します。
リンクやボタンの大きさと間隔は、WCAG 2.2のターゲットサイズに関する達成基準を参照し、重要な操作には余裕のある領域を確保します。
フォームでは入力前とエラー後の迷いを減らす
フォームの支援は、送信後のエラー表示だけでは足りません。
入力前に項目名、必須か任意か、求める形式、入力例を示し、利用者が間違いを避けやすくします。
エラーが起きたら、画面上部の一覧で全体を知らせるだけでなく、該当項目の近くにも原因と修正方法を表示します。
「入力に誤りがあります」ではなく、「メールアドレスに@を含めてください」のように、次の行動がわかる文にします。
<label for="email">メールアドレス</label>
<input id="email" type="email" aria-invalid="true" aria-describedby="email-error">
<p id="email-error">メールアドレスに@を含めてください。</p>この例は関連付けの基本だけを示しているため、実装時にはフォーカス移動、通知のタイミング、再入力後の状態も確認します。
詳しい設計と確認方法は、同サイトのフォームの入力支援とエラー設計で解説しています。
よくある質問は単純な構造から始める
回答を開閉する必要がなければ、見出しと本文をそのまま並べる方法が最も単純です。
開閉が必要な場合は、独自の操作を増やす前に、標準のHTML要素で表現できるかを検討します。
<details>
<summary>購入の手順を教えてください</summary>
<p>商品ページで「カートに入れる」を押し、配送先と支払い方法を入力してください。</p>
</details>実装後は、キーボードだけで開閉できるか、フォーカスが見えるか、開閉状態を支援技術が認識できるかを実際の環境で確認します。
WCAG 2.2と補足指針を使い分ける
WCAG 2.2は、Webアクセシビリティを評価するための検証可能な達成基準を示しています。
W3Cは新規開発や更新でWCAG 2.2を使うよう勧めていますが、最高レベルの達成だけで、認知、言語、学習に関するすべてのニーズを満たせるわけではありません。
認知面の使いやすさを検討するときは、W3Cの補足文書「Making Content Usable for People with Cognitive and Learning Disabilities」も参照できます。
この補足文書はWCAG適合の必須条件ではなく、明確な言葉、予測できる操作、利用者を設計とテストに含める方法などを補います。
WCAGの版ごとの違いは、同サイトのWCAG 2.2の変更点を実務で読む解説も参考になります。
公開前と運用中のチェックリスト
- ページ冒頭だけで目的と主要な行動がわかるか。
- 見出しだけを読んでも情報の順序を追えるか。
- 専門用語、略語、比喩に説明があるか。
- 同じ役割の操作に同じ名前を使っているか。
- ボタン名から操作後の結果を予測できるか。
- 色やアイコンだけで意味を伝えていないか。
- 時間制限や自動更新を停止または調整できるか。
- エラーの場所、原因、直し方がわかるか。
- キーボード操作時の順序とフォーカス表示に問題がないか。
- 利用者テストで見つかった困りごとを次の改善に反映しているか。
設計ルールを利用者の行動で確かめる
認知特性や発達特性への配慮は、短文や大きなボタンといった個別の形式をそろえるだけでは完了しません。
利用者が目的を理解し、迷ったときに戻り、間違いを直し、自分のペースで操作を終えられるかを、ページ全体の流れで確かめます。
基準の確認、目視と操作による検証、利用者からのフィードバックを組み合わせ、公開後も改善を続けることが現実的な進め方です。
この記事に関連する株式会社greedenの取り組み
情報の順序や表現を整えても、実際の使いにくさは継続的な確認で見つかります。株式会社greedenは、Webアクセシビリティサービス「UUU」とチェックサービスを通じ、読みやすく操作しやすいWebサイトづくりを支援しています。