В сердце веб-доступности есть неочевидный факт, о который каждый год спотыкаются владельцы бизнеса с лучшими намерениями: самый частый инструмент, за которым тянутся, чтобы «сделать сайт доступным», - это и один из самых частых способов сделать его менее доступным. Этот инструмент - ARIA (Accessible Rich Internet Applications), набор атрибутов HTML, которые говорят экранным чтецам, что это за элемент и что он делает. При правильном и умеренном использовании ARIA закрывает пробелы, которые не может закрыть обычный HTML. При небрежном - когда её разбрызгивает разработчик, понимающий её наполовину, или целиком вставляет виджет-оверлей - она активно врёт вспомогательным технологиям: объявляет кнопки, которых нет, неверные подписи и роли, которые не совпадают. Экранный чтец верит коду, а не экрану. И клиенту хуже, чем если бы никто ничего не трогал.
Ключевые факты
- WebAIM Million 2026 - ежегодный анализ WebAIM по миллиону главных страниц - показал, что на главных страницах с ARIA в среднем было 59,1 обнаруженной ошибки, против 42 на страницах без ARIA; чем больше атрибутов ARIA использовала страница, тем больше обнаруженных ошибок доступности на ней обычно было (WebAIM, 2026 WebAIM Million).
- Тот же отчёт нашёл обнаруживаемые нарушения WCAG 2 на 95,9% главных страниц в 2026 году против 94,8% в 2025 году, что перечеркнуло несколько лет медленного улучшения (WebAIM, 2026 WebAIM Million).
- Собственные рекомендации W3C формулируют жёсткое правило: без ARIA лучше, чем с плохой ARIA. Первое правило ARIA: если нативный элемент HTML справляется с задачей, используйте его, а не воссоздавайте его через ARIA (W3C, WAI-ARIA Authoring Practices).
- WCAG 4.1.2 Имя, роль, значение - уровень A (Web Content Accessibility Guidelines): каждый интерактивный элемент должен сообщать вспомогательным технологиям правильные имя, роль и значение, а неправильная ARIA - один из самых быстрых способов этот критерий провалить (W3C).
- Раздел 14 IASR Онтарио (Регламент об интегрированных стандартах доступности, O. Reg. 191/11) требует от организаций с 50 и более сотрудниками обеспечить соответствие публичных сайтов WCAG 2.0 уровня AA, а следующий ACR (отчёт о соответствии требованиям доступности) для организаций с 20 и более сотрудниками нужно подать до 31 декабря 2026 года (ontario.ca, O. Reg. 191/11).
Что такое ARIA и что на самом деле требует от неё WCAG?
ARIA - словарь атрибутов, таких как role="button", aria-label, aria-expanded, aria-hidden, которые добавляют в HTML, чтобы передать смысл экранному чтецу. Её задача узкая: описывать нестандартные виджеты и динамический контент, для которых в обычном HTML нет встроенного элемента. По-настоящему нестандартный выпадающий список, панель вкладок, сумма корзины, обновляющаяся на лету, - им может действительно понадобиться ARIA, чтобы экранный чтец объявлял, что происходит.
WCAG требует не «использовать ARIA». По 4.1.2 Имя, роль, значение (уровень A) она требует, чтобы каждый интерактивный элемент сообщал правильные имя, роль и состояние - любым способом. Стандартная <button>Add to cart</button> уже делает это бесплатно. Как только вы заменяете её стилизованным <div> и прикручиваете role="button", вы берёте на себя задачу заново реализовать всё, что давала нативная кнопка: фокус клавиатуры, клавиши Enter и пробел, объявляемую роль. Пропустите любую часть, и вы построили то, что в коде выглядит доступным, а на практике не работает. Поэтому первое правило ARIA от W3C - предпочитать нативный HTML, и поэтому её рекомендации прямо говорят, что без ARIA лучше, чем с плохой.
Почему добавление ARIA так часто делает сайт менее доступным?
Потому что ARIA меняет то, что объявляет экранный чтец, не меняя того, что страница на самом деле делает, и ошибка невидима для зрячего человека, который её допустил. Повторяется несколько шаблонов:
aria-hidden="true"не на том элементе. Задуманный, чтобы скрыть декоративный мусор, он попадает на настоящий элемент управления или кусок контента, который затем полностью исчезает для пользователей экранных чтецов, оставаясь полностью видимым для всех остальных.aria-label, который перекрывает видимый текст. На экране кнопка «Submit», а объявляется «кнопка» или, хуже, подпись, оставшаяся от прошлого релиза, и пользователь голосового управления, говорящий «нажать Submit», ни во что не попадает.- Роль, противоречащая элементу. Ссылка с
role="button"или заголовок сrole="presentation"говорят экранному чтецу одно, а страница ведёт себя как другое. Это та же структурная поломка, что описана в статье экранные чтецы и структура сайта: карта для вспомогательных технологий больше не совпадает с реальностью. - Состояние, которое никогда не обновляется.
aria-expanded="false"у меню, которое уже открыто, или ошибка, отмеченная ARIA, о которой экранному чтецу так и не сообщили, - разрыв, стоящий за большей частью проблем доступных форм и обработки ошибок.
Именно поэтому сканирование - не аудит. Автоматический сканер может подтвердить, что aria-label существует; обычно он не может сказать, правильна ли подпись, совпадает ли роль с поведением или должен ли был скрытый контент быть скрыт. Это человеческие суждения, и именно поэтому данные WebAIM показывают, что больше ARIA связано с большим, а не меньшим числом обнаруженных ошибок.
Почему оверлеи доступности делают проблему ARIA хуже?
Оверлей - один скрипт, который вы вставляете на сайт и который обещает автоматически исправить доступность, и значительная часть того, что он вставляет, - это ARIA. Хуже источника не придумать. Оверлей не может знать, какой из ваших <div> на самом деле кнопка, что должны говорить ваши элементы из одной иконки и нужно ли скрывать область, поэтому он гадает в масштабе, накладывая общую ARIA поверх структуры, которую не понимает. Результат - больше атрибутов, больше противоречий и больше ровно тех ошибок, которые продолжает измерять WebAIM Million. Это разрыв в центре темы виджеты-оверлеи или настоящее исправление, и поэтому меры FTC на 1 млн долларов США против поставщика оверлеев (accessiBe) вращались вокруг разрыва между маркетинговым обещанием и тем, что инструмент на самом деле давал. Плохая ARIA - не безобидное дополнение, а измеримый вред, и прикручивается он автоматически.
Как проверить, помогает ваша ARIA или вредит, и каков риск в Онтарио?
Полезную первую проверку можно сделать самому. Включите экранный чтец - VoiceOver есть в каждом Mac (Cmd-F5), Экранный диктор в Windows (Ctrl-Win-Enter), широко используется бесплатный NVDA - и пройдите реальную задачу: найти товар, добавить в корзину, заполнить форму, дойти до оформления заказа. Слушайте признаки. Объявляет ли каждый элемент имя, совпадающее с видимым текстом? Сообщают ли меню и аккордеоны правильное состояние «открыто/закрыто»? Не замолкает ли что-то, что вы видите, и не объявляет ли чтец то, чего нет на экране? Любое из этого - вероятно, дефект ARIA, и честное исправление почти никогда не больше ARIA. Это удаление сломанных атрибутов и, где возможно, использование нативного элемента HTML, которому ARIA вообще не была нужна. Работа по WCAG 2.2, действующему стандарту, держит эту основу чистой.
С юридической стороны: в Онтарио у AODA (Accessibility for Ontarians with Disabilities Act) нет права частного иска - человек не может подать по нему в суд. Путь для частного лица - HRTO (Трибунал по правам человека Онтарио), который рассматривает жалобы о дискриминации по Кодексу прав человека Онтарио; у клиента, который не может завершить покупку, которую может завершить зрячий, есть правдоподобная претензия о неравном доступе к товарам и услугам. Если вы продаёте ещё и в США, сломанные элементы управления - одни из самых упоминаемых проблем в исках по ADA, часть из более чем 5 000 исков о цифровой доступности, поданных в суды США в 2025 году (UsableNet). Как всегда, долговечная позиция - задокументированное исправление: найденные дефекты, удалённая сломанная ARIA, выкаченные нативные исправления и даты, - и это же должен отражать честный ACR к 31 декабря 2026 года.
Узнайте, не находит ли проверка на вашем сайте сломанную ARIA, код оверлея или другие проблемы доступности, - бесплатный отчёт Vayle, примерно 30 секунд: vayle.art. Он обнаруживает оверлеи, показывает реальные нарушения WCAG и точно говорит, что юридически относится к вашей организации в Онтарио. Без обязательств.
Vayle работает удалённо и занимается инженерной доступностью сайтов для бизнеса Онтарио. Общая информация, а не юридическая консультация.