WCAG 2.2.3: タイミングなし

WCAG 2.2.3（レベルAAA）は、非インタラクティブな同期メディアおよびリアルタイムイベントを除き、コンテンツによって提示されるイベントやアクティビティにおいて、タイミングが本質的な要素であってはならないと求めています。これは、読む・操作する・応答するのにより多くの時間を必要とする障害のあるユーザーが、時間に依存したデザインによって決して排除されないようにするためのものです。

この規定が意味すること

WCAG 2.2.3 — No Timing（時間制限なし）は、ガイドライン 2.2「十分な時間」の下にある AAA 適合レベルの達成基準です。その要件は明確で、ユーザーに提示されるあらゆるイベントやアクティビティにおいて、時間が本質的な要素であってはならないというものです。言い換えると、コンテンツや機能に時間制限、締め切り、あるいは何らかの形の時間依存のインタラクションが含まれる場合、その時間依存性は取り除けるか、またはそのタスクにとって完全に無関係でなければなりません — ただし、限定的な例外のいずれかに該当する場合を除きます。

この達成基準は、レベル A の達成基準 2.2.1（Timing Adjustable：時間調整可能）やレベル AA の達成基準 2.2.2（Pause, Stop, Hide：一時停止、停止、非表示）よりも踏み込んだ内容です。これらの達成基準では時間制限の調整や一時停止を認めていますが、2.2.3 は、そもそも時間が意味のある制約として存在してはならないと求めています。フォームの入力、メニューのナビゲーション、ワークフローの完了に 10 秒かけるユーザーも 10 分かけるユーザーも、瞬時に終えるユーザーと同じ結果に到達できなければなりません。

適合とみなされるケース：時間制限が存在しないコンテンツ、または存在する時間制限が純粋に装飾的で結果に影響しないコンテンツ（例：ループ再生されるが操作を妨げないアニメーション）。ユーザーがどれだけ時間をかけても完全に機能するコンテンツは、この達成基準に適合します。

不適合とみなされるケース：非アクティブ状態が続くとユーザーをログアウトさせるセッションタイムアウト、一定時間内に完了しないと得点や完了が左右される時間制限付きクイズや評価、商品を削除するショッピングカートの有効期限タイマー、入札を締め切るカウントダウン付きオークション入札インターフェイス、有効期限があるワンタイムパスワード（OTP）入力欄、時間制限付き CAPTCHA チャレンジ、経過時間に基づいて利用できなくなったり自動送信されたりするあらゆるインタラクティブ要素などです。

WCAG が定める公式の例外：この達成基準は明示的に 2 つのカテゴリーを免除しています。1 つ目はリアルタイムの例外で、ライブオークション、ライブ配信、リアルタイムのマルチプレイヤーゲームなど、時間が活動に本質的に組み込まれているイベントです。2 つ目は本質的な例外で、時間制限を取り除くと活動そのものが根本的に変質してしまう状況です。例えば、タイピング速度の習熟度テストは本質的に速度を測定するため、時間は不可欠です。ただし、開発者やプロダクトオーナーは厳密でなければなりません。利便性、技術的負債、ビジネス上の好みは「本質的」とは認められません。時間制約がなければ活動がその核心的な意味や目的を失ってしまうかどうかが判断基準です。

また、同期メディア — 例えばキャプション付きの事前録画動画 — も除外される点は重要です。メディア再生のタイミングはユーザー自身のメディアプレーヤーによって制御されており、ページ上の他の部分とユーザーのインタラクション能力に制約を課すものではないためです。

なぜ重要なのか

ウェブ上の時間制限は、幅広い障害のあるユーザーに不均衡な悪影響を与えます。その影響は抽象的なものではなく、多くのユーザーにとって、時間制限のあるインターフェイスは事実上アクセス不能です。

運動障害のあるユーザー — スイッチアクセスデバイス、マウススティック、視線追跡ソフトウェア、その他の代替入力手段を使用する人を含め — は、マウスとキーボードを使うユーザーとは根本的に異なるペースで操作します。複数ステップのフォームを完了したり、ドロップダウンメニューをナビゲートしたりするには、数倍の時間がかかることがあります。セッションタイムアウトや自動的に期限切れになるカートは、数分間にわたる慎重で大きな労力を一瞬で無にしてしまう可能性があります。

認知障害のあるユーザー（ディスレクシア、ADHD、情報処理障害、脳損傷などを含む）は、指示を読む、選択肢を理解する、回答を作成するといった作業に、かなり多くの時間を必要とする場合があります。Web Accessibility Initiative がまとめた調査では、認知・学習障害は何らかの形で世界人口のおよそ 15–20% に影響すると推定されています。これらのユーザーにとって、カウントダウンタイマーは単にストレスになるだけでなく、タスク完了に必要な認知処理を実際に妨げます。

スクリーンリーダー利用者である全盲やロービジョンのユーザーは、コンテンツを線形にナビゲートし、インターフェイス要素を順番に聞いたり読んだりしなければなりません。複雑なページの構造や選択肢を理解するには、視覚的にざっと目を通すことができる晴眼者よりも時間がかかります。慎重に注文内容を確認している最中に有効期限が切れてしまう時間制限付きのチェックアウトフローは、視覚障害のあるユーザーにとって商取引への直接的な障壁となります。

不安障害のあるユーザーは、カウントダウンタイマーが存在するだけで、たとえ時間的には十分な余裕があっても、タスク完了を妨げるほどの認知的・感情的負荷が生じることがあります。時間を要因から取り除くことで、この障壁は完全に解消されます。

具体的な現実のシナリオ：5 分間の非アクティブ状態でタイムアウトし、60 秒で期限切れになる OTP を組み合わせたオンラインバンキングポータルを考えてみましょう。入力に支援技術を必要とするパーキンソン病のユーザーや、アプリを素早く切り替えることに慣れていない高齢のユーザーは、SMS を受信し、アプリを切り替え、コードを読み、再度切り替えて入力することを、定められた時間内に物理的に行えないかもしれません。彼らはセキュリティ上の必然性ではなく、恣意的な時間制限によって自分の口座から締め出されてしまいます。OTP の有効期間をより長く設定する（あるいは厳格な有効期限を廃止し再送メカニズムに置き換える）ことで、セキュリティを損なうことなくこの問題を解決できます。

アクセシビリティの観点を超えても、不要な時間制限を取り除くことは一般的なユーザビリティを向上させ、離脱率を下げます。途中で期限切れにならない EC のチェックアウトは、より多くの顧客を維持し、コンバージョンを高め、サポート負荷を軽減します — つまり、倫理的な必須事項であると同時に、ビジネスにとってもプラスの変化です。

テスト方法

自動ベースラインスキャン：axe DevTools や Lighthouse をページで実行し、2.2.1 や 2.2.2 でカバーされるような、より低レベルの時間関連の違反を特定します。これらは、より深い手動検証が必要な領域を示す手がかりになります。axe には 2.2.3 を直接テストするルールはありませんが、時間制限の警告や自動リフレッシュに関する検出結果は、手動監査の範囲を絞り込むのに役立ちます。Lighthouse では、「Accessibility」セクションで時間関連のフラグを確認します。
時間依存の機能をすべて洗い出す：テスト前に、アプリケーション内の時間が関係しそうな機能を体系的に一覧化します。これには、セッション管理と非アクティブ時のタイムアウト、OTP や認証コード入力欄、ショッピングカートや予約のホールド、時間制限付きクイズ・評価・アンケート、オークションや入札インターフェイス、CAPTCHA チャレンジ、送信期限付きの自動保存メカニズム、目に見えるカウントダウンや進捗タイマーなどが含まれます。
セッションタイムアウトの挙動をテストする：アプリケーションを開き、複数ステップにまたがるタスク（例：複数ページのフォーム入力やチェックアウトの完了）を開始します。想定されるタイムアウト時間を超える間、操作を行わずに放置します。その後、続行を試みます。進捗が保持されているか、警告とセッション延長の手段が提供されているか、あるいはログアウトされたりデータを失ったりするかを観察します。適合とみなされるには、タイムアウトが存在しないか、タイムアウトが純粋に予防的で再認証後もデータが保持されるか、またはユーザーに十分な警告と制御が与えられている必要があります。
OTP とコードの有効期限をテストする：OTP や認証コードのフローを開始します。コードの表示上の有効期限を過ぎるまで（あるいは時間が表示されない場合はそれ以上）待ちます。その後、コードの入力を試みます。システムが時間だけを理由にコードを拒否する場合、これは 2.2.3 の不適合です。注意：単に「コードを再送」する仕組みがあるだけでは 2.2.3 の問題は解決しません — 元のコードの有効期限が依然として時間制限を課しているためです。
スクリーンリーダーテスト（NVDA + Firefox）：NVDA と Firefox を使用し、キーボードとスクリーンリーダーのみで時間制限のあるインターフェイスをナビゲートします。支援技術によるナビゲーションのオーバーヘッドを含め、各ステップにどれくらい時間がかかるかを確認します。意図的にゆっくり進み — すべての指示を聞き、仮想カーソルで全ての選択肢を確認したうえで — 送信や次への進行を試みます。ゆっくりしたナビゲーションがタイムアウトや状態の喪失を引き起こさないことを確認します。
スクリーンリーダーテスト（VoiceOver + macOS の Safari）：macOS の VoiceOver と Safari を使って、同じくゆっくりとしたナビゲーションテストを繰り返します。特に動的なカウントダウンタイマーに注意し、VoiceOver が残り時間を緊迫感を生むような形で読み上げていないか、また時間切れになったときにインターフェイスが失敗しないかを確認します。
スクリーンリーダーテスト（JAWS + Chrome）：JAWS と Chrome を使用して同じフローをテストします。JAWS ユーザーはプロフェッショナルなスクリーンリーダーユーザーの大きな割合を占めており、NVDA ユーザーに影響するタイミングの問題は、通常 JAWS ユーザーにも同様に影響します。
例外の正当性を検証する：開発チームが「本質的」または「リアルタイム」と主張する時間制限について、その根拠を文書化し、時間が本当に活動の目的に内在しているのか、それともタスクの本質を変えずに緩和・延長・削除できるのかを評価します。

修正方法

セッションタイムアウト — 不適切な例

<!-- Session expires after 5 minutes of inactivity with no warning.
     User data is lost and they are redirected to login. -->
<script>
  setTimeout(function() {
    window.location.href = '/logout?reason=timeout';
  }, 300000);
</script>

セッションタイムアウト — 適切な例

<!-- No automatic session expiry on inactivity.
     Server session is maintained as long as the browser tab is open.
     If a timeout is legally required (e.g. banking regulation),
     warn the user well in advance and offer to extend the session
     without time pressure on the extension dialog itself. -->
<div role='dialog' aria-modal='true' aria-labelledby='session-dialog-title' aria-describedby='session-dialog-desc' id='session-warning' hidden>
  <h2 id='session-dialog-title'>Your session is about to expire</h2>
  <p id='session-dialog-desc'>For your security, your session will expire due to inactivity. Would you like to stay signed in?</p>
  <button type='button' id='extend-session'>Stay signed in</button>
  <button type='button' id='end-session'>Sign out now</button>
</div>
<!-- The "Stay signed in" button itself has no expiry —
     the user can take as long as they need to find and activate it. -->

有効期限付き OTP フィールド — 不適切な例

<!-- OTP expires in 60 seconds. After expiry, form submission
     returns an error and the user must restart the entire flow. -->
<label for='otp'>Enter the code sent to your phone</label>
<input type='text' id='otp' name='otp' autocomplete='one-time-code' inputmode='numeric' maxlength='6'>
<p aria-live='assertive'>Code expires in: <span id='countdown'>60</span> seconds</p>
<button type='submit'>Verify</button>

有効期限付き OTP フィールド — 適切な例

<!-- OTP does not expire within a short user-facing window.
     A longer server-side validity period (e.g. 15-30 minutes) is used.
     A resend option is available but the original code remains valid.
     No countdown timer is shown, removing false urgency. -->
<label for='otp'>Enter the 6-digit code sent to your phone</label>
<input type='text' id='otp' name='otp' autocomplete='one-time-code' inputmode='numeric' maxlength='6'>
<p>The code is valid for 30 minutes. <button type='button' id='resend-otp'>Send a new code</button></p>
<button type='submit'>Verify</button>
<!-- Server invalidates the code after first successful use,
     not after a short time window. -->

時間制限付きクイズ — 不適切な例

<!-- Quiz auto-submits when the 10-minute timer reaches zero,
     regardless of whether the user has finished answering. -->
<div id='quiz-timer' aria-live='polite'>Time remaining: <span id='time-left'>10:00</span></div>
<form id='quiz-form'>
  <!-- quiz questions -->
  <button type='submit'>Submit Quiz</button>
</form>

時間制限付きクイズ — 適切な例

<!-- Quiz has no time limit unless timing is the explicit
     subject being assessed (e.g. a certified speed test).
     If an optional time indicator is shown for user reference,
     it does not trigger auto-submission or penalise slow completion. -->
<form id='quiz-form'>
  <!-- quiz questions -->
  <button type='submit'>Submit Quiz</button>
</form>
<!-- If a time reference is genuinely needed, it is informational only:
<p>Most users complete this in about 10 minutes. Take as long as you need.</p> -->

よくある間違い

セッションのセキュリティには厳格なタイムアウトが必要だと決めつける：多くのチームはセキュリティ要件を理由に短い非アクティブ時タイムアウトを実装しますが、ほとんどのセキュリティ標準（PCI-DSS や OWASP を含む）は、ユーザーによるセッション延長を認めています。警告や延長の機会なしに強制ログアウトすることは、セキュリティ上の必然ではなくアクセシビリティ上の不適合です。
停止や延長手段を提供せずにカウントダウンタイマーだけを表示する：カウントダウンに aria-live 領域を追加すると、スクリーンリーダーユーザーにとっては状況を悪化させます — 毎秒読み上げられるだけで、根本的な時間の問題は解決されません。修正すべきなのは制約そのものであり、それをよりアクセシブルに告知することではありません。
「コード再送」を OTP 有効期限の解決策だとみなす：再送ボタンを提供すると新しいコードを取得できますが、元のコードが時間制限によって期限切れになる事実は変わりません。時間制限は依然として存在します。正しい修正は、有効期間を延長して時間的なプレッシャーを取り除くことです。
非アクティブ時に自動で進むカルーセルやウィザードステップ：一定時間後に自動的に次のステップへ進むマルチステップフォームやウィザードは、時間制限を課しています。指示を読んだり回答を検討したりしているユーザーが不利になります。ステップは、ユーザーの明示的な操作によってのみ進行すべきです。
商品を保存せずに削除するショッピングカートタイマー：EC における予約タイマー（「カートは 15 分で期限切れになります」など）は、有効期限到達時に商品が完全に失われ、単に予約が解除されるだけでない場合、2.2.3 に不適合です。最低限、商品はウィッシュリストに保存されるか、セッションを復元できるようにすべきです。
「リアルタイムの例外」を広く適用しすぎる：本当にライブではないのに、時間制限を正当化するためにインターフェイスを「リアルタイム」とラベリングすることです。録画済みのオークションの再生、静的な入札インターフェイス、単にクイズ番組風に見えるだけのクイズなどは、リアルタイムの例外には該当しません。
バックエンド API レスポンスのタイミングを無視する：フロントエンドのタイマーは修正しても、API 自体が一定時間後のリクエストを拒否するケースを見落とすことがあります。ユーザーにはカウントダウンが見えないのに、送信が黙って失敗します。バックエンドのセッション管理は、フロントエンドの体験と整合していなければなりません。
フォーム状態を保存せずに自動ログアウトのために setTimeout を使用する：自動ログアウトが避けられない場合（例：規制要件による場合）、リダイレクト前にユーザーのフォームデータを保存しないと、すべての作業が失われます。最低限、下書き状態を保存し、再認証後に復元できるようにすべきです。
2.2.1 への適合と 2.2.3 への適合を混同する：（レベル A の 2.2.1 が求めるような）「オフにする・調整する・延長する」ためのコントロールを提供しても、2.2.3 を満たしたことにはなりません。レベル AAA は、時間が本質的でないこと — 単に管理可能であることではなく — を求めています。延長可能な寛大な時間制限であっても、それは依然として時間制限です。
サードパーティの埋め込みコンポーネントにおけるタイミングを見落とす：埋め込みチャットウィジェット、決済プロセッサ、本人確認 SDK、地図サービスなどは、それぞれ独自の時間制限を導入している場合があります。サードパーティ由来であっても、インターフェイスに統合されている以上、WCAG の適用対象外にはなりません。

トルコのアクセシビリティ規制との関係

トルコの大統領通達 2025/10は、2025 年 6 月 21 日付官報第 32933 号で公布され、WCAG 2.2 を技術的基盤として参照する国内のウェブアクセシビリティ枠組みを確立しています。この通達は、トルコでデジタルサービスを提供する幅広い主体に対し、遵守を義務付けています。

対象となる主体には、公的機関や政府機関、EC プラットフォーム、銀行や金融サービス、病院や医療提供者、20 万人以上の加入者を持つ通信事業者、旅行代理店、民間輸送会社、国民教育省（MoNE）に認可された私立学校などが含まれます。これらの組織は、一般向けにデジタルサービスを提供する際、通達で定義または参照されるアクセシビリティ基準を満たすことが求められます。

WCAG 2.2.3 — No Timing はレベル AAA の達成基準であり、これと整合する欧州規格 EN 301 549 と同様に、大統領通達 2025/10 はレベル A およびレベル AA の適合を法的な最低要件としています。レベル AAA への適合は、この枠組みの下では直接的な法的義務ではありません。しかし、レベル AAA を達成し — 特に 2.2.3 を実装することは — 一流のアクセシビリティ成熟度の指標とみなされ、最低限の法的基準を超えたインクルーシブデザインへの真摯なコミットメントを示すものです。

特定の対象主体、とりわけ BDDK の監督下で事業を行う銀行や金融サービス、および取引量の多いEC プラットフォームでは、OTP の有効期限、セッション管理、チェックアウトフローのタイマーなど、時間制限が広く用いられています。2.2.3 が法的に要求されていない場合でも、これらのフローにおける時間的な障壁に対処しないことは、実質的な差別リスクを生みます — 特に、トルコのアクセシビリティ執行メカニズムが成熟し、苦情処理手続きが整備されていくにつれて、そのリスクは高まります。

障害のあるユーザー、高齢者、デジタルリテラシーの低いユーザーにサービスを提供する公的機関や医療提供者には、時間制限を完全に排除することについて、特に強い倫理的根拠があります。デジタル政府サービスや医療ポータルから時間制限を取り除くことは、トルコのより広範な電子政府のインクルージョン目標と整合し、公共調達における AAA 採用が一般的になるにつれて将来の規制リスクを軽減します。

自社のデジタルプロダクトを完全にインクルーシブなものとして位置付けたい組織 — 国内でのリーダーシップ、国際市場へのアクセス、あるいは EN 301 549 や欧州アクセシビリティ法が適用される欧州連合の文脈での調達上の優位性を目的とする組織 — は、WCAG 2.2.3 への適合を、任意の改善ではなく戦略的な投資として捉えるべきです。

出典と参考資料

AWCAG 1.1.1: 非テキストコンテンツ AWCAG 1.2.1: 音声のみおよび映像のみ（事前録画）AWCAG 1.2.2: キャプション（事前録画）