「動きを抑える」設定にゲームが対応すべき理由と実装
遊びをつくる執筆にClaudeを使用しています。
OSには「視差効果を減らす」「アニメーションを減らす」といった設定項目があります。iOSなら「アクセシビリティ → 動作 → 視差効果を減らす」、Androidなら「ユーザー補助 → アニメーションを削除」、Windowsなら「視覚効果 → アニメーションを表示する」のオフがそれに当たります。ユーザーがこれをオンにすると、ブラウザはCSSメディアクエリ prefers-reduced-motion: reduce を報告します。 ゲームを作るとき、この設定を無視してもプレイ自体はできます。しかし、前庭障害・片頭痛・てんかんなどを持つ人の中には、激しい画面の動きで体調を崩すことがあります。「動きを抑える」設定はそういった人が自分の環境で使っているSOSのような信号です。それをゲームが読み取らないと、そのユーザーはそのゲームを選ばないか、無理してプレイして不快な体験を持ちます。 この記事では、対応が必要な理由の整理から、実際にどの動きをどう変えるかの判断基準、JavaScriptとCSSそれぞれの実装手順、そして「ゲームとして成立させながら対応する」ための考え方を示します。
なぜゲームが対応すべきか
アクセシビリティ対応は「配慮」の問題と捉えられがちですが、実用的な観点でも意味があります。対応しているゲームは設定をオンにしているユーザーでも離脱しないため、プレイ完了率が上がります。また、PWA（Progressive Web Apps）や一部のブラウザ拡張が自動でアニメーションを止める場合、対応していないゲームは意図しない壊れ方をすることがあります。自分でコントロールした対応の方が、外から勝手に止められるより安全です。
ゲーム特有の事情として、次の動きが特に問題になりやすいです。
- 画面全体が揺れるシェイクエフェクト
- 高速でループするパーティクルやフラッシュ
- スクロール速度と背景速度をずらした視差スクロール
- 連続する点滅（1秒間に3回以上の点滅はWCAGの禁止基準に触れます）
逆に、ボタンを押したときのフェードイン・フェードアウト、キャラクターが歩くアニメーション、テキストが順に表示される演出は、それほど問題になりません。「速い・大きい・繰り返す・画面全体に影響する」という属性を持つ動きを優先して対応します。
判断基準：止める・差し替える・そのままにする
すべてのアニメーションを止める必要はありません。ゲームプレイに直結する動きを止めると、ゲーム自体が成立しなくなります。整理の基準は次の3区分です。
止める（animation: none / transition: none）画面シェイク、点滅エフェクト、視差スクロール背景、ローディング時のスピナーアニメーション。これらはゲームプレイの本質ではなく、見た目の演出です。
差し替える（短くする・フェードに置き換える）ヒット時のフラッシュ → 短い色変化。キャラクターの待機アニメーション → 静止。ステージクリア演出の爆発 → フェードアウトとテキスト表示。動きをゼロにするのではなく、「小さくて短い動き」に置き換えることで視覚的なフィードバックは残ります。
そのまま（ゲームプレイの動き）プレイヤーの移動、弾の飛行、ブロックの落下。これらはゲームのルールそのものなので止められません。ユーザーも「これが動くこと」を期待してプレイしています。
CSS での実装
CSSのメディアクエリを使う方法が最もシンプルです。既存のアニメーション定義を書き換えずに追記できます。
@media (prefers-reduced-motion: reduce) {
/* 演出用のアニメーションをまとめて止める */
.screen-shake,
.particle,
.flash-overlay {
animation: none !important;
transition: none !important;
}
/* 視差背景を固定する */
.parallax-bg {
transform: none !important;
background-attachment: scroll;
}
/* ローディングスピナーをフェードに差し替える */
.spinner {
animation: fade-pulse 1.5s ease-in-out infinite;
}
}
@keyframes fade-pulse {
0%, 100% { opacity: 1; }
50% { opacity: 0.4; }
}!important を使うのは、ゲームのロジックが動的にスタイルを書き換える場合に確実に上書きするためです。インラインスタイルで animation を直接指定している箇所がある場合は、後述のJavaScript対応も合わせて行います。
prefers-reduced-motion: no-preference がデフォルト（設定していない状態）です。reduce のみを書けば、設定していない人には一切影響しません。
JavaScript での実装
Canvas描画やJavaScript側でアニメーションを制御しているゲームでは、CSSだけでは対応できません。ゲーム起動時にユーザーの設定を読み取り、フラグとして持っておきます。
const prefersReduced = window.matchMedia(
'(prefers-reduced-motion: reduce)'
).matches;
// ゲーム設定に統合する
const gameConfig = {
reducedMotion: prefersReduced,
// ...他の設定
};このフラグを使って、演出関数の中で分岐します。
function playHitEffect(x, y) {
if (gameConfig.reducedMotion) {
// 点滅なしで短い色変化のみ
drawColorFlash(x, y, 'rgba(255,80,80,0.5)', 100);
return;
}
// 通常の爆発パーティクル
spawnParticles(x, y, 20);
startScreenShake(8, 300);
}設定がゲームプレイ中に変わることも考慮するなら、addEventListener で変更を検知できます。
window.matchMedia('(prefers-reduced-motion: reduce)')
.addEventListener('change', (e) => {
gameConfig.reducedMotion = e.matches;
});設定をゲーム内オプションとして提供する
prefers-reduced-motion はOSの設定を自動で読み取る方法ですが、それだけでは不十分な場合があります。OSの設定を変えていないユーザーでも、特定のゲームだけ動きを抑えたいと思うことがあります。逆に、設定をオンにしているユーザーでも、このゲームでは演出を楽しみたいと思うかもしれません。
理想的な実装は、「OS設定を初期値として読み取り、ゲーム内オプションで上書きできる」構造です。
function loadMotionPreference() {
const saved = localStorage.getItem('reducedMotion');
if (saved !== null) return saved === 'true';
return window.matchMedia('(prefers-reduced-motion: reduce)').matches;
}オプション画面に「アニメーションを減らす」トグルを置き、変更時に localStorage に保存します。こうすることで、OS設定を持っていないユーザーでも、アクセシビリティの恩恵を受けられます。オプション画面を作るコストが小さくない場合は、まずOS設定への自動対応だけ実装して、後からゲーム内オプションを追加するという順番でも構いません。
次の行動
まず手元のゲームで window.matchMedia('(prefers-reduced-motion: reduce)').matches を開発者ツールのコンソールで実行し、OSの設定が正しく読み取れるか確認してください。その後、画面シェイクとパーティクルの2か所だけを対象に分岐を追加し、OSの「動きを抑える」設定をオンにしてプレイして動作を確認するところから始めると、影響範囲が小さく試しやすいです。できたゲームをアソバースに投稿する際は、説明文に「動きを抑える設定に対応」と一行書いておくと、同じ配慮を探しているプレイヤーに伝わります。
参考資料
- MDN Web Docs「prefers-reduced-motion」
- W3C WCAG 2.1 達成基準 2.3.1（3回点滅または閃光のしきい値）
- Apple Human Interface Guidelines「Accessibility / Motion」
- Google Material Design「Motion / Accessibility」
