WCAG 2.2の達成基準「2.5.4 モーション操作」（Level A）は、端末や利用者の動きを入力として使う機能に、動きを必要としない操作方法と、意図しない作動を防ぐための無効化手段を用意することを求めます。
たとえば、端末を振って内容をリセットできるなら、画面上の「リセット」ボタンでも同じ結果に到達できるようにします。
この記事では、基準が対象とする操作、実装時の判断、よくある失敗、公開前のテスト手順を順に整理します。
「モーション操作」が対象とする入力
モーション操作とは、ボタンの押下や文字入力ではなく、端末や利用者の動きをセンサーで受け取り、機能を実行する操作です。
代表例は、端末を振る、傾ける、回転させるといった操作です。
「画面が動くこと」ではなく、「動きを入力として機能を作動させること」が、この達成基準の対象です。
達成のために必要な二つの対応
| 要件 | 実装時の判断 | 例 |
|---|---|---|
| 代替操作を用意する | モーション操作と同じ機能を、一般的なUIコンポーネントでも実行できるようにします。 | 端末を振る操作に加えて、画面上に「リセット」ボタンを置きます。 |
| モーションへの反応を止められるようにする | 利用者が設定を切り替えた後は、端末が動いても機能が作動しないようにします。 | 「端末の動きによる操作を有効にする」という設定を用意します。 |
代替操作は、似た画面を表示するだけでは足りず、モーション操作と同じ目的を達成できる必要があります。
一方、動作そのものが機能に不可欠で、代替すると活動の意味が成立しない場合などには例外があります。
元記事で挙げていた歩数計は、その考え方を理解しやすい例ですが、例外を適用できるかどうかは機能ごとに確認します。
代替UIと無効化設定の実装例
同じ処理をボタンからも呼び出す
モーション操作と代替ボタンが別々の処理を持つと、更新時に動作がずれるおそれがあるため、同じ関数を呼び出す構造にします。
<button type="button" id="resetButton">内容をリセット</button>
<label>
<input type="checkbox" id="motionToggle" checked>
端末の動きによる操作を有効にする
</label>const resetButton = document.getElementById('resetButton');
const motionToggle = document.getElementById('motionToggle');
let motionEnabled = motionToggle.checked;
function resetContent() {
console.log('リセットが実行されました');
}
resetButton.addEventListener('click', resetContent);
motionToggle.addEventListener('change', (event) => {
motionEnabled = event.target.checked;
});
window.addEventListener('deviceorientation', (event) => {
if (!motionEnabled) return;
// 必要な傾きの条件を満たした場合に resetContent() を呼び出す
});このコードは、代替ボタンと無効化設定の関係を示すための最小例です。
実際の実装では、対象端末でのセンサー利用条件、誤検知を避ける判定、設定の保存方法もアプリケーションの仕様に合わせて確認します。
表示状態と内部状態を一致させる
チェックボックスがオフなのに内部変数が有効のままだと、利用者は停止したつもりでもモーション操作が作動します。
初期表示時に入力要素の状態を読み取り、設定変更のたびに実際の動作へ反映させます。
アニメーション軽減設定と混同しない
端末やOSが提供するモーション入力の無効化設定に対応できる場合は、その設定を尊重する方法も検討できます。
ただし、CSSのprefers-reduced-motionは、画面上のアニメーションを減らすための設定であり、端末の傾きやシェイクへの反応を止める仕組みではありません。
したがって、prefers-reduced-motionだけで「2.5.4 モーション操作」への対応を終えることはできません。
画面上の動きへの配慮は、関連するモーションとアニメーションのアクセシビリティとして分けて確認すると、実装要件を整理しやすくなります。
よくある失敗と改善方法
| 失敗 | 利用者への影響 | 改善方法 |
|---|---|---|
| シェイクや傾きだけで操作させる | 端末を動かしにくい利用者や、端末を固定している環境では機能を使えません。 | ボタン、リンク、メニュー項目など、動きを必要としない操作を用意します。 |
| モーション操作を無効にできない | 端末の揺れや意図しない動作で、機能が作動する可能性があります。 | アプリケーション内の設定、または対応可能なシステム設定で反応を止めます。 |
| 設定の表示と動作が一致しない | 画面では無効に見えても、センサー入力が処理され続けます。 | 初期状態と変更後の状態を、実際のイベント処理に反映します。 |
| 自動チェックだけで適合を判断する | 代替操作が同じ結果になるか、無効化後に反応しないかを確認できません。 | センサー入力を使える実機または検証環境で、手動テストを行います。 |
公開前のテスト手順
- シェイク、傾き、回転などを入力として使う機能を洗い出します。
- 各機能をモーション操作で実行し、起きる結果を記録します。
- ボタンやメニューなどの代替UIから、同じ結果に到達できることを確認します。
- モーション操作を無効にし、端末を動かしても機能が作動しないことを確認します。
- 無効化した後も、代替UIからは機能を利用できることを確認します。
- 設定の表示状態と実際の有効状態が一致していることを確認します。
- 代替UIをキーボードやスクリーンリーダーでも識別し、操作できることを確認します。
axeやWAVEなどの自動チェックツールは、代替ボタンのラベルなど一般的な問題を見つける補助にはなります。
しかし、センサー入力と代替操作の結果が同じか、無効化設定が実際に効くかは、自動チェックだけでは判断できません。
モーション操作への配慮が役立つ場面
- 端末を安定して持つことや、狙った方向へ動かすことが難しい場合
- 端末を固定して使っており、傾けたり振ったりできない場合
- 意図しない揺れによる誤操作を避けたい場合
- ボタンやメニューなど、慣れた方法で確実に操作したい場合
操作方法を増やす目的は、機能を複雑にすることではなく、同じ結果へ到達できる経路を確保することです。
実装時の確認ポイント
- モーション操作と同じ機能を実行できる代替UIがあるか
- モーションへの反応を利用者が止められるか
- 無効化後も代替UIを使えるか
- 設定の表示と実際の動作が一致しているか
- 実機を使った手動テストを行ったか
「代替操作」と「無効化設定」を分けて確認すると、「2.5.4 モーション操作」で求められる対応を実装とテストの両面から整理できます。
当社では、ウェブアクセシビリティを導入しやすくするUUU ウェブアクセシビリティを提供しています。
アクセシビリティ改善を検討している方は、サービスの詳細をご覧ください。