Вы это испытывали, даже если никогда не считали это проблемой доступности. Начинаете заполнять форму, отходите на телефонный звонок, возвращаетесь, нажимаете «Отправить», а страница тихо вас разлогинила или стёрла то, что вы ввели. «Ваша сессия истекла». Для большинства людей это мелкая досада, потерянные две минуты. Для того, кто читает экран по одной строке, печатает с помощью переключателя или указки на голове или должен отвести взгляд, чтобы справиться с тремором или когнитивной задачей, тот же обратный отсчёт может сделать форму, оформление заказа или страницу аккаунта по-настоящему невыполнимыми. Эти люди не медленные. Просто ваши часы идут быстрее, чем им приходится работать. В 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 работает удалённо и занимается инженерной доступностью сайтов для бизнеса Онтарио. Общая информация, а не юридическая консультация.