認証デザインの盲点「セッションタイムアウト」のアクセシビリティ改善ガイド
Webサイトのセッション管理は、ユーザー体験とセキュリティ、そしてリソース管理のバランスを取る高度な技術的判断が求められる領域だ。しかし、多くの開発現場で見落とされがちなのが、このセッションタイムアウトが障害を持つユーザーにとって深刻なアクセシビリティの障壁になっているという事実である。
世界中で約13億人が何らかの重大な障害を抱えており、その多くがデジタル環境での時間制限によって、チケットの購入やローン申請、SNSの閲覧といった日常的な活動を阻害されている。タイムアウトの設定一つが、特定のユーザーにとってはサービスを完全に放棄せざるを得ない原因になりかねない。
バックエンドの設計をわずかに工夫するだけで、こうしたフラストレーションを解消し、誰にとっても使いやすいサイトを構築できる。本記事では、セッションタイムアウトがなぜアクセシビリティの問題となるのか、そしてどのように改善すべきかを専門的な視点から解説する。
なぜセッションタイムアウトがアクセシビリティの障壁になるのか
セッションタイムアウトは、一定時間操作がない場合にセキュリティ保護のためにユーザーをログアウトさせる仕組みだ。しかし、この「操作がない」という判定基準が、特定のユーザーにとっては不当に厳格なものとなっている。
運動機能障害と入力速度のギャップ
脳性麻痺などの運動機能障害を持つユーザーは、筋肉のこわばりや調整の難しさから、情報の入力に非障害者よりも長い時間を要する場合がある。例えば、オンラインでコンサートチケットを購入する際、日付の選択や個人情報の入力に慎重な操作が必要となり、クレジットカード情報の入力にたどり着く前に「タイムアウト」の警告が表示されてしまうといったケースだ。
障害者権利の擁護活動を行っているMatthew Kayne氏によれば、適応デバイスを使用したWeb操作は非常に多大な労力を伴うという。慎重にページを移動している最中に突然ログアウトされることは、単なる不便を超え、数時間に及ぶ作業を無に帰す「デジタル的なグリッチ（不具合）」として機能してしまう。DWPアクセシビリティマニュアルでも、適応技術が入力信号を登録するまでに複数回の試行が必要になることがあり、ユーザーの操作速度が大幅に低下する可能性が指摘されている。
認知特性と情報の処理時間
認知的な違いを持つユーザーにとっても、厳格なタイムアウトは大きな圧力となる。自閉症、ADHD、失読症、あるいは認知症などの特性を持つ人々は、情報を読み取り、理解し、処理するために、より多くの時間を必要とする傾向がある。彼らは決して「非アクティブ」なわけではなく、画面の前で深く考え、処理を行っている最中なのだ。
特に「時間盲（タイムブラインドネス）」と呼ばれる特性を持つADHDのユーザーなどは、時間の経過を正確に把握することが難しい。ADHDの技術リーダーであるKate Carruthers氏は、時間の感覚が一般的なものとは異なり、数時間を失ってしまうこともあると述べている。このようなユーザーにとって、事前の通知なしにセッションが切れる設計は、作業の継続を著しく困難にする。
視覚障害とスクリーンリーダーのオーバーヘッド
全盲やロービジョンのユーザーは、ページ全体を視覚的にスキャンすることができない。スクリーンリーダーを使用してリンク、見出し、フォーム項目を一つずつ音声で確認していく作業は、本質的に視覚的な操作よりも時間がかかる。世界で約4,300万人が全盲、2億9,500万人が中等度から重度の視覚障害を抱えている現状を考えると、これは決して無視できない規模の問題だ。
また、タイムアウトを知らせるライブタイマーが逆に仇となることもある。アクセシビリティに詳しい開発者のBogdan Cerovac氏は、1秒ごとに残り時間を読み上げるカウントダウンタイマーに遭遇した際、その通知メッセージが画面操作を妨げ、実質的にページ操作が不可能になった経験を報告している。アクセシビリティを考慮していないタイマーの実装は、ユーザーを支援するどころか「スパム」のような妨害行為になりかねない。
アクセシビリティ要件を満たさない一般的なタイムアウト設定
セキュリティの観点からは、認証情報を無期限に保持するよりもセッションを適切に管理する方が望ましい。しかし、利便性を損なういくつかのパターンは、現代のアクセシビリティ基準に照らすと不合格と言わざるを得ない。
警告なしのサイレントログアウト
最も深刻なのは、何の前触れもなくユーザーをログアウトさせる設計だ。例えば、米国のビザ申請ページ（DS-260）では、約20分間操作がないと警告なしにセッションが終了する。保存していないデータはすべて消失するため、複雑なフォームを入力しているユーザーにとっては致命的な設計ミスといえる。
スクリーンリーダーを利用している場合、数秒間だけ表示されるポップアップ警告では、音声読み上げが完了する前にセッションが切れてしまうこともある。運動機能障害を持つユーザーにとっても、30秒程度の短いカウントダウンでは、延長ボタンをクリックするまでの時間が足りない場合が多い。
延長不可なセッション設計
セッションが切れた際に「セッションが終了しました」というメッセージと共にログイン画面へ戻されるだけの設計も問題だ。ユーザーが作業を継続したいという意思を示しても、それを反映する手段がなければ、すべての工程を最初からやり直す必要が生じる。これは障害の有無にかかわらずストレスフルな体験だが、操作に多大な労力を要するユーザーにとっては、その日の活動を断念させるほどの打撃を与える。
セッション終了に伴うフォームデータの消失
多くのWebサイトでは、セッションの終了と同時に入力中のフォームデータが破棄される。1時間をかけて入力した申請書や注文書が、わずかな放置時間で消えてしまうのは、設計上の配慮が欠けている証拠だ。データの保存が完了するまで作業が保護されない仕組みは、特に長い思考時間を必要とするユーザーを排除することにつながる。
作業を続けますか？ 延長すると現在の入力内容が保持されます。
このデモは、突然の終了（Before）と、十分な猶予を持った警告（After）のUXの違いを示している。
セキュリティとアクセシビリティを両立させる設計パターン
セキュリティを維持しつつ、アクセシビリティを向上させることは十分に可能だ。英国の年金クレジット申請サイトのように、期限の少なくとも2分前に警告を発し、セッションを延長できるように設計されている例もある。これはWCAG 2.2のレベルAAを満たす優れた実装だ。
事前警告システムと延長機能の実装
セッションが開始される前に、タイムリミットの存在とその長さを明示することが重要だ。銀行のフォームなどでは、最初のページで「この手続きには60分の時間制限があります」と伝え、必要に応じて制限時間を調整できるかどうかをユーザーに知らせるべきである。
実際のタイムアウトが近づいた際には、ダイアログを表示してワンクリックで延長できるようにする。この際、スクリーンリーダーのユーザーが即座に反応できるよう、ARIAライブリージョンなどを用いて適切に通知を行う必要がある。ただし、前述のCerovac氏の例のように、過度な頻度でのカウントダウン読み上げは避けるべきだ。
活動ベースと絶対時間の使い分け
セッション管理には「活動ベース（一定時間の無操作で終了）」と「絶対時間（操作の有無にかかわらず一定時間で終了）」の2種類がある。共有PCなどでの利用が想定される場合は絶対時間タイマーが有効だが、ユーザーがいつ終了するかを正確に予見できるため、活動ベースよりもアクセシビリティが高いとされる場合もある。重要なのは、ユーザーが「いつ、なぜ切れるのか」を完全にコントロールできていると感じられることだ。
オートセーブによる入力内容の保護
技術的な解決策として最も強力なのが、localStorageやsessionStorage、あるいはCookieを活用したオートセーブだ。ユーザーの入力を一定間隔でクライアントサイドに保存し、たとえ不意にセッションが切れても、再ログイン後に続きから再開できるようにする。
この仕組みがあれば、タイムアウトによる「やり直し」のペナルティがなくなる。特に複雑なフォームや長文の入力が必要なサイトでは、このデータ保護機能がアクセシビリティにおけるセーフティネットとして機能する。セキュリティ上の懸念がある場合は、再認証後にのみデータを復元する、あるいは機密性の高いフィールド（クレジットカード番号など）のみ除外するといった調整が可能だ。
このデモは、ユーザーが入力中に「保存されている」という安心感を得られるUIの概念を示している。
WCAG準拠とテストの重要性
W3Cが公開しているWeb Content Accessibility Guidelines（WCAG）は、セッションタイムアウトのアクセシビリティを判断する国際的な基準だ。開発者は特に、WCAG 3.0（草案）のガイドライン2.9.2や、現行の2.2.1「調節可能な時間制限」に注目すべきである。
ガイドライン2.2.1「調節可能な時間制限」の理解
このガイドラインでは、時間制限がある場合、ユーザーがその制限を解除、調整、または延長できる手段を提供することを求めている。具体的には、制限時間が切れる前にユーザーに警告し、少なくとも10回以上、簡単な操作（スペースキーを押すなど）で制限を延長できる猶予を与える必要がある。
この基準を満たすことで、運動機能障害や認知特性を持つユーザーが、自分たちのペースで操作を完了できる権利が保証される。Pew Research Centerのデータによれば、障害を持つ成人の62%がコンピュータを所有し、72%が高速インターネットを利用している。これは非障害者と統計的に差がない数字であり、Webサイト側が彼らを排除しない設計を行う責任は大きい。
タイムアウト制限が免除されるケース
ただし、WCAGでも例外は認められている。例えば、ライブのチケット販売のように、在庫を保持できる時間に制限を設けなければ他のユーザーが購入できなくなる場合や、セキュリティリスクが極めて高い特定の金融取引などが該当する。また、制限時間が20時間を超える場合も、実質的にユーザーの操作を妨げないため免除される。
ニュース記事の閲覧、SNSのスクロール、一般的なECサイトの商品検索など、本来時間制限が必要ない場所で恣意的なセッション終了を設けることは避けるべきだ。時間制限が必要な試験などの場面でも、管理者側が障害を持つ学生に対して個別に時間を延長できる仕組みを整えることが推奨されている。
この記事のポイント
- セッションタイムアウトは、運動・認知・視覚障害を持つユーザーにとって重大なアクセスの障壁となる
- 警告なしの強制ログアウトは、それまでの多大な入力作業を無に帰すため、アクセシビリティ上極めて不適切だ
- WCAG準拠のためには、期限の少なくとも2分前に警告を出し、簡単な操作で時間を延長できる機能が必須である
- オートセーブ機能を実装することで、不意の切断時でもデータを保護し、ユーザーのフラストレーションを最小限に抑えられる
- セキュリティとアクセシビリティは対立するものではなく、適切な設計によって両立させることが可能だ
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、Java等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
Figma変数でフォント拡大テストを実践する——アクセシビリティ対応の効率的なワークフロー
デジタルアクセシビリティの取り組みは、日常のデザインワークフローに自然に溶け込む時に最も効果を発揮する。大規模な変革ではなく、チームの日常業務にフィットするシンプルな作業プロセスが鍵だ。Figmaの変数機能を使えば、フォントサイズの拡大テストはデザイン作業そのものの一部となり、アクセシビリティ対応が「オプション」ではなく「当然」のプロセスとして感じられるようになる。
Smashing Magazineの記事によれば、アクセシビリティ文化の構築は「どうやって実現するか」という具体的な方法論が重要だと指摘されている。多くのチームが「これをやるか、あれをやるか」の選択を迫られる中で、アクセシビリティは後回しにされがちだ。しかし、Figma変数を活用した体系的なテストプロセスを確立すれば、この状況を変えられる。
特にフォントサイズの拡大対応は、WCAG 2.2のAAレベル必須項目であり、実ユーザーの26%がスマートフォンでフォントサイズを拡大している現実を考えると、無視できない設計課題だ。この記事では、Figma変数を使った実践的なテスト手法を、具体的な手順とともに解説する。
フォントサイズ拡大がアクセシビリティにおいて重要な理由
テキストはデジタル体験において中心的な役割を果たす。操作説明、ボタンのラベル、ナビゲーション要素など、多くの情報がテキストを通じて伝えられる。読みやすさに問題があれば、ユーザー体験は大きく損なわれる。
支援技術としてのフォントサイズ調整
アクセシビリティの文脈では、フォントサイズの拡大は「支援技術・戦略」の一つに分類される。これは、ユーザーがより快適な利用モデルを見つけるために頼る技術的なツールや工夫だ。スクリーンリーダーや色の変更と同様に、フォントサイズの調整も多くのユーザーにとって不可欠な機能となっている。
APPT（Accessible Platform Preferences and Technologies）の2026年2月のデータによると、AndroidとiOSのモバイルデバイスユーザーの26%がデフォルトのフォントサイズを拡大している。これは4人に1人の割合に相当し、無視できない規模のユーザー層だ。
WCAG 1.4.4「テキストのサイズ変更」要件
Webコンテンツアクセシビリティガイドライン（WCAG）2.2の成功基準1.4.4は、AAレベル（必須）の要件として明確に定めている。
キャプションや文字画像を除き、支援技術なしでテキストを200%までサイズ変更しても、コンテンツや機能が失われないこと。
WCAG 2.2 成功基準1.4.4「テキストのサイズ変更」
この「200%」は、初期サイズの2倍まで拡大可能であることを意味する。実際のユーザー設定では120%、140%、160%などの段階的な拡大も一般的だ。重要なのは、インターフェース内に独自の拡大ツールを提供する必要はない点だ。デバイスやブラウザの標準機能で対応すればよく、これはUIの複雑化を避ける合理的なアプローチと言える。
標準化されたアクセス方法
ほとんどのデバイスやブラウザには、フォントサイズ調整機能が標準で搭載されている。ユーザーは特別なソフトウェアを購入する必要なく、システム設定で簡単に調整できる。
iPhoneでは「設定」→「アクセシビリティ」→「視覚」→「テキストサイズと表示」から調整可能だ。Google Chromeでは「設定」→「外観」→「フォントサイズ」で「特大」などのオプションを選択できる。これらの標準機能を正しくサポートすることが、開発側に求められる対応となる。
Figma変数を使ったテストの基本コンセプト
Figmaでフォントサイズ拡大テストを実施する核心は、変数機能の活用にある。このアプローチの目標は、インターフェースのテキストを100%、120%、140%、160%、180%、200%の各スケールで即座に切り替えて確認できる環境を構築することだ。
必要な前提知識
このテストを効果的に実施するには、Figmaの3つの基本機能に対する理解が不可欠だ。テキストスタイル、オートレイアウト、変数の使い方をマスターしている必要がある。元記事の著者であるRuben Ferreira Duarte氏は、これらの機能を体系的に学ぶことを強く推奨している。段階を飛ばすと、後で大きな手戻りが発生する可能性がある。
テストの全体像
基本的なワークフローは、ライトモードとダークモードの切り替えに変数を使う場合と同様の原理に基づく。各テキストスタイルのフォントサイズと行間を変数として定義し、その変数に異なるスケールの値を割り当てる。これにより、変数セットを切り替えるだけで、インターフェース全体のテキストサイズが一括で変更される。
このアプローチの最大の利点は、テストがデザインプロセスに自然に組み込まれる点だ。特別なテスト環境を用意する必要がなく、日常のデザイン作業の中で継続的にアクセシビリティを検証できる。
Figmaでの実践手順：10のステップ
ここからは、具体的な実装手順を10のステップに分けて解説する。各ステップは積み重ね式になっており、前のステップが適切に完了していないと次のステップで問題が発生する。順を追って確実に進めることが重要だ。
ステップ1：インターフェースのデザイン
まずはテスト対象となるインターフェースをデザインする。この段階では、フォントサイズ拡大テストを意識しすぎる必要はない。ただし、基本的なアクセシビリティ原則（色のコントラスト、インタラクションサイズなど）には最初から配慮しておく。後から大きな修正が入らないよう、土台をしっかり作ることが肝心だ。
ステップ2：すべての要素にオートレイアウトを適用
画面デザインのすべての要素に、適切なオートレイアウトを適用する。これは最も重要なステップの一つだ。オートレイアウトの一貫した適用が、後でフォントサイズを拡大した際のインターフェースのスケーラビリティを保証する。このステップをおろそかにすると、テキスト拡大時に「陶器店に象が入り込んだような」崩壊が発生する。
オートレイアウトは、要素間のスペーシングや整列を数学的に管理する。これにより、テキストサイズが変化しても、レイアウトが予測可能な形で調整される。
ステップ3：テキストスタイルの構造化と適用
次に、テキストスタイルを構造化し、インターフェースのすべてのテキスト要素に適用する。多くのデザイナーはデザイン作業中に自然にテキストスタイルを作成していくが、もしまだならこの時点で整理する。テストを正常に動作させるためには、デザイン内のすべてのテキスト要素にテキストスタイルが適用されている必要がある。
テキストスタイルは、見出し、本文、キャプションなど、役割ごとに一貫した設定を保証する。これが変数と連動する基盤となる。
ステップ4：100%スケールの変数セットを定義
ここから変数の本格的な設定が始まる。まず、100%表示モデル（初期参照バージョン）用の変数セットを定義する。Figmaの「数値」タイプの変数を作成し、各テキストスタイルのフォントサイズと行間に対して個別の変数を割り当てる。
例えば、「見出し1」のフォントサイズが32pxなら、`Heading1/font-size`という変数を作成して32を設定する。行間にも同様に変数を設定する。この構造化が、後の拡大スケール計算の基礎となる。
ステップ5：変数をテキストスタイルに適用
定義した変数を、ステップ3で作成したテキストスタイルに適用する。テキストスタイルの編集画面で、フォントサイズと行間の値入力欄の横にあるアイコンをクリックし、対応する変数を選択する。最低でもフォントサイズと行間には変数を適用する必要がある。他のタイポグラフィ変数（字間、フォントファミリーなど）があれば、それらにも変数を適用できるが、必須ではない。
ステップ6：テキスト拡大用の変数を定義
100%スケールの変数が設定できたら、次は拡大スケール用の変数を定義する。120%、140%、160%、180%、200%などの各スケールに対して、各テキストスタイルの新しい変数値を計算する。
計算方法は単純だ。初期値にスケール率を乗算する。例えば、フォントサイズ16pxのテキストスタイルの場合、120%スケールでは16×1.2=19.2pxとなる。行間も同様に計算する。最終値の丸め処理は任意だ。これは近似テストであるため、丸めによるわずかな差異はテスト結果の知覚に影響しない。
ステップ7：異なるスケールバージョンに変数を適用
テストの核心部分だ。元のインターフェースをコピーし、各フォントサイズ拡大率に対応する変数セットを適用する。120%、140%、160%、180%、200%の各スケールに対してこの作業を繰り返す。
作業を簡素化したい場合は、スケールの数を減らしても構わない。ただし、最低でも100%と200%の2スケールは必須だ。WCAG要件を満たすためには、200%スケールでの動作確認が不可欠である。
ステップ8：改善点の特定
同じ画面に異なる拡大スケールを適用すると、どこに改善が必要かが明確になる。これがデザインにおけるフォントサイズ拡大テストの本質であり、最も重要なアクセシビリティ作業の始まりだ。
分析時には以下の点に注意する。
- テキストが巨大に見えること自体は問題ではない。これは、ユーザーが製品やサービスを利用できるかどうかの分かれ目になり得る。
- フォントサイズを拡大した結果、特定のテキストが読めなくなったり、コントロールが操作不能になったりする場合に、初めてアクセシビリティ問題が発生する。
- すでに十分大きなテキスト要素をさらに拡大することは、可読性を向上させず、不必要なスペースを占有するだけの場合がある。
- 要素が画面からはみ出しているように見える場合は、まずオートレイアウトの適用方法を確認する。多くのデザイン上の問題は、適切なオートレイアウト設定で解決できる。
- 拡大スケールに関わらず、タイポグラフィの視覚的階層を維持することが重要だ。情報のレベル差を認識するためには、この読みやすさが不可欠である。
- このテストは、特定の拡大率で正常に機能するためにコード側での調整が必要な要素を特定するのにも役立つ。すべてがデザインだけで解決できるわけではないが、それは問題ない。アクセシビリティは本質的にチーム全体での取り組みだからだ。
ステップ9：デザインの修正と調整
様々な拡大スケールを適用した画面を基に、必要なデザイン変更を実施する。これらの調整の一部はコード側でのみ対応可能な場合もある。その場合は、すべての提案を文書化して開発チームに引き継ぐ。繰り返しになるが、デザインで遭遇する問題の多くは、オートレイアウトプロパティの適切な適用だけで迅速に解決できる。
ステップ10：最初に戻ってプロセスを繰り返す
これは循環的なアプローチだ。プロジェクトを通じて必要に応じてこれらのステップ（またはその変形）を何度も繰り返す。時間の経過とプロセスの最適化に伴い、一部のステップが不要になるのは自然なことだ。しかし、重要なのは、アクセシビリティとこのフォントサイズ拡大テストが一度きりの作業ではないという認識だ。各プロジェクトとチームの日常業務の中で、何度も何度も実施されるテストなのである。
デザインシステムの役割と効率化
一見すると、この一連のステップは複雑な作業に思えるかもしれない。しかし、デザインシステムが存在する環境では、そのほとんどが容易に実行できる。実際、デザインシステムはプロダクトデザイン業界において「避けられない標準」となっている。各チームが何をデザインシステムと呼ぶかは議論の余地があるが、今日、コンポーネントとスタイルの最小限構造化されたライブラリさえ持たないプロダクトデザインチームを見つけるのは非常に難しい。
この基盤があれば、Figma変数を使ったフォントサイズ拡大テストの適用は非常に容易になる。さらに、デザインシステムがライトモードとダークモード用の構造化変数を既に持っているなら、このテストに適用する原理は全く同じものだ。つまり、新しい概念を導入する必要はない。
デザインシステムでの作業には、この種のテスト作成にも有用な「構造化と組織化」のレベルが伴う。デザインシステムが創造性を制限するという神話があるが、これは誤りだ。デザインシステムはデザインの「事務的」部分を解決し、本当に重要なこと——この場合はアクセシビリティのテストと、より多くの人々に本当にアクセシブルな製品・サービスの構築——に時間を割くことを可能にする。
元記事の著者は、コミュニティに公開されたFigmaファイルを例として提示している。このファイルには、ここで説明したテストプロセスの実践例が含まれている。ただし、これはあくまで一例であり、Figmaファイル内でこの種のテストを実行する方法は無数にある。各チームの具体的な現実、プロセス、成熟度レベルに合わせてアプローチを適応させることが重要だ。
この記事のポイント
- フォントサイズ拡大はWCAG 2.2 AAレベル必須項目であり、実ユーザーの26%が利用している現実的なニーズである。
- Figmaの変数機能を使えば、フォントサイズ拡大テストをデザインワークフローに自然に組み込める。
- テスト実施には、テキストスタイル、オートレイアウト、変数の3つの基本機能の理解が不可欠である。
- 10のステップからなる体系的なアプローチで、誰でも再現可能なテスト環境を構築できる。
- デザインシステムが存在すれば、テストの導入と運用は大幅に効率化される。
出典
- Smashing Magazine「Testing Font Scaling For Accessibility With Figma Variables」（2026年3月24日）
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、Java等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験