Доступный интернет-магазин — это не главная страница с хорошим контрастом. Покупатель должен найти и понять товар, выбрать вариант, исправить ошибку, войти, оплатить и получить подтверждение без мыши, идеального зрения и необходимости угадывать.
Короткий ответ
Аудит доступности интернет-магазина начинается с определения рынков, юридических лиц, цифровой услуги и применимых национальных правил. Затем нужно проверить репрезентативные пути от поиска до подтверждения заказа: автоматическими тестами, только с клавиатурой, при увеличении и переформатировании, со скринридером и вручную. По возможности привлекайте людей с инвалидностью. В первую очередь устраняйте барьеры, которые не дают завершить задачу, а не замечания, сильнее всего снижающие условный рейтинг.
Директива (ЕС) 2019/882 — Европейский акт о доступности — применяется через законы стран ЕС с 28 июня 2025 года. Услуги электронной торговли прямо входят в ее область. Охваченная услуга должна быть воспринимаемой, управляемой, понятной и надежной; это относится и к идентификации, безопасности и платежам, если они предоставляются как часть услуги.
Определите область EAA без ложных сокращений
Составьте реестр применимости: продавец, страны потребителей, сайт и приложение, оформление заказа, платежные сервисы и провайдеры идентификации, поддержка, продаваемые товары или услуги, национальный акт, ответственный и дата пересмотра. Основные требования гармонизированы, но трансграничный магазин может иметь дело с разными надзорными органами и процедурами.
Директива освобождает микропредприятия, предоставляющие услуги, от части обязанностей. Однако «мы маленькая компания» — не анализ: определение учитывает сотрудников, финансовые пороги и связи между компаниями, а реализация зависит от национального права. Положения о фундаментальном изменении и несоразмерном бремени тоже требуют обоснованной оценки. Они не позволяют просто отложить неудобную доработку. Юридическую область должен подтвердить профильный специалист.
Исключение из закона не отменяет продуктовый смысл. Навигация с клавиатуры, заметный фокус, понятные ошибки, читаемый текст и предсказуемая оплата помогают людям с постоянными и временными ограничениями, пожилым покупателям, пользователям маленьких экранов и тем, кто оформляет заказ в сложной обстановке.
Разделяйте правовой вывод и инженерный ориентир
Директива задает функциональные требования. Маршрут подтверждения соответствия определяют национальные законы, применимые гармонизированные стандарты или технические спецификации, договоры и отраслевые разъяснения. WCAG 2.2 — международно используемый набор проверяемых критериев и сильная основа для разработки. Но «мы протестировали WCAG 2.2 AA» не равнозначно заявлению «мы выполнили все обязанности EAA».
До аудита подготовьте короткий паспорт: границы, версия стандарта, целевой уровень, браузеры, устройства, скринридеры, языки, тестовые аккаунты, внешние сервисы, метод выборки, исключения, формат доказательств и дата повторной проверки. Если без платежного iframe или CAPTCHA покупка невозможна, пометка «сторонний сервис» не устраняет проблему клиента. Нужны ответственный за эскалацию и доступный резервный маршрут.
Выбирайте процессы и состояния, а не удобные страницы
Сканирование главной страницы не оценивает торговую операцию. Включите в выборку поиск, категорию и фильтры, карточку с вариантами, изменение корзины, гостевое оформление и покупку из аккаунта, промокод, доставку, платежную проверку, подтверждение, отмену или возврат и обращение в поддержку. Воспроизведите отсутствие товара, ошибку поля, отклоненный платеж, завершение сессии и загрузку.
Возьмите контент с разной сложностью: простой и настраиваемый товар, видео или PDF-инструкцию, длинный перевод, скидку, marketplace-продавца и страницу из CMS. Проверьте мобильную и десктопную версии. Нативное приложение аудируется отдельно: успешный результат адаптивного сайта на него не переносится.
12 проверок доступности интернет-магазина
| Проверка | Что сделать | Типичный барьер |
|---|---|---|
| 1. Клавиатура | Пройдите путь с Tab, Shift+Tab, Enter, Space, стрелками и Escape | Фильтр, вариант товара, модальное окно или платежное поле не работают |
| 2. Фокус | Следите за видимостью, порядком, входом в диалог и возвратом | Фокус скрывается под закрепленным блоком или теряется после обновления корзины |
| 3. Семантика | Проверьте заголовки, области, подписи, имена, роли, состояния и значения | Красивый нестандартный элемент не имеет понятного программного представления |
| 4. Контраст | Оцените текст, индикатор фокуса, иконки, ошибки и выбранные состояния | Описание читается, а checkbox или сообщение об ошибке — нет |
| 5. Увеличение | Увеличьте текст и страницу, сузьте область просмотра, смените ориентацию | Цена, кнопка закрытия или итог перекрываются и пропадают |
| 6. Нетекстовый контент | Проверьте фото, схемы, иконки, видео, аудио и PDF | Цвет или изображение сообщает важное свойство без текстового эквивалента |
| 7. Данные товара | Проверьте информацию о доступности, совместимости, безопасности и сервисе | Магазин получил сведения от производителя, но не показал покупателю |
| 8. Поиск и фильтры | Используйте подсказки, сортировку, фильтры и пустую выдачу без зрения | Число результатов меняется молча, активный фильтр нельзя определить |
| 9. Формы | Отправьте пустую, ошибочную и исправленную форму адреса и оплаты | Есть красная рамка, но нет текста, связи с полем или способа исправить |
| 10. Вход и оплата | Протестируйте вход, MFA, альтернативу CAPTCHA, электронный кошелек, карту и 3-D Secure | Проверка безопасности создает тупик для клавиатуры или скринридера |
| 11. Динамика | Вызовите изменение цены, запаса, корзины, валидации и загрузки | Визуальное уведомление есть, а вспомогательная технология его не получает |
| 12. Текст и поддержка | Оцените ясность инструкций, условий, чата, службы поддержки и альтернатив | Интерфейс управляем, но условия непонятны или помощь недоступна |
Автоматизируйте проверки, которые можно однозначно выразить правилами: отсутствующие имена, неверные связи, часть проблем контраста, язык документа, дубли ID и требования к компонентам. Запускайте их при разработке и в CI. При этом W3C прямо предупреждает: ни один инструмент сам по себе не устанавливает соответствие сайта стандартам доступности. Ноль ошибок в сканере не является сертификатом.
Совершите реальную покупку со вспомогательной технологией
Сначала уберите мышь и пройдите весь маршрут с клавиатуры. Фиксируйте, куда попадает фокус и можно ли предсказать следующую операцию. Затем используйте хотя бы одну подходящую пару «скринридер + браузер». Слушайте интерфейс, не подглядывая: выбор варианта должен сообщать имя, состояние и влияние на цену, итоги — обновляться, ошибки — находиться, подтверждение — звучать однозначно.
Успешной тестовой карты мало. Проверьте отказ банка, дополнительную аутентификацию, изменение доставки, просроченный промокод и новую стоимость корзины. Сохраняйте введенные данные там, где это безопасно, описывайте ошибку текстом, связывайте ее с полем, корректно переводите или уведомляйте фокус и объясняйте восстановление. До возникновения финансового обязательства дайте просмотреть и исправить заказ.
Локализация входит в тест. Задайте верный язык страницы, отмечайте настоящие смены языка, переводите программные имена элементов и ошибки, проверяйте размещение длинного текста при увеличении. Украинская кнопка в русском оформлении или наоборот — не только редакционная проблема: скринридер может изменить произношение, а действие станет менее понятным.
Приоритизируйте по сорванной задаче и масштабу повтора
Для каждой находки запишите воспроизводимый путь, ожидаемый и фактический результат, компонент, конфигурацию, критерий, запись или снимок, владельца, исправление и результат ретеста. Не сводите вывод к одному «баллу доступности». Он не показывает, что важнее: двадцать небольших замечаний или одна keyboard trap, блокирующая все заказы.
- P0 — транзакция заблокирована: нельзя выбрать товар, войти, оплатить или восстановиться после ошибки. Нужны немедленный безопасный обход и исправление.
- P1 — серьезная потеря информации или контроля: частый сценарий становится чрезмерно сложным, неоднозначным или ненадежным.
- P2 — локальный барьер: задача выполнима, но требует лишних усилий или обходного пути.
- P3 — улучшение: полезная работа для удобства и поддержки с ограниченным срочным эффектом.
Учитывайте повторяемость. Ошибка в общем поле, модальном окне, компоненте цены или дизайн-токене затрагивает тысячи состояний и все языковые версии. Ремонт базового компонента обычно полезнее, чем исправление страниц по скриншотам.
Сделайте доступность свойством релиза
Опишите в дизайн-системе обычное состояние, наведение, фокус, отключение, выбор, ошибку, загрузку, успех и пустой результат. Начинайте с семантического HTML, добавляя ARIA только когда нативного элемента недостаточно. В критерии приемки компонента включите клавиатуру, объявления изменений, увеличение, размер области нажатия, уменьшение движения и ограничения контента.
При проверке изменений запускайте lint и браузерные тесты для компонентов и критических путей. Перед релизом выполняйте короткий ручной прогон с клавиатурой и увеличением. По расписанию и перед серьезными изменениями оформления повторяйте маршруты со скринридером и пользователями с инвалидностью. Отслеживайте долю барьеров, дошедших до рабочей версии, время исправления, возврат дефектов по компонентам и завершение ключевых задач.
Включите поставщиков в критерии выпуска. Запрашивайте у сервисов оплаты, чата, отзывов, согласия на cookie и идентификации актуальную документацию, проверенные конфигурации, известные ограничения, контакт для эскалации и уведомления об изменениях. Для незаменимой интеграции нужен план перехода или доступный канал с участием сотрудника.
План исправлений на 30 дней
Не начинайте с виджета, обещающего мгновенно сделать сайт доступным. Накладной инструмент в браузере не исправляет надежно базовую семантику, клавиатурное поведение, внешнюю оплату, контент и ответственность команды. Цель первого месяца — убрать реальные барьеры и создать воспроизводимую систему доказательств.
Честно описывайте границы и обновляйте доказательства
Аудит — датированный результат для определенной выборки и конфигурации, а не бессрочный сертификат. Новый товар, акция, контент из CMS, релиз платежного провайдера или эксперимент завтра могут внести дефект. Храните версию, дату, артефакты, владельцев и график ретеста; публикуйте только подтвержденные заявления.
Для охваченных услуг директива предусматривает доступную информацию о том, как услуга выполняет требования. Формат зависит от национальной реализации. Подготовьте фактическую основу из аудита: описание услуги, применимые требования, способы их выполнения, известные ограничения, канал обратной связи и порядок обновления. Публичный документ проверяет сторона, отвечающая за юридический вывод.
В отчете WebAIM Million 2026 автоматический анализ обнаружил в среднем 56,1 ошибки на главной странице миллиона популярных сайтов. Авторы одновременно отмечают: отсутствие найденных ошибок не доказывает доступность. Это показатель распространенности регрессий, а не ориентир «быть чуть лучше среднего». Полезная цель — покупатели выполняют важные задачи, а команда умеет подтверждать, поддерживать и улучшать результат.
Частые вопросы
Распространяется ли Европейский акт о доступности на магазин вне ЕС?
Может распространяться, если ecommerce-услуга предлагается потребителям в ЕС. Значение имеют продавец, рынок, вид услуги, исключения и национальный закон. Нужна консультация квалифицированного юриста.
Достаточно ли WCAG 2.2 AA для соответствия EAA?
Это сильный технический ориентир, но не автоматический правовой вывод. Учитывайте национальные нормы, стандарты, внешние сервисы, документы и процесс поддержки.
Может ли автоматический сканер сертифицировать сайт?
Нет. Автоматизация находит только часть проблем. Клавиатуру, скринридер, увеличение, смысл, восстановление после ошибок и полные процессы оценивают люди.
С чего начать аудит цифровой доступности?
С самого ценного полного маршрута: поиск товара, успешный заказ и восстановление после неудачной оплаты. Сначала исправляйте блокеры в общих компонентах.
Как часто повторять проверку?
Автотесты — постоянно, короткий ручной набор — на релизах, широкий аудит сценариев — по графику и после значимых изменений темы, CMS, оформления или поставщика.
Rendframe может описать критические маршруты магазина, провести технический аудит, исправить общие компоненты и оформление заказа, добавить регрессионные тесты и передать доказательный список работ. Юридическое заключение остается за вашим консультантом. Посмотрите, как мы создаем надежные ecommerce-системы, или пришлите магазин, рынки и платежных провайдеров для первичного обзора доступности.
Продолжить: сопоставьте барьеры доступности с полным аудитом причин брошенного оформления, подготовьте вопросы к агентству разработки или встройте доступность в продуктовую разработку.