Чек-лист доступности сайта для малого бизнеса и магазинов

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

Большинство проблем доступности на сайтах малого бизнеса выглядят именно так: владелец их не видит, а для покупателя это тупик. Этот чек-лист — для тех, у кого сайт на Shopify, WooCommerce, Wix или Squarespace, а разработчика в штате нет.

Должен ли сайт малого бизнеса быть доступным?

Если вы продаёте потребителям в ЕС, скорее всего, да. Европейский акт о доступности (откроется в новой вкладке) распространяется на услуги электронной торговли с 28 июня 2025 года. Главное исключение — для микропредприятий, оказывающих услуги: компаний, в которых работает менее 10 человек и годовой оборот или итог баланса не превышает 2 млн евро.

Электронная торговля здесь означает продажу на расстоянии, через сайт или приложение, «по индивидуальному запросу потребителя с целью заключения потребительского договора» (статья 3(30)). Интернет-магазин или система бронирования под это определение подходят. Исключение касается только услуг: если вы продаёте охватываемые товары, например электронные книги-ридеры, требования к товарам всё равно действуют (статья 4(5)). Не спасает и то, что компания находится за пределами ЕС: британский магазин, продающий покупателям во Франции, подпадает под действие акта в отношении них (статья 3(4)). О национальных законах и штрафах рассказывает наше руководство по Европейскому акту о доступности.

Британский Закон о равенстве 2010 года (откроется в новой вкладке) (Equality Act 2010) требует разумных приспособлений для людей с инвалидностью, но не устанавливает технического стандарта для сайтов. В США руководство Министерства юстиции от марта 2022 года (откроется в новой вкладке) говорит, что компании, открытые для публики, должны делать доступным то, что они предлагают онлайн, и что такие стандарты, как WCAG, «дают полезные ориентиры». Что бы ни говорил закон, покупатель, который не может завершить оформление заказа, ничего не купит.

Какие проблемы доступности встречаются на сайтах чаще всего?

Шесть ошибок встречаются чаще всех остальных. В WebAIM Million 2026 (откроется в новой вкладке) — автоматическом сканировании миллиона самых популярных главных страниц в феврале 2026 года — на 95,9% страниц обнаружены нарушения WCAG, в среднем 56,1 ошибки на страницу. Самой частой проблемой оказался текст с низким контрастом: он нашёлся на 83,9% главных страниц.

Эти проверки основаны на WCAG, Руководстве по обеспечению доступности веб-контента; большинство законов ссылаются на его уровень AA, а о последней версии рассказывает наше руководство по WCAG 2.2. Некоторые проверки ниже не может оценить ни один сканер.

Все ли могут прочитать ваш текст и понять ваши изображения?

Начните отсюда: эти исправления дешёвые, и в основном вы можете сделать их сами в редакторе сайта. Текст должен быть достаточно контрастным, у изображений, которые несут информацию, должен быть альтернативный текст, и ничто не должно передаваться только цветом. По данным Colour Blind Awareness (откроется в новой вкладке), нарушение цветового зрения есть примерно у каждого 12-го мужчины и у каждой 200-й женщины.

• Контраст. Обычному тексту нужен коэффициент контраста не менее 4,5:1 (откроется в новой вкладке) относительно фона, крупному — не менее 3:1. Проверьте свои цвета, в том числе текст поверх фото на баннерах, в бесплатном инструменте. Наше руководство по цветовому контрасту показывает исправления, которые сохраняют фирменный стиль.
• Альтернативный текст для товаров. Опишите то, что нужно знать покупателю: «Тёмно-синий шерстяной свитер с высоким воротником в рубчик, вид спереди» лучше, чем «изображение товара 1». Начните с десяти самых продаваемых товаров.
• Декоративные изображения. У фонового завитка альтернативный текст должен быть пустым, чтобы скринридеры его пропускали. Некоторые платформы подставляют в пустое поле alt имя файла, так что проверьте свою.
• Только цвет. «Нет в наличии», показанное только посеревшим образцом цвета, или обязательное поле, отмеченное только красным, дойдут не до всех. Посмотрите на страницу через фильтр оттенков серого в телефоне и добавьте слово или значок везде, где пропадает смысл.
• Масштаб. При масштабе браузера 200% текст должен увеличиваться, не накладываясь и не обрезаясь, а меню — по-прежнему работать.
• Язык страницы. Любой бесплатный инструмент проверки покажет, что язык страницы не указан. Это настройка темы или изменение одной строки в шаблоне.

Можно ли пользоваться вашим сайтом с клавиатуры?

Многие просматривают сайты без мыши: пользователи скринридеров, люди с тремором или ограниченной подвижностью рук и все, у кого только что отказал тачпад. Отложите мышь и нажимайте Tab. Вы должны добраться до каждой ссылки, кнопки и поля формы в логичном порядке, всегда видеть, где находитесь, и нигде не застревать.

• Видимый фокус. Контур должен показывать, какой элемент активен, и его не должны закрывать закреплённая шапка или значок чата (критерий WCAG 2.2 2.4.11 «Фокус не скрыт»). Многие темы убирают контур ради внешнего вида; разработчик может его вернуть.
• Никаких ловушек. Откройте с клавиатуры меню, выбор размера, всплывающие окна и галерею изображений, выберите что-нибудь и попробуйте выйти. Escape должен закрывать всплывающие окна.
• Названия для значков. Каждой ссылке-значку и кнопке нужно название, которое может озвучить скринридер, например «Корзина, 2 товара». Замените «Нажмите здесь» словами, которые говорят, куда ведёт ссылка.
• Ссылка для пропуска и заголовки. В идеале первое нажатие Tab показывает ссылку «Перейти к содержимому». В опросе пользователей скринридеров WebAIM 2024 года (откроется в новой вкладке) 71,6% респондентов сказали, что на длинной странице сначала ориентируются по заголовкам, поэтому используйте настоящие уровни заголовков, а не жирный текст.
• Области нажатия. WCAG 2.2 требует областей нажатия не меньше 24 на 24 CSS-пикселя или достаточного свободного места вокруг них (критерий успешности 2.5.8 (откроется в новой вкладке)).

Все ли могут пройти ваши формы, корзину и оформление заказа?

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

• Подписи, а не подсказки. Текст-подсказка внутри поля исчезает, как только человек начинает печатать, и часто слишком бледный, чтобы его прочитать. Каждому полю нужна подпись, которая остаётся на виду.
• Сообщения об ошибках. Отправьте форму пустой. Каждая ошибка должна быть описана словами («Введите почтовый индекс, например 10115»), находиться рядом со своим полем и озвучиваться скринридером, а не сводиться к красной рамке.
• Не спрашивайте дважды. Предложите вариант «Адрес для счёта совпадает с адресом доставки», а не заставляйте заново вводить адрес. В WCAG 2.2 это стало требованием уровня A — 3.3.7 «Повторный ввод».
• Вход в аккаунт. Позвольте вставлять пароли и одноразовые коды и пользоваться менеджерами паролей. Запрет вставки нарушает критерий «Доступная аутентификация» (откроется в новой вкладке) WCAG 2.2, если вы не предлагаете другого способа войти.
• CAPTCHA. В опросе WebAIM 2024 года пользователи скринридеров назвали CAPTCHA самым проблемным элементом в интернете. Если нужна защита от ботов, избегайте визуальных головоломок и всегда предлагайте невизуальную альтернативу.
• Ограничения по времени. Если резерв корзины или бронирования истекает, предупредите об этом и дайте продлить срок.

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

А баннеры о cookie, всплывающие окна и виджеты чата?

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

• Баннер о cookie. Можно ли добраться клавишей Tab до кнопок «принять» и «отклонить», прочитать их при масштабе 200% и затем продолжить с того же места?
• Всплывающие окна. Фокус должен переходить во всплывающее окно, оставаться в нём до закрытия, а затем возвращаться. Escape должен его закрывать.
• Виджеты чата. У кнопки должно быть название, окно должно открываться и закрываться с клавиатуры, а на телефоне не должно перекрывать кнопку «Оплатить».
• Карусели. Для всего, что движется автоматически дольше пяти секунд, нужен способ это приостановить, остановить или скрыть (WCAG 2.2 (откроется в новой вкладке), критерий успешности 2.2.2).
• Встроенные элементы. Виджеты отзывов, карты и инструменты бронирования тоже находятся на вашей странице. О нарушениях сообщайте поставщику.

Работают ли ваши видео, PDF и меню для всех?

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

• Субтитры и расшифровки. Исправляйте автоматические субтитры перед публикацией. Подкастам нужна текстовая версия.
• Текст на картинках. Размещайте меню, прайс-листы, таблицы размеров и часы работы на обычной веб-странице. Если без PDF не обойтись, экспортируйте его из текстового редактора с заголовками и тегами, а не сканируйте распечатку.
• Старые файлы. EAA не требует исправлять офисные файлы и заранее записанные аудио и видео, опубликованные до 28 июня 2025 года, или архивы, которые вы больше не обновляете (статья 2(4)). Новые файлы под действие акта подпадают.

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

Большинство проблем с контентом вы можете исправить сами в CMS: альтернативный текст, заголовки, текст ссылок, цвета, субтитры и многие подписи полей форм. Проблемы на уровне темы — отсутствие стилей фокуса, клавиатурные ловушки и нестандартные выпадающие списки — требуют разработчика. Аудит разумнее всего проводить, когда основное уже исправлено, или перед запуском редизайна.

Какое место здесь у виджета вроде нашего? Панель на стороне посетителя, такая как SiteAccessible, позволяет повысить контраст, увеличить текст или включить линейку для чтения. Это помогает части посетителей, но не закрывает ни одного пункта этого чек-листа: кнопка без названия так и остаётся без названия, а клавиатурная ловушка — ловушкой. Сначала исправьте сайт, а виджет считайте дополнением.

Как зафиксировать сделанное?

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

Эта вторая обязанность следует из приложения V к директиве, а формат определяет национальный закон. В нашем руководстве по составлению заявления о доступности есть шаблон, который можно адаптировать. Дальше главное — не бросать:

1. Пройдите чек-лист на трёх ключевых страницах и сделайте скриншот каждой ошибки.
2. На этой неделе сами исправьте пункты, касающиеся контента.
3. Поставьте разработчику задачи по теме и оформлению заказа, начиная с самых серьёзных.
4. Перепроверяйте каждое исправление не только инструментом, но и клавиатурой.
5. Опубликуйте или обновите заявление, указав дату.
6. Повторяйте всё это каждый раз, когда добавляете приложение, меняете тему или запускаете новый лендинг.