AI はアクセシビリティとアニメーションを両立できるか

アニメーションの多いサイトを、見た目の楽しさを残したままアクセシビリティ対応したい。この相談に AI で応えられるかを、Claude に UI を作らせて確かめました。結果は「両立できた。ただし手順つきで」です。アコーディオンやカルーセルなど 6 つの UI で、どこがぶつかり、どう落としどころを決めたかをまとめます。

---

動きを残すと基準に引っかかり、止めるとサイトらしさが消える

きっかけは、エンタメ系の遊び心のあるアニメーションが入ったサイトを、アクセシビリティの観点で改修したいという案件でした。求められるのは WCAG レベル AA を満たすことです。

悩ましいのは、動きを残すと基準に引っかかる箇所が出て、すべて止めるとそのサイトらしさが消えてしまう点でした。両方を満たす作り方を AI が出せるなら、改修の進め方が変わります。

最初は「アニメーションとアクセシビリティを両立した UI を作って」とそのまま頼みました。返ってきたのは、動きとしても物足りず、アクセシビリティとしても詰めの甘い UI です。一度の指示で両方を満たそうとすると、どちらにも寄り切れない結果になりました。

極端な 2 案を作らせてから両立版を作る

そこで、あえて極端に作ってぶつかる場所を見る手順に切り替えました。

1. サイトでよく見る UI を 6 つ選ぶ（アコーディオン / モーダル / カルーセル / ボタンのホバー / ハンバーガーメニュー / スクロール連動の登場演出）
2. 「動き全開」版を作らせる。アクセシビリティは考慮させない。ただし実際のサイトで使える程度の動きに留めるよう指示する
3. 「アクセシビリティ最優先」版を作らせる。動きは使わない
4. 2 つを並べてぶつかった点を見て、落としどころを人が決める
5. 「両立」版を作らせ、検査にかける

判定に使った 6 項目

WCAG の AA には多くの達成基準があります。今回は動きと操作に関わる 6 項目に絞って判定しました。

加えて、OS の「視差効果を減らす」「動きを減らす」といった設定にも従うようにしました。AA の必須項目ではありませんが、動きが苦手な人への追加の配慮として入れています。

6 つの UI で起きた衝突と落としどころ

ここからは UI ごとに、動き全開版の代償、アクセシビリティ最優先版の代償、両立版の落としどころを見ていきます。動き全開版は 6 つすべてでキーボード操作ができなかった ことが最大の問題でした。

各 UI の動画は、左が動き全開版（Before）、右が両立版（After）です。どちらにも同じ操作を同時に行っています。前半はマウスでの操作、後半はキーボードでの操作で、赤い丸はマウスの位置を示しています。

アコーディオン

動き全開版は、開閉のたびに回転し、弾み、飛び出す動きがついていました。ポップなサイトなら採用できそうな動きですが、キーボードではまったく操作できません。

アクセシビリティ最優先版はキーボードで開閉でき、開いている・閉じている状態も読み上げられます。その代わり動きがなく、地味な見た目になります。

両立版では「開くたびに弾む楽しさ」と「答えをすぐ読みたい」がぶつかりました。button 要素でキーボード操作と開閉状態の読み上げに対応し、動きは 0.4 秒の開閉とホバーだけに絞っています。

モーダル

動き全開版は回転しながら飛び出して登場しますが、キーボードでは開くことも閉じることもできません。

アクセシビリティ最優先版は、開いた瞬間にフォーカスがモーダルの中へ移り、Esc で閉じられ、Tab を押してもフォーカスが背景のボタンへ抜けません。モーダルで見落とされやすいのはこのフォーカスの扱いです。

両立版は標準の dialog 要素を使い、Esc で閉じる・フォーカスを移すといった挙動をブラウザに任せました。動きは登場時の 0.25 秒だけです。

カルーセル

動き全開版は 1.5 秒ごとに自動で切り替わり、文字も揺れ続けます。利用者が止められないので、2.2.2 にはっきり反します。

アクセシビリティ最優先版は自動再生をやめ、「前へ」「次へ」とページ番号のボタンで操作します。いま何枚目かも読み上げられますが、自分で押さないと動きません。

両立版は 4 秒ごとの自動再生に一時停止ボタンを付けました。ホバー中やフォーカス中は止まり、OS で動きを減らす設定をしている人の環境では最初から動きません。

ボタンのホバー

動き全開版はホバーで拡大して震え、クリックで一回転します。キーボードで操作できないうえ、スマートフォンやタブレットでタップする場合は演出そのものが見えません。

アクセシビリティ最優先版はホバーでもフォーカスでも色が反転し、「カートに追加しました」と読み上げます。ただ、カートに入れるという大きなアクションに対して手応えが弱くなりました。

両立版はホバーとフォーカスに同じ 0.25 秒の浮き上がりを付け、追加時には手応えのある演出を入れたうえで、同じ内容を読み上げでも伝えます。

ハンバーガーメニュー

動き全開版はアイコンがくるっと回って × に変わり、項目が飛び込んできます。キーボードで操作できず、何のボタンか、いま開いているのかも読み上げでは伝わりません。

アクセシビリティ最優先版は、アイコンの横に「メニュー」の文字を添え、開閉状態を読み上げ、Esc で閉じられるようにしました。

両立版も「メニュー」の文字と開閉状態の読み上げは残し、アニメーションを最低限に抑えています。抑えても、動きが入っていることは見た目で十分に伝わりました。

スクロール連動の登場演出

この UI だけは、後半で操作を変えています。OS の「動きを減らす」設定をオンにしてから、もう一度スクロールしました。

動き全開版はスクロールするたびにカードが回転しながら飛び込んできます。動きが苦手な人には負担になり、OS の動きを減らす設定も無視し、キーボードでも操作できません。

アクセシビリティ最優先版は最初からすべてを表示し、領域にフォーカスを当ててキーボードでスクロールできます。登場の楽しさはなくなります。

両立版は 0.5 秒のふわっとした登場に変えました。動きを減らす設定やページの「動きを止める」ボタンを使うと、最初から全部表示されます。

6 つに共通する対応

UI ごとの対応とは別に、背景の装飾が動き続けて止められない点も 2.2.2 に反していました。両立版ではページに「動きを止める」ボタンを置き、OS の設定と合わせてすべての動きを止められるようにしています。点滅は使っていません。

振り返ると、両立版の多くは button や dialog といった標準の HTML 要素を正しく使うこと で、フォーカス・キーボード操作・状態の読み上げをまかなえていました。そのうえで動きは時間を短く、範囲を狭くして足しています。

3 つの版を検査した結果

作った 3 つの版は、AI に検査させました。結果は次のとおりです。

今回の 6 項目では、アクセシビリティ最優先版と両立版が基準を満たしました。動き全開版で満たせたのは、文字の色と点滅だけです。

検査を AI に任せられたのはコードから判定できる項目までで、読み上げが実際にどう聞こえるかは人が実機で確認 しています。開閉状態やカート追加の読み上げは、事前にスクリーンリーダーで聞いて確かめました。

両立はできたが、毎回 3 倍の作業はできない

AI はアクセシビリティとアニメーションを両立できたか、という問いへの答えは「できた」です。ただし今回は、極端な 2 案を作ってから両立版を作る手順が前提でした。役割分担は次のようになりました。

• 極端な 2 案を作らせる: 動き全開とアクセシビリティ最優先を並べると、ぶつかる場所が見える
• 落としどころは人が決める: AI は実装と比較を引き受け、どこで折り合うかの判断は人が持つ
• 検査させて直す: コードで判定できる項目は AI に任せ、読み上げの実機確認は人が行う

課題は作業量です。毎回極端な 2 案を作ってから両立版を作ると、単純に 3 倍の作業になり、実案件では現実的ではありません。今回の落としどころ（標準要素を使う、動きは短く、止める手段と OS 設定への追従を必ず入れる）をプロンプトに織り込み、最初から両立版を出せるようにしていくのが次の取り組みです。

もう 1 つ、Figma などで上がってきたデザインを AI 駆動開発でどう再現するかも、やり方が多すぎてまだ定番が見えていません。PRD からデザインまで AI に作らせる流れと、デザインが先にある流れとでは、向いている手順が違いそうだと考えています。

AI を使ったアクセシビリティ検査の自動化は Claude でアクセシビリティチェックをどこまで自動化できるか検証した記事、アニメーションの作り込みは Claude Design で Web サイトのアニメーションを作った記事 でも紹介しています。デザインと実装を AI と一緒に進める体制づくりは、AIDD デザイン でご相談いただけます。