入力方法のガイドライン

2.5.2 ポインタのキャンセル (レベル A)

ボタンに「触れた瞬間」ではなく、「指を離した瞬間」に処理を実行する

作成日: 2024.4.10 / 最終修正日: 2026.5.12

この達成基準は、利用者が誤ってボタンやリンクを押してしまった際、その操作を取り消せる（キャンセルできる）ようにすることを目的としています。ポインタのボタンを押し込んだ瞬間や、タッチ画面に指が触れた瞬間（ダウンイベント）に即座に機能が実行されてしまうと、利用者が「間違えた！」と気づいても取り消しにくくなります。

実践すべきこと

ダウンイベントでの実行を避ける

• 機能を実行するトリガーとして、ポインタのダウンイベント（押し下げ、タッチの開始）を使用しない。

アップイベントでの実行とキャンセル手段の確保

• 機能の実行は、ポインタのアップイベント（押し上げ、タッチの終了）で行うようにする。
• 利用者がボタン上でダウンイベントを起こした後でも、ボタンの外側までポインタを移動させてからアップイベントを起こす（指を離す）ことで、操作を無効化（キャンセル）できるようにする。

例外となる機能

• 「ピアノの鍵盤アプリ」「お絵かきツールの描画」「ドラッグ＆ドロップ機能」など、ダウンイベントの瞬間に反応することが機能の本質として必要不可欠な場合は、例外として認められる。

運用者への注意

テストによる操作性の確認

• サイト内のボタンやリンクの上でポインタのボタンを「押しっぱなし」にし、そのままボタンの外へ移動させてからボタンを「離す」というテストを行う。このとき、リンク先に遷移したりフォームが送信されたりしなければ、キャンセル機能が正しく働いていると言える。

開発者への注意

標準イベントの利用

• ウェブ開発において、標準の click イベントは「同じ要素内でダウンイベントとアップイベントが両方発生したとき」に発火する仕様になっているため、基本的に click を使用していればこの基準を自然に満たすことができる。

独自のタッチイベント実装時の注意

• JavaScript で mousedown や touchstart の発火だけでフォーム送信やモーダルの開閉などを実行すると、指を離す前に操作を取りやめられず、本達成基準の意図と合わないことが多い。可能な限り click やポインタのアップ側に処理を寄せる。

今のWeb環境で気をつけたい点

• touchstart だけで確定させる実装： タッチ操作向けでは、click より早く反応させる目的で touchstart のみで画面遷移や送信を行う実装がみられます。押し始めの時点で確定してしまうと、ボタン外へスライドして取り消す余地がなくなり、本達成基準の意図とずれやすくなります。
• ドラッグ＆ドロップのとき： ダウンイベントから始まる例外として認められる操作でも、「元の位置に戻す」「ドロップ領域外で離したら無効」など、やり直せる経路があると、誤操作時の負担を減らせます。

参考リンク

解説書 達成基準 2.5.2: ポインタのキャンセル

2.5.3 ラベルを含む名前 (name) (レベル A)

画面に見えている文字（ラベル）と、システムが読み取る名前を一致させる

作成日: 2024.4.10 / 最終修正日: 2026.5.12

この達成基準は、主に「音声操作や音声認識ソフト」を使用している利用者が、画面に表示されている文字を読み上げて正しく操作できるようにするためのものです。画面に見えているラベルのテキストと、支援技術向けに設定された名前が異なっていると、利用者が「『検索』を押して」と発話してもシステムが認識できず、操作しにくくなります。

実践すべきこと

アクセシブルな名前には視覚的なラベルのテキストを含める

• ボタンやリンクに設定される「アクセシブルな名前（支援技術が読み取る名前）」には、画面上に表示されているラベルのテキストを含める。
• 含まれていれば基準は満たすが、利用者の混乱を防ぐため、画面上のテキストとアクセシブルな名前は一致していることが望ましい。

運用者への注意

表記揺れの防止

• 画面上のボタンには「送信」と書かれているのに、システムの仕様書や内部データでは「登録」という名称が使われているなど、運用上の表記揺れがそのままシステム（aria-label など）に反映されないよう注意する。

開発者への注意

aria-label の不用意な上書きに注意

• テキストを含むボタンに対し、スクリーンリーダー向けにより詳しい説明をしようとして aria-label を設定すると、元のHTMLテキストが上書きされて消えてしまう仕様に注意する。
• 例えば、画面上に「検索」と書かれたボタンに対し、aria-label="サイト内を探す" と設定すると、画面上の言葉と音声操作の名前がずれます。情報を補足したい場合は、元の表示テキストを先頭に置いて aria-label="検索：サイト内を探す" のようにするか、aria-describedby 属性を利用する。

今のWeb環境で気をつけたい点

• aria-label で名前を変えすぎない： 支援向けに詳しく書き込もうとして aria-label に長い文言だけを載せると、画面上の短いラベルとアクセシブルな名前がずれ、音声操作では画面の表記と一致せず操作しづらくなることがあります。視覚ラベルで足りる要素では、aria-label で名前を差し替えず、補足が必要なら上の開発者向けのとおり aria-describedby なども検討するとよいです。
• アイコンとテキストの併用： アイコン画像と「検索」などのテキストが並ぶボタンで、アイコンに「虫眼鏡」などの alt を付けると、名前が「虫眼鏡 検索」のように連結され、「検索」とだけ発話した操作が合いにくくなります。装飾であれば aria-hidden="true" や空の alt="" で画像側を名前から外し、表示テキストが名前の中心になるよう整えるとよいです。

参考リンク

解説書 達成基準 2.5.3: ラベルを含む名前 (name)

2.5.4 動きによる起動 (レベル A)

端末を振ったり傾けたりする操作に依存せず、動きの検知をオフにできるようにする

作成日: 2024.4.10 / 最終修正日: 2026.5.12

この達成基準は、端末を「振る」「傾ける」といった動きや、カメラを通じた利用者のジェスチャによって実行される機能について、それ以外の画面上のボタンなど一般的な操作でも実行できるようにすることを目的としています。端末をスタンドやアームなどに固定して使っている利用者や、手の震えによって意図せず機能が発動してしまう利用者を支援します。

実践すべきこと

代替操作（ボタンなど）の提供

• デバイスを振る・傾けるなどの動きをトリガーとする機能には、画面上のボタンやリンクなど、動きを伴わない一般的なUI操作による代替手段を用意する。

動き検知の無効化（オフ機能）の設定

• 意図しない動作を防ぐため、利用者が動きによる機能の起動を無効にできる設定を提供する。

例外事項の理解

• 「万歩計」や「端末の傾きを利用した水準器」など、その動きの検知自体が機能の本質であり不可欠な場合は、例外として認められる。

運用者への注意

イベントやキャンペーン企画のチェック

• 「端末を振ってくじ引き！」のようなキャンペーンコンテンツを企画・運用する際は、振る操作が難しい利用者のために「ボタンを選択してくじを引く」という代替ルートが設計されているかを確認する。

開発者への注意

DeviceMotion API 等の適切な制御

• ブラウザの DeviceMotionEvent や DeviceOrientationEvent などを利用して機能を実装する場合、画面上に同等の処理を発火させる <button> を配置する。

設定UIの組み込み

• 「シェイクして入力を取り消す」ような機能を独自に実装する場合は、アプリやサイトの設定画面等に「シェイクで取り消し」のチェックボックスを設け、プログラム的にイベントの検知を無効化できるようにする。

今のWeb環境で気をつけたい点

• ネイティブアプリに近い操作の再現： iOS の「シェイクで取り消し」のような挙動を Web で再現する例があります。本達成基準では、動きだけに頼らない操作（ボタンなど）と、動き検知をオフにできる設定の両方が求められるため、要件を満たすまでの工数や保守と照らしてから採用を検討するとよいです。
• AR と 360 度ビューアー： 端末の傾きで視点を動かすコンテンツでも、スワイプや画面上のボタンなど、傾けなくても同様の視点移動ができる経路を用意すると、本達成基準を満たしやすくなります。コンテンツの性質に合わせて、どの操作を代替にするか設計するとよいです。

参考リンク

解説書 達成基準 2.5.4: 動きによる起動

2.5.5 操作範囲（ターゲット）のサイズ (高度) (レベル AAA)

操作方法にかかわらず押し間違えにくいように、ボタンなどの操作できる範囲を「44×44ピクセル以上」にする

作成日: 2024.4.10 / 最終修正日: 2026.5.27

この達成基準は、手元の細かな操作が難しい利用者や、揺れる電車内で端末を操作している利用者が、目的のボタンやリンクを正確に選択（タップやクリック）できるようにするための基準です。WCAG 2.2で新設されたレベルAAの「2.5.8 操作範囲（ターゲット）のサイズ (最低限)」では24×24ピクセル（＋余白）で許容されますが、このレベルAAAでは余白の有無に関わらず、操作範囲そのものを「44×44 CSSピクセル以上」の押しやすい十分な大きさにすることを求めています。

実践すべきこと

十分な操作範囲の確保

• ウェブページ上のボタン、リンク、チェックボックスなどの操作可能な要素のサイズを、縦横ともに少なくとも 44 CSSピクセル以上 にする。

例外事項（適用されないもの）

• 文章の中にあるリンクや、ブラウザ標準のUIコントロール。
• 同じページ内に、44×44ピクセル以上の「同じ機能を持つ別のボタン」が用意されている場合。
• 操作範囲のサイズが、本質的にその大きさでなければ意味が通じない場合。

運用者への注意

デザインレビューでのチェック

• フッターの小さなSNSアイコンや、狭い画面で表示される「閉じる」ボタンなどをデザインする際、見た目が小さくても、操作できる領域として縦横44ピクセル以上を確保できているかを確認する。

開発者への注意

CSSによる操作できる範囲の拡大

• デザイン上の理由でアイコン自体を小さく見せたい場合でも、CSSの padding や width / height を調整して、操作判定される領域だけは透明なまま 44×44ピクセル以上に広げるコーディングを行う。

今のWeb環境で気をつけたい点

• レベルAAAの難易度と優先度： テキストリンクが密集しているリストなど、すべての操作範囲を44×44ピクセル以上にすると画面に配置できる情報量が減り、デザインが間延びしてしまう場合があるため、この基準は「レベルAAA」に設定されています。まずは 2.5.8（操作範囲（ターゲット）のサイズ (最低限)）で「24×24ピクセル＋操作範囲同士の間に十分な余白を空ける」ことを満たすのが優先ですが、文字が読みにくい利用者が多いサイトや、屋外で片手で操作されることが多いアプリ（地図や決済アプリなど）においては、この44×44ピクセルの確保が誤操作のストレスを軽減します。
• AppleやGoogleのガイドラインとの一致： AppleのiOSヒューマンインターフェイスガイドラインでは「44×44pt以上」、GoogleのMaterial Designでは「48×48dp以上」のタップ領域を推奨しています。つまり、WCAGのレベルAAA（44×44px）は、現代のモバイル向けWebデザインにおいては、タッチ操作を支える標準的な考え方として浸透しつつあります。

参考リンク

解説書 達成基準 2.5.5: 操作範囲（ターゲット）のサイズ (高度)

2.5.6 入力メカニズムの共存 (レベル AAA)

タッチ、ポインタ、キーボードなど、利用者が複数の操作方法をいつでも自由に切り替えて使えるようにする

作成日: 2024.4.10 / 最終修正日: 2026.5.27

この達成基準は、利用者がその時の状況や好みに応じて、ポインタ操作、キーボード、タッチスクリーン、音声入力、スタイラスペンなど様々な入力方法を自由に組み合わせて、または途中で切り替えて操作できるようにすることを目的としています。ウェブサイト側で「この画面はタッチ操作専用だからポインタ操作は無効にする」といった制限をかけず、利用者の自由な操作を妨げないようにするための基準です。

実践すべきこと

あらゆる入力方法の許容と共存

• ウェブコンテンツ側で特定の入力メカニズムを強制したり、ある入力方法（例：タッチスクリーン）が使われたからといって、他の入力方法（例：外付けキーボードやポインタ操作）の動作をブロックしたりしない。

運用者への注意

「専用」という決めつけの排除

• タッチ操作を想定したサイトの企画であっても、「利用者は指でスワイプするはずだ」と決めつけず、端末にBluetoothキーボードやポインタデバイスをつないで操作する利用者もいることを前提に、特定の操作方法に依存しすぎないUIを検討する。

開発者への注意

イベントリスナーの柔軟な設計（余計な制御を避ける）

• JavaScriptでイベントを実装する際、「タッチを検知したら、ポインタ操作やホバーなどのイベントを無効にする」といった、過剰な排他制御を行わない。
• HTMLの標準的なボタン（<button>）やリンク（<a>）を使っていれば、ブラウザが自動的にポインタ操作、タッチ、キーボードの操作を受け入れてくれるため、基本的には標準のHTML要素を使うことが有効な対策になります。

今のWeb環境で気をつけたい点

• レベルAAAの難易度と優先度： 標準的なHTMLコーディングをしていれば自然と満たせることも多いため、技術的な難易度は高くありません。しかし、独自のジェスチャー操作を伴うウェブアプリやブラウザゲームなどでは、すべての入力デバイスを同時にサポートすることが難しい場合があるため、この基準は「レベルAAA」に設定されています。まずはすべての機能をキーボードで操作できるようにする 2.1.1（キーボード）を満たすことが優先ですが、複数の入力デバイスが混在する現代においては、この「共存を邪魔しない」という方針が重要です。

参考リンク

解説書 達成基準 2.5.6: 入力メカニズムの共存

2.5.7 ドラッグの動き (レベル AA)

ドラッグ操作に依存せず、1回の選択でも同じ操作ができるようにする

作成日: 2024.4.10 / 最終修正日: 2026.5.12

この達成基準は、WCAG 2.2 から新たに追加されました。画面上の要素をドラッグ（ポインタを押し下げたまま移動し、離す操作）して操作する機能に対して、ドラッグ操作を行わなくても、1回の選択（クリックやタップ）だけで同等の機能を実現する代替手段を提供することを目的としています。

実践すべきこと

ドラッグに代わる選択操作の提供

• ドラッグ＆ドロップで要素を並べ替える機能には、要素の横に「上へ移動」「下へ移動」といった選択できる矢印ボタンを併設する。
• ツマミをドラッグして数値を変更するスライダーには、バー上の任意の位置を選択することでツマミが移動する機能や、数値を直接入力・増減できるボタンを提供する。

例外事項の理解

• 「自由な手書きのお絵かきツール」など、ドラッグの軌跡そのものが機能の本質であり必要不可欠な場合は、例外として認められる。

運用者への注意

新しいUIツールの導入時チェック

• カンバンボード（タスクをカードのように移動させるツール）や、アイテムの並び替え機能を持つ新しいプラグインやサービスをサイトに導入する際は、ポインタのドラッグ操作以外に、メニューから「〇〇へ移動」を選ぶといった選択操作だけで完結する操作ルートが用意されているかを確認する。

開発者への注意

標準的な代替UIの実装

• ドラッグ可能なリスト要素を実装する場合、JavaScriptの drag イベントだけに依存せず、各要素に <button> を用いた「上へ」「下へ」ボタンを配置し、click イベントでも順序を入れ替えられるようにプログラムを実装する。

マップやカルーセルの制御

• 地図（マップ）の移動はドラッグで行うことが多いが、画面上に上下左右へ移動するためのパン（矢印）ボタンを配置しておくことで、この基準を満たすことができる。

今のWeb環境で気をつけたい点

• ドラッグ＆ドロップでアップロードする領域： 「ここにファイルをドラッグ＆ドロップ」と案内するエリアに加え、「ファイルを選択」など、選択（クリックやタップ）でファイルを選べる <input type="file"> やボタンが置かれている例は、ドラッグに頼らない経路としてよく挙げられます。ドロップだけで追加でき、選択UIがない場合は別途検討が必要です。
• 2.5.1（ポインタのジェスチャ）との違い： 2.5.1 は、スワイプやピンチなど、軌跡や複数指を要する操作を主に扱います。2.5.7 は、押したまま移動して離す「ドラッグ」に焦点を当てた達成基準です。いずれも、単一のポインタ操作だけで同じ結果にたどり着ける手段を用意することが求められますが、対象とする操作の種類が異なります。

参考リンク

解説書 達成基準 2.5.7: ドラッグの動き