Цифровая доступность — не про «режим для слабовидящих» как отдельную кнопку в футере. Это работа над тем, чтобы интерфейс можно было воспринять, понять и использовать разными способами: без мыши, при увеличении масштаба, со скринридером, при сниженной точности движений, в шумной среде или при временном ограничении вроде травмы руки.
Специалист по цифровой доступности (accessibility specialist, a11y-специалист) проверяет продукт, находит барьеры, объясняет команде причины проблем и помогает встроить исправления в дизайн, код и процессы тестирования. Войти в профессию реально за 6–12 месяцев регулярной практики, особенно если у вас уже есть база в QA, дизайне или frontend. Но важно честно оценить рынок: в России роль редко выделяют в отдельную штатную позицию. Чаще это специализация внутри более широкой должности — QA-инженера, UX-дизайнера, frontend-разработчика, аналитика качества или консультанта по инклюзивному дизайну.
Что делает специалист по цифровой доступности на практике
Рабочий день обычно состоит не из абстрактной «проверки на инклюзивность», а из конкретных задач на стыке интерфейсов, кода и коммуникации.
Например, специалист может:
- пройти путь регистрации только с клавиатуры и проверить, не «теряется» ли фокус;
- открыть страницу через скринридер и выяснить, понятны ли названия кнопок, заголовки, поля формы и сообщения об ошибках;
- проверить, сохраняется ли функциональность при увеличении страницы до 200%;
- оценить контраст текста и элементов управления, не полагаясь только на цвет в сообщениях об ошибке;
- посмотреть HTML-разметку: правильно ли используются заголовки, ссылки, кнопки, подписи полей;
- проверить, не пытается ли команда заменить нормальную семантику избыточными ARIA-атрибутами;
- оформить дефекты так, чтобы разработчик мог воспроизвести проблему и понять ожидаемый результат;
- участвовать в ревью макетов до разработки, чтобы не исправлять очевидные барьеры после релиза;
- подготовить чек-листы, правила для дизайн-системы и критерии приемки для команды.
В международной практике основным ориентиром служат рекомендации WCAG 2.2. Они построены вокруг четырёх принципов: контент должен быть воспринимаемым, управляемым, понятным и надёжно работающим со вспомогательными технологиями. Критерии WCAG проверяемы и распределены по уровням A, AA и AAA; в продуктовой работе часто обсуждают достижение уровня AA, но конкретная цель всегда зависит от требований организации и проекта. (w3.org)
В России полезно знать ГОСТ Р 52872-2019: он распространяется на интернет-ресурсы, цифровой контент, приложения и пользовательские интерфейсы. А с 1 марта 2026 года для официальных сайтов государственных органов, органов местного самоуправления и подведомственных организаций действуют утверждённые Правительством требования доступности информации для людей с инвалидностью по зрению. Среди упомянутых требований — работа со средствами экранного доступа, управление с клавиатуры, увеличение текста не менее чем до 200% без потери функциональности и текстовые альтернативы нетекстовому контенту. Это не означает, что любая коммерческая компания обязана нанять отдельного accessibility-специалиста, но делает экспертизу особенно практичной для команд, работающих с государственными цифровыми ресурсами. (protect.gost.ru)
Кому подойдёт эта профессия — и кому может не подойти
Эта специализация хорошо ложится на опыт людей, которым нравится разбираться, почему пользователь не может завершить задачу, а не только фиксировать формальное несоответствие чек-листу.
Хороший старт, если вы уже работаете в QA
QA-специалисту знакомы сценарии, баг-репорты, регресс и критерии приемки. Нужно добавить понимание WCAG, основ HTML, поведения клавиатурного фокуса и принципов работы скринридеров. Сильная сторона такого кандидата — умение превращать наблюдение в воспроизводимый дефект.
Пример: вместо записи «форма недоступна» QA-специалист фиксирует: «На шаге оплаты при переходе клавишей Tab фокус после поля “Номер карты” уходит в адресную строку браузера. Кнопка “Оплатить” недостижима с клавиатуры. Ожидаемо: все интерактивные элементы доступны в логичном порядке фокуса». Это уже задача, с которой может работать разработчик.
Естественный переход для UX/UI-дизайнера
Дизайнеру пригодятся навыки работы с цветом, типографикой, состояниями компонентов и пользовательскими сценариями. Придётся глубже освоить ограничения реального HTML и браузеров: красивый макет не гарантирует, что компонент можно корректно озвучить или использовать с клавиатуры.
Пример: дизайнер создаёт ошибку в поле формы только красной рамкой. Специалист по доступности предложит добавить понятное текстовое сообщение, связать его с полем программно и продумать, как ошибка будет объявлена пользователю скринридера.
Сильная база у frontend-разработчика
Frontend-разработчик быстрее понимает семантическую разметку, DOM, фокус, события и ARIA. Но ему важно не свести доступность к набору атрибутов. MDN отдельно рекомендует предпочитать нативные HTML-элементы, когда они подходят: у них уже есть встроенная семантика и клавиатурное поведение. ARIA дополняет HTML, а не заменяет его. (developer.mozilla.org)
Когда стоит выбрать другую траекторию
Профессия может разочаровать, если вы:
- хотите исключительно визуальную работу без чтения требований, тестирования и обсуждения технических деталей;
- не готовы многократно проверять одни и те же сценарии после исправлений;
- рассчитываете только на вакансии с точным названием «специалист по цифровой доступности»;
- не любите объяснять и аргументировать: часть команд поначалу воспринимает доступность как необязательную дополнительную нагрузку.
База знаний: что нужно освоить в первую очередь
Не пытайтесь за первую неделю выучить все критерии WCAG наизусть. Гораздо полезнее сформировать рабочую связку: пользовательская задача → потенциальный барьер → техническая причина → способ проверки → понятная рекомендация.
| Блок | Что освоить | Зачем это в работе |
|---|---|---|
| Стандарты | WCAG 2.2, уровни A/AA/AAA, ГОСТ Р 52872-2019 | Чтобы опираться на проверяемые критерии, а не на личный вкус |
| HTML | Заголовки, списки, ссылки, кнопки, формы, таблицы, `label` | Семантика помогает вспомогательным технологиям передавать структуру страницы |
| Клавиатура | Tab, Shift+Tab, Enter, Space, Escape, порядок и видимость фокуса | Не все пользователи работают мышью |
| Скринридеры | Базовая навигация по заголовкам, ссылкам, формам и областям страницы | Чтобы проверять реальное восприятие интерфейса, а не только код |
| ARIA | Роли, состояния, имена элементов, live-регионы | Для сложных кастомных компонентов, когда нативного HTML недостаточно |
| Дизайн | Контраст, размер целей, состояния, текстовые инструкции, ошибки | Многие барьеры появляются ещё на этапе макета |
| Документация | Баг-репорты, аудит, приоритизация, рекомендации | От качества отчёта зависит, будут ли проблемы исправлены |
Минимум, который нужно уметь делать руками: пройти интерфейс с клавиатуры; найти на странице логическую структуру заголовков; отличить ссылку от кнопки; проверить наличие и понятность подписи у поля; определить, не скрыт ли фокус; объяснить, почему кликабельный `div` обычно хуже нативной кнопки.
Доступность форм — особенно полезная тема для старта. W3C рекомендует связывать элементы управления с подписями, группировать связанные поля и давать инструкции там, где они нужны. Это помогает не только пользователям скринридеров: ясные формы и обратная связь снижают когнитивную нагрузку для всех. (w3.org)
План на 24 недели: от базы к первому портфолио
Ниже не программа курса, а самостоятельный маршрут. Его можно растянуть до 9–12 месяцев, если у вас мало времени, или пройти быстрее при опыте в веб-разработке.
Недели 1–4: понять предмет и научиться видеть барьеры
- Прочитайте обзор WCAG 2.2 и разберите четыре принципа POUR.
- Освойте базовую семантику HTML: `button`, `a`, `label`, заголовки `h1–h6`, списки, `fieldset` и `legend`.
- Каждый день выбирайте одну знакомую страницу и проходите её только клавиатурой.
- Ведите журнал наблюдений: сценарий, барьер, кому мешает, как воспроизвести, возможное решение.
Практика недели: проверьте страницу входа в любой открытый сервис. Не публикуйте обвинительных постов и не называйте это «сертифицированным аудитом». Ваша цель — учиться наблюдать: есть ли подписи у полей, виден ли фокус, можно ли отправить форму без мыши, понятно ли сообщение об ошибке.
Недели 5–8: научиться тестировать, а не только читать
- Настройте среду для ручной проверки: браузер, инструменты разработчика, средство оценки контраста, скринридер, доступный в вашей операционной системе.
- Отработайте сценарии навигации с клавиатуры: открытие меню, работа с модальным окном, закрытие по Escape, возврат фокуса.
- Научитесь смотреть доступное имя элемента, роль и состояние в инструментах разработчика.
- Освойте базовые паттерны: раскрывающиеся блоки, вкладки, диалоговые окна, уведомления, выпадающие списки.
Автоматизированные проверки полезны для быстрого поиска части проблем, но не заменяют эксперта. W3C прямо указывает, что один инструмент не может определить доступность сайта целиком: необходима квалифицированная ручная оценка. (w3.org)
Недели 9–12: освоить скринридер и отчёты
- Возьмите одну страницу и изучите её без визуальной опоры: переходите по заголовкам, ссылкам, элементам форм и ориентирам страницы.
- Сравните то, что вы услышали, с тем, что видите в браузере.
- Научитесь отличать критичную проблему от косметической. Если человек не может войти, оплатить, отправить заявку или понять ошибку — это обычно выше по приоритету, чем второстепенный недочёт оформления.
- Составьте короткий отчёт на 8–15 находок с единым шаблоном.
Шаблон одного наблюдения:
- Серьёзность: критично / высоко / средне / низко.
- Где найдено: страница, компонент, сценарий.
- Как воспроизвести: конкретные шаги.
- Фактический результат: что происходит.
- Влияние на пользователя: какая задача становится недоступной или сложной.
- Ориентир: критерий WCAG или пункт внутренних требований.
- Рекомендация: что изменить в дизайне, разметке или логике.
- Как перепроверить: конкретный способ регресса.
Недели 13–18: сделать три портфельных кейса
Не ждите коммерческого заказа. Для начала подойдут учебные прототипы, личный пет-проект, проект знакомого разработчика — но с разрешением на публикацию. Не выдавайте учебную работу за аудит клиента.
Соберите три разных кейса:
- Аудит формы. Проверьте регистрацию или запись на услугу: клавиатура, подписи, ошибки, обязательные поля, сообщения после отправки.
- Редизайн компонента. Возьмите неудобное меню, модальное окно или табы. Покажите проблему, макет/описание исправления и требования к разработке.
- Разбор страницы по структуре. Проанализируйте заголовки, ссылки, изображения, таблицу, контраст и масштабирование. Добавьте список того, что нельзя подтвердить без доступа к коду или полноценного тестирования.
Как оформить портфолио, которое покажет реальные навыки
Хорошее портфолио accessibility-специалиста — не коллекция сертификатов и не перечень стандартов. Оно отвечает на вопрос работодателя: «Сможет ли человек найти барьер, объяснить его и довести исправление до проверки?»
Для каждого кейса используйте структуру:
- Контекст. Что за интерфейс и какой пользовательский путь вы проверяли.
- Границы работы. Например: пять экранов веб-версии, Chrome, клавиатура, один скринридер, выборочная проверка контраста. Это защищает от ложного впечатления, будто вы проверили весь продукт.
- Методика. Ручная проверка, инструменты, критерии, дата тестирования.
- Находки. 5–10 наиболее показательных проблем с понятными шагами воспроизведения.
- Рекомендации. Не «сделать доступно», а конкретные изменения.
- Результат. Если исправления вносились — что именно перепроверено. Если нет, честно обозначьте, что это предложения.
- Вывод. Какие правила стоит добавить в дизайн-систему или критерии приемки, чтобы проблема не повторялась.
Пример сильной находки
Проблема: в карточке товара иконка корзины не имеет доступного имени.
Пользовательский эффект: скринридер объявляет только «кнопка», поэтому человек не понимает действие.
Рекомендация: использовать нативную кнопку и задать понятное доступное имя, например «Добавить [название товара] в корзину». Если рядом уже есть видимый текст, не дублировать его бессмысленно, а проверить, какое имя реально получает элемент.
Проверка после исправления: перейти к кнопке с клавиатуры, активировать Enter и Space, удостовериться, что скринридер объявляет понятное имя и изменение состояния.
Где искать первую работу и как назвать свою специализацию
Не ограничивайте поиск точной должностью. Вакансии могут называться иначе, а задача быть той же или близкой.
Ищите по сочетаниям:
- accessibility / a11y / web accessibility;
- цифровая доступность / доступность интерфейсов / инклюзивный дизайн;
- QA accessibility / специалист по качеству интерфейсов;
- frontend-разработчик с опытом WCAG, ARIA, semantic HTML;
- UX/UI-дизайнер с опытом доступных интерфейсов;
- специалист по развитию дизайн-системы;
- консультант или аудитор цифровых продуктов.
Для первого шага разумнее претендовать не только на отдельную роль, но и на смежные позиции с фокусом на доступность. Например, QA-инженер может взять на себя accessibility-регресс для ключевых сценариев, дизайнер — развивать доступные компоненты библиотеки, frontend-разработчик — исправлять семантику и клавиатурные паттерны.
В резюме не пишите «эксперт по WCAG», если сделали несколько учебных проверок. Точнее и убедительнее: «Провожу базовую ручную проверку веб-интерфейсов по WCAG: клавиатурная навигация, семантика, формы, доступные имена, контраст; оформляю воспроизводимые дефекты и рекомендации». Это честно показывает уровень и направление роста.
Как пройти собеседование: вопросы, к которым стоит подготовиться
На интервью вас могут попросить не перечислить критерии, а разобрать интерфейс и объяснить решение.
Подготовьте ответы на такие вопросы:
- Чем ссылка отличается от кнопки и почему нельзя менять их роли только стилями?
- Что вы проверите в форме оплаты или регистрации?
- Что такое доступное имя элемента?
- Почему автоматический сканер не даёт окончательного вердикта?
- Что делать, если дизайн предполагает кастомный селект или модальное окно?
- Как вы приоритизируете 30 найденных проблем?
- Как объяснить продакт-менеджеру ценность исправления, не превращая разговор в лекцию о стандартах?
Хороший ответ строится на сценарии. Например: «Сначала проверю, что пользователь может открыть селект, перемещаться по вариантам, понять текущее значение, подтвердить выбор и закрыть компонент с клавиатуры. Затем посмотрю, как он объявляется скринридером. Если нативный `select` отвечает задаче продукта, предложу его: это обычно надёжнее, чем самостоятельно воспроизводить сложное поведение через ARIA».
Частые ошибки новичка
Пытаться исправить всё через ARIA
ARIA — важный инструмент для сложных интерфейсов, но она требует корректно воспроизвести роли, состояния, управление с клавиатуры и обновления информации. Если есть подходящий нативный элемент HTML, он часто безопаснее и понятнее в поддержке. (developer.mozilla.org)
Считать контраст единственной проверкой
Контраст важен, но не решает проблемы фокуса, структуры заголовков, подписей, логики модального окна, непонятных ошибок или недоступного drag-and-drop.
Отправлять команде список требований без приоритета
Документ на 80 пунктов без контекста редко приводит к изменениям. Начинайте с задач, которые блокируют ключевые пользовательские пути: вход, поиск, заполнение формы, оплата, получение результата.
Давать рекомендации без способа перепроверки
Фраза «добавить ARIA» не является готовой рекомендацией. Нужны ожидаемое поведение, критерий готовности и сценарий регресса.
Говорить от лица всех пользователей с инвалидностью
Специалист проверяет барьеры и умеет привлекать пользователей к исследованию, но не заменяет опыт людей с разными потребностями. W3C рекомендует включать людей с инвалидностью в группы при проведении человеческого тестирования. (w3.org)
Чек-лист: готовы ли вы к первому проекту
Отметьте пункты, которые вы уже можете выполнить без подсказки:
- [ ] Объясняю четыре принципа WCAG своими словами.
- [ ] Прохожу ключевой сценарий сайта только клавиатурой.
- [ ] Проверяю порядок, видимость и возврат фокуса.
- [ ] Нахожу базовые ошибки семантики HTML.
- [ ] Понимаю, когда нужна нативная кнопка, ссылка или поле формы.
- [ ] Могу проверить, есть ли у интерактивного элемента понятное доступное имя.
- [ ] Пользуюсь хотя бы одним скринридером на уровне навигации по заголовкам, ссылкам и формам.
- [ ] Отличаю автоматическую проверку от ручного тестирования.
- [ ] Оформляю дефект с шагами, влиянием, рекомендацией и способом ретеста.
- [ ] Подготовил минимум два кейса, в которых ясно обозначены границы проверки.
- [ ] Умею корректно сказать «этого я не проверял» вместо необоснованного вывода о доступности всего продукта.
Если отмечены 8–9 пунктов, можно искать стажировку, проектную задачу или смежную роль с фокусом на accessibility. Если меньше — не нужно откладывать карьеру «до идеального знания стандарта»: выберите один тип интерфейса, например формы, и сделайте законченный практический кейс.
Честный вывод
Специалист по цифровой доступности — перспективная, но не массовая профессия. В ней меньше стандартных вакансий и понятных карьерных лестниц, чем в обычном QA, дизайне или frontend-разработке. Поэтому самый надёжный путь — не ждать идеальной позиции, а наращивать accessibility-экспертизу внутри смежной роли и показывать её через реальные проверки, понятные отчёты и исправленные компоненты.
Эта работа подойдёт тем, кому интересно сочетание качества, технологий, дизайна и пользовательских сценариев. Её ценность не в том, чтобы поставить продукту формальную оценку, а в том, чтобы конкретный человек смог самостоятельно завершить нужное действие: записаться к врачу, подать заявление, оплатить заказ, прочитать документ или получить услугу без лишнего барьера.