# Astroブログでループ動画を一時停止可能にする — WCAG 2.2.2でGIFを、iOSのハードウェア非対応でVP9を退けた

> GIFには一時停止APIがなく、WCAG 2.2.2で不適合になった。VP9より大きいMP4を選んだのはiOSにVP9のハードウェアデコーダーがないため。エンコード手順とガード、テストの記録。

- Source: https://oharu121.com/ja/blog/astro-looping-video-figure-gif-pause-wcag-vp9-ios/
- Published: 2026-09-02T21:41:49+09:00
- Tags: Astro, Web API, iOS, アクセシビリティ

---
## はじめに

ダウンロードフォルダには2本のスライド画面録画が残っていた。もとの下書き記事では、MarpとReveal.jsの決定的な違いはスライド内アニメーションだと主張していたのに、そのアニメーションを1枚も見せていなかった。そこで一見ただの表示形式の質問を投げた。再生・一時停止ボタン付きのループクリップは、ブログで`<video>`をそのまま使うべきか、それともGIFに変換すべきか。そもそも動画ファイルをこのリポジトリで持つべきなのか、という問いも一緒だった。

最初の問いへの答えは、好みの問題ではなかった。**GIFは一時停止できない**ため、自分が求めたボタンによって、ファイルサイズを比較するより前にこのフォーマットは脱落した。2つ目の問いも一段階下で同じ結末をたどった。35%小さいVP9より重いMP4を選んだのは、**iOSにVP9のハードウェアデコーダーがない**からで、これは一度だけ再生する動画よりループするクリップにとってはるかに重要な違いだった。

この記事ではまず、アクセシビリティ要件がコンテナ形式を決めた理由と、コーデックに関する定番の助言がループコンテンツには当てはまらない理由を扱う。続けてエンコードのレシピと、Homebrewの`ffmpeg`ができない2つのことを説明する。後半はやや格好悪い話だ。ガードの中に潜んでいた3つのバグと、まだ証明していない結果を報告していた2つのテストを記録する。

## 前提条件と環境

- macOS（Apple Silicon）、ローカルはNode.js 26
- Astro 7.2、TypeScript 6.0
- Homebrew経由の`ffmpeg` 8.0
- このサイトが既に依存している`sharp` 0.35
- このサイトのすべての図版とスクリーンショットを囲み、クリックで`<dialog>`に開く既存の`Figure`コンポーネント

## GIFではそもそも成立しなかった理由

一時停止ボタンが要件であり、それがフォーマットを決めた。

ブラウザはGIFの再生に対して一切の操作手段を公開していない。`pause()`も`paused`も`play`イベントもなく、ボタンを結びつける先がない。GIFを止めるには静止フレームに差し替えるか、キャンバスに焼き付けて描き直すしかなく、それはアニメーションを一時停止しているのではなく、別の画像に置き換えているにすぎない。つまり自分が求めたコントロールは、このフォーマットでは扱いにくいという程度の話ではなかった。**実装そのものが不可能**だった。

これによって好みの問題が、達成基準を満たすかどうかの問題に変わる。WCAG 2.2の達成基準2.2.2（一時停止、停止、非表示）は、自動的に開始し5秒を超えて動き続けるコンテンツについて、利用者が一時停止・停止・非表示にできることを求めている。今回の2本のクリップはどちらも5秒を超える。したがってGIFは程度の問題ではなく**構造上**この基準を満たせず、配置の工夫で救うこともできない。

ファイルサイズは、既に決まっていた結論を裏付けたにすぎない。GIFは256色パレットしか持たず、フレーム間予測もまともに行わないため、同じ録画をGIF化するとH.264エンコードより**おおよそ10倍から20倍大きく**なり、それでいて見た目も劣る。

## web.dev自身の助言に反してMP4がVP9に勝った理由

アニメーションGIFを置き換える際のweb.devのガイドラインは明確だ。WebMとMP4の両方を用意し、**WebMを先に書く**べきだとしている。ブラウザはどのソースが最適かを推測せず、対応している最初の1つを採用するからだ。同じ画質であればWebM内のVP9はH.264よりおおよそ35%小さい。この助言に従うなら、このサイトはクリップごとに2ファイルを、WebMを先頭にして配信すべきということになる。

**実際に配信するのは1ファイルだけで、それはMP4だ。**

| | MP4 / H.264 | WebM / VP9 |
| --- | --- | --- |
| このクリップ2本のサイズ | 820 KB（実測） | 約530 KB（35%から推定） |
| iOSでのハードウェアデコード | あり | **なし** |
| Safariのクロマ制約 | なし | 4:2:0または4:2:2のみ |
| バージョンの下限 | 実質なし | iOS 15 |
| クリップごとの保持ファイル数 | 1 | 1、またはフォールバック込みで2 |

理由は**iOSにVP9のハードウェアデコーダーがない**ことだ。現行デバイスで`VTIsHardwareDecodeSupported(kCMVideoCodecType_VP9)`を試した開発者は`false`を返されており、WebKitは自前のWebMデマルチプレクサに、その裏でソフトウェアVP9デコードを実装している。1回だけ再生する動画であれば、ソフトウェアデコードのバッテリーコストは払って終わりだ。しかし**画面に映っている間ずっとループする**クリップでは、そのコストを継続的に払い続けることになる。そして今回のクリップはまさに、記事の中に置かれて繰り返し再生されるために存在している。

同じ調査からVP9のより小さな制約も2つ見つかった。Safariが対応するVP9のクロマサブサンプリングは4:2:0と4:2:2のみで、4:4:4でエンコードするとFirefoxとChromiumでは再生できてもSafariでは無音で失敗する。この問題はエージェントが確認した時点でもまだ未解決のままissueが開いていた。`<video>`内のWebMにはさらにiOS 15という下限があり、2026年時点では実質無視できる制約だが、H.264にはそもそも存在しない下限でもある。

エージェントが最初にMP4単独を主張した根拠は**間違っていた**もので、1メッセージ後に自ら撤回している。その根拠はgitの重さからの推論だった。バイナリはリビジョンごとに差分なしで丸ごと保存されるため、フォーマットを1つ増やせばリポジトリが永久に抱える容量が倍になる、という理屈だ。しかしその主張に実際の数字を当てはめると、根拠にならなかった。20本のクリップはH.264ならおよそ5MB、VP9ならおよそ3.2MBで、`.git`全体33MBに対してはどちらの数字も意味を持たない。**gitの重さは決め手ではなく、決め手として持ち出すべきではなかった**。決め手はハードウェアデコードの有無だった。

## エンコードと、Homebrewのffmpegができない2つのこと

レシピは1つで、両方のクリップに適用した。

```bash
ffmpeg -i raw.mov -vf scale=1324:-2 \
  -c:v libx264 -crf 28 -preset slow \
  -pix_fmt yuv420p -movflags +faststart -an \
  clip.mp4
```

`1324`は本文カラムのコンテンツ幅662pxの2倍で、Retinaディスプレイでは1CSSピクセルあたり2デバイスピクセルになる。`-2`は高さを偶数に丸めるための指定で、`libx264`が要求する。`-an`は音声を落とす指定だ。今回のクリップはもともと無音で、音声トラックがなければ自動再生ポリシーを気にする必要もなくなる。`+faststart`は`moov`アトムをファイルの先頭に移動させ、全体をダウンロードしきる前にストリーミング再生できるようにする。

Constant Rate Factor（CRF）の値は勘ではなく計測で決めた。エージェントは両方のクリップを24と28でそれぞれエンコードし、同じフレームを取り出して1:1で見比べた。小さな文字で比較表を表示しているスライドでは両者を見分けられず、しかも**28は29.6%小さかった**。短いクリップは156KB対204KB、長いクリップは664KB対960KBだった。もし24を勘で選んでいたら、2ファイル合計で344KB余分にかかっていたことになる。

続けて、Homebrewの`ffmpeg`はポスター画像の生成を拒んだ。

```
[vost#0:0 @ 0xc54c24300] Unknown encoder 'libwebp'
[vost#0:0 @ 0xc54c24300] Error selecting an encoder
Error opening output file .../marp-demo-poster.webp
Error opening output files: Encoder not found
```

このエラーは一見、コーデックが足りないというよりフラグの指定ミスのように読める。それこそが書き残す価値のある点だ。**Homebrewのビルドには、そもそもWebPエンコーダーが組み込まれていない**。しかもHomebrewは数年前にformulaごとのビルドオプションを廃止しているため、`--with-libwebp`のような指定手段も存在しない。解決策は`ffmpeg`でフレームをPNGとして取り出し、このサイトが画像最適化に既に使っている`sharp`で変換することだった。

**このポスター画像は二重に役立っており**、あれば嬉しい程度のものではなく、コミット対象のファイルとして扱う理由もそこにある。自動再生が起きなかったときに読者が目にするのはこの画像であり、`ImageMetadata`としてインポートされているため、その`width`と`height`が`<video>`要素にそのまま渡り、クリップが1バイトも読み込まれる前にレイアウト用の領域を確保してくれる。

## 読者に見えている範囲に絞った自動再生

ポスター表示を先にする案ではなく、一時停止ボタン付きの自動再生を選んだ。つまりクリップは自分から再生を始める。それを正当化しているのは、その自動再生を縛っている条件のすべてだ。

しきい値25%の`IntersectionObserver`が、クリップがビューポートに入ったら再生し、外れたら一時停止する。長い記事の中で2本のクリップが常時デコードされ続けることこそ、自動再生ループを正当化しづらくするコストであり、この仕組みがそれを取り除いている。**折り返しより下では何もデコードされない**。`preload="none"`と組み合わせているため、ダウンロードも発生しない。ページ2本目のクリップは、スクロールで表示されるまで`readyState: 0`のままだった。

実際に頭を使ったのは、読者が一時停止を押してからスクロールしたときの挙動だ。制御しているのは1つの真偽値で、ルールは**そのフラグを書き換えるのはバッジだけ**というものだ。オブザーバーは画面外に出たクリップを一時停止するがフラグには触れない。だから後で再開できる。一方、一時停止を押した読者は何かを要求しており、オブザーバーがそれを上書きすることは許されない。

*Figure — PauseOutranksObserver: どちらの経路もクリップを一時停止させるが、画面外に出て戻ってくる往復を生き延びるのは片方だけだ。オブザーバーは決してフラグを書き換えないからこそ、自分が一時停止したクリップを後で再開できる。*

`prefers-reduced-motion: reduce`はこの同じフラグをtrueで初期化する。これによって「この読者はモーションを減らしてほしいと望んでいる」状態と「この読者が一時停止を押した」状態は同じ1つの状態になり、どちらも再生ボタンを押せば元に戻る。また拒否された`play()`は例外ではなく通常の結果として扱う。iPhoneの低電力モードは自動再生をそのまま拒否するからだ。バッジのラベルは、自分が呼び出しをしたかどうかではなく`play`イベントと`pause`イベントから決まるため、拒否された場合はそのまま「再生」と表示され続ける。それが事実だからだ。

## 自分自身のUIにマッチしてしまったガード

動画には既存の`Figure`コンポーネントが持っていないコントロールが必要で、逆に持っているコントロールの1つを手放す必要もあった。拡大ダイアログは`<svg>`や`<img>`を`<dialog>`に複製するが、クリップをその方法で複製すると再生位置が失われてしまう。そのため動画figureは拡大鏡の代わりにフルスクリーンバッジを持つ。

拡大鏡を抑制する最初の試みは、一見わかりやすいものだった。ダイアログは既に自分のメディアを判定していたので、バッジも同じ判定を使えばよいはずだった。

```ts
if (!this.#frame.querySelector("svg, img")) return;
```

**これは何も効かなかった**。動画figureにも拡大鏡が復活し、クリックすると**再生ボタンの三角形**の上にダイアログが開いてしまうところだった。新しいコンポーネントの再生・一時停止アイコンは*実際に*`<svg>`要素であり、あのセレクタはそのsvgを見つけてしまっていたからだ。

*Figure — FrameSubtree: セレクタはframe全体に対して実行され、そのframeの中には拡大鏡ボタンも含まれている。自分自身のアイコンを持つ子要素であれば何であれ、本来figureのメディアを判定するはずだったテストを満たしてしまう。*

解決策は、探るのをやめて子要素自身に宣言させることだった。動画figureは`data-figure-owns-controls`属性を持ち、バッジ側のスクリプトはこの属性を見つけると処理を打ち切る。**オプトアウトは意図を明示するが、メディアを探る方法は意図を推測するだけ**であり、その推測はサブツリーに何か新しいマークアップが加わるたびに裏切られる。

## 発火しえないガード

`svg, img`による判定は第2のチェックとしてそのまま残されていた。svgでもimgでもない何かを包むfigureにはまだ効くはずだという想定だった。しかしリリース時のコードレビューで、この判定は**到達不可能**であることが判明した。

拡大鏡ボタンは、検索対象そのものの要素の中に存在し、しかもアイコンを描画している。そのためframeに対する`querySelector("svg, img")`は必ず何かにマッチし、`null`を返すことは決してない。エージェントがあるケースを捕まえるために書いた行も、それを「修正済み」と記述したCHANGELOGの記述も、どちらも実行され得ない分岐について書いていたことになる。

この判定が捕まえるはずだったバグ自体も残っており、しかもCHANGELOGが主張していたのとは違う形をしていた。テーブルを包むfigureでは、バッジを押すと拡大鏡のアイコン自体が全幅で描かれたダイアログが開いてしまう。CHANGELOGが言うような「何もしないコントロール」ではなかった。**むしろ、おかしなことをするコントロール**だった。

```ts
#media(): SVGSVGElement | HTMLImageElement | null {
  const candidates =
    this.#frame?.querySelectorAll<SVGSVGElement | HTMLImageElement>("svg, img") ?? [];

  for (const candidate of candidates) {
    if (!this.#badge?.contains(candidate)) return candidate;
  }

  return null;
}
```

`svg:not(.figzoom-badge svg)`のようなCSSではなくスクリプト側で絞り込んでいるのには具体的な理由がある。記事内のラスター画像は`.frame > p > img`という位置にあり、remarkが単独のMarkdown画像を`<p>`で包んでしまうからだ。どんな`:scope >`の書き方でもそこには届かない。

## フルスクリーンが実サイズのまま描画されていた

この不具合は、別のことを計測している最中に見つかった。図版ダイアログが背景クリックで閉じるのと同じように、動画の外側をクリックしたらフルスクリーンを終了すべきかを尋ねたところ、エージェントは1.94:1のクリップに対して実際にどれだけの「外側」があるのかを計測しに行った。

戻ってきた計測結果には、レターボックスの寸法に加えて誰も探していなかった数字が含まれていた。1920×1080の画面上でクリップは保存時のサイズそのままである1324×682で描画されており、**画面の56.5%が空白**のままだった。

*Figure — FullscreenSizing: クリップがインライン表示で既に持っていた686pxと比べると、壊れていたコントロールは1.9倍にしか広げていなかったのに対し、修正後は2.8倍まで広げる。小さな文字を読むことだけが目的の機能であることを踏まえると、この差は大きい。*

原因は、`<video>`に対する`width: auto`がファイルの実サイズに解決されてしまうことであり、`max-width: 100%`は縮小方向にしか制約をかけない。ここでフルスクリーンを用意しているのは読者が10pxのスライド文字を読めるようにするためであり、1920px幅の画面の中の1324pxでは、クリップがインラインで既に持っていた686pxとほとんど変わらない。

修正では、ポスター画像自身の寸法から取った比率を基準にサイズを決めるため、この数値がファイルの実態からずれることはない。

```css
video-figure:fullscreen video {
  width: min(100vw, calc(100vh * var(--video-ratio)));
  max-width: 100vw;
  height: auto;
  max-height: 100vh;
}
```

これは同じリポジトリがラスター画像に適用しているルールとあえて逆にしている。拡大ダイアログはスクリーンショットを実サイズより大きく描画することを拒否する。拡大は補間にすぎないからだ。違いは読者が何をしているかにある。図版ダイアログは細部を確認するためのものであり、それでも足りない読者はブラウザ側でさらにズームできる。一方クリップはインラインで半分のサイズのまま視聴されており、他に大きく見る手段がない。だからこそ**画面上での見かけの大きさが、1ピクセルあたりの精細さよりも優先される**。これまでに出荷されたあらゆる動画プレーヤーが、同じ結論にたどり着いている。

ここにも誘惑的だが間違った修正案があった。全画面いっぱいのボックスに`object-fit: contain`を使う案は一見同等に見えるが、実際には自分が求めていた機能を静かに壊してしまう。要素自体が画面全体を覆うことになり、レターボックスは`<video>`の一部になってしまい、画像の外側をクリックしても着地する場所がなくなる。

## 間違った結果を報告した2つのテスト

最初に書いた2つの検証ハーネスは、どちらも間違った結果を報告していた。しかも方向が逆だった。

*Figure — TestsThatLied: 誤った合格と誤った失敗が、同じセッションから生まれた。前者は本来重要な性質より弱い性質を検証しており、後者はすでに答えを引き継いでしまったオブジェクトを測っていた。*

誤った合格は、検証すべき性質を取り違えたことから生まれた。JavaScriptが無効な状態では、すべてのコントロールが非表示のままであるはずで、そのチェックは各バッジに対して`hasAttribute("hidden")`を検証していた。4つとも`true`が返り、実行結果は検証済みと報告された。しかしコンポーネント自身のCSSには`:not([hidden])`の限定なしで`.badge { display: grid }`とだけ書かれていた。**author側の宣言はユーザーエージェントスタイルシートの`[hidden] { display: none }`に勝つ**。hidden属性は存在していたが無視されていたのだ。スクリプトが一度も走らなかったページ上には、ポスター画像の上に4つの死んだコントロールが描画されており、そのテストは結果ではなく属性の存在だけを確認していたことになる。既存の`Figure`コンポーネントがまさにこの理由で`.figzoom-badge:not([hidden])`を書いており、コメントにもその旨が記されている。

次に起きたのが誤った失敗で、`#media()`の修正が効いていることを証明するために書いたテストだった。このテストは既にハイドレーション済みの要素を複製し、メディアを取り除いてから追加し、バッジが非表示のままかどうかを検証していた。非表示のままではなく、実行結果は「ガードが壊れている」と報告した。**しかしガードは正常だった**。カスタム要素を複製すると、そのコンストラクタは空のノードに対して実行されるため、フィールドの初期化処理は何も見つけられず、`connectedCallback`は何も変更しないまま早期リターンする。一方で複製された要素には、コピー元から引き継いだ`hidden = false`と`data-ready`がそのまま残っていた。

再テストを信頼できるものにしたのは**正常系を並べて走らせたこと**だった。この再テストは`insertAdjacentHTML`というパーサー経由の方法で要素を組み立てるため、要素がアップグレードされる前に子要素が存在しており、サーバーレンダリングされたページとまったく同じ状況になる。さらにハイドレーションが変更していた2つの属性をリセットし、メディアがない場合のケースと並べてメディアがある場合のケースも実行する。証拠になるのはこのペアだけだからだ。

```
positive control (media present): {"badgeHidden":false,"frameReady":true,"svgsInFrame":2}
guard under test (no media):      {"badgeHidden":true,"frameReady":false,"svgsInFrame":1}
```

**frame内にsvgが2つあれば図版と拡大鏡の両方が揃っており、バッジは表示される。svgが1つだけなら拡大鏡しかなく、バッジは表示されない**。正常系を伴わないガードのテストでは、**正常に動くガードと壊れたテストハーネスを区別できない**。今回のセッションでは、この2つの失敗パターンがそれぞれ1回ずつ実際に起きた。

## 検証できず、そのままになったこと

**確認できなかったことが3つある**。それを正直に書いておくほうが、確認済みであるかのように装うより安上がりだ。

**Escapeキーでフルスクリーンを終了する動作**。このバインディングはページではなくブラウザのUI側に存在しており、CDP経由で注入した`Escape`はそこに届かない。ヘッドレスChromiumでも、DevToolsプロトコル経由で操作する実際のChromeでも同様だ。これはこのコンポーネントが実装しているわけでも壊しうるわけでもない標準的なブラウザの挙動だが、今回一度も動作しているところを確認できてはいない。Escapeを押して動作したものとみなしてしまうテストは、ページをフルスクリーンのままにしてしまい、後続の実行で無関係な要素に対する`subtree intercepts pointer events`という紛らわしいエラーで失敗する原因になった。

**Vercelのプレビュー環境**。デプロイ保護の背後にあるため、ヘッドレスでのfetchはログインページにリダイレクトされ、サインイン済みのブラウザからしか開けない。

**本番環境でのクリップ**。クリップを含む記事はまだ`status: 'draft'`のままで、`astro build`はこれをスキップするため、ビルドが通ってもこの部分は一切検証されない。実際に本番に届いた変更は、すべての拡大figureに共通の閉じるコントロールであり、そちらのほうがリスクとしては大きい半分でもある。下書き1本ではなく既存の86個のfigureに影響するからだ。

## まとめ

コンテナ形式を決めたのは好みではなくアクセシビリティ要件だった。GIFには一時停止APIがないため、WCAG 2.2の達成基準2.2.2は5秒を超えるすべてのクリップに対してこのフォーマットを排除する。ファイルサイズが議論に入ってくるより前に、フォーマットは決まっていたことになる。

コーデックの選択は、定番の推奨とは逆になった。web.devはWebMを先に、MP4をフォールバックにと言うが、画面上でループするクリップに関してはiOSでのVP9ハードウェアデコード非対応がこの助言を裏返してしまう。**その助言自体は正しく、ただし想定している範囲は見た目より狭い**。1回きり視聴する動画とループするfigureは、配信の問題として同じではない。

セッションの残りは、バグが実際にどこに潜んでいるかについての教訓だった。3件はいずれもバグを防ぐために書いたコードの中にあった。想定していなかったアイコンに裏をかかれたガード、到達不可能になった後も残されたままだった同じガード、本来サイズを設定すべきところをただ制約するだけになっていたフルスクリーンのルールだ。これらが見つかるより前に、2つのテストハーネスが間違った結果を報告しており、一方は根拠なく合格し、もう一方は不具合がないのに失敗していた。エンコードを計測したことで344KBを節約できた。そしてガードを計測したことこそが、3つのもっともらしい修正を3つの本物の修正に変えた。

## 参考リンク

- [ページ読み込みを高速化するためにアニメーションGIFを動画に置き換える。WebMを先に両方のフォーマットを用意するという推奨の出典](https://web.dev/articles/replace-gifs-with-videos)
- [画像を超えて、Web向けの基本的な動画を扱う](https://web.dev/articles/video-basics)
- [WCAG 2.2 達成基準2.2.2 一時停止、停止、非表示](https://www.w3.org/WAI/WCAG22/Understanding/pause-stop-hide.html)
- [iOSでVTIsHardwareDecodeSupportedがVP9に対してfalseを返すApple Developer Forumsのスレッド](https://developer.apple.com/forums/thread/664770)
- [SafariがVP9を4:4:4クロマでデコードできない問題を扱う、まだ開いたままのcaniuse issue 7541](https://github.com/Fyrd/caniuse/issues/7541)
- [iOS 15という下限も含む、WebM動画フォーマットの対応状況表](https://caniuse.com/webm)