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

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

• Текст должен иметь контрастность 4,5:1
• Крупный текст размером от 18pt — 3:1
• UI-компоненты и графика — минимум 3:1

Что проверять:

1. Все состояния ссылок и кнопок — не только обычное, но и :hover, :focus, :visited
2. Если вы проектируете тёмный режим, он должен соответствовать тем же стандартам доступности, что и светлый — только в инверсии. 
3. Текст поверх фото или градиента — самое уязвимое место
4. Плейсхолдеры в полях часто не проходят проверку контрастности

Белый текст на тёмном фоне может быть проблемой для людей с астигматизмом — давать выбор пользователю обязательно.

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

Что добавлять к цвету

• Иконка + текстовая подпись: не просто красный фон, а восклицательный знак и слово «Ошибка»
• В графиках и таблицах — текстуры, паттерны или прямые подписи к данным, не только цветовые легенды
• В формах — не только красная рамка у поля с ошибкой, но и текст под полем с объяснением

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

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

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

APCA (Advanced Perceptual Contrast Algorithm) — это новый способ считать контраст, который придёт на смену формуле WCAG 2.x в WCAG 3.0. 
Старая формула считает контраст одинаково для любого текста — 4.5:1 и всё. Но человеческое зрение так не работает. Мелкий светло-серый текст на белом фоне может формально пройти проверку, но на практике читаться плохо. И наоборот — жёлтый на белом не проходит, хотя крупный жирный жёлтый читается нормально.

Цветовые пространства и доступность

HEX и RGB — одно и то же, разный синтаксис
#FF5733 и rgb(255, 87, 51) — это одинаковый цвет, просто записанный по-разному. Оба описывают цвет через три канала: красный, зелёный, синий. 
Охватывает примерно 35% всех цветов, видимых человеческому глазу. Современные экраны — iPhone, MacBook, OLED-дисплеи — поддерживают Display P3, который примерно на 25–30% шире sRGB. HEX, RGB и HSL работают только в пространстве sRGB — они физически не могут описать цвета за его пределами. OKLCH может описать любой цвет — и sRGB, и даже за его пределами. Это означает, что дизайнер впервые получает доступ ко всей палитре современного экрана.

HSL — чуть лучше, но всё ещё неточный
hsl(12, 100%, 60%) — добавляет человекопонятные параметры: оттенок, насыщенность, светлота. Кажется, что светлота 50% у любого цвета будет одинаковой яркости. Но это иллюзия — жёлтый при 50% воспринимается намного ярче синего при тех же 50%. HSL не учитывает человеческое восприятие.

LCH — первый по-настоящему перцептивный формат
lch(55% 80 30) — три параметра: яркость (Lightness), насыщенность (Chroma), оттенок (Hue). Главное свойство: одинаковое значение яркости = одинаково воспринимаемая яркость. Жёлтый и синий с L=55 будут выглядеть одинаково светлыми для глаза.

OKLCH — улучшенный LCH, сейчас лучший выбор
oklch(0.65 0.18 30) — та же идея, но с исправленными математическими проблемами LCH. В LCH синие и фиолетовые оттенки вели себя непредсказуемо при изменении насыщенности. OKLCH это исправляет.
Что это даёт для доступности:

• Меняешь только яркость — оттенок не уплывает
• Можно создавать целые палитры с гарантированно предсказуемым контрастом
• Тёмный режим делается проще: берёшь тот же оттенок, меняешь L — и контраст предсказуем
• Дает +30% больше цвета, который может восприниматься человеческим глазом.

Как работает APCA
APCA учитывает три фактора одновременно:
Размер шрифта — чем крупнее, тем меньше нужен контраст. Но не два порога как в WCAG (обычный / крупный), а плавная шкала.
Насыщенность шрифта — жирный текст читается лучше тонкого при том же контрасте. APCA это учитывает отдельно.
Направление контраста — тёмный текст на светлом фоне и светлый на тёмном считаются по-разному, потому что глаз воспринимает их неодинаково.

Размер шрифта
Для основного текста — минимум 16pt.

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

Длина строки
Оптимально — 45–75 символов с пробелами, идеал около 66. Для заголовков и подписей строка может быть короче.

Иерархия заголовков
Большинство пользователей сначала просматривают страницу по заголовкам. Для незрячих скринридер зачитывает заголовки списком — это основной способ понять структуру страницы. Соблюдайте последовательность от H1 до H6, не пропускайте уровни. Размер и начертание шрифта незрячие не видят — уровень заголовка определяется только разметкой в коде.

Указывайте для ссылок и кнопок осмысленные названия
«Подробнее» и «Узнать больше» без контекста бесполезны — особенно для тех, кто навигирует по списку всех ссылок на странице. Скринридер зачитает просто «Подробнее» без пояснения, куда ведёт ссылка.
Если визуально изменить название нельзя — попросите разработчика добавить доступное имя в код. Это текст, который скринридер озвучивает при фокусе на элемент, но не отображается визуально. Задаётся двумя способами:
aria-label — указываете нужное название прямо в атрибуте
aria-labelledby — ссылаетесь на отдельный текстовый элемент через его id

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

Skip link — ссылка для пропуска контента
Позволяет пользователю клавиатуры перепрыгнуть через навигацию и сразу попасть к контенту. Без неё на каждой странице нужно многократно нажимать Tab.
Ссылка скрыта по умолчанию и появляется при фокусе — должна быть хорошо заметна и появляться плавно.

Область нажатия — минимум 44 пикселя
Маленькие иконки и кнопки сложно нажать — особенно большим пальцем или при двигательных нарушениях. Минимальный размер области нажатия — 44×44px. Если иконка меньше, увеличьте кликабельную зону вокруг неё, не саму иконку.

Указывайте описательные alt тексты для изображений
Альт-текст — это описание изображения, которое скринридер озвучивает пользователями.
Если у изображений нет альт-текста, то скринридеры просто произнесут имя файла или слово «изображение», что чаще всего не даст никакого контекста.

• “cropped_img32_900px.png” или “1521591232.jpg” — названия файлов, вероятно, потому что в изображении нет атрибута alt.
• “<Заголовок статьи>”
• “Фотограф: Эмма Ли”

Описывайте изображения подробно, но ограничивайтесь примерно 130 символами для каждой картинки.

У ценных SVG-изображений тоже должен быть альт-текст.

Завершайте alt-text точкой. Это позволит скринридеру сделать небольшую паузу после последнего слова alt-text, что более приятно звучит.

Пользователи взаимодействуют с интерфейсом по-разному — мышью, клавиатурой или скринридером. Фокус — это выделение элемента, с которым работает пользователь в данный момент.

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

Порядок фокуса
Фокус должен переключаться последовательно — слева направо, сверху вниз — и нигде не застревать. Браузер автоматически скроллит страницу к элементу с фокусом, поэтому нарушенный порядок дезориентирует.
Управление стандартное: Tab для перехода, Enter и Space для активации, стрелки для навигации внутри компонента. Элементы не активируются по Tab — только по Enter. Это предотвращает случайные действия.

Модальные окна и выпадающие списки
Требуют особого внимания: фокус должен уходить внутрь при открытии и возвращаться на триггер при закрытии. Фокус не должен уходить за пределы открытого модального окна.

Видеоплеер управляется с клавиатуры - проверить кнопки play/pause/субтитры в плеере

Пользователь может увеличивать масштаб страницы встроенными браузерными средствами и при помощи инструментов операционной системы. При этом страница должна остаться читаемой, пользователю должен быть доступен весь контент. Мы рекомендуем поддерживать и тестировать масштабирование страниц до 150 %.

Для этого делайте адаптивными страницы продукта. Это делается дополнительно к мобильной, планшетной, десктопной версии.

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

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

✦ Субтитры включены по умолчанию, а не спрятаны в настройках.

✦ Настраиваемые параметры: шрифт, размер, цвет текста и фона — пользователь сам выбирает под своё зрение.

✦ Визуальные уведомления вместо звука: popups не исчезают сами собой.

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

✦ Ошибка, успех, загрузка передаётся цветом, иконкой и текстом одновременно.

✦ Текст состояния конкретный: не «Ошибка», а «Не удалось отправить сообщение — проверьте соединение».

Текстовая расшифровка видео

Формы и поля ввода
Без форм пользователь не может зарегистрироваться, оформить заказ или войти в аккаунт — это один из ключевых сценариев взаимодействия.

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

Label всегда виден
Не используйте плейсхолдер вместо подписи к полю — при вводе он исчезает, и пользователь теряет контекст. Особенно это критично для людей с проблемами памяти.
Правильный паттерн: label над полем всегда виден, плейсхолдер внутри служит дополнительной подсказкой и исчезает при вводе.

Ошибки и подсказки
Сообщайте не только о факте ошибки, но и как её исправить — текстом рядом с полем. Хорошая практика: предупреждать о включённом Caps Lock при вводе пароля.

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

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

Используйте семантические теги
Ориентиры — это атрибуты, которые добавляются к смысловым блокам страницы. Они нужны, чтобы создавать семантические разделы на странице и помочь пользователям со скринридером легче перемещаться по сайту.
Самые распространенные ориентиры в HTML:

• header — для шапки сайта;
• nav — для навигации;
• main — для основного контента;
• aside — для дополнительного контента;
• section — для разделения страницы на смысловые блоки;
• footer — для подвала сайта.

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

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

Лучше один раз увидеть своими глазами, как это работает, поэтому вот видео об этой программе от её автора — Михаила Рубанова https://www.youtube.com/watch?v=XmqSZ6pcNvM

Попробуйте в действии NVDA https://youtu.be/Jao3s_CwdRU или JAWS https://youtu.be/DE7cLKgK2to для веба, Voice Over для Mac https://youtu.be/5R-6WvAihms, Talk back для Андроид https://youtu.be/0Zpzl4EKCco .

Так вы сможете понять, как люди воспринимают интерфейс и взаимодействуют с ним.

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

Доступность — это работа над собой.

WCAG — Web Content Accessibility Guidelines
Международный стандарт доступности веб-контента от W3C. Определяет, как делать сайты и приложения доступными для людей с особенностями по здоровью.

Три уровня соответствия

• A — минимум, без которого сайт просто нельзя использовать
• AA — обязательный стандарт для большинства продуктов и законодательств
• AAA — максимум, достигается не везде и не всегда обязателен

Четыре принципа — POUR

• Perceivable (воспринимаемый) — контент можно увидеть, услышать или почувствовать
• Operable (управляемый) — интерфейс работает с клавиатуры, без мыши
• Understandable (понятный) — текст и поведение предсказуемы
• Robust (надёжный) — работает с разными браузерами и ассистивными технологиями