Ви це відчували, навіть якщо ніколи не вважали це проблемою доступності. Починаєте заповнювати форму, відходите на телефонний дзвінок, повертаєтеся, натискаєте «Надіслати», а сторінка тихо вас розлогінила чи стерла те, що ви ввели. «Вашу сесію завершено». Для більшості людей це дрібна прикрість, утрачені дві хвилини. Для того, хто читає екран по одному рядку, друкує за допомогою перемикача чи вказівки на голові або мусить відвести погляд, щоб упоратися з тремором чи когнітивним завданням, той самий зворотний відлік може зробити форму, оформлення замовлення чи сторінку акаунта по-справжньому нездійсненними. Ці люди не повільні. Просто ваш годинник іде швидше, ніж їм доводиться працювати. У WCAG є правило саме про це, одне з найстаріших у стандарті, і воно всередині тієї версії, яку Онтаріо реально застосовує.
Ключові факти
- Критерій успіху 2.2.1 «Регульований час» WCAG (Web Content Accessibility Guidelines) належить до рівня A, найбазовішого рівня відповідності, і входить до стандарту від часів WCAG 2.0 (W3C).
- Якщо ваш контент встановлює обмеження часу, 2.2.1 вимагає, щоб виконувалася бодай одна з умов: користувач може його вимкнути, налаштувати в діапазоні щонайменше вдесятеро більшому за значення за замовчуванням або отримати попередження щонайменше за 20 секунд з можливістю продовжити час простою дією, причому продовжувати щонайменше десять разів (W3C).
- У правила три вузькі винятки: подія в реальному часі (наприклад, аукціон), обмеження, необхідне для самого завдання, або будь-яке обмеження понад 20 годин (W3C).
- Розділ 14 IASR Онтаріо (Регламент про інтегровані стандарти доступності, O. Reg. 191/11) вимагає від організацій із 50 і більше працівниками відповідності WCAG 2.0 рівня AA на публічних сайтах, а рівень AA містить кожен критерій рівня A (ontario.ca).
- Наступний ACR (звіт про відповідність вимогам доступності) для організацій із 20 і більше працівниками треба подати до 31 грудня 2026 року (ontario.ca).
Що насправді вимагає «Регульований час»?
Менше, ніж бояться власники, і йдеться саме про те, щоб повернути контроль користувачеві. Правило не забороняє обмежень часу. Сесії й далі можуть закінчуватися, вихід із міркувань безпеки й далі має сенс, бронь місця на подію й далі може відлічувати час. 2.2.1 каже, що коли ваш контент нав'язує користувачеві годинник, ви маєте запропонувати йому один із трьох виходів.
Найчистіший - вимкнути обмеження до того, як воно спрацює: дати користувачеві вимкнути його заздалегідь. Другий - дати йому заздалегідь налаштувати його на значення щонайменше вдесятеро більше за ваше за замовчуванням. Третій, який більшість сайтів може додати найшвидше, - шаблон «попередити й продовжити»: до того як сесія помре, показати зрозуміле вікно («За хвилину ви вийдете з акаунта. Залишитися?»), дати людині щонайменше 20 секунд, щоб відповісти однією простою дією, і дозволити їй зробити це щонайменше десять разів. Будь-який із трьох варіантів виконує правило.
Де приховані обмеження часу шкодять реальним користувачам?
Пастка в тому, що такі обмеження зазвичай невидимі для того, хто зробив сайт, бо він у них ніколи не впирається. Ви перевіряєте оформлення замовлення, заповнюючи його за тридцять секунд. Користувач, якому потрібне це правило, заповнює його десять хвилин, а ваш таймер бездіяльності спрацював на п'ятій.
Шаблон проявляється в найкомерційно важливіших місцях. Багатокрокове оформлення замовлення, яке скидає кошик за кілька хвилин бездіяльності. Довга анкета чи форма заявки, яка очищується за тайм-аутом без попередження й без відновлення, і тут правило жорстко перетинається з тим, щоб зробити доступною саму форму. Сесія акаунта чи банку, яка закінчується посеред завдання. Навіть екран входу може нести прихований годинник: код чи перевірку, які спливають раніше, ніж людина з допоміжною технологією до них дістанеться, а це прямо пов'язано з доступною автентифікацією. Зауважте, це ті самі цінні, критичні для конверсії сторінки, з яких ви найменше хочете, щоб хтось ішов: доступність і завершені продажі тут тягнуть в один бік.
2.2.1 входить до настанови WCAG 2.2 «Достатньо часу», тієї самої, що й правило «пауза, стоп, сховати» для автовідтворення й рухомого контенту. Спільна думка проста: скільки часу потрібно, вирішує користувач, а не сторінка.
Які тайм-аути звільнені, а які ні?
Тут правило чесніше, ніж здається спершу. Завдяки трьом виняткам ви не зобов'язані робити регульованим кожен годинник. Подія в реальному часі, де час і є суттю, - живий аукціон, розпродаж обмеженої кількості товару, - звільнена, бо немає чесного способу дати одному учасникові більше часу. Обмеження, яке необхідне, коли продовження зламало б саме завдання, звільнене. І будь-яке обмеження понад 20 годин звільнене з розумної логіки: вікно завдовжки в добу - не той бар'єр, про який ми турбуємося.
Не звільнений звичайний тайм-аут сесії через бездіяльність: вихід за п'ятнадцять хвилин, автоматичний вихід із форми «з міркувань безпеки». Безпека - законна причина мати тайм-аут; але це не причина пропускати попередження й можливість продовжити. Можна зберегти рівень безпеки й однаково виконати правило, попередивши користувача й дозволивши йому залишитися одним натисканням. Одне одному не суперечить.
Як це перевірити і чим ризикуєте, якщо не перевірите?
Перевірити власний сайт можна за кілька хвилин:
- Знайдіть кожну сторінку, яка може вас розлогінити чи очистити введене: оформлення замовлення, акаунт, довгі форми, усе, що за входом.
- Почніть завдання й зачекайте. Залиште сторінку без дій довше, ніж триває сесія. Чи попередило вас щось до закінчення? Чи можна було продовжити час або залишитися в акаунті однією дією? Якщо вас мовчки розлогінило чи форма стерлася, це провал.
- Засічіть попередження, якщо воно є. Вікно має давати щонайменше 20 секунд і простий спосіб відповісти, а не двосекундний спалах, який можна пропустити, читаючи екранним читачем.
Автоматичний сканер майже ніколи цього не впіймає. Тайм-аут живе в логіці сервера й сесії, а не в статичній розмітці, яку читає робот, тож він проходить автоматичну перевірку чистим. Це хрестоматійний приклад того, чому сканування - не аудит, і чому прикручений віджет теж не допоможе: оверлей не може переписати логіку сесії за вашим оформленням замовлення.
Щодо ставок, чесна картина та сама, що й у будь-якого бар'єра. В Онтаріо в AODA (Accessibility for Ontarians with Disabilities Act) немає права приватного позову, тож напряму за ним на вас ніхто не подає; чинний шлях для приватної особи - скарга до HRTO (Трибунал із прав людини Онтаріо) за Кодексом прав людини Онтаріо, і ось як насправді розгортається одна скарга. Якщо ви продаєте в США, оформлення замовлення, яке викидає людей за тайм-аутом, - саме такий бар'єр, що з'являється в претензіях за ADA (Americans with Disabilities Act) щодо сайтів. Довговічна відповідь - не застереження, а задокументоване виправлення: датований запис того, що ви знайшли й виправили, - те, що має відображати чесний ACR до 31 грудня 2026 року.
Обнадіює те, що для більшості сайтів це невелика зміна з непропорційно великою віддачею. Вікно «ви зараз вийдете з акаунта, залишитися?» - скромна робота на фронтенді, і вона рятує саме ті покинуті сесії, які тихо коштували вам заповнених форм і продажів.
Дізнайтеся, чи не викидають ваші форми й оформлення замовлення людей за тайм-аутом, і перевірте інші проблеми доступності - безкоштовний звіт Vayle, приблизно 30 секунд: vayle.art. Він виявляє віджети-оверлеї, показує реальні порушення WCAG і точно каже, що юридично стосується вашої організації в Онтаріо. Без зобов'язань.
Vayle працює віддалено й займається інженерною доступністю сайтів для бізнесу Онтаріо. Загальна інформація, а не юридична консультація.