HTMLとWCAGの関係｜アクセシビリティを支える正しいマークアップを解説

2026年05月16日

HTMLとWCAGは、Webアクセシビリティを考えるうえで非常に深い関係があります。HTMLはWebページの構造や意味を表すための言語であり、WCAGはそのWebページが多様なユーザーにとって利用しやすいかを確認するための基準です。つまり、HTMLはアクセシビリティの土台を作り、WCAGはその品質を確認するための観点を与えるものだと考えると分かりやすくなります。

Webページは、見た目がきれいであれば十分というわけではありません。視覚的にはボタンに見えていても、HTML上では単なるdivになっている場合、キーボードで操作できなかったり、スクリーンリーダーで正しく読み上げられなかったりします。見出しのように見えるテキストも、実際にはh1やh2ではなく装飾されたspanで作られていると、ページ構造が支援技術へ伝わりにくくなります。

現代のWeb制作では、UIデザイン、UX設計、SEO、アクセシビリティ、実装品質が切り離せなくなっています。正しいHTMLを使うことは、検索エンジンやブラウザだけでなく、スクリーンリーダー、キーボード操作、音声操作、支援技術にも情報を伝えることにつながります。WCAGに対応するためには、表面的な見た目だけではなく、HTMLの意味構造から丁寧に設計することが重要です。

1. HTMLとWCAGの関係とは？

HTMLとWCAGの関係は、構造と評価基準の関係として理解できます。HTMLは、見出し、段落、リンク、ボタン、フォーム、画像、リスト、表、ナビゲーションなどの意味をブラウザや支援技術へ伝える役割を持ちます。一方、WCAGは、その構造や操作が多様なユーザーにとって知覚可能・操作可能・理解可能・堅牢であるかを確認するための考え方を提供します。

たとえば、フォームの入力欄にlabelが正しく関連付いていれば、スクリーンリーダーはその入力欄が何を入力する場所なのかを読み上げやすくなります。ボタンをbutton要素で作れば、キーボード操作や支援技術でボタンとして扱いやすくなります。このように、HTMLを正しく使うことは、WCAGに対応するための実装面の基本になります。

主な関係

項目内容
構造HTMLが情報構造を表す
基準WCAGが確認観点を示す
支援技術スクリーンリーダーなどへ影響する
操作性キーボード操作へ関係する
理解性情報の分かりやすさへ影響する

図：HTMLとWCAGの関係

HTML  ↓ ページ構造・意味・操作要素を作る  ↓ 支援技術やブラウザが解釈する  ↓ WCAG  ↓ 利用しやすい状態かを確認する

1.1 HTMLはアクセシビリティの土台になる

HTMLは、Webアクセシビリティの土台になります。なぜなら、ユーザーが画面上で見ている要素の多くは、HTMLによって意味づけされているからです。見出しは見出しとして、ボタンはボタンとして、入力欄は入力欄として、ナビゲーションはナビゲーションとしてマークアップすることで、ブラウザや支援技術がページ内容を理解しやすくなります。

もしHTMLの意味構造が崩れていると、見た目は整っていてもアクセシビリティ上の問題が起きやすくなります。たとえば、クリックできる見た目のdivをボタン代わりに使うと、キーボード操作や読み上げで問題が出ることがあります。HTMLを正しく使うだけで、多くのアクセシビリティ問題を未然に防ぐことができます。

1.2 WCAGは利用しやすさを確認する基準になる

WCAGは、Webページが多様なユーザーにとって利用しやすいかを確認するための基準になります。HTMLが正しくても、文字のコントラストが弱い、キーボード操作が不自然、エラー説明が分かりにくい、状態変化が伝わらないといった問題が残る場合があります。そのため、HTMLだけでなくWCAGの観点で総合的に確認することが重要です。

WCAGでは、情報を知覚できるか、操作できるか、理解できるか、多様な環境で利用できるかが重要になります。HTMLはこの中でも、特に構造、操作、支援技術との連携に大きく関係します。正しいHTMLとWCAGの観点を組み合わせることで、見た目だけでなく実際に使いやすいWebページを作りやすくなります。

1.3 見た目だけでは準拠できない

WCAGに対応するには、見た目だけでは不十分です。ボタンらしい見た目、見出しらしい文字サイズ、カードらしいレイアウトを作っても、HTML上で意味が正しく表現されていなければ、支援技術やキーボード操作で問題が発生する可能性があります。

特に、CSSやJavaScriptで複雑なUIを作る場合は注意が必要です。タブ、モーダル、アコーディオン、ドロップダウン、カスタムセレクトなどは、見た目だけでなく、フォーカス管理、キーボード操作、ARIA属性、状態変化の伝達まで考える必要があります。HTMLとWCAGの関係を理解することは、アクセシブルなUI実装の基本になります。

2. セマンティックHTMLとの関係

セマンティックHTMLとは、要素の意味に合ったHTMLタグを使ってマークアップする考え方です。たとえば、見出しにはh1〜h6、段落にはp、リンクにはa、ボタンにはbutton、ナビゲーションにはnav、主要コンテンツにはmainを使います。意味のあるタグを使うことで、人間だけでなくブラウザや支援技術にもページ構造を伝えやすくなります。

WCAG対応では、セマンティックHTMLが非常に重要です。なぜなら、正しいHTML構造は、スクリーンリーダーの読み上げ、キーボード操作、ページ内移動、フォーム理解、検索エンジンの解釈にも影響するからです。見た目をCSSだけで整えるのではなく、HTMLそのものが意味を持つように設計する必要があります。

2.1 意味のあるタグを使う

セマンティックHTMLでは、意味のあるタグを使うことが重要です。クリックできる要素ならbuttonやaを使い、単なる装飾ではなく情報のまとまりならsectionやarticleを使い、ページの主要領域にはmainを使います。これにより、ブラウザや支援技術が要素の役割を理解しやすくなります。

使用言語

HTML

ファイル名

semantic-layout.html

<header>  <h1>サービス紹介</h1> </header> <nav aria-label="メインナビゲーション">  <ul>    <li><a href="/about">会社情報</a></li>    <li><a href="/service">サービス</a></li>    <li><a href="/contact">お問い合わせ</a></li>  </ul> </nav> <main>  <section>    <h2>サービスの特徴</h2>    <p>業務改善とシステム開発を組み合わせて支援します。</p>  </section> </main>

このように、ページの役割ごとに適切なタグを使うと、見た目だけでなく構造としても理解しやすいHTMLになります。

2.2 構造を機械にも伝える

HTMLは、人間に見せるためだけではなく、機械にも構造を伝える役割を持ちます。スクリーンリーダー、検索エンジン、ブラウザ、音声操作、翻訳機能などは、HTML構造をもとにページを解釈します。意味のないdivやspanだけで構成されたページは、見た目は整っていても、構造が伝わりにくくなります。

構造を機械に伝えることで、ユーザーは見出しジャンプ、ランドマーク移動、フォーム項目の読み上げ、リンク一覧の確認などを行いやすくなります。これは、WCAGの堅牢性や理解可能性にも関係します。

2.3 支援技術で理解しやすくする

セマンティックHTMLは、支援技術でページを理解しやすくします。スクリーンリーダーを使うユーザーは、視覚的なデザインではなく、HTML構造や要素の役割を手がかりにページを読み進めます。見出し、リスト、リンク、フォーム、ボタンが正しくマークアップされていると、ページ全体を把握しやすくなります。

逆に、すべてをdivで作ってしまうと、支援技術にとって要素の意味が分かりにくくなります。必要に応じてARIAを使う場合もありますが、まずは標準HTMLで表現できるものは標準HTMLを使うことが基本です。

3. 見出し構造との関係

見出し構造は、HTMLとWCAGの関係で非常に重要な要素です。h1からh6までの見出しは、ページの情報階層を表します。視覚的には文字サイズや太さで見出しらしく見せることができますが、HTMLとして正しい見出しタグを使わなければ、支援技術には構造が伝わりにくくなります。

見出し構造が整理されていると、ユーザーはページ全体の内容を把握しやすくなります。スクリーンリーダー利用者は見出し単位でページを移動することもあります。そのため、見出しは単なる装飾ではなく、ページ理解を支えるナビゲーションの役割も持ちます。

3.1 h1からh6を適切に使う

見出しは、h1からh6までをページ構造に合わせて使います。h1はページ全体の主題、h2は主要セクション、h3はその中の小見出しというように、階層を意識して設計します。文字サイズを大きくしたいからh1を使う、見た目を小さくしたいからh5を使うという選び方は避けるべきです。

3.2 ページ構造を整理する

見出し構造を整理すると、ページ全体の情報が理解しやすくなります。長いページでも、見出しが適切に配置されていれば、ユーザーは必要な情報へ移動しやすくなります。これはSEOにも関係しますが、アクセシビリティの観点でも重要です。

見出しを使わずに太字や大きな文字だけで章を表現すると、視覚的には見出しに見えても、支援技術には見出しとして伝わりません。ページの意味構造をHTMLで表すことが、WCAG対応の基本になります。

3.3 読み上げ順序へ影響する

見出し構造は、スクリーンリーダーの読み上げやページ移動に影響します。見出しが適切に設定されていれば、ユーザーは見出し一覧から目的のセクションへ移動できます。これは、長い記事、FAQ、管理画面、ヘルプページなどで特に重要です。

不自然な見出し階層や、見出しの飛びすぎは、ページ構造の理解を妨げます。視覚的なデザインとHTMLの見出し構造を一致させることで、より理解しやすいページになります。

4. 画像と代替テキスト

画像と代替テキストは、HTMLとWCAGの関係で代表的なテーマです。画像は視覚的に情報を伝える強力な要素ですが、画像が表示されない場合や、スクリーンリーダー利用者には内容がそのまま伝わりません。そのため、意味を持つ画像にはalt属性で代替テキストを設定する必要があります。

ただし、すべての画像に長い説明を入れればよいわけではありません。装飾目的の画像には空のaltを設定し、情報を持つ画像には内容を適切に説明します。画像の役割に応じて代替テキストを設計することが重要です。

4.1 alt属性を適切に設定する

alt属性は、画像の代替情報を伝えるために使います。商品画像、図解、アイコン、バナーなど、画像に意味がある場合は、その意味が分かる説明を入れます。代替テキストは、画像の見た目を細かく説明するだけでなく、その画像がページ内で果たしている役割を伝えることが重要です。

使用言語

HTML

ファイル名

image-alt.html

<img  src="/images/service-flow.png"  alt="お問い合わせから導入までの流れを示す図" />

この例では、画像が「何を示す図なのか」を簡潔に説明しています。画像の意味がユーザーに伝わることが大切です。

4.2 装飾画像は空altにする

装飾目的の画像は、空のaltを設定します。たとえば、背景装飾、区切り線、意味を持たないアイコンなどは、読み上げられると逆にノイズになる場合があります。そのため、装飾画像にはalt=""を使い、支援技術で読み飛ばせるようにします。

使用言語

HTML

ファイル名

decorative-image.html

<img src="/images/bg-decoration.svg" alt="">

装飾画像に不要な説明を入れると、ユーザーにとって情報量が増えすぎます。意味のある画像と装飾画像を区別することが重要です。

4.3 情報画像は内容を説明する

図表やグラフ、手順画像など、情報を持つ画像には内容を説明する必要があります。単に「グラフ画像」と書くだけでは、ユーザーは何を理解すればよいのか分かりません。図の要点や、必要な場合は本文で補足説明を用意します。

複雑な図の場合、altだけですべてを説明しようとすると長くなりすぎます。その場合は、画像の近くにテキスト説明を置き、altでは概要を伝える方法が適しています。HTMLと本文構造を組み合わせて、情報が失われないように設計することが大切です。

5. フォームとラベル

フォームは、HTMLとWCAGの関係が特に強く表れる部分です。問い合わせ、登録、購入、予約、ログイン、検索、申請など、フォームはユーザーの行動完了に直結します。フォームが分かりにくい、入力欄の意味が伝わらない、エラーが理解できない場合、ユーザーは目的を達成できません。

フォームでは、label要素、入力目的、エラー説明、必須表示、補足説明、フォーカス、入力状態などを適切に設計する必要があります。HTMLを正しく使うことで、支援技術にも入力欄の意味を伝えやすくなり、WCAG対応にもつながります。

5.1 label要素を使う

入力欄には、対応するlabel要素を使うことが基本です。labelとinputを関連付けることで、スクリーンリーダーが入力欄の意味を読み上げやすくなり、ラベルをクリックして入力欄へフォーカスすることもできます。

使用言語

HTML

ファイル名

form-label.html

<label for="email">メールアドレス</label> <input id="email" name="email" type="email">

このように、for属性とidを対応させることで、ラベルと入力欄の関係が明確になります。

5.2 入力目的を明確にする

フォームでは、何を入力する欄なのかを明確にする必要があります。ラベルが曖昧だったり、プレースホルダーだけで説明していたりすると、入力中に説明が消えて分かりにくくなる場合があります。プレースホルダーは補助情報として使い、ラベルは常に見える形で用意することが望ましいです。

たとえば、「名前」だけではなく、「お名前」「会社名」「担当者名」のように、入力目的に合わせて具体的に示すと分かりやすくなります。フォームの分かりやすさは、理解可能性と操作可能性の両方に関係します。

5.3 エラー説明と関連付ける

エラーが発生した場合は、どの入力欄に問題があり、どう修正すればよいのかを示す必要があります。HTMLでは、aria-describedbyを使って、入力欄と補足説明やエラーメッセージを関連付けることができます。

使用言語

HTML

ファイル名

form-error.html

<label for="email">メールアドレス</label> <input  id="email"  name="email"  type="email"  aria-describedby="email-error"  aria-invalid="true" > <p id="email-error">  メールアドレスの形式を確認してください。 </p>

このように、入力欄とエラー説明を関連付けることで、支援技術でもエラー内容を理解しやすくなります。エラー表示は色だけに頼らず、テキストで原因と修正方法を伝えることが重要です。

6. ボタンとリンクの正しい使い分け

ボタンとリンクは、HTML実装で混同されやすい要素です。リンクは別ページや別位置へ移動するための要素であり、ボタンは送信、開閉、保存、削除などのアクションを実行するための要素です。見た目だけで選ぶのではなく、役割に応じてaとbuttonを使い分けることが重要です。

WCAGの観点では、ユーザーが操作要素の役割を理解できること、キーボードで操作できること、支援技術で意味が伝わることが大切です。divやspanにクリックイベントを付けてボタンのように使う実装は、アクセシビリティ上の問題を起こしやすくなります。

6.1 ページ移動はa要素を使う

ページ移動や外部リンク、ページ内アンカーにはa要素を使います。hrefがあることで、ブラウザや支援技術はリンクとして認識できます。リンクはキーボードでフォーカスでき、Enterキーで開くことができます。

使用言語

HTML

ファイル名

link-example.html

<a href="/contact">お問い合わせページへ移動する</a>

リンクの文言は、「こちら」だけではなく、移動先が分かる表現にすると理解しやすくなります。

6.2 操作実行はbutton要素を使う

送信、保存、削除、開閉、モーダル表示など、ページ内でアクションを起こす場合はbutton要素を使います。buttonは標準でキーボード操作に対応しており、支援技術にもボタンとして伝わります。

使用言語

HTML

ファイル名

button-example.html

<button type="button">  メニューを開く </button>

見た目をCSSで自由に調整することはできますが、要素の意味はbuttonとして保つことが重要です。

6.3 divボタンを避ける

divやspanにクリックイベントを付けてボタンのように使う実装は避けるべきです。標準ではフォーカスできず、キーボード操作にも対応していないため、追加実装が必要になります。結果として、アクセシビリティの抜け漏れが起きやすくなります。

どうしてもカスタム要素を使う場合は、role、tabindex、キーボードイベント、状態管理などを適切に追加する必要があります。しかし、多くの場合は標準のbuttonを使うほうが安全で分かりやすいです。

7. ランドマーク要素との関係

ランドマーク要素とは、ページ内の大きな領域を示すHTML要素です。header、nav、main、aside、footerなどが代表例です。これらを適切に使うことで、ページの構造が分かりやすくなり、支援技術を使うユーザーが目的の領域へ移動しやすくなります。

WCAGの観点では、ページ構造が理解しやすいこと、ナビゲーションしやすいことが重要です。ランドマーク要素は、視覚的なレイアウトだけでなく、意味構造としてページを整理する役割を持ちます。

7.1 header・main・footerを整理する

headerはページやセクションのヘッダー、mainはページの主要コンテンツ、footerはフッター情報を示します。これらを正しく使うことで、ページの大きな構造が分かりやすくなります。

使用言語

HTML

ファイル名

landmark-layout.html

<header>  <p>サイトロゴ</p> </header> <main>  <h1>HTMLとWCAGの関係</h1>  <p>アクセシビリティを支えるマークアップを解説します。</p> </main> <footer>  <p>© Example Company</p> </footer>

mainはページの中心となる内容を示すため、基本的には1ページに1つの主要なmainを置く設計が分かりやすくなります。

7.2 navでナビゲーションを示す

ナビゲーションにはnav要素を使います。グローバルナビゲーション、パンくず、ページ内メニューなど、主要な移動導線を示すときに有効です。複数のnavがある場合は、aria-labelで役割を補足すると分かりやすくなります。

使用言語

HTML

ファイル名

nav-example.html

<nav aria-label="パンくずリスト">  <ol>    <li><a href="/">ホーム</a></li>    <li><a href="/accessibility">アクセシビリティ</a></li>    <li>HTMLとWCAGの関係</li>  </ol> </nav>

ナビゲーションの役割が明確だと、ユーザーはページ内やサイト内を移動しやすくなります。

7.3 支援技術のページ移動を助ける

ランドマーク要素は、支援技術のページ移動を助けます。スクリーンリーダー利用者は、ページを上から順番にすべて読むだけではなく、見出しやランドマークを使って目的の領域へ移動することがあります。

ページ構造が整理されていれば、主要コンテンツ、ナビゲーション、補足情報、フッターへ移動しやすくなります。これは操作可能性と理解可能性の両方に関係します。

8. キーボード操作との関係

WCAGでは、キーボード操作が重要な確認項目になります。マウスを使えないユーザーや、キーボードで操作するほうが効率的なユーザーにとって、すべての重要操作がキーボードで行えることは基本です。HTMLを正しく使うことで、多くのキーボード操作は標準で対応できます。

たとえば、aやbutton、inputは標準でフォーカス可能です。一方、divやspanは標準ではフォーカスできません。カスタムUIを作る場合は、キーボード操作を意識した実装が必要になります。

8.1 Tabキーで移動できる

キーボード操作では、Tabキーで操作可能な要素へ移動できることが重要です。リンク、ボタン、入力欄、セレクトボックスなどを自然な順序で移動できるようにします。フォーカス順序が視覚的な順序と大きくずれていると、ユーザーは混乱します。

tabindexを多用して無理に順序を調整するより、HTMLの並びを自然な構造にすることが基本です。視覚的なレイアウトとHTML構造が大きく違う場合は、キーボード操作で不自然な動きになりやすくなります。

8.2 フォーカス表示を消さない

フォーカス表示は、現在どの要素が選択されているかを示す重要な情報です。デザイン上の理由でoutline: none;だけを指定してフォーカス表示を消してしまうと、キーボード利用者は現在位置を見失います。

フォーカス表示をカスタマイズすることは問題ありませんが、見やすい代替表示を用意する必要があります。フォーカスは操作中の視線誘導でもあり、WCAGの操作可能性に深く関係します。

8.3 カスタムUIは特に注意する

タブ、アコーディオン、モーダル、ドロップダウン、カルーセルなどのカスタムUIでは、キーボード操作が抜けやすくなります。クリックでは動くがEnterキーでは動かない、Escキーで閉じられない、フォーカスがモーダル外へ移動してしまうといった問題が起きやすくなります。

カスタムUIを実装する場合は、見た目だけでなく、フォーカス管理、キーボードイベント、状態の伝達、読み上げ情報まで確認する必要があります。HTMLだけで表現できる場合は、標準要素を優先することが安全です。

9. ARIAとの関係

ARIAは、HTMLだけでは伝えきれない役割や状態を支援技術へ補足するための仕組みです。たとえば、タブUI、モーダル、開閉メニュー、ライブ更新などでは、ARIA属性を使って状態や役割を補うことがあります。ただし、ARIAは正しく使わないと逆に混乱を招く場合があります。

基本は、まずセマンティックHTMLを使うことです。標準HTMLで表現できるものを無理にARIAで置き換える必要はありません。ARIAは、標準HTMLだけでは不足する場合に補助として使うものです。

9.1 ARIAは補助的に使う

ARIAは、HTMLの意味を補助するために使います。たとえば、開閉ボタンにはaria-expandedを使って、現在開いているか閉じているかを伝えることができます。これにより、視覚的な状態だけでなく、支援技術にも状態が伝わりやすくなります。

使用言語

HTML

ファイル名

aria-expanded.html

<button  type="button"  aria-expanded="false"  aria-controls="menu-list" >  メニューを開く </button> <ul id="menu-list" hidden>  <li><a href="/service">サービス</a></li>  <li><a href="/contact">お問い合わせ</a></li> </ul>

開閉状態が変わる場合は、JavaScriptでaria-expandedの値も更新する必要があります。

9.2 標準HTMLを優先する

ARIAを使う前に、標準HTMLで表現できないかを確認することが重要です。ボタンならbutton、リンクならa、入力欄ならinputやtextarea、見出しならh1〜h6を使います。標準要素には、キーボード操作や支援技術対応が最初から備わっていることが多いためです。

たとえば、div role="button"を使うより、buttonを使うほうが安全です。ARIAで役割を付けても、キーボード操作やフォーカス管理まで自動で完全に補われるわけではありません。

9.3 状態変化を伝える

動的なUIでは、状態変化を支援技術へ伝える必要があります。メニューが開いた、タブが選択された、エラーが表示された、読み込みが完了したなど、視覚的には分かる変化でも、支援技術には伝わらない場合があります。

ARIAを使うことで、状態や関係性を補足できます。ただし、属性を付けるだけでなく、実際の状態とARIAの値が一致していることが重要です。表示は閉じているのにaria-expanded="true"のままになっていると、ユーザーに誤った情報を伝えてしまいます。

10. テーブルとリストの正しいマークアップ

テーブルとリストも、HTMLとWCAGの関係で重要な要素です。情報の見た目を整えるためだけにテーブルを使ったり、箇条書きに見える内容をdivだけで作ったりすると、構造が伝わりにくくなります。情報の種類に合わせて、適切なHTMLを選ぶことが重要です。

表形式のデータにはtable、順序のあるリストにはol、順序のないリストにはulを使います。HTMLの意味に合ったタグを使うことで、支援技術でも情報の関係性を理解しやすくなります。

10.1 表データにはtableを使う

比較表や数値表のように、行と列の関係が重要な情報にはtableを使います。見出しセルにはthを使い、表の意味が分かるようにします。

使用言語

HTML

ファイル名

accessible-table.html

<table>  <caption>WCAG適合レベルの比較</caption>  <thead>    <tr>      <th scope="col">レベル</th>      <th scope="col">内容</th>    </tr>  </thead>  <tbody>    <tr>      <th scope="row">A</th>      <td>最低限の基準</td>    </tr>    <tr>      <th scope="row">AA</th>      <td>実務で採用されやすい基準</td>    </tr>  </tbody> </table>

captionやthを使うことで、表の意味や行列の関係が伝わりやすくなります。

10.2 箇条書きにはulやolを使う

箇条書きにはulやolを使います。単に改行したテキストやdivを並べるだけでは、支援技術にリストとして伝わりません。リスト構造を使うことで、項目数や関係性が理解しやすくなります。

順序が重要な手順にはol、順序が重要でない項目一覧にはulを使います。見た目はCSSで調整できますが、HTMLの構造は意味に合わせることが大切です。

10.3 レイアウト目的のtableを避ける

テーブルをレイアウト目的で使うのは避けるべきです。テーブルは行と列の関係を持つデータを表すための要素です。レイアウト目的で使うと、支援技術が表として解釈し、ユーザーに不要な情報構造を伝えてしまう場合があります。

レイアウトにはCSS GridやFlexboxを使い、表データにはtableを使うという役割分担が重要です。HTMLは意味を表し、CSSは見た目を整えるという基本を守ることで、アクセシビリティ品質を保ちやすくなります。

11. エラー表示と状態表示

エラー表示と状態表示は、WCAGの理解可能性に大きく関係します。ユーザーが操作した結果、何が起きたのか分からなければ、不安やミスにつながります。フォーム送信、ログイン、保存、削除、読み込み、入力エラーなどでは、状態を明確に伝えることが重要です。

HTMLでは、エラー文言と入力欄を関連付けたり、aria-liveを使って動的なメッセージを伝えたりすることができます。視覚的な表示だけでなく、支援技術にも状態が伝わるように設計する必要があります。

11.1 エラー原因を明確にする

エラー表示では、何が問題なのかを明確に伝える必要があります。「エラーが発生しました」だけでは、ユーザーは何を修正すればよいか分かりません。入力形式、必須項目、文字数、選択漏れなど、原因を具体的に示します。

エラーは、入力欄の近くに表示すると理解しやすくなります。色だけでなく、テキストでも明示することが重要です。色の違いだけに依存すると、情報が伝わらないユーザーが出る可能性があります。

11.2 aria-liveで動的な変化を伝える

非同期処理やフォーム送信後のメッセージなど、画面内で動的に表示される情報は、支援技術に伝わらない場合があります。そのような場合、aria-liveを使って更新内容を通知できます。

使用言語

HTML

ファイル名

status-message.html

<div role="status" aria-live="polite">  保存しました。 </div>

ただし、すべての変化を通知すると情報量が多くなりすぎます。重要な状態変化だけを適切に伝えることが大切です。

11.3 成功・失敗・読み込み中を分ける

状態表示では、成功、失敗、読み込み中を分けて表示することが重要です。ユーザーがボタンを押したあと、処理中なのか、完了したのか、失敗したのかが分からないと不安になります。

「送信中です」「送信しました」「送信に失敗しました。もう一度お試しください」のように、状態ごとに文言を分けると分かりやすくなります。状態表示は、HTML構造、ARIA、UI文言、視覚デザインを組み合わせて設計する必要があります。

12. JavaScript UIとWCAG

現代のWebサイトやアプリでは、JavaScriptによって動的なUIを作ることが多くなっています。モーダル、タブ、アコーディオン、ドロップダウン、トースト通知、ライブ検索、無限スクロールなどは、便利な一方でアクセシビリティ上の問題を起こしやすい要素でもあります。

JavaScript UIでは、見た目の変化だけでなく、HTML構造、フォーカス管理、キーボード操作、ARIA属性、状態通知を合わせて設計する必要があります。画面上では動いていても、支援技術に状態が伝わらない場合、ユーザーは操作状況を理解できません。

12.1 モーダルはフォーカス管理が重要

モーダルを開いたときは、フォーカスをモーダル内へ移動し、モーダル内で操作できるようにします。モーダルの背後にある要素へフォーカスが移動してしまうと、ユーザーは現在どこを操作しているのか分かりにくくなります。

また、モーダルはEscキーで閉じられるようにする、閉じるボタンを明確にする、モーダルを閉じた後は元の操作位置へフォーカスを戻すなどの配慮が必要です。これは操作可能性と理解可能性の両方に関係します。

12.2 タブUIは選択状態を伝える

タブUIでは、どのタブが選択されているのかを視覚的にも支援技術にも伝える必要があります。見た目だけで選択状態を示すのではなく、適切なHTML構造やARIA属性を使って状態を補足します。

タブはキーボード操作も重要です。左右キーやTabキーで自然に移動できるようにし、選択中のタブと対応するパネルの関係を明確にします。単にクリックで表示を切り替えるだけでは不十分です。

12.3 非同期更新は状態通知を考える

API通信や非同期処理によって画面が更新される場合、ユーザーに状態を伝える必要があります。検索結果が更新された、保存が完了した、エラーが発生した、読み込み中であるといった情報は、視覚的にも支援技術にも伝えることが重要です。

状態通知がないと、ユーザーは操作が成功したのか分かりません。特にWebアプリでは非同期処理が多いため、HTMLとARIAを使って状態を適切に伝える設計が重要になります。

13. UI/UX設計との関係

HTMLとWCAGは、UI/UX設計にも大きく関係します。正しいHTMLは支援技術やブラウザに意味を伝え、WCAGは多様なユーザーが使いやすいかを確認します。この2つを組み合わせることで、見た目だけではなく、実際に使えるUIを作りやすくなります。

UI/UX設計では、視覚階層、余白、色、ボタン、フォーム、状態表示、エラー文言、ナビゲーションなどを考えます。これらはすべてHTML構造と関係します。デザイン段階からHTMLとWCAGを意識することで、実装時の手戻りを減らし、アクセシビリティ品質を保ちやすくなります。

13.1 視覚階層とHTML構造を一致させる

視覚階層とHTML構造は、できるだけ一致させることが重要です。見た目では大見出しに見えるものがHTMLでは普通のdivになっていると、支援技術には見出しとして伝わりません。視覚的な重要度とHTML上の意味がずれていると、ページ理解が難しくなります。

デザイン上の階層を、HTMLの見出し、セクション、リスト、テーブルなどへ適切に落とし込むことで、視覚ユーザーにも支援技術ユーザーにも分かりやすいページになります。

13.2 コンポーネント設計に組み込む

アクセシビリティは、個別ページごとに対応するより、コンポーネント設計に組み込むほうが効果的です。ボタン、フォーム、カード、モーダル、タブ、ナビゲーションなどをアクセシブルに作っておけば、再利用時にも品質を維持しやすくなります。

コンポーネント設計では、HTML構造、キーボード操作、ARIA、状態表示、エラー表示をセットで定義することが重要です。デザインシステムにアクセシビリティルールを含めることで、チーム全体で品質を揃えやすくなります。

13.3 ユーザーの迷いを減らす

HTMLとWCAGを意識したUIは、ユーザーの迷いを減らします。見出し構造が整理され、フォームラベルが明確で、ボタンの役割が分かり、状態表示が適切であれば、ユーザーは次に何をすればよいか判断しやすくなります。

アクセシビリティ対応は、特定のユーザーだけに向けた対応ではありません。分かりやすく、操作しやすく、状態が明確なUIは、すべてのユーザーにとって使いやすい体験につながります。

14. 実装で起きやすい問題

HTMLとWCAGの関係を理解していないと、実装段階でさまざまな問題が起きます。見た目を優先しすぎて意味構造が崩れる、divでボタンを作る、見出しを装飾だけで表現する、フォームラベルを省略する、フォーカス表示を消すなどはよくある問題です。

これらの問題は、見た目だけでは気づきにくい場合があります。ブラウザ上では普通に使えているように見えても、キーボード操作やスクリーンリーダーで確認すると、利用しにくい状態になっていることがあります。

14.1 divやspanに頼りすぎる

divやspanは便利ですが、意味を持たない汎用要素です。すべてをdivで作ると、HTML構造が支援技術へ伝わりにくくなります。特にボタン、リンク、見出し、リスト、フォームのように意味が明確な要素は、適切なHTMLタグを使うべきです。

見た目はCSSで調整できますが、意味はHTMLで伝える必要があります。標準HTMLで表現できるものは、標準HTMLを使うことがアクセシビリティの基本です。

14.2 見出しを装飾だけで作る

見出しをdivやpに大きな文字サイズを指定して作ると、視覚的には見出しに見えても、HTML構造としては見出しになりません。スクリーンリーダー利用者は見出し単位でページを移動することがあるため、見出しタグが適切でないとページ把握が難しくなります。

見出しは、見た目ではなく構造として設計する必要があります。ページの情報階層に合わせてh1からh6を使い、CSSで見た目を調整する方法が適しています。

14.3 フォーカス表示を消す

フォーカス表示を消す実装もよくある問題です。デザイン上の理由でoutline: none;を指定すると、キーボード操作中に現在位置が分からなくなります。これは操作可能性に大きく影響します。

フォーカス表示は、ユーザーの現在位置を示す重要なUIです。標準の表示がデザインに合わない場合は、見やすいカスタムフォーカスを用意することが必要です。

14.4 ARIAを誤用する

ARIAは便利ですが、誤用するとアクセシビリティを悪化させることがあります。標準HTMLで表現できる要素に不必要なARIAを付けたり、実際の状態とARIA属性が一致していなかったりすると、支援技術に誤った情報を伝える可能性があります。

ARIAは、標準HTMLだけでは不足する場合に補助的に使うものです。まずセマンティックHTMLを正しく使い、それでも不足する部分にだけARIAを追加する考え方が安全です。

14.5 動的UIの状態が伝わらない

JavaScriptで画面を動的に更新する場合、状態変化が支援技術に伝わらないことがあります。検索結果が変わった、メニューが開いた、保存が完了した、エラーが表示されたといった変化を視覚的に示すだけでは不十分な場合があります。

動的UIでは、aria-expanded、aria-live、aria-controls、フォーカス管理などを適切に使い、状態が伝わるようにする必要があります。視覚的な変化と支援技術への情報を一致させることが重要です。

15. HTMLとWCAG対応のチェックポイント

HTMLとWCAG対応を進めるときは、実装前・実装中・公開前・運用中の各段階で確認することが重要です。特に、共通コンポーネントや主要導線は、早い段階でアクセシビリティを確認しておくと後からの修正コストを減らせます。

チェックポイントは、単なる項目確認ではなく、ユーザーが実際に利用できるかを見るためのものです。見た目、構造、操作、理解、状態表示を総合的に確認する必要があります。

15.1 HTML構造を確認する

まず、HTML構造を確認します。見出し、ランドマーク、リスト、テーブル、フォーム、ボタン、リンクが適切なタグで表現されているかを見ます。divやspanだけに頼りすぎていないかも確認します。

構造が正しければ、支援技術やブラウザがページ内容を理解しやすくなります。アクセシビリティ対応は、見た目の調整よりも先に、構造の整理から始めると効果的です。

15.2 キーボードだけで操作する

次に、キーボードだけで操作できるか確認します。Tabキーで自然に移動できるか、EnterやSpaceで操作できるか、フォーカス表示が見えるか、モーダルやメニューで迷子にならないかを確認します。

マウスでは問題なく使えるUIでも、キーボードで操作すると問題が見つかることがあります。特にカスタムUIは、キーボード操作の確認が欠かせません。

15.3 フォームとエラーを確認する

フォームでは、ラベル、入力例、補足説明、必須表示、エラー表示を確認します。入力欄の意味が分かるか、エラーの原因と修正方法が分かるか、エラー箇所へ移動しやすいかを見る必要があります。

フォームはユーザーの目的達成に直結するため、アクセシビリティ問題の影響が大きくなります。問い合わせ、購入、予約、申請、ログインなどは優先的に確認するべきです。

15.4 動的UIの状態を確認する

JavaScriptで動くUIでは、状態が正しく伝わるか確認します。メニューの開閉、タブの選択、モーダルの表示、保存完了、エラー表示、読み込み中などが、視覚的にも支援技術にも伝わるかを確認します。

状態表示が不十分だと、ユーザーは操作が成功したのか分かりません。動的UIでは、HTML、ARIA、フォーカス管理、文言を組み合わせて設計することが重要です。

15.5 運用ルールへ組み込む

最後に、HTMLとWCAG対応を運用ルールへ組み込みます。公開時だけ確認しても、更新で品質が崩れることがあります。新しいページ、画像、フォーム、コンポーネントを追加するたびに、アクセシビリティを確認できる仕組みが必要です。

デザインシステム、コードレビュー、QAチェック、コンテンツ作成ガイドラインにアクセシビリティの観点を含めることで、長期的に品質を維持しやすくなります。

おわりに

HTMLとWCAGは、Webアクセシビリティを支えるうえで密接に関係しています。HTMLはページの意味構造を作る土台であり、WCAGはそのページが多様なユーザーにとって利用しやすいかを確認するための基準です。正しいHTMLを使うことで、支援技術やブラウザに情報が伝わりやすくなり、WCAG対応の基盤を作ることができます。

特に重要なのは、セマンティックHTML、見出し構造、画像の代替テキスト、フォームラベル、ボタンとリンクの使い分け、ランドマーク、キーボード操作、ARIAの適切な利用です。これらは単なる実装ルールではなく、ユーザーが情報を認識し、操作し、理解するための設計要素です。

見た目だけでアクセシビリティを判断することはできません。画面上ではきれいに見えていても、HTML構造が不適切であれば、スクリーンリーダーで理解しづらくなったり、キーボードで操作できなかったりします。WCAGに対応するには、デザイン、HTML、CSS、JavaScript、文言、状態表示を総合的に確認する必要があります。

今後のWeb制作では、HTMLとWCAGを別々に考えるのではなく、最初から一体で設計することが重要になります。正しいマークアップを行い、WCAGの観点で利用しやすさを確認し、継続的に改善していくことで、より多くのユーザーにとって使いやすく、信頼されるWebサイトやアプリを作りやすくなります。

LINE Chat