キーボード・リモコン・スイッチでインタラクティブ映画を同等に操作する方法
クリック専用の選択を、キーボード、テレビのリモコン、スイッチ操作で同じ結果へ進める課題に変え、移動・決定・取消・誤操作防止・機器切替を検証します。
はじめに
三つの入力を別々の追加機能にせず、「選択へ移動、決定、戻る、再生を操作」という共通課題を定義します。どの入力でも同じ物語結果へ進めることが重要です。
インタラクティブ映画のアクセシビリティは、公開前に字幕だけを確認すれば終わるものではありません。選択画面、再生操作、分岐状態、映像と音声が一つの体験を構成します。どこか一層でも知覚・操作・理解できなければ、視聴者は物語を続ける手段を失います。WCAG 2.2は、ウェブコンテンツを知覚可能、操作可能、理解可能、堅牢にする原則を示しています。本稿は関連する考え方をインタラクティブ映画の制作方法へ応用しますが、これだけで適合を証明するものではありません。配信基盤、対象市場、障害のある利用者によるテストを別途確認してください。
合否を判断できる体験の約束を書く
ブラウザーはマウス、テレビは方向キー、スイッチ利用者は順次走査で最初の選択を操作します。フォーカスの開始点、循環、決定時点を共有しなければ、同じノードの操作性が機器ごとに変わります。
例には架空の短編『霧の港から届いた手紙』を使います。視聴者は夜の港で差し替えられた手紙を調べ、倉庫、待合室、灯台のどこへ向かうかを選びます。人物、分岐、テスト記録、素材番号はすべて学習用の創作です。実在する利用者事例、実施済みのテスト結果、DramaFork が自動提供する機能ではありません。
最初に体験の約束と失敗条件を一文ずつ書きます。約束には、誰が、どの機器と状況で、何を完了できるべきかを含めます。失敗条件は公開を止める境界です。「キーボードだけで全選択を完了できる」は検証できますが、「キーボードに優しい」は検証できません。方向入力で移動、決定で実行、戻るでメニューを閉じます。走査には明確な停止と一つのスイッチによる決定を用意します。機器を替えても現在のフォーカスを保ち、長押し、連続入力、誤操作の処理も決めます。
要件・実装・証拠を同じ表で結ぶ
| 項目 | 確認する問い | 証拠 |
|---|---|---|
| 視聴者の課題 | 何を知覚し、判断し、操作する必要があるか | 課題と利用状況を示す一文 |
| 操作規則 | 標準手段と代替手段が同じ結果に着くか | 入力、フォーカス、時間、表示の規則 |
| 分岐への影響 | 設定変更、戻る操作、再開で物語状態を保てるか | 入口・出口・保持状態の記録 |
| 受け入れ確認 | 誰がどの機器で調べ、失敗をどこへ戻すか | ルート番号、操作記録、担当者 |
H02 では倉庫と待合室を選びます。キーボードは Tab または矢印、リモコンは左右、走査は一定順序で移動します。どれも同じ destination 状態を書き、同じ受け付け反応を返します。
四項目は同じ版を参照させます。画面案だけ更新すると、以前の欠陥が直ったか判断できません。コードだけ変えると、「反応した」を「理解できた」と取り違えます。編集、操作設計、開発、品質確認が受け入れるのは、静止画ではなく再現可能な一連の体験です。
制作工程へ五段階で組み込む
まず主ルート、短縮ルート、戻るルート、無入力ルートを列挙し、選択、再生操作、重要情報を記録します。次に各課題へ標準手段と代替手段を用意し、どちらも同じ物語上の結果へ到達させます。三つ目に規則を安定したシーン番号、素材番号、状態項目へ結び、文言修正で追跡関係が壊れないようにします。
四つ目は仕上げ前の低コスト確認です。キーボードだけ、文字拡大、動きの低減、停止後の再開をそれぞれ試します。五つ目に複数機器と支援技術で確認し、手順、期待結果、実際の結果、証拠の場所を残します。機器、動作、連続入力、取消方法、反応を入力対応表へ記します。マウスを外して各方式だけで結末まで進み、途中で二回機器を替えてフォーカス、停止状態、分岐が保持されるか確認します。
記録には「問題なさそう」と書かず、「H02 から入り、代替設定を有効にし、左の行動を選び、clue_letter=true を確認し、H03 の冒頭がその状態を反映することを確認」と書きます。入口、行動、反応、出口が一続きになり、失敗時に入力、表示、物語状態のどこを調べるか判断できます。
不具合はシステムの境界で起きやすい
キー処理だけを加えてフォーカスを管理しないと、実行できても見つけられません。画面順と逆のリモコン移動や、停止・取消のない走査も失敗です。利用者の誤りではなく入力経路の欠陥として扱います。
支援設定が深い設定画面に隠れていると、必要な人がそこへ着けません。起動時、最初の選択、停止メニューから見つけられる入口を用意します。変更後はすぐ知覚できる反応を返し、次のノードでも有効にします。再読み込みで消えるなら、公開前に直すか制約を明示します。
自動検査は名前の欠落、一部のコントラストやフォーカス問題を見つけられます。しかし、選択文が理解しやすいか、音声解説が別分岐を明かしていないか、停止が理解を損なわないかは判断できません。ルートを通した人手の確認と障害のある利用者の参加が必要です。文章は編集、素材は音響・ポストプロダクション、状態は開発、範囲の衝突は責任者へ戻します。
公開判定は完全な手順を対象にする
各入力で導入、選択、停止、再開、結末を完了し、キーボードトラップがなく、機器変更で物語状態が変わらず、決定反応を視覚と音声または支援技術で確認できることを合格条件にします。
最低限の公開資料には、機能範囲、ルート一覧、設定の初期値、五言語の画面文、確認した機器と入力方法、既知の制約、不具合担当者、開始から結末までの記録を含めます。W3C の資料は規格と解説です。本稿の表、ノード名、架空事例は編集上の方法であり、W3C が指定する固定様式ではありません。
ブラウザー、テレビ、支援スイッチは異なるイベントを出します。本稿は共通課題と検証法を示すもので、すべての機器に共通するキー配置を保証しません。実機と版を公開記録へ残します。
最後に制作へ参加していない人に、記録だけで体験を再現してもらいます。「何を押すのか」「残り時間は」「この合図の意味は」「再開位置は」と尋ねる必要が残るなら、引き継ぎは未完了です。答えを規則と証拠へ書き戻してから公開します。
参考資料：W3C Understanding SC 2.1.1: Keyboard、W3C Understanding SC 2.5.8: Target Size (Minimum)。
