Доступность сайта: как сделать его удобным для людей с нарушениями зрения

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

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

Что такое доступность сайта для людей с нарушениями зрения

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

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

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

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

Кому особенно важна доступность сайта

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

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

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

Как спроектировать понятную структуру страницы

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

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

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

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

Текст, шрифт и масштабирование

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

Для сплошного текста обычно подходят размеры от 16 пикселей, а точное значение зависит от гарнитуры, межстрочного интервала и длины строки. Интервал между строками должен позволять легко переходить к следующей строке. Слишком плотный набор утомляет, особенно при увеличении, а чрезмерно широкий текстовый блок мешает не потерять строку.

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

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

Контраст, цвет и визуальные состояния

Текст и важные элементы должны заметно отличаться от фона. Для обычного текста разумный ориентир по WCAG составляет контраст не ниже 4,5:1, для крупного текста допускается 3:1. Для элементов управления и графических объектов, без которых нельзя понять состояние интерфейса, также нужен достаточный контраст.

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

Цвет не должен быть единственным способом передать смысл. Формулировка «поля, отмеченные красным» недостаточна. Лучше добавить текстовую подсказку, значок с доступным названием и понятное сообщение рядом с конкретным полем. Для диаграммы нужны подписи, узоры или таблица данных, а не только разные цвета сегментов.

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

Изображения, иконки и видео

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

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

• Изображение-ссылка должно сообщать, куда ведёт переход.
• Иконка корзины должна иметь доступное имя, например «Добавить товар в корзину».
• Кнопка с крестиком должна быть понятна без визуального контекста, например «Закрыть окно».
• Инфографика должна иметь текстовый вывод с теми же данными.
• Видео желательно сопровождать субтитрами, а важную информацию из изображения или речи дублировать текстом.

Проблема часто возникает при использовании декоративных иконок вместо текста. Если рядом с символом нет понятной подписи, пользователь экранного диктора может получить только слово «кнопка» без объяснения действия. Для часто повторяющихся действий лучше использовать видимую короткую подпись, а для компактных элементов обязательно задавать доступное название.

Навигация с клавиатуры и управление без мыши

Проверьте сайт только клавиатурой. Клавиша Tab должна перемещать фокус по элементам в логичном порядке, Shift и Tab возвращать его назад, Enter активировать ссылки и кнопки, а стрелки работать внутри списков выбора и вкладок, если такой сценарий предусмотрен. В любой момент должно быть понятно, какой элемент выбран.

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

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

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

Формы, ошибки и заявки

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

Ошибку следует показывать рядом с конкретным полем и описывать действие, которое поможет её исправить. Сообщение «Неверно» не объясняет причину. Лучше написать: «Введите номер телефона из 10 цифр после кода страны». При отправке формы полезно сообщить об общей ошибке в начале блока и переместить фокус к первому проблемному полю.

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

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

Что проверять на этапе разработки и перед публикацией

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

Минимальный порядок проверки выглядит так:

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

В типичном проекте первичный технический аудит занимает от 1-3 рабочих дней для небольшого сайта до 1-2 недель для интернет-магазина или сложного сервиса. Исправления могут занять от нескольких дней, если проблема ограничена контрастом и подписями, до 3-6 недель, если требуется переработать компоненты, шаблоны и логику форм. По рынку аудит небольшого сайта часто оценивают в диапазоне 20 000-60 000 рублей, а полный комплекс работ считают отдельно после изучения проекта.

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

Типичные ошибки при создании доступного сайта

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

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

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

Ошибка 4. Alt-текст заполняют автоматически. CMS может подставить имя файла, повторить заголовок или оставить описание пустым. Альтернативный текст нужно писать по смыслу, а декоративные изображения корректно исключать из чтения.

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

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

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

Частые вопросы

Нужно ли делать отдельную мобильную версию для людей с нарушениями зрения?

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

Достаточно ли увеличить размер шрифта?

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

Может ли доступность ухудшить дизайн сайта?

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

Нужен ли аудит, если сайт сделан на готовой системе управления?

Да. Система управления может формировать корректную базовую разметку, но итог зависит от темы, шаблонов, плагинов, виджетов и контента. Готовая тема не гарантирует доступность формы, фильтра, всплывающего окна или нестандартного меню.

Сколько стоит сделать сайт доступным?

Точная сумма зависит от числа шаблонов, количества ошибок и способа реализации. По рынку точечные исправления на небольшом сайте могут стоить от 30 000-80 000 рублей, а переработка сложного проекта, включая аудит и тестирование, может оцениваться от 100 000 рублей и выше. Точную смету составляют после брифа и проверки сайта.

Как понять, что исправления действительно помогли?

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

Что делать: короткий план

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

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