Как проверить доступность сайта: бесплатные инструменты и тесты

Вот история, которую мы слышим часто. Человек запускает Lighthouse, получает зелёные 100 баллов за доступность и идёт дальше. Через неделю покупатель пишет, что не смог оплатить заказ, потому что до формы ввода карты не добраться с клавиатуры. Верно и то и другое. Автоматическая проверка пройдена, а живого человека сайт всё равно подвёл.

Это руководство показывает, как проверить сайт как следует при скромном бюджете: какие бесплатные инструменты запустить, 15-минутная ручная проверка, первое знакомство со скринридером и когда стоит платить за аудит.

Может ли автоматический инструмент сказать, доступен ли мой сайт?

Нет. Автоматические инструменты быстро находят часть проблем, но на многие вопросы доступности может ответить только человек. Когда Служба цифровых технологий правительства Великобритании (GDS) проверила 10 инструментов на странице со 143 известными ошибками, лучший нашёл 41%. W3C говорит прямо: инструменты оценки «не могут определить доступность, они могут лишь помочь в этом».

Тест GDS (откроется в новой вкладке) проводился в феврале 2017 года, и его 41% (у Asqatasun) включали подсказки инструмента для ручных проверок. С тех пор инструменты стали лучше, но у разрыва та же причина. Программа может определить, что у изображения нет альтернативного текста. Но не может определить, что «красное платье» — неверное описание фото синего костюма, или понять, логичен ли порядок фокуса.

Поэтому относитесь к автоматической проверке как к пожарному датчику, а не к обследованию здания. Запускать её всё равно стоит: WebAIM Million 2026 (откроется в новой вкладке) нашёл автоматически обнаруживаемые ошибки на 95,9% из миллиона самых популярных главных страниц, так что почти на любом сайте найдётся что исправить быстро. Как сказано в руководстве W3C по выбору инструментов (откроется в новой вкладке), «требуется человеческое суждение».

Какими бесплатными инструментами проверки доступности пользоваться?

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

Что можно проверить вручную за 15 минут?

Довольно много. Easy Checks (откроется в новой вкладке) от W3C («Простые проверки») охватывают заголовки страниц, альтернативный текст, заголовки разделов, контраст, ссылки для пропуска, видимый фокус клавиатуры, язык страницы, масштабирование, субтитры и подписи полей форм. Выберите одну важную страницу, например карточку товара или форму бронирования, и уделите каждой проверке минуту-две. Вы найдёте то, о чём не сообщит ни один инструмент.

W3C пишет, что эти проверки «охватывают лишь несколько проблем доступности», так что полной оценкой они не являются. И всё же это лучшие четверть часа, которые вы можете потратить:

1. Заголовок страницы (1 минута). Говорит ли вкладка браузера, что это за страница, например «Забронировать столик | Кухня Розы», а не «Главная» везде?
2. Изображения (2 минуты). Покажите альтернативный текст с помощью WAVE или похожего инструмента. Он точен? Декоративные изображения пропускаются?
3. Заголовки (2 минуты). Выведите список заголовков и прочитайте их отдельно. Работают ли они как оглавление?
4. Контраст (2 минуты). Проверьте основной текст, мелкий серый текст, текст кнопок и текст на изображениях.
5. Клавиатура (4 минуты). Отложите мышь и пройдите страницу клавишей Tab (см. следующий раздел).
6. Масштаб (2 минуты). При 200%, а затем 400% можно ли всё прочитать и пользоваться меню без горизонтальной прокрутки?
7. Формы и язык (2 минуты). Щёлкните по подписи каждого поля: в правильно сделанной форме курсор окажется в поле. Проверьте в отчёте инструмента, не пропущен ли язык страницы.

Как проверить сайт с клавиатуры?

Уберите мышь. Нажимайте Tab, чтобы двигаться вперёд, Shift+Tab — чтобы вернуться, Enter — чтобы перейти по ссылке, пробел или Enter — чтобы нажать кнопку, а клавиши со стрелками — внутри меню и групп переключателей. Каждый интерактивный элемент должен быть доступен, вы всегда должны видеть, где находитесь, и нигде не должны застревать.

На Mac браузер Safari пропускает ссылки при нажатии Tab, пока вы не включите в дополнительных настройках параметр, при котором Tab выделяет каждый объект на веб-странице (Press Tab to highlight each item on a webpage). Затем проверьте:

• Всегда ли видно, где вы находитесь? Если контур фокуса исчезает, пользователь клавиатуры теряется.
• Логичен ли порядок? Фокус должен следовать порядку чтения.
• Не перекрыто ли что-нибудь? Закреплённая шапка или баннер о cookie, скрывающие элемент в фокусе, нарушают критерий WCAG 2.2 «Фокус не скрыт».
• Можно ли выбраться обратно? Откройте каждое меню, всплывающее окно и выбор даты, а затем попробуйте выйти. Escape должен закрывать диалоговые окна.
• Работает ли весь сценарий? Добавьте товар, измените количество, примените промокод и дойдите до оплаты без мыши.

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

Как впервые проверить сайт со скринридером?

Начните со скринридера, который уже есть на вашем устройстве, или с NVDA в Windows и прослушайте одну страницу. Вы не пытаетесь пользоваться им как эксперт. Вы проверяете, что заголовки, ссылки, кнопки, изображения и поля форм озвучиваются с понятными названиями и что ничего важного не молчит.

• Mac: Command+F5 включает и выключает VoiceOver; Control+Option+U открывает ротор — список заголовков, ссылок и элементов форм.
• Windows: в NVDA нажмите H, чтобы переходить между заголовками, и Insert+F7, чтобы вывести список ссылок и заголовков.
• Телефон: включите VoiceOver (iPhone) или TalkBack (Android) и проводите пальцем вправо, чтобы переходить от элемента к элементу. Сначала узнайте, как его выключить.

Прислушивайтесь к главному. В опросе пользователей скринридеров WebAIM 2024 года (откроется в новой вкладке) 71,6% респондентов сказали, что на длинной странице сначала ориентируются по заголовкам, так что начните с них. Затем выведите список ссылок: пять ссылок «Подробнее» никому ничего не говорят. «В корзину, тёмно-синий свитер» — полезная кнопка, а просто «кнопка» — нет. Напоследок заполните форму и проверьте, что каждое поле и каждая ошибка зачитываются.

Не делайте далеко идущих выводов. Если вам кажется, что что-то сломано, скорее всего, так и есть; если всё звучит нормально, это ещё не доказательство. Как работают опытные пользователи, читайте в статье «Как люди с инвалидностью пользуются сайтами».

Как проверить масштабирование, перестроение контента и интервалы в тексте?

Увеличьте масштаб браузера до 200% и проверьте, что текст растёт, не обрезаясь и не накладываясь. Затем проверьте перестроение: при масштабе 400% в окне шириной 1280 пикселей контент должен помещаться без горизонтальной прокрутки. Наконец, увеличьте интервалы между буквами, словами, строками и абзацами и проверьте, что ничего не ломается и не пропадает.

Это соответствует критериям WCAG «Изменение размера текста» (1.4.4), «Перестроение» (1.4.10) (откроется в новой вкладке) и «Интервалы в тексте» (1.4.12) (откроется в новой вкладке). «Перестроение» использует ширину 320 CSS-пикселей, что, как отмечает W3C, «эквивалентно начальной ширине области просмотра 1280 CSS-пикселей при масштабе 400%». «Интервалы в тексте» требуют, чтобы ничего не терялось, когда читатель задаёт межстрочный интервал в 1,5 размера шрифта, интервал между абзацами в 2 размера, межбуквенный интервал в 0,12 и межсловный в 0,16 размера шрифта.

Букмарклет для интервалов — небольшой скрипт, сохранённый как закладка, — применяет все четыре значения одним щелчком. Ищите текст, вылезающий за пределы кнопок, и подписи, обрезанные по краю. При масштабе 400% ноутбук показывает примерно то же, что маленький телефон, поэтому хорошо сделанный адаптивный сайт проходит большую часть этих проверок уже сейчас.

Как проверить формы, ошибки и оформление заказа?

Заполните каждую важную форму трижды: один раз правильно, один раз оставив все поля пустыми и один раз с намеренными ошибками. У каждого поля должна быть видимая подпись, каждая ошибка должна объясняться словами рядом со своим полем, а в поля пароля и кода подтверждения должна работать вставка.

• Ошибки. Красного «Недопустимый ввод» недостаточно. «Введите срок действия в формате ММ/ГГ» рядом с полем — достаточно. После отправки фокус должен переходить к сводке ошибок или к первому полю с проблемой.
• Вход и коды. По критерию «Доступная аутентификация» (откроется в новой вкладке) WCAG 2.2 блокировка вставки или менеджеров паролей — нарушение, если нет другого способа войти.
• CAPTCHA и ограничения по времени. В опросе WebAIM пользователи скринридеров назвали CAPTCHA самым проблемным элементом в интернете. Проверьте, есть ли доступная альтернатива и можно ли продлить ограничения по времени.

В нашем чек-листе доступности сайта есть более полный список для магазинов, включая баннеры о cookie и всплывающие окна.

Что входит в профессиональный аудит доступности и когда он нужен?

Аудит доступности — это структурированная проверка, которую специалист проводит по названному стандарту, обычно WCAG 2.1 или 2.2 уровня AA. Он сочетает автоматическое сканирование с ручным тестированием и тестированием вспомогательными технологиями ключевых шаблонов и сценариев, а в конце даёт отчёт с приоритетами. Он нужен, если на вас распространяется закон, перед крупным запуском или когда клиенты просят доказательств.

Прежде чем согласовать цену, спросите:

• По какому стандарту, версии и уровню вы будете проверять?
• Какие шаблоны и сценарии входят в проверку? Для магазина: главная, категория, товар, корзина, оформление заказа, личный кабинет и формы.
• Проверяете ли вы вручную со скринридерами, клавиатурой и масштабированием и в каких браузерах и на каких устройствах?
• Ранжирует ли отчёт проблемы по серьёзности, указывает ли, где они находятся, и предлагает ли исправления?
• Включена ли повторная проверка?

Цены сильно зависят от исполнителя, страны и объёма работ, поэтому сравнивайте, что входит в стоимость. Если на вас распространяется Европейский акт о доступности, аудит также подкрепляет ваше публичное заявление; на кого распространяется акт, объясняет наше руководство по EAA.

Зачем тестировать с участием пользователей с инвалидностью?

Потому что соответствовать стандарту и быть удобным — не одно и то же. Оформление заказа может выполнять все критерии WCAG и всё равно отнимать у пользователя скринридера двадцать минут. W3C пишет, что оценка с участием пользователей с инвалидностью «выявляет проблемы удобства, которые не обнаруживает одна лишь оценка соответствия», а ещё она показывает вашей команде, как люди на самом деле пользуются сайтом.

Лаборатория не нужна. Несколько сессий по вашей самой важной задаче, например поиску товара и оплате, научат вас большему, чем ещё один раунд сканирований. Находите участников через организации людей с инвалидностью, исследовательские агентства или среди собственных покупателей и платите людям за их время. Пусть они пользуются своими устройствами и настройками. Практическая сторона описана в руководстве W3C о привлечении пользователей к оценке (откроется в новой вкладке).

Что делать с результатами?

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

1. Расставьте приоритеты. Сначала блокирующие проблемы в ключевых сценариях (оформление заказа, бронирование, регистрация), затем общие шаблоны, затем отдельные страницы.
2. Исправляйте в источнике. Меняйте тему, компонент или контент, а не только симптом.
3. Проверьте заново. Повторите те же проверки — и вручную, и инструментами.
4. Задокументируйте. Перечислите известные проблемы с датами в своём заявлении о доступности. Более новые критерии объясняет наше руководство по WCAG 2.2.
5. Повторяйте. Добавьте проверку клавиатурой и сканирование в каждый релиз.

Если вы используете виджет доступности, включая наш, тестируйте с закрытым виджетом. Панель вроде SiteAccessible даёт посетителям дополнительные способы настроить страницу, но WCAG оценивает, работает ли страница в состоянии по умолчанию. Некоторые программы аудита не оценивают страницы, на которых работает скрипт-оверлей, поэтому заранее уточните это у аудитора.