WCAG 1.3.4: 向き

WCAG 1.3.4 Orientation は、特定の向きが不可欠な場合を除き、コンテンツが縦向きや横向きなど単一の画面の向きに表示や操作を制限しないことを求めています。この基準は、タブレットを固定している人や運動機能に障害のある人など、物理的にデバイスを回転できないユーザーでも、すべてのコンテンツにアクセスできるようにするものです。

このルールの意味

WCAG 1.3.4 Orientation は、WCAG 2.1 で導入され、WCAG 2.2 に引き継がれているレベル AA の達成基準です。これは、コンテンツが特定の表示の向き—縦向き（ポートレート）または横向き（ランドスケープ）のいずれか一方—に固定されてはならないと定めています。ただし、その特定の向きがコンテンツの機能にとって本質的である場合は例外です。実務的には、ウェブページやウェブアプリケーションは、ユーザーのデバイスが縦向きか横向きか、または向きがデバイスの OS やユーザー自身の設定によって制御されているかにかかわらず、正しく応答し、完全に操作可能でなければならないことを意味します。

この達成基準は、開発者が CSS のメディアクエリ、JavaScript、またはデバイス API を使って、意図的にコンテンツを一つの向きに制限する状況を対象としています。よくある違反例として、「デバイスを横向きに回転してください」といったメッセージを表示しつつ、縦向きではすべてのインタラクティブなコンテンツを非表示または無効にしてしまうケースがあります。別の違反例としては、ウェブアプリケーションが CSS transform を適用したり、ビューポートを強制的に回転させて、ユーザーのデバイスの向き設定を上書きしてしまうケースがあります。

適合とみなされる条件: コンテンツが縦向きと横向きの両方で利用可能であること。テキスト、インタラクティブ要素、フォーム、ナビゲーション、メディアが、デバイスの向きにかかわらず可視かつ操作可能であること。レイアウトは、CSS Flexbox、CSS Grid、メディアクエリなどのレスポンシブデザイン手法を用いて変化しても構いませんが、向きだけを理由に何かが削除されたり操作不能になったりしてはなりません。

不適合とみなされる条件: ある向きでコンテンツを隠したり、無効にしたり、操作を妨げること。動作する代替手段を提供せずに、ユーザーにデバイスを回転するよう指示するメッセージを表示すること。DeviceOrientationEvent や screen.orientation を監視し、その後 UI の一部をロックしたり無効にする JavaScript。あるいは、重要なコンテンツに対してブロッキングオーバーレイを表示したり、display: none を適用するために @media (orientation: portrait) を使用する CSS などです。

本質的な例外: WCAG は、一部のコンテンツには本質的に特定の向きが必要な目的があることを認めています。ピアノキーボードアプリケーションは、縦向きレイアウトでは音楽的に有用な数の鍵盤を表示できないため、横向きを正当な理由として要求できるかもしれません。カメラで横長の小切手を撮影することに依存する銀行の小切手入金機能は、横向きを必要とする場合があります。VR ヘッドセットのインターフェースは、機能するために固定された向きを必要とするかもしれません。しかし、「本質的」であると認められるハードルは高く、開発者の利便性や美的な好みだけでは正当化されません。この例外は、デザイン上の選択ではなく、コンテンツ自体の根本的な要件によって正当化されなければなりません。

なぜ重要か

向きの制限は、身体的・運動障害のある人々に不釣り合いな影響を与えます。たとえば、車椅子ユーザーがタブレットを椅子の肘掛けに縦向きで固定している状況を考えてみてください。その人は物理的にデバイスを傾けることができないため、横向きを要求するコンテンツは完全に利用不可能になります。これは仮想的なレアケースではなく、脳性まひ、脊髄損傷、ALS、重度の関節炎などの状態を持つ人々に対する一般的な配慮として、支援技術デバイスを特定の向きに固定して設置することはよく行われています。

固定されたデバイス以外でも、多くのユーザーは障害とは無関係な理由で OS の向きロック機能に依存しています。ベッドに横になっているユーザーは、画面が頻繁に回転するのを防ぐために、スマートフォンを縦向きにロックするかもしれません。内耳と平衡感覚に影響を与える前庭障害のあるユーザーは、向きの変化によるレイアウトの急な変化を、混乱を招くもの、あるいは身体的に気分が悪くなるものと感じるかもしれません。こうしたユーザーに、コンテンツへアクセスするためにデバイスの向きロックを解除することを強いるのは、不必要で差別的な障壁を生み出します。

認知アクセシビリティも要因の一つです。認知障害のあるユーザーは、一貫性があり予測可能なレイアウトから恩恵を受けることが多くあります。コンテンツを突然ブロックしたり、デバイスの回転を求めるエラーのようなメッセージを表示するアプリケーションは、特に、なぜ警告が表示されているのか、なぜ期待したコンテンツではないのかを理解できないユーザーにとって、混乱や不安を引き起こす可能性があります。

ユーザビリティとビジネスの観点からも、向きの制限はすべてのユーザーにとって不利益になります。モバイルウェブトラフィックのかなりの割合は縦向きで発生しており、サイトを横向きに限定すると、即座に離脱される可能性があります。検索エンジンも、モバイルフレンドリーであることや、安定したレイアウト挙動を含む Core Web Vitals をランキングアルゴリズムにますます取り入れており、向きに関連する問題は、SEO パフォーマンスやオーガニックトラフィックに測定可能な悪影響を与えうることを意味します。

世界的には、世界保健機関によると約 13 億人が何らかの障害を持って生活しています。このグループの相当数が、インターネットへのアクセス手段として主に、あるいは唯一、モバイルデバイスを利用しており、モバイルの向きに関するアクセシビリティは特に重要です。

テスト方法

ベースラインとして自動スキャンを実行する: Chrome、Firefox、または Edge でページを開きます。axe DevTools ブラウザ拡張機能を使用するか、Lighthouse のアクセシビリティ監査を実行してベースラインを確立します。これらのツールは向きの違反を直接検出することはできませんが、レスポンシブデザインの関連問題、ビューポート meta タグの問題、向きのアクセシビリティの失敗を悪化させる ARIA の欠如などを指摘する場合があります。自動レポートに問題がないからといって、1.3.4 に準拠していることにはなりません。
ブラウザ DevTools のデバイスエミュレーションを使用する: Chrome または Edge で DevTools（F12）を開き、デバイスツールバーアイコン（Ctrl+Shift+M / Cmd+Shift+M）をクリックし、iPhone 14 や Galaxy S21 などのモバイルデバイスを選択します。デバイスツールバーの回転アイコンを使って、縦向きと横向きの間で切り替えます。ナビゲーション、見出し、本文テキスト、フォーム、ボタン、画像、メディアなど、すべてのコンテンツが両方の向きで可視かつ操作可能であることを体系的に確認します。一方の向きでのみ表示されるブロッキングオーバーレイ、非表示セクション、無効化されたインタラクティブ要素がないかを探します。
実機でテストする: Android または iOS デバイスを接続し、モバイルブラウザでページを開きます。デバイスを実際に縦向きと横向きの間で回転させます。OS の向きロックが有効な場合でも、コンテンツが崩れたり、回転を促すプロンプトが表示されたりしないことを確認します。向きロックをオンとオフの両方でテストします。
スクリーンリーダーで向きのシミュレーションを行うテスト: iOS で VoiceOver を有効（サイドボタンをトリプルクリック）にし、スワイプジェスチャーを使って縦向きでページを操作します。その後、横向きに回転させ、VoiceOver の読み上げ順序とアクセシブルネームが正しいままであることを確認します。Android の TalkBack でも同様のテストを行います。デスクトップでは NVDA と Firefox を使用し、DevTools で向きをシミュレートして、アクセシビリティツリーが向きにかかわらず一貫していることを確認します。
CSS と JavaScript に向きの制限がないか確認する: DevTools で Sources または Elements パネルを開き、スタイルシート内で orientation: portrait と orientation: landscape のメディアクエリを検索します。各ブロックが何をしているかを確認します。display: none でコンテンツを隠しているのか、ブロッキングオーバーレイを適用しているのか、それとも単にレイアウトを調整しているだけなのかを確認します。JavaScript ファイル内で screen.orientation、orientationchange、screen.orientation.lock を検索します。見つかったパターンが UI をロックしたりコンテンツをブロックしたりしていないか評価します。
本質的な例外を検証する: サイトが意図的に向きを制限している場合は、文書化され正当化された本質的なユースケースが存在することを確認します。この例外は見た目ではなくコンテンツ主導でなければなりません。スクリーンショットと具体的な正当化理由とともに、調査結果を文書化します。

修正方法

縦向きでの CSS ブロッキングオーバーレイ — 誤った例

<!-- 縦向きのときだけ表示され、すべてのコンテンツをブロックする全画面オーバーレイ -->
<style>
  .rotate-prompt {
    display: none;
    position: fixed;
    inset: 0;
    background: #fff;
    z-index: 9999;
    text-align: center;
    padding: 2rem;
  }
  @media (orientation: portrait) {
    .rotate-prompt {
      display: flex; /* 下層のコンテンツをすべてブロックする */
    }
  }
</style>
<div class='rotate-prompt'>
  <p>Please rotate your device to landscape mode.</p>
</div>
<main id='app-content'>
  <!-- ここにアプリケーションのすべてのコンテンツ -->
</main>

縦向きでの CSS ブロッキングオーバーレイ — 正しい例

<!-- ブロッキングオーバーレイは完全に削除し、レイアウトの調整にはレスポンシブ CSS を使用する -->
<style>
  /* 縦向きレイアウト: 要素を縦に積む */
  @media (orientation: portrait) {
    .dashboard-grid {
      grid-template-columns: 1fr;
    }
  }
  /* 横向きレイアウト: 列を横に並べる */
  @media (orientation: landscape) {
    .dashboard-grid {
      grid-template-columns: 1fr 1fr;
    }
  }
</style>
<main id='app-content'>
  <div class='dashboard-grid'>
    <!-- コンテンツはレイアウトが変化しても常にアクセス可能 -->
  </div>
</main>

JavaScript による向きロック — 誤った例

<script>
  // 画面を横向きにロックし、失敗した場合（例: iOS）にはエラーを表示する
  screen.orientation.lock('landscape').catch(function() {
    document.getElementById('orientation-error').style.display = 'block';
    document.getElementById('main-content').style.display = 'none';
  });
</script>
<div id='orientation-error' style='display:none'>
  This application only works in landscape mode.
</div>
<div id='main-content'>
  <!-- アプリケーションコンテンツ -->
</div>

JavaScript による向きロック — 正しい例

<script>
  /*
    JavaScript で向きをロックしないこと。
    代わりに、向きの変化を監視して UI を調整するが、
    コンテンツを隠したり無効にしたりしないこと。
  */
  window.addEventListener('orientationchange', function() {
    var isPortrait = window.matchMedia('(orientation: portrait)').matches;
    // レイアウト用のクラスをスタイリング目的で切り替えるだけ — コンテンツは決して隠さない
    document.body.classList.toggle('portrait-layout', isPortrait);
    document.body.classList.toggle('landscape-layout', !isPortrait);
  });
</script>
<div id='main-content'>
  <!-- すべてのコンテンツは両方の向きで可視かつ操作可能 -->
</div>

向きの変更を妨げるビューポート meta タグ — 誤った例

<!-- 古い実装の中には、ビューポートで向きを「修正」しようとしたものがある -->
<meta name='viewport' content='width=device-width, initial-scale=1, user-scalable=no'>
<!--
  'user-scalable=no' 自体は直接向きをロックしませんが、
  ビューポートを回転させる CSS transform と組み合わせると、
  向きのアクセシビリティの失敗を引き起こす既知のアンチパターンになります。
-->
<style>
  /* アンチパターン: 縦向きデバイスで横向きをシミュレートするために body 全体を回転させる */
  @media (orientation: portrait) {
    body {
      transform: rotate(90deg);
      transform-origin: left top;
      width: 100vh;
      overflow-x: hidden;
    }
  }
</style>

向きの変更を妨げないビューポート meta タグ — 正しい例

<!-- 標準的なレスポンシブビューポートタグを使用し、CSS transform で body を回転させない -->
<meta name='viewport' content='width=device-width, initial-scale=1'>
<!--
  ブラウザと OS に向きの処理を自然に任せること。
  あらゆるビューポートのアスペクト比でコンテンツが機能するようにデザインすること。
  コンテンツの再配置には CSS Grid や Flexbox を使用し、transform は使わないこと。
-->

よくある間違い

@media (orientation: portrait) を使って、ナビゲーションメニュー、サイドバー、メインコンテンツ領域に display: none を適用すること。 コンテンツを単に再配置するのではなく、視界から取り除くあらゆる CSS の向きクエリは、違反の可能性があります。スタイルシート内のすべての向きメディアクエリを監査し、レイアウトだけを変更し、コンテンツの可用性を変えていないことを確認してください。
本質的ではないアプリケーションで screen.orientation.lock() を呼び出すこと。 この Web API はゲームや特定のメディア用途を想定しています。標準的なウェブアプリケーションや EC サイトで、横向きの見た目を「改善」するために使用することは、本質的な例外には該当せず、WCAG 1.3.4 の直接的な違反になります。
アクセシブルな代替手段なしに「デバイスを回転してください」というスプラッシュ画面を表示すること。 短時間の向きのヒントを表示する場合でも、それがコンテンツへのアクセスをブロックしてはなりません。表示する場合は必ず閉じることができ、メインコンテンツを覆わず、要件ではなく提案として伝えられなければなりません。
モバイルユーザーは常に動画コンテンツを横向きで見ることを好むと想定すること。 縦向きでは再生コントロールや再生ボタンを無効にし、ユーザーが操作する前に回転を強制する動画プレーヤーを埋め込むことは、その動画形式が縦向きでは本当に表示不可能である場合（標準的なウェブ動画ではほとんどありえません）を除き、1.3.4 に違反します。
ある向きで <body> またはルートコンテナに CSS の transform: rotate(90deg) を適用すること。 これは、デバイスに自然に処理させる代わりに CSS で向きの変更をシミュレートするもので、レイアウトの崩れ、画面外のコンテンツ、スクリーンリーダーにとってのアクセシビリティツリーの深刻な混乱を引き起こします。
QA の際に、チームがデスクトップブラウザでしかテストしないため、向きの挙動をテストしないこと。 デスクトップブラウザの DevTools による向きのシミュレーションは、標準的な QA サイクルで必ずしも使用されていません。向きはモバイルテスト計画の明示的な項目とし、iOS と Android の実機の両方で検証する必要があります。
親ページの向き状態を考慮せずに、iframe 内で向きの挙動を上書きすること。 サードパーティのウィジェット、埋め込み地図、決済 iframe は、独自に向きをロックしている場合があります。あなたのページが準拠していても、向きをロックした iframe を埋め込むと、その iframe の本質的な例外が文書化されていない限り、ページ全体が非準拠になります。
サーバーサイドのユーザーエージェント検出を使って、モバイルユーザーに「横向き専用」バージョンのページを配信すること。 縦向きに対応したフォールバックを提供せずに、モバイルユーザーを横向きでしか動作しない別 URL にリダイレクトすることは、システム的な違反であり、SEO や URL 正規化の問題も引き起こします。
本番ビルドでのみ向きの制限を適用し、開発時のテストでは見えないようにしてしまうこと。 フィーチャーフラグや A/B テストフレームワークが、特定の環境や特定のユーザーセグメントに対してのみ向きロックのコードを有効化し、その結果、ローンチ前のアクセシビリティ監査で違反が見逃されることがあります。
デザイナーが横向きレイアウトを好むという理由だけで、本質的な例外が適用されると想定すること。 本質的な例外は、法的にも倫理的にも高いハードルです。コンテンツの主要な機能が、別の向きでは根本的に不可能であることが必要であり、単に見た目が良い、あるいは縦向きのレスポンシブレイアウトを実装する時間が足りなかったといった理由では正当化されません。

トルコのアクセシビリティ規制との関係

トルコの大統領通達第 2025/10 号は、2025 年 6 月 21 日付官報（Resmî Gazete）第 32933 号で公布され、デジタルアクセシビリティに関する包括的な国家枠組みを確立しています。この通達は、対象となる組織に WCAG 2.2 レベル AA への準拠を義務づけており、その中には WCAG 1.3.4 Orientation も明示的に含まれています。これは、対象組織が運営するあらゆるデジタルサービスやウェブサイトが、コンテンツを単一の向きに制限してはならないことを意味し、すべての市民—障害のある人を含む—が、デバイスとの物理的な関わり方にかかわらずデジタルサービスにアクセスできるようにするという通達の意図を反映しています。

通達の対象となり、レベル AA 準拠が求められる組織には、公的機関・機構（ウェブサイトやデジタルサービスを運営するすべての政府機関）、銀行および金融機関、病院および医療提供者、20 万人以上の加入者を持つ通信会社、電子商取引プラットフォーム、旅行代理店、民間輸送会社、および国民教育省（MoNE）に認可された私立学校が含まれます。これらの組織にとって、1.3.4 に違反する向きの制限—たとえば、横向きのみのアクセスを要求する政府ポータルや、本質的ではない理由で縦向きにロックされた銀行アプリ—は、拘束力のある国家規制への直接的な不遵守を構成します。

アクセシビリティロゴ（Erişilebilirlik Logosu）は、家族・社会サービス省（Aile ve Sosyal Hizmetler Bakanlığı）によって発行される認証マークであり、国家アクセシビリティ基準への準拠を示します。レベル AA 準拠を達成することは、このロゴを取得するための前提条件です。Erişilebilirlik Logosu の取得を目指す組織は、1.3.4 を含むすべてのレベル A およびレベル AA の達成基準に合格していることを、自らのデジタルプロパティについて示さなければなりません。サイトのごく一部であっても向きの制限による失敗があると、認証全体が危うくなる可能性があります。

WCAG 1.3.4 は手動テストを必要とし、自動スキャンだけでは準拠を確認できないため、対象組織は正式なアクセシビリティ監査プロセスに向き特有のテストケースを組み込むべきです。縦向きと横向きの両方で実機を用いて行ったテスト結果の文書化は、規制遵守およびロゴ認証のために求められるアクセシビリティ準拠記録の一部として保持されるべきです。Accsible SDK は、トルコの進化するデジタルアクセシビリティ義務を満たすための包括的なアプローチの一環として、組織が向きに関連する障壁を特定し対処するのを支援します。

出典と参考資料

AWCAG 1.1.1: 非テキストコンテンツ AWCAG 1.2.1: 音声のみおよび映像のみ（事前録画）AWCAG 1.2.2: キャプション（事前録画）