Как сообщать скринридеру об изменениях в таблице

Когда пользователь ищет запись, меняет фильтр или запускает обновление, содержимое таблицы может измениться без перемещения фокуса. Видящий пользователь замечает новый счётчик или строку статуса, а скринридер не всегда сообщает об этом сам. Разберём, какие короткие объявления нужны, как связать их с действием и как не превращать каждое обновление данных в непрерывный голосовой поток.

После фильтрации приложение может заменить двадцать строк пятью. Для человека, который смотрит на экран, изменение заметно сразу: пропавшие строки, обновлённый счётчик, текст «Найдено 5 записей». Пользователь скринридера в этот момент может продолжать читать прежнюю позицию и не узнать, что результат изменился. Сам факт появления нового содержимого не во всех ситуациях сообщает, почему оно появилось и сколько записей теперь доступно.

В WCAG 2.2 критерий 4.1.3 касается статусных сообщений, которые появляются без смены контекста и фокуса: например, результата действия, ожидания, прогресса или ошибки. Руководство W3C отдельно приводит число результатов поиска и сообщение об отсутствии результатов как возможные статусные сообщения. Сам список результатов при этом не заменяется объявлением: статус дополняет таблицу, а не пересказывает её целиком. Подробности есть в разъяснении W3C о статусных сообщениях.

Перед добавлением live region составьте карту действий таблицы. Ищите отдельные события: поиск завершён, фильтр применён, сортировка изменила порядок, сервер вернул новые записи, выбранная строка удалена, массовое действие завершилось. Для каждого события решите, что должен знать пользователь, чтобы продолжить работу. Обычно ответ помещается в одно короткое предложение: количество найденных записей, факт сохранения или объяснение ошибки.

Для обычного подтверждения подходит роль status. В WAI-ARIA у неё предусмотрено вежливое объявление при удобной паузе, без обязательного перехвата фокуса; это поведение подходит для результата поиска или завершения фонового обновления. W3C указывает, что у role="status" есть неявные aria-live="polite" и aria-atomic="true". В реальных сочетаниях браузера и вспомогательной технологии поведение может отличаться, поэтому полезно проверять живой пример с целевой технологией.

Например, контейнер может заранее присутствовать в документе как элемент с role="status" и aria-atomic="true". После запроса в него попадает фраза «Поиск завершён. Найдено 12 записей». W3C отмечает, что явный aria-atomic="true" может быть полезен, если нужно объявлять содержимое контейнера целиком, поскольку в некоторых средах значение по умолчанию обрабатывается не одинаково. Это рекомендация к проверке, а не гарантия одинаковой озвучки во всех комбинациях.

Хорошая фраза называет завершившееся действие и его результат. «Готово» слишком неопределённо: непонятно, что завершилось. «Найдено 12 записей» полезнее, но при нескольких таблицах контекст может потеряться. «Поиск завершён. Найдено 12 записей» связывает итог с причиной. Для фильтра можно назвать его значение: «Фильтр “В работе” применён. 8 записей». Текст статуса должен совпадать по смыслу с видимым состоянием страницы.

При нулевом результате скажите не только число, но и что делать дальше, если действие очевидно. Например: «По запросу “Север” совпадений нет. Измените запрос или сбросьте фильтры». Это короткое сообщение не заменяет оформление пустого состояния внутри таблицы: зрячему пользователю тоже нужно увидеть причину и возможное действие. Не сообщайте читателю подсказку, если интерфейс не предлагает соответствующий контроль.

При сортировке достаточно подтвердить активный столбец и порядок: «Сортировка по дате, сначала новые». При этом состояние кнопки или заголовка таблицы должно оставаться доступным при навигации. Статус помогает услышать факт изменения в момент нажатия, а семантика элемента помогает позднее проверить текущий порядок. Эти способы дополняют друг друга и не должны расходиться.

Во время долгого запроса уместно показать и сообщить «Обновляем таблицу». После ответа замените это сообщение итогом. Если операция быстрая и длится мгновение, промежуточное «Загрузка» может создавать больше шума, чем пользы. Для повторяющегося автообновления обычно важен только результат, который меняет решение пользователя: например, новая запись появилась или обработка завершилась.

Не используйте срочное прерывание для обычной сортировки, поиска или успешного сохранения. Роль alert и aria-live="assertive" предназначены для действительно срочных сообщений: такое объявление может прервать текущую речь и сбросить часть очереди. Ошибка, которую нужно исправить до продолжения формы, может требовать срочного внимания; временный сетевой сбой в фоновой таблице чаще лучше сообщить спокойно, сохранив введённый запрос и доступную кнопку повтора.

Если несколько изменений приходят подряд, объединяйте их в итог одного действия. Например, не объявляйте отдельно «фильтр выбран», «запрос отправлен», «получен ответ», «таблица обновлена», если пользователь совершил одно действие. Сообщите завершённый результат один раз. Для частых автоподгрузок определите понятный интервал и произносите только значимые итоги, иначе объявление будет мешать читать строки.

Уведомление не должно заставлять пользователя искать новую позицию. После фильтрации фокус часто остаётся в поле ввода или на элементе управления, запустившем фильтр. После удаления строки следует продумать, куда перейдёт фокус, если активная строка исчезла. Это вопрос управления фокусом, отдельный от объявления статуса: фраза может подтвердить удаление, но не должна маскировать потерю текущей позиции.

Когда действие открывает диалог или явно переводит пользователя в другой контекст, это уже другой сценарий. Если фокус перемещён на новый контент и изменение очевидно из нового контекста, дополнительное статусное объявление может повторить то же самое. Проверьте путь целиком: команда, сообщение, новое состояние таблицы и доступный следующий шаг.

Если фильтр срабатывает при каждом вводимом символе, не озвучивайте промежуточное число результатов после каждой буквы. Пользователь ещё формирует запрос, а поток сообщений будет перебивать его ввод и создавать впечатление, что система говорит непрерывно. Обновляйте таблицу после небольшой паузы, явной команды поиска или другого принятого в продукте момента завершения ввода. В статус помещайте только итог последнего запроса. Если старые ответы сервера приходят позже новых, не позволяйте им перезаписывать и озвучивать устаревшее количество строк.

Проверяйте не только наличие role="status" в разметке, но и то, что контейнер существует до первого изменения и его текст действительно меняется после действия. Если при повторном одинаковом поиске DOM не меняется, повторное сообщение может не прозвучать. Тогда обновляйте содержимое осознанно и тестируйте это поведение в реальных средах, не добавляя искусственные паузы без необходимости.

Обычно нет. Объявите итог поиска и количество совпадений, затем оставьте пользователю возможность перейти к строкам обычной навигацией. Озвучивание каждой строки превращает краткий статус в длинный поток и затрудняет возвращение к элементу, с которого началось действие.

Да, если фильтр обновляет данные без смены контекста и пользователю нужно узнать результат действия. Сообщение вроде «Фильтр применён. Найдено 8 записей» информативнее фразы «Готово». Проверьте его в целевых браузерах и скринридерах.

По WAI-ARIA у роли status есть неявное значение aria-live="polite". W3C также предупреждает, что в некоторых средах atomic-поведение может различаться, поэтому aria-atomic="true" иногда задают явно. Итог следует подтвердить ручной проверкой, а не предполагать по одному атрибуту.

Используйте alert только для сообщения, которое требует немедленного внимания, например критической ошибки, блокирующей текущую задачу. Уведомления assertive могут прерывать озвучивание. Результат обычного поиска, сортировки или обновления лучше сообщать спокойно.

Не обязательно. Статус может быть объявлен без получения фокуса; пользователь продолжает работу с поля поиска или кнопки. Перемещение фокуса проектируют отдельно и только когда оно помогает следующему шагу, например после удаления активной строки.

Назовите отсутствие результатов и, если это полезно, доступное действие: «Совпадений нет. Измените запрос или сбросьте фильтры». Не предлагайте действие, которого нет в интерфейсе, и синхронизируйте фразу с видимым пустым состоянием.

Начните с разъяснения W3C по WCAG 4.1.3, примера role=status для результатов поиска и определения роли status в спецификации WAI-ARIA. Эти документы объясняют критерии и семантику, но не заменяют тестирование вашего интерфейса.

Для таблицы достаточно нескольких точных сообщений: что завершилось, сколько записей найдено и что делать при ошибке или пустом результате. Держите уведомление коротким, сохраняйте контроль фокуса и проверяйте фактическую озвучку вместе с чтением самой таблицы. Если вы создаёте собственный шрифт для чисел, статусов и служебных экранов, начните с шаблонов Fontgenerator на fontgenerator.ru.