ログイン

POUR原則の解説：知覚可能、操作可能、理解可能、堅牢

2 min read
注ぐWcagアクセシビリティ

POUR — Perceivable（知覚可能）、Operable（操作可能）、Understandable（理解可能）、Robust（堅牢）— は、すべてのWCAG達成基準の背後にある4つの基本原則です。これらを習得すれば、あらゆる人にとって利用でき、かつ法令を順守するウェブサイトを構築するための、明確で実行可能なフレームワークを手に入れられます。

何時間もかけてウェブサイトのデザインを完璧に仕上げたのに、訪問者のかなりの割合がまったく利用できないとしたらどうでしょうか。これは、世界中で約13億人、つまり世界人口の約16%にあたる、何らかの障害とともに暮らす人たちにとっての現実です。WebAIM Million 2025レポートによると、いまだに94.8%のウェブサイトに、検出可能なアクセシビリティ上の不具合が少なくとも1つは存在しており、平均的なホームページには51件を超える個別のアクセシビリティエラーが含まれています。朗報なのは、ノイズを切り分け、「アクセシブルなウェブコンテンツがどのようなものであるべきか」を明確に示してくれる原則的なフレームワークが存在することです。それがPOURです。

POURとは何か、どこから来たのか？

POURは、Web Content Accessibility Guidelines (WCAG) を支える4つの中核原則の頭字語で、Perceivable（知覚可能）、Operable（操作可能）、Understandable（理解可能）、そしてRobust（堅牢）を表します。World Wide Web Consortium (W3C) がそのWeb Accessibility Initiative (WAI) を通じて策定・維持しているWCAGは、ウェブアクセシビリティに関する国際的なベンチマークです。現在の安定版であるWCAG 2.2では、13のガイドラインと、その下にある多数のテスト可能な達成基準が、これら4つの原則に整理されています。

POURは、あらゆるウェブコンテンツについて投げかける質問の階層だと考えることができます。ユーザーはそれを実際に検知できるか？ それと対話できるか？ 理解できるか？ そして、技術が進化しても動作し続けるか？ これらのうち1つでも答えが「いいえ」であれば、現時点で実在する誰かがあなたのサイトから排除されていることになります。これは仮定の話ではなく、スクリーンリーダーユーザー、キーボードのみで操作するユーザー、認知特性のある人たち、古い支援技術を使っているユーザーなど、何百万人もの人にとっての日常的な体験です。

POURを理解することは、道義的な義務を超えた意味を持ちます。世界各地の法律や規制――アメリカ合衆国のAmericans with Disabilities Act (ADA)、EU全域のEuropean Accessibility Act (EAA)、英国のEquality Act――は、技術的な標準としてWCAGに依拠しています。企業がアクセシビリティ訴訟に直面する場合、その訴状はほぼ必ず、POURの1つ以上の原則における不履行にさかのぼることができます。2025年だけでも、ADAに基づくデジタルアクセシビリティ訴訟が5,114件提起されており、最も頻繁に標的となったセクターはeCommerce企業でした。実務的に言えば、POURを知ることは、自社の法的リスクを知ることにほかなりません。

それぞれの原則は、上位の目標であるガイドラインへと分岐し、さらにそのガイドラインが、具体的でテスト可能な達成基準へと分岐します。達成基準には、レベルA（最低限）、レベルAA（強い要件――最も広く求められている標準）、レベルAAA（強化版）が設定されています。本ガイドの残りの部分では、各原則を掘り下げ、すぐに適用できる実践的な例やコードパターンを紹介していきます。

原則1: Perceivable（知覚可能）――検知できなければ、存在しないのと同じ

WCAG仕様はこれを明快に述べています。情報およびユーザーインターフェイスコンポーネントは、ユーザーが知覚できる方法で提示されなければならない、と。言い換えれば、ページ上のどの要素も、ユーザーのすべての感覚に対して同時に「見えない」状態であってはなりません。色だけで意味を伝えるグラフは、色覚異常の人には見えないのと同じです。字幕のない動画は、聴覚障害のある人にとっては実質的に無音です。装飾目的の画像に冗長なaltテキストを付けると、スクリーンリーダーユーザーの時間を浪費します。知覚可能性とは、特定のチャネルにアクセスできないユーザーのために、あらゆるコミュニケーションチャネルにフォールバックを用意することです。

Perceivableの下には4つのWCAGガイドラインがあります。テキストによる代替、時間依存メディア、適応可能なコンテンツ、判別可能なコンテンツです。テキストによる代替（ガイドライン1.1）では、すべての非テキスト要素――画像、アイコン、グラフ、インフォグラフィック、音声ファイル、動画――に、同じ目的を果たすテキストの同等物を用意することが求められます。ホームページへのリンクとして使われている画像には、「logo.png」や空文字列ではなく、「Return to homepage」のようなaltテキストを付けるべきです。一方で装飾目的の画像には、スクリーンリーダーが完全にスキップできるようにalt=''を指定し、不要なノイズを防ぎます。

時間依存メディア（ガイドライン1.2）は、動画や音声コンテンツに対する字幕、音声解説、トランスクリプトを扱います。同期された字幕は、聴覚障害や難聴のユーザーを支援します。音声解説――画面上の動きを説明するナレーション――は、視覚障害のあるユーザーを支援します。トランスクリプトは両方のグループに役立つだけでなく、騒がしい環境にいるユーザーや、音声よりも書かれたテキストの方が処理しやすいユーザーにも有益です。

適応可能なコンテンツ（ガイドライン1.3）とは、プレゼンテーションが取り払われてもコンテンツが意味をなすことを意味します。視覚ユーザーが必須項目を赤色のハイライトで認識している場合、スクリーンリーダーユーザーも、単なる視覚的な色ではなく、プログラム的なマークアップを通じてそれが必須であると分かる必要があります。「右側の緑のボタンをクリックしてください」といった指示は、視覚障害のあるユーザーにはまったく通用しません。ルールは明確です。指示は、形、色、サイズ、画面上の位置といった感覚的特徴のみに依存してはなりません。

判別可能なコンテンツ（ガイドライン1.4）は、コントラスト、テキストのリサイズ、音声の制御を扱います。WCAG 2.2レベルAAでは、通常のテキストに少なくとも4.5:1、大きなテキストに3:1のコントラスト比を求めています。コントラストの低いテキストは、ウェブ上で最も一般的なアクセシビリティの不具合です。2026年2月のWebAIM Million分析では、ホームページの83.9%で低コントラストのテキストが見つかり、1ページあたり平均34件の個別インスタンスが確認されました。また、テキストは200%まで拡大しても内容や機能を失わずに読める必要があり、320 CSSピクセル幅（Reflow達成基準1.4.10）で表示しても情報が失われてはなりません。

最も一般的なPerceivableの不具合――altテキストの欠如、低い色コントラスト、ラベルのないフォームフィールド――は、複雑なエンジニアリングの問題ではありません。どこを見ればよいかさえ分かれば、たいてい数分で修正できる日常的な抜け漏れです。

以下は、アクセシブルでない画像マークアップとアクセシブルな画像マークアップの簡単な比較です。

<!-- アクセシブルでない例: alt属性なし -->
<img src='product-chart.png'>

<!-- アクセシブルな例: 説明的なaltテキスト -->
<img src='product-chart.png' alt='Bar chart showing a 40% increase in Q3 revenue compared to Q2'>

<!-- 装飾画像: 支援技術にスキップさせる -->
<img src='divider-wave.png' alt='' role='presentation'>

原則2: Operable（操作可能）――すべての機能は、あらゆる入力方法で動作しなければならない

Operableはインタラクションに関する原則です。WCAGは、ユーザーインターフェイスコンポーネントとナビゲーションは操作可能でなければならない、と定めています。つまり、インターフェイスはユーザーが実行できない操作を要求してはならないということです。これが最も明確に表れるのがキーボードアクセシビリティです。運動障害、反復性ストレス障害、視覚障害のある多くのユーザーは、キーボード（あるいはスイッチデバイス、シップ・アンド・パフコントローラー、音声入力ソフトウェアなど、キーボードをエミュレートする支援技術）だけに頼ってウェブを操作しています。ドロップダウンメニューがマウスホバーでしか開かない場合、そうしたユーザーは締め出されてしまいます。

ガイドライン2.1では、すべての機能がキーボードから利用可能であることを求めています。これは、すべてのインタラクティブ要素――リンク、ボタン、フォームコントロール、カスタムウィジェット、スライダー、日付ピッカー、モーダルダイアログ――がTabキーで到達可能であり、キーボードコマンドで操作可能であることを意味します。重要なのは、キーボードトラップがあってはならないという点です。モーダルのようなコンポーネントにフォーカスが移動した場合、ユーザーはキーボードだけでフォーカスを外に戻せなければなりません（通常はEscapeキーで）。フォーカスが閉じ込められたユーザーは、ブラウザを閉じる以外に手段がなくなります。

同じくらい重要なのがフォーカスの可視性（ガイドライン2.4、達成基準2.4.7）です。視覚のあるキーボードユーザーは、常にフォーカスがどこにあるかを視認できる必要があります。美観上の理由からブラウザのデフォルトのフォーカスアウトラインを削除する慣行は、開発者が取り得る中で最も有害なアクセシビリティ上の決定の1つです。フォーカスが見えないと、キーボードユーザーは暗闇の中を操作しているような状態になります。デフォルトのフォーカススタイルを上書きする場合は、周囲の背景に対して少なくとも3:1のコントラスト比を持つ、視認可能な代替スタイルを必ず提供しなければなりません。

<!-- アクセシブルでない例: フォーカスアウトラインを全体で抑制 -->
* { outline: none; }

<!-- アクセシブルな例: カスタムの視認可能なフォーカススタイル -->
:focus-visible {
  outline: 3px solid #005fcc;
  outline-offset: 2px;
  border-radius: 2px;
}

ガイドライン2.2はタイミングを扱います。あるユーザーは、コンテンツを読む、フォームに入力する、セッションタイムアウトの警告に応答するのに、他のユーザーよりもはるかに多くの時間を必要とします。コンテンツ側で設定するあらゆる時間制限について、ユーザーはそれをオフにするか、（デフォルトの少なくとも10倍まで）延長するか、期限が切れる前に警告を受け、単純な操作で応答するために少なくとも20秒が与えられなければなりません。自動で進むカルーセル、制限時間付きクイズ、セッション期限切れのモーダルなどは、ここでよく問題になる要素です。

ガイドライン2.3は、1秒間に3回を超えて点滅するコンテンツを禁止しています。このようなコンテンツは光感受性発作を誘発する可能性があるためです。ガイドライン2.4はナビゲーション性を扱い、ユーザーがコンテンツを見つけ、自分がどこにいるかを把握できるようにすることを求めます。実務的な要件としては、繰り返し現れるナビゲーションブロックをスキップする手段（最も簡単なのは「メインコンテンツへスキップ」リンク）、説明的なページタイトル、論理的なフォーカス順序、意味のあるリンクテキスト（「click here」ではなく「Read the Q3 report」）、そして視認可能なフォーカスインジケーターなどがあります。WCAG 2.2ではさらにガイドライン2.5が追加され、入力モダリティを扱っています。マルチポイントや軌跡ベースのジェスチャー（ピンチズーム、スワイプ）を使うすべての機能は、単一ポインタでも操作可能でなければならず、タッチターゲットは最小サイズ要件を満たす必要があります。

キーボードアクセシビリティはニッチな懸念事項ではありません。視覚障害のあるユーザー、パワーユーザー、運動障害のあるユーザー、そしてトラックパッドが突然壊れた人まで、みなキーボードに依存しています。キーボードファーストで構築することは、レジリエンスのために構築することです。

原則3: Understandable（理解可能）――明瞭さは「あると良い」ではなく必須

コンテンツが知覚可能で、すべてのインタラクションが操作可能であっても、コンテンツ自体が分かりにくければ、ユーザーは完全に迷子になり得ます。Understandableの原則は、提示される情報とインターフェイスの動作の両方が、ユーザーにとって理解可能でなければならないと定めています。この原則は、認知障害や学習障害のあるユーザー、デジタルリテラシーの低いユーザー、あるいは第一言語ではない言語でサイトを利用しているすべての人にとって、特に重要です。

ガイドライン3.1は可読性を扱います。最も基本的な要件は、ページの言語がコード上で特定されていること――つまり<html>要素のlang属性です。この1つの属性によって、スクリーンリーダーは適切な発音エンジンに切り替えることができます。2025年のWebAIMデータでは、ホームページの15.8%で言語宣言が欠落しており、ユーザーのデフォルト言語設定が異なる場合、スクリーンリーダーが英語のページをフランス語アクセントで（あるいはその逆で）読み上げてしまう可能性があることが分かりました。コンテンツの途中で言語が切り替わる場合――多言語サイトではよくあることです――は、該当する要素にlang属性を付与しなければなりません。

<!-- ページの言語宣言 -->
<html lang='en'>

<!-- インラインでの言語切り替え -->
<p>The phrase <span lang='fr'>joie de vivre</span> means joy of living.</p>

ガイドライン3.2は予測可能性を扱います。ページやコンポーネントは、一貫性があり、期待どおりに振る舞わなければなりません。ナビゲーションメニューは、ページをまたいで同じ位置と順序で表示されるべきです。ドロップダウンで値を選択しただけで、事前の警告なしに自動的に別ページへ遷移してはなりません――自動送信の挙動が必要な場合は、ユーザーにその旨を知らせる必要があります。サイト全体で見た目が同じコンポーネント（アイコンのみの閉じるボタン、検索フィールドなど）は、同じように動作すべきです。予期しないコンテキストの変化――予告なしに新しいタブが開く、ページが自動更新される――は混乱を招き、特にスクリーンリーダーユーザーにとって問題です。彼らは変化にすぐ気づけないことがあるからです。

ガイドライン3.3は入力支援を扱っており、アクセシビリティの中でも実務的なインパクトが最も大きい領域の1つです。ユーザーがフォーム入力でエラーを起こしたとき、知る必要があるのは3つです。エラーが発生したこと、どのフィールドが原因か、そしてどう直せばよいか。単にエラーのあるフィールドを赤くするだけでは不十分で、エラーメッセージはテキストベースであり、該当フィールドとプログラム的に関連付けられ、かつ具体的で行動可能でなければなりません。「This field is required」は、何もないよりはわずかにマシです。「Please enter your email address in the format [email protected]」は、本当に役に立つメッセージです。WCAG 2.2では、達成基準3.3.7（Redundant Entry）と3.3.8（Accessible Authentication）も追加されました。特に後者は、パズルや記憶テストのような認知機能テストを唯一の認証手段とすることを禁じており、そのような障壁が認知障害のあるユーザーに不釣り合いな影響を与えることを認識しています。

理解しやすいデザインは、コンテンツを「レベルダウン」させることではありません。不必要な摩擦を取り除くことです。平易な言葉遣い、一貫したパターン、役に立つエラーメッセージは、障害の有無にかかわらず、すべてのユーザーにとって有益です。

原則4: Robust（堅牢）――技術をまたいで長く使えるように構築する

Robustは、デザイン段階では最も軽視されがちでありながら、時間の経過とともに最も問題を引き起こす原則です。要件は、コンテンツが多様なユーザーエージェント（支援技術を含む）によって確実に解釈できるほど堅牢でなければならない、というものです。そして技術が進歩しても、コンテンツは引き続きアクセシブルであるべきです。実務的には、クリーンで妥当なセマンティックHTMLを書き、ARIAを慎重に使うことで、今日のスクリーンリーダーと明日のブラウザエンジンのどちらからもコンテンツが理解されるようにすることを意味します。

ガイドライン4.1は、WCAG 2.2におけるRobustの唯一のガイドラインであり、その中で最も重要な達成基準が4.1.2「名前（Name）、役割（Role）、値（Value）」です。あらゆるユーザーインターフェイスコンポーネント――フォーム、リンク、ボタン、カスタムウィジェット――について、その名前（何と呼ばれるか）、役割（どのような種類の要素か）、値や状態（チェックボックスがチェックされているか、アコーディオンが展開されているか）が、プログラム的に判別可能でなければなりません。支援技術はアクセシビリティツリーからこの情報を読み取り、ユーザーに「今何とやり取りしているのか」を伝えます。

4.1.2を満たす最も確実な方法は、ネイティブのHTML要素を使うことです。ネイティブ要素には、アクセシビリティツリーに自動的に公開されるセマンティクスが組み込まれています。<button>要素はネイティブにボタンであり、正しいroleを持ち、デフォルトでフォーカス可能で、EnterとSpaceの両方でアクティブになります。見た目だけボタンのようにスタイルした<div>には、role='button'やtabindex='0'、キーボードとポインタイベントの両方に対応するJavaScriptイベントハンドラを手動で追加しない限り、これらの特性は一切ありません。ネイティブなセマンティクスは「タダ」で手に入りますが、カスタム実装には継続的なメンテナンスが必要です。

<!-- アクセシブルでないカスタムボタン -->
<div class='btn' onclick='submitForm()'>Submit</div>

<!-- アクセシブルな例: ネイティブ要素 -->
<button type='submit'>Submit</button>

<!-- カスタムコンポーネントが不可避な場合 -->
<div
  role='button'
  tabindex='0'
  aria-pressed='false'
  onkeydown='handleKey(event)'
  onclick='toggleState()'
>
  Toggle
</div>

達成基準4.1.3（Status Messages、レベルAA）は、重要なステータスメッセージ――フォーム送信の確認、読み込みインジケーター、エラー通知、ショッピングカートの更新――が、キーボードフォーカスをそこへ移動させることなく、支援技術ユーザーに対してアナウンスされることを求めています。標準的な仕組みはARIAライブリージョンです。緊急性の低い更新（「Your changes have been saved」）にはaria-live='polite'を、緊急の割り込み（「Session expired」）にはaria-live='assertive'を使います。これがないと、チェックアウトを行っているスクリーンリーダーユーザーがフォームを送信しても、確認もエラーも何も聞こえず、自分の注文が通ったのかどうか分からない、という状況になりかねません。

<!-- 緊急性の低いステータス用のpoliteライブリージョン -->
<div aria-live='polite' aria-atomic='true' class='sr-only'>
  <!-- 動的に挿入: 'Your profile has been updated.' -->
</div>

<!-- 緊急アラート用のassertiveライブリージョン -->
<div role='alert' aria-live='assertive'>
  <!-- 動的に挿入: 'Error: Payment failed. Please try again.' -->
</div>

なお、WCAG 2.2では旧達成基準4.1.1（Parsing）が削除されました。これは以前、厳密なHTMLバリデーションを要求していたものです。現代のブラウザや支援技術は、かつてよりもはるかに寛容に不正なHTMLを処理できるようになっており、この達成基準は時代遅れとなりました。焦点は完全に、有意味なセマンティクスとARIAの正しい使用へと移っています。

4つの原則はどのように連携するのか

POURは、個別のチェックボックスの羅列ではなく、統合されたフレームワークです。1つの原則での不履行は、ほぼ必ず他の原則での不履行へと連鎖します。<div>要素とCSSだけで構築されたカスタムドロップダウンメニューは、たいてい4つの原則すべてに同時に違反します。スクリーンリーダーからは知覚できず（セマンティックなroleがない）、キーボードでは操作できず（フォーカス管理がない）、スクリーンリーダーユーザーには理解できず（状態のアナウンスがない）、支援技術APIが進化しても堅牢ではありません（プログラム的な名前や値がない）。

逆に、1つの原則をうまく満たすと、他の原則も改善されることがよくあります。セマンティックHTMLを書くこと（Robust）は、自動的に支援技術にとってコンテンツをより知覚可能にします。画像にテキストの代替を提供すること（Perceivable）は、画像を見られないユーザーにとって、そのコンテンツの理解可能性も高めます。視認可能なフォーカスインジケーターを追加すること（Operable）は、現在のインタラクションコンテキストを明確にすることで、インターフェイスの理解可能性を高めます。この相互連関性は意図されたものです。W3CはPOURを、モジュール式のチェックリストではなく、全体的なレンズとして設計しました。

アクセシビリティプログラムを構築するコンプライアンス担当者にとって、POURは是正作業を分類・優先順位付けする最良の方法を提供します。サイトを監査して50件のアクセシビリティ問題を見つけたとき、それらを原則ごとにグルーピングすることで、知覚可能性の問題（コンテンツチームがaltテキストなしで画像をアップロードしているのか）、操作可能性の問題（フロントエンドチームがキーボード対応のないカスタムコンポーネントを使っているのか）、理解可能性の問題（UXチームが一貫性のないナビゲーションパターンを設計しているのか）、堅牢性の問題（開発者がARIAを誤用している、あるいはまったく使っていないのか）を見極めることができます。問題の種類が違えば、必要となる組織的な解決策も異なります。

POURの実践: 自社サイトへのフレームワークの適用

理論を知ることは出発点にすぎません。POURを実践に移すには、アクセシビリティをプロダクトライフサイクルのあらゆる段階に統合する、一貫したプロセスが必要です――プロジェクトの最後に一度だけ監査する、というやり方ではありません。以下に、各原則に対して最もインパクトの大きいステップを示します。

Perceivableについては、まずWAVEやAxeのようなツールを使った自動スキャンから始め、alt属性の欠如、コントラストの不備、フォームラベルの欠如、ページ言語の欠如といった「取りやすい果実」を拾い上げます。こうした自動チェックで、WCAGの問題のおよそ30〜40%を検出できます。そのうえで残りを手動で監査します。NVDAやVoiceOverなどのスクリーンリーダーにページを読み上げさせて観察し、色覚異常シミュレーターで色覚異常のユーザーが何を見るかを確認し、視覚的に伝えられているあらゆる意味が、テキストや構造でも伝えられていることを検証します。

Operableについては、マウスを外し、Tab、Enter、Space、Escape、矢印キーだけを使って、すべてのページとすべてのインタラクティブなフローを操作してみてください。フォーカスが決して消えず、決して閉じ込められず、常に論理的な読み順で移動することを確認します。すべての時間制限付きインタラクションを見直し、ユーザーがそれらを延長または無効化できることを確認します。タッチデバイスでテストし、ジェスチャーベースのインタラクションにポインタの代替手段があることを検証します。

Understandableについては、すべてのテンプレートでページ言語宣言を監査します。すべてのフォームについて、明確で関連付けられたラベルがあるかを確認し、すべてのエラー状態をテストして、メッセージが具体的でテキストベースであり、該当する入力とプログラム的にリンクされていることを確かめます。可読性指標を使ってコンテンツレビューを行い、対象読者に適したFlesch-Kincaid読解レベルを目標とし、複雑なセクションには平易な言葉での書き換えを加えます。サイト全体のナビゲーションパターンを見直し、一貫性を確認します。

Robustについては、HTMLをバリデートします。ブラウザの開発者ツールとアクセシビリティツリーインスペクター（Chrome、Firefox、Safari DevToolsに内蔵）を使い、すべてのインタラクティブ要素に意味のあるアクセシブルネーム、正しいrole、正確な状態情報があることを検証します。すべてのカスタムウィジェットを監査します。複数のスクリーンリーダー――JAWS、NVDA、VoiceOver――でサイトを動かし、それぞれ挙動が少しずつ異なることを踏まえつつ、フォームエラー、読み込み状態、トースト通知などの動的更新が、ライブリージョンを通じて正しくアナウンスされることを確認します。

重要なポイント

  • POURはWCAGの背骨である。 WCAG 2.2のすべての達成基準は、Perceivable、Operable、Understandable、Robustという4つの原則のいずれかに対応しています。原則を理解することで、単なるチェックリスト追いではなく、アクセシビリティを原理立てて考えられるようになります。
  • 最も一般的な不具合は防ぎ得る。 低コントラストのテキスト（ページの83.9%で発見）、altテキストの欠如、ラベルのないフォームフィールド、ページ言語宣言の欠如は、いずれもPOURの不履行であり、自動スキャンで特定でき、開発者が迅速に修正できます。
  • キーボードアクセシビリティは操作可能性の土台である。 すべてのインタラクティブ要素は、キーボードだけで到達・操作・離脱できなければなりません。これは、運動障害や視覚障害のあるユーザー、そして状況的な制約を受けるユーザーをカバーします。
  • セマンティックHTMLは、堅牢性のための最良の戦略である。 ネイティブHTML要素は、正しい名前・役割・状態を自動的にアクセシビリティツリーへ公開します。非セマンティック要素の上に構築されたカスタムコンポーネントは、このベースラインに追いつくために、多大な追加作業と継続的なメンテナンスを必要とします。
  • アクセシビリティは継続的な実践であり、プロジェクトの一工程ではない。 デザインレビュー、コードレビューのチェックリスト、コンテンツワークフローに、POURに基づく考え方を組み込みましょう。自動ツールが検出できるのは問題の一部にすぎません。ギャップを埋めるのは、継続的な人によるテストとインクルーシブなデザインプロセスです。