WCAG 2.1.3: キーボード（例外なし）

この規定の意味

WCAG 2.1.3 — Keyboard (No Exception) は、WCAG 2.1 および 2.2 におけるレベル AAA の達成基準であり、すべての例外を取り除くことで WCAG 2.1.1（Keyboard, レベル A）を拡張したものです。具体的には、コンテンツのすべての機能は、個々のキー入力に特定のタイミングを要求することなく、キーボードインターフェースを通じて操作可能でなければならない と定めています。2.1.1 との重要な違いは、ユーザーの動きの経路（パス）に依存する入力が必要であり、終点だけではない 機能を免除する例外条項が存在しない点です。

2.1.1 の下では、フリーハンド描画キャンバス、ジェスチャーベースのペイントツール、パスに依存するドラッグインターフェースなど、ユーザーのポインタの正確な経路が出力を決定する機能については、キーボード対応から正当に除外することができます。WCAG 2.1.3 はこの例外を完全に廃止します。この基準の下では、描画、ドラッグ、パス依存のジェスチャー、そして歴史的にポインタの動きに依存してきたあらゆるインタラクションを含む、すべての機能がキーボードでアクセス可能でなければなりません。つまり、開発者は、フリーハンドやパス依存のタスクであっても、アクセシブルな図形ツール付きツールバー、キーボード制御の描画モード、フォームベースの入力代替など、代替となるキーボードメカニズムを提供しなければならないということです。

適合（パス）とみなされるには、ページ上のあらゆる操作がキーボードだけで開始・移動・完了できる必要があります。これには、フォーカス管理、モーダルダイアログ、ドラッグ＆ドロップによる並べ替え、カスタムスライダー、キャンバス描画ツール、地図インタラクション、カルーセルナビゲーション、動画再生コントロールが含まれます。キーボードトラップ（2.1.2 でも扱われる）があってはならず、クリック、ホバー、タッチジェスチャーでしか起動できる経路がなく、同等のキーボード経路が存在しない機能があってはならず、マウスポインタの経路に依存してもいけません。

不適合（フェイル）は、どれほどニッチで副次的に見える機能であっても、キーボードだけでは到達または完了できない場合に発生します。この基準には例外が一切ないため、キーボードでアクセスできない機能が 1 つでもあれば完全な不適合となり、WCAG の中でも最も要求水準の高い基準の 1 つとなっています。

なぜ重要か

キーボードアクセシビリティは、ポインティングデバイスを使用できない運動障害のあるユーザーにとって基盤となるものです。パーキンソン病、四肢麻痺、脳性まひ、反復性ストレス障害、四肢の差異などの状態にある人々は、多くの場合、物理キーボード、スイッチデバイス、シップ・アンド・パフコントローラー、またはキーボード入力をエミュレートする視線入力技術のみに依存しています。世界保健機関によると、世界で約 13 億人が何らかの重大な障害を抱えており、その中で運動または身体機能の障害は相当な割合を占めています。トルコだけでも、トルコ統計機構（TÜİK）のデータによれば、850 万人以上が少なくとも 1 つの機能制限を報告しています。

運動障害にとどまらず、キーボードアクセシビリティは NVDA、JAWS、VoiceOver などのスクリーンリーダーでナビゲートする視覚障害・ロービジョンのユーザーにも恩恵をもたらします。これらはすべて、ウェブコンテンツを移動・操作するためにキーボードコマンドに依存しています。光過敏性のあるユーザーはタッチスクリーンを避けることがあり、認知障害のあるユーザーは、キーボードインタラクションが提供する予測可能で線形なナビゲーションからしばしば恩恵を受けます。

具体的な現実のシナリオを考えてみましょう。フリーハンドのベクター描画ツールを提供するグラフィックデザインプラットフォームがあるとします。WCAG 2.1.1 の下では、ポインタの経路が形状を定義するため、これは例外として扱うことができました。WCAG 2.1.3 の下では、このプラットフォームは代替手段を提供しなければなりません。たとえば、図形ライブラリ、キーボード制御のアンカーポイントの系列、テキストベースの SVG パスエディタなどです。これにより、運動障害のあるユーザーもマウスなしでベクターアートワークを作成できます。これを行わないことは、キーボードのみのアクセスに依存するクリエイティブな専門職の意味のある一群を締め出すことになります。

ユーザビリティと SEO の観点からも、適切にキーボードアクセス可能なインターフェースは、フォーカス管理がよりクリーンで、タブ順がより論理的であり、DOM 階層がよく構造化されていることが一般的です。これらはすべて、クロールのしやすさと、キーボードショートカットを好むパワーユーザーを含むすべての人にとっての高品質なユーザー体験に寄与します。

関連する Axe-core のルール

WCAG 2.1.3 には手動テストが必要です。多くの WCAG 基準とは異なり、この基準の違反を自動ツールで確実に検出することはできません。その理由は次のとおりです。

• パス依存の機能検出は静的解析の範囲外である：axe-core や Lighthouse は、tabindex の欠如、role 属性の欠落、フォーカス管理の破綻といった構造的パターンを DOM から検査しますが、ページ上のあらゆる機能をユーザーが試行し、キーボード代替が存在するかどうかを判断することはできません。キャンバス要素が DOM に ARIA 属性なしで存在していても、近くにあるアクセシブルなキーボードツールバーが 2.1.3 を完全に満たしている場合があります。逆に、一見普通のボタンが JavaScript アクションをトリガーし、そのアクションがマウス専用ウィジェットを起動することもあり、自動ツールはこれを検出できません。マウス駆動の経路に対するキーボード代替の論理的な同等性は、人間の判断を必要とします。
• 2.1.3 に対応する専用の axe-core ルールは存在しない：scrollable-region-focusable（スクロール可能なコンテンツ領域がキーボードフォーカスを受け取れるかをチェックする）や tabindex（自然なフォーカス順を乱す正の tabindex 値を警告する）など、最も近い axe のルールは 2.1.1 と 2.4.3 の下にある関連するがより狭い懸念事項を扱っています。これらは、パスに依存する操作を含むすべての機能にキーボード同等物があるかどうかを評価することはできません。
• インタラクティブウィジェットの監査には実行時のインタラクションが必要：カスタムのドラッグ＆ドロップコンポーネント、キャンバスベースのエディタ、ジェスチャー駆動のカルーセルは、テスターが実際にマウスなしで使用を試みたときに初めて、そのキーボード非対応性が明らかになります。axe-core の静的 DOM スキャンは、イベントリスナーをトリガーしたり、非同期処理中のフォーカス喪失を観察したり、ドラッグ操作がキーボードの矢印キーと Enter/Space で完了できるかどうかを評価したりすることはできません。
• 手動監査で確認すべき点：テスターは、描画やインタラクションに使用されるキャンバス要素、ドラッグ＆ドロップのリストやファイルアップロード領域、カスタムの地図やデータ可視化コントロール、時間ベースのスライダー、そして mousemove、pointermove、タッチジェスチャーイベントに対応しながら、対応するキーボードイベントハンドラーを持たないコンポーネントを特に探すべきです。

テスト方法

1. 自動ベースラインスキャンを実行する：axe DevTools（ブラウザ拡張または CLI）や Google Lighthouse をページに対して実行し、フォーカス可能要素の欠如、キーボードトラップ、インタラクティブであるべき要素に対する pointer-events: none など、簡単に見つかるキーボードアクセシビリティの不具合を特定します。これらのツールは 2.1.3 の違反を直接検出することはできませんが、関連する問題を表面化させ、手動テスト開始前にクリーンなベースラインを確立します。
2. すべてのインタラクティブ機能をカタログ化する：テスト前に、ページ上のすべてのインタラクティブコンポーネントの完全な一覧を作成します。ボタン、リンク、フォーム、モーダル、アコーディオン、カルーセル、地図、キャンバスツール、ドラッグ＆ドロップ領域、カスタムドロップダウン、日付ピッカー、ビデオプレーヤー、マウスやタッチイベントに反応するあらゆるウィジェットを含めます。この一覧がテストチェックリストになります。
3. キーボードのみのナビゲーションテスト：マウスを切断または無効化します。Tab と Shift+Tab でフォーカスを移動し、Enter と Space でコントロールを起動し、複合ウィジェット（メニュー、スライダー、タブ、ラジオグループ）には 矢印キー を使用し、Escape でダイアログを閉じます。チェックリストにあるすべての機能を完了しようとします。キーボードだけでは開始・完了・終了できない機能をすべて記録します。
4. NVDA + Firefox によるスクリーンリーダーテスト：NVDA（Windows）を Firefox とともに起動します。仮想カーソルを使ってナビゲートします（見出しには H、ボタンには B、フォームフィールドには F、インタラクティブ要素には Tab）。各機能を試します。読み上げられるロール、名前、状態を確認します。到達できない、または音声によるアナウンスがないインタラクティブ領域を特定します。
5. JAWS + Chrome によるスクリーンリーダーテスト：Windows 上で JAWS を Chrome とともに使用します。JAWS の仮想カーソルとフォームモード（Enter で切り替え）を使用します。すべての機能が操作可能であり、とくにモーダルダイアログが開いた後や AJAX コンテンツが読み込まれた後に、各インタラクション後のフォーカスが正しく管理されていることを確認します。
6. VoiceOver + Safari（macOS/iOS）によるスクリーンリーダーテスト：VoiceOver を有効にします（macOS では Command + F5）。Control + Option + 矢印キーでナビゲートします。iOS ではスワイプジェスチャーを使用します。すべての機能に到達でき、操作可能であることを確認します。デスクトップ版でキーボード同等物を欠いている可能性のある、カスタムのタッチベースウィジェットに特に注意を払います。
7. パス依存機能の監査：描画キャンバス、地図インタラクション、ジェスチャー駆動のコンポーネントについて、代替のキーボードメカニズムが存在するかを確認します。キーボードだけで図形を作成したり、リスト項目を並べ替えたり、地図をパンしたりできるか試します。キーボード経路が存在しない場合、これは直接的な 2.1.3 の不適合です。
8. フォーカス可視性の確認：キーボードのみでナビゲートしている間、フォーカスが常に画面上で視認でき、論理的な順序になっていることを確認します。フォーカスが見えない、または予期しない場所にジャンプする場合、それはユーザビリティ上の問題であり、2.4.7 および 2.4.3 に違反している可能性も高いです。

修正方法

キャンバス描画ツール — 不適切な例

<!-- キーボード代替のないフリーハンドキャンバス -->
<canvas id='drawingBoard' width='800' height='600'
  onmousedown='startDraw(event)'
  onmousemove='draw(event)'
  onmouseup='endDraw()'>
</canvas>

キャンバス描画ツール — 適切な例

<!-- キーボードアクセス可能な図形ツールバーを代替として備えたキャンバス -->
<div role='toolbar' aria-label='Drawing tools'>
  <button id='addRect' onclick='insertShape("rectangle")'>Add Rectangle</button>
  <button id='addCircle' onclick='insertShape("circle")'>Add Circle</button>
  <button id='addLine' onclick='insertShape("line")'>Add Line</button>
  <label for='shapeColor'>Color</label>
  <input type='color' id='shapeColor' value='#000000'>
</div>
<canvas id='drawingBoard' width='800' height='600'
  aria-label='Drawing canvas — use toolbar above to add shapes'
  tabindex='0'
  onmousedown='startDraw(event)'
  onmousemove='draw(event)'
  onmouseup='endDraw()'
  onkeydown='handleCanvasKey(event)'>
</canvas>
<!-- handleCanvasKey は矢印キーでの移動と Enter による図形配置を可能にする -->

ドラッグ＆ドロップによるリスト並べ替え — 不適切な例

<!-- 並べ替えにマウスドラッグのみをサポートするリスト -->
<ul id='sortableList'>
  <li draggable='true' ondragstart='dragStart(event)' ondragover='dragOver(event)'>Item One</li>
  <li draggable='true' ondragstart='dragStart(event)' ondragover='dragOver(event)'>Item Two</li>
  <li draggable='true' ondragstart='dragStart(event)' ondragover='dragOver(event)'>Item Three</li>
</ul>

ドラッグ＆ドロップによるリスト並べ替え — 適切な例

<!-- ARIA listbox パターンと矢印キーによるキーボード並べ替えを備えたリスト -->
<p id='reorderInstructions'>Tab で項目に移動し、Space でつかみ、Up/Down 矢印キーで移動し、再度 Space でドロップします。</p>
<ul id='sortableList' role='listbox' aria-labelledby='reorderInstructions'>
  <li role='option' tabindex='0' aria-selected='false'
    draggable='true'
    ondragstart='dragStart(event)'
    ondragover='dragOver(event)'
    onkeydown='handleReorderKey(event)'>Item One</li>
  <li role='option' tabindex='0' aria-selected='false'
    draggable='true'
    ondragstart='dragStart(event)'
    ondragover='dragOver(event)'
    onkeydown='handleReorderKey(event)'>Item Two</li>
  <li role='option' tabindex='0' aria-selected='false'
    draggable='true'
    ondragstart='dragStart(event)'
    ondragover='dragOver(event)'
    onkeydown='handleReorderKey(event)'>Item Three</li>
</ul>
<!-- handleReorderKey: Space = つかむ/ドロップ、ArrowUp/Down = 移動、Escape = キャンセル -->

インタラクティブな地図コントロール — 不適切な例

<!-- マウスのパンとスクロールズームにのみ反応する地図 -->
<div id='mapContainer' style='width:100%;height:400px;'
  onwheel='zoomMap(event)'
  onmousedown='startPan(event)'
  onmousemove='pan(event)'>
</div>

インタラクティブな地図コントロール — 適切な例

<!-- キーボードコントロールとアクセシブルなズーム/パンボタンを備えた地図 -->
<div id='mapContainer' tabindex='0'
  role='application'
  aria-label='Interactive map. Use arrow keys to pan, plus and minus to zoom.'
  onwheel='zoomMap(event)'
  onmousedown='startPan(event)'
  onmousemove='pan(event)'
  onkeydown='handleMapKey(event)'>
</div>
<div role='group' aria-label='Map controls'>
  <button onclick='zoomIn()'>Zoom In</button>
  <button onclick='zoomOut()'>Zoom Out</button>
  <button onclick='panMap("north")'>Pan North</button>
  <button onclick='panMap("south")'>Pan South</button>
  <button onclick='panMap("east")'>Pan East</button>
  <button onclick='panMap("west")'>Pan West</button>
</div>
<!-- 矢印キーでパン、+ / - でズーム、handleMapKey がこれらのアクションをディスパッチする -->

よくある間違い

• WCAG 2.1.1 のパス依存例外がまだ適用されると想定してしまう：レベル A に慣れた開発者は、2.1.3 がこの例外を明示的に削除していることに気づかず、キーボード代替なしでフリーハンド描画やジェスチャーツールを構築してしまうことがあります。このレベルでは、パスに依存する機能を含め、あらゆる機能にキーボード同等物が必要です。
• カスタムインタラクティブ要素に onclick と onmousedown だけを付与する：<div> や <span> 要素で構築されたカスタムウィジェットがマウスイベントだけをリッスンしている場合、キーボードからは完全に到達不能です。常にマウスイベントリスナーとともに onkeydown または onkeyup ハンドラーを追加し、その要素に tabindex='0' と適切な ARIA ロールを付与してください。
• タブ順に含めるべき要素に tabindex='-1' を使用する：tabindex='-1' を設定すると、その要素は連続したタブ順から除外されます。これは（ロービング tabindex を用いる複合ウィジェット内など）プログラム的に管理される要素にのみ適切です。スタンドアロンのインタラクティブコントロールにこれを適用すると、キーボードからアクセスできなくなります。
• キーボードベースの並べ替えメカニズムなしでドラッグ＆ドロップを実装する：SortableJS のようなライブラリやカスタムドラッグ実装は、多くの場合、キーボード代替を標準で提供していません。開発者は ARIA のドラッグ＆ドロップパターンを実装するか、Up/Down 矢印キーによる並べ替えを提供し、リストの並べ替えが完全にキーボード操作可能になるようにしなければなりません。
• インタラクティブコントロールの表示に :hover CSS のみを頼る：ドロップダウンサブメニュー、ツールチップベースのアクションボタン、ホバー時にのみ表示されるコントロールは、:focus や :focus-within 状態も処理しない限り、キーボードユーザーにはアクセスできません。キーボードユーザーはホバーできないため、ホバー専用コンテンツは事実上彼らから隠されていることになります。
• 動的コンテンツ変更後のフォーカス管理を怠る：モーダルが開いたとき、インラインアラートが表示されたとき、AJAX で読み込まれたウィジェットが既存コンテンツを置き換えたときには、element.focus() を使ってフォーカスをプログラム的に新しいコンテンツへ移動させる必要があります。これを怠ると、キーボードユーザーは変更をトリガーした位置に取り残され、新しいコンテンツの存在に気づけません。
• onmousemove のみでカスタムスライダーを構築する：値の変更にマウス位置を追跡する <div> ベースのレンジスタイルスライダーは、ARIA スライダーパターンに従って ArrowLeft、ArrowRight、Home、End キーの処理も実装し、現在値を aria-valuenow、aria-valuemin、aria-valuemax で公開しなければなりません。
• iframe 内にキーボードフォーカスを置いたまま脱出手段を提供しない：とくに地図、決済フォーム、チャットツールなどのサードパーティウィジェットを含む埋め込み iframe は、埋め込みコンテンツ自体がキーボードアクセス可能でなく、Escape キーで親ドキュメントにフォーカスを戻すことをサポートしていない場合、キーボードフォーカスをトラップしてしまう可能性があります。
• キャンバスベースのデータ可視化にキーボードサポートを省略する：<canvas> 上に描画されたチャートやグラフは、キャンバス要素の横にアクセシブルな代替（データテーブル、ARIA を備えた SVG 等価物、キーボードでナビゲート可能なデータポイント）が提供されない限り、キーボードやスクリーンリーダーからは見えません。
• 複合ウィジェットのキー操作パターンを無視し、Tab と Enter だけでキーボードアクセシビリティをテストする：多くの ARIA ウィジェットパターン（メニュー、ツリー、グリッド、タブパネル、リストボックス）は、コンポーネント全体でタブストップを 1 つにし（ロービング tabindex）、ウィジェット内部のナビゲーションに矢印キーを必要とします。Tab と Enter だけをテストしても、これら複合パターンの不具合は明らかにならず、誤った適合感を与えてしまいます。

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

トルコの 大統領通達 2025/10 は、2025 年 6 月 21 日付官報（番号 32933）で公布され、トルコで事業を行う幅広い公的・民間主体を対象とした包括的なウェブおよびモバイルアクセシビリティの枠組みを確立しています。この通達は WCAG 2.1 および 2.2 に整合した標準への適合を義務付けており、対象組織に対し、障害のある人を含むすべてのユーザーにとってデジタルサービスを知覚可能、操作可能、理解可能、堅牢なものにすることを求めています。

この規制の対象となる主体には、あらゆるレベルの政府機関・公的機関、e コマースプラットフォーム、銀行および金融サービス提供者、病院および医療機関、20 万人以上の加入者を有する通信会社、旅行代理店、民間輸送会社、国民教育省（MoNE）の認可の下で運営される私立学校が含まれます。これらの組織にとって、レベル A およびレベル AA の達成基準への適合が法的な最低ラインとなります。

WCAG 2.1.3 — Keyboard (No Exception) は レベル AAA の基準であり、そのためこの通達の下でベースラインの法的要件として明示的に義務付けられているわけではありません。しかし、トルコにおける何百万人もの障害のあるユーザーに対して公平なデジタルアクセスを確保するという、この規制の精神は、この基準の意図と強く一致しています。運動障害のあるユーザー向けに特化したサービスを提供する対象セクターの組織や、支援技術に依存する市民が利用する政府ポータルを運営する組織は、キーボードアクセスについて AAA 適合を目指すことが強く推奨されます。

WCAG 2.1.3 への適合を達成することは、規制上の最低要件を超えた、最高水準のアクセシビリティへのコミットメントを示すものです。可能な限り幅広いユーザーベースにサービスを提供しようとするトルコの組織、社会的責任を示そうとする組織、あるいはより高いアクセシビリティ基準が適用される可能性のある欧州連合のデジタル市場に参入しようとする組織にとって、例外のない完全なキーボード操作性を実装することは、競争上および倫理上の両面で優位性となります。トルコの規制環境が進化し、執行メカニズムが成熟するにつれ、2.1.3 のような AAA レベルの基準を早期に採用した組織は、高額な是正措置を伴うことなく、将来の規制強化に対応できる有利な立場に立つことができるでしょう。