ariaNotify(): новая мощная функция для доступности в WAI-ARIA 1.3

Метод ariaNotify() из черновика WAI-ARIA 1.3 позволяет разработчикам программно вызывать озвучивание в скринридерах без изменения DOM. Это прямое решение давней проблемы: как сообщить пользователю о важном событии, не прерывая его текущую задачу и не нарушая естественный поток навигации. В отличие от традиционных подходов, таких как использование aria-live или скрытых элементов, ariaNotify() не требует изменений в DOM и не влияет на фокус. Это делает его идеальным для ситуаций, когда нужно сообщить о завершении фоновой операции, обновлении данных или ошибке, не отвлекая пользователя от основного контента.

Что такое ariaNotify() и как он работает

ariaNotify() — это метод, определённый в черновике WAI-ARIA 1.3. Он принимает строку и необязательный объект с настройками, включая приоритет ('important' или 'polite'). Когда метод вызывается, скринридер произносит переданный текст, причём сообщения с приоритетом 'important' прерывают текущую речь, а 'polite' — ожидают паузы. Это напоминает поведение aria-live, но с важным отличием: ariaNotify() не требует наличия соответствующего элемента в DOM. Он работает как программный вызов, что упрощает реализацию и снижает нагрузку на производительность.

Например, разработчик может вызвать ariaNotify('Файл загружен', {priority: 'polite'}) после завершения загрузки, и пользователь услышит уведомление, не теряя контекста. Это особенно полезно для одностраничных приложений, где динамические изменения не всегда очевидны для скринридеров. Метод доступен только в защищённом контексте (HTTPS) и может быть ограничен в iframe.

Предыстория и контекст

До появления ariaNotify() разработчики использовали несколько обходных путей для программного озвучивания. Самый распространённый — создание скрытого элемента с role='alert' или aria-live='polite' и изменение его содержимого через JavaScript. Этот метод работает, но имеет недостатки: требуется управление DOM, возможны задержки, а при частых обновлениях скринридер может накапливать сообщения. Другой подход — использование focus() для перемещения фокуса на элемент с текстом, что дезориентирует пользователя.

ariaNotify() решает эти проблемы, предоставляя прямой API для скринридеров. Это результат многолетней работы WAI-ARIA Working Group, направленной на улучшение взаимодействия между веб-приложениями и вспомогательными технологиями. Метод уже обсуждается в сообществе и, вероятно, будет включён в финальную версию спецификации.

Как ariaNotify() отличается от aria-live?

Главное отличие — ariaNotify() не привязан к DOM-элементу. aria-live требует наличия элемента с атрибутом, и скринридер следит за изменениями его содержимого. ariaNotify() же — это прямой вызов, который отправляет уведомление скринридеру без модификации страницы. Это делает его более гибким и предсказуемым. Кроме того, ariaNotify() поддерживает приоритеты, что позволяет разработчику контролировать, прерывать ли текущую речь пользователя.

Однако ariaNotify() не заменяет aria-live полностью. Для контента, который постоянно обновляется (например, чат), aria-live остаётся предпочтительным, так как автоматически отслеживает изменения. ariaNotify() лучше подходит для одноразовых уведомлений о событиях.

Технические подробности и поддержка браузеров

На момент написания статьи ariaNotify() находится на стадии черновика и не реализован ни в одном браузере. Однако W3C ожидает, что метод будет поддерживаться основными скринридерами, такими как JAWS, NVDA и VoiceOver, после стандартизации. Разработчики могут уже сейчас начать использовать полифилы или готовиться к внедрению, изучив API.

Вызов метода прост: window.ariaNotify('текст', {priority: 'polite'}). Объект options может содержать только priority, но в будущем возможно расширение. Важно отметить, что метод доступен только в защищённом контексте (HTTPS) и может быть ограничен в iframe.

Кого затронет и как

В первую очередь, ariaNotify() улучшит опыт пользователей скринридеров, особенно в сложных веб-приложениях. Разработчики получат простой и эффективный способ уведомлений без хаков. Для бизнеса это означает повышение доступности сайтов, что может улучшить SEO и избежать юридических рисков, связанных с ADA и другими законами.

В российском контексте, где требования к доступности регулируются ГОСТ Р 52872-2019, внедрение ariaNotify() поможет привести сайты к стандартам. Однако пока нет информации о поддержке этого метода в русскоязычных версиях скринридеров.

Что будет дальше

Ожидается, что WAI-ARIA 1.3 будет принят в ближайшие год-два. После этого браузеры и скринридеры начнут внедрять поддержку. Разработчикам рекомендуется следить за обновлениями спецификации и тестировать полифилы. Возможно, появятся библиотеки, облегчающие использование ariaNotify().

Итог

ariaNotify() — значительный шаг вперёд в области веб-доступности. Он предоставляет чистый, эффективный API для программного озвучивания, решая давние проблемы. Хотя до полной поддержки ещё далеко, уже сейчас стоит изучить его возможности и готовить код к будущим изменениям. Это инвестиция в инклюзивность и удобство пользователей с ограниченными возможностями.