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