Цифровая доступность — это не «добавить alt-тексты перед релизом». Это работа над тем, чтобы сайт, мобильное приложение, личный кабинет или сервис можно было воспринимать, понимать и использовать с клавиатурой, скринридером, увеличением, голосовым вводом и другими вспомогательными технологиями.
Для человека, который выбирает профессию, здесь важен парадокс: ИИ действительно сократит часть рутинной работы accessibility-специалиста, но одновременно сделает заметнее тех, кто умеет отличить формальное исправление от реально доступного опыта. Это не профессия, где ценность строится на механической проверке чек-листа. Это профессия на стыке QA, frontend-разработки, UX-исследований, контент-дизайна и инклюзивного продуктового мышления.
Что именно делает специалист по цифровой доступности
В русскоязычных компаниях отдельная должность может называться по-разному: accessibility specialist, эксперт по доступности, QA accessibility, UX-аудитор, frontend-разработчик с зоной ответственности за a11y. Иногда такую функцию берёт на себя один сильный специалист внутри команды качества или дизайна. Поэтому карьеру стоит искать не только по точному названию роли, но и по задачам: WCAG, screen reader, ARIA, keyboard navigation, semantic HTML, inclusive design.
Типичный цикл работы выглядит так:
- Определить рамки аудита. Какие пользовательские пути критичны: регистрация, поиск, оформление заказа, подача заявления, оплата, загрузка документов?
- Проверить интерфейс автоматически. Сканеры и браузерные инструменты быстро находят часть проблем: ошибки разметки, некоторые нарушения контраста, отсутствующие имена у контролов.
- Проверить вручную. Специалист проходит сценарии только с клавиатурой, тестирует семантику и порядок фокуса, слушает интерфейс через скринридер, смотрит поведение на разных масштабах и устройствах.
- Объяснить проблему команде. Не просто написать «нарушен пункт WCAG», а показать, где пользователь застревает, как это влияет на сценарий и какое исправление не сломает интерфейс.
- Перепроверить исправление. Доступность легко ухудшить новым компонентом, редизайном, маркетинговым виджетом или изменением текста.
- Встроить практику в процесс. Создать правила для дизайн-системы, чек-листы для pull request, критерии готовности задач и шаблоны тест-кейсов.
WCAG 2.2 — актуальная рекомендация W3C для веб-доступности. Она развивает WCAG 2.1 и добавляет, в частности, критерии, связанные с видимостью фокуса, перетаскиванием, минимальным размером цели касания и доступной аутентификацией. При этом WCAG — не магическая печать качества: сам W3C отдельно подчёркивает, что стандарт не закрывает абсолютно все пользовательские потребности. (w3.org)
В России для официальных сайтов государственных органов и подведомственных организаций действуют требования доступности информации для людей с нарушением зрения; документ прямо отсылает к ГОСТ Р 52872-2019. Это важный ориентир для работы с государственными цифровыми сервисами, но не повод обещать, что у каждого коммерческого продукта уже есть одинаковые формальные обязанности. (government.ru)
Где ИИ и автоматизация действительно помогут
Самая реалистичная картина — не «ИИ заберёт профессию», а «ручной аудит станет короче там, где ошибка типовая и технически наблюдаемая». Инструменты могут быть встроены в редактор кода, CI/CD, браузер или систему контроля качества. Генеративный ИИ также способен быстро подготовить черновик описания проблемы, предложить варианты HTML-разметки или объяснить разработчику критерий простым языком.
| Задача | Что может ускорить ИИ или автоматизация | Что обязан проверить человек |
|---|---|---|
| Поиск типовых нарушений | Сканирование страниц, повторяющиеся ошибки атрибутов, базовые проблемы с контрастом | Полнота покрытия, ложные срабатывания, приоритет исправлений |
| Проверка кода | Подсказки по semantic HTML, ролям ARIA, доступным именам контролов | Уместность семантики и корректность поведения компонента |
| Подготовка отчёта | Черновик описаний дефектов, группировка однотипных находок | Точность выводов, воспроизводимость, понятный план исправления |
| Анализ дизайн-системы | Поиск повторяющихся паттернов, проверка токенов контраста | Логика состояний, видимость фокуса, сценарии без мыши |
| Подготовка тестов | Варианты тест-кейсов и чек-листов | Критичные пользовательские пути и реальные барьеры |
| Работа с контентом | Черновые alt-тексты, расшифровки, упрощение языка | Соответствие описания цели изображения и смыслу контента |
Важно не перепутать скорость с доказательством качества. Методология W3C WCAG-EM 2.0 прямо указывает: большинство проверок доступности нельзя полностью автоматизировать. Инструменты полезны для поиска образцов и поддержки ручной оценки, но полнота проверки конкретного продукта требует качественного анализа; W3C также настоятельно рекомендует привлекать людей с инвалидностью, потому что они могут обнаружить барьеры, неочевидные даже эксперту. (w3.org)
Практический пример: «зелёный отчёт» и недоступная оплата
Представьте интернет-магазин. Автоматический сканер не нашёл критических ошибок на странице оплаты. ИИ предлагает добавить `aria-label` к кнопкам и считает задачу закрытой.
Но ручная проверка выявляет другое:
- после выбора пункта выдачи фокус клавиатуры прыгает в начало страницы;
- сообщение «Поле заполнено неверно» появляется визуально, но скринридер его не озвучивает;
- кнопка подтверждения становится активной без понятного объяснения, какие поля ещё требуют внимания;
- пользователь на мобильном устройстве не может выполнить часть действия без жеста перетаскивания.
Ни одна из этих проблем не сводится к вопросу «есть ли нужный атрибут в коде». Специалист должен воспроизвести путь, понять контекст, сформулировать критерий готовности и договориться с аналитиком, дизайнером и разработчиком о безопасном исправлении. Именно здесь автоматизация становится помощником, а не заменой.
Почему профессия не исчезнет из-за ИИ
Устойчивость этой роли связана не с тем, что ИИ «плохо пишет код». Напротив: ИИ будет всё чаще генерировать интерфейсы и кодовые заготовки. Но скорость генерации способна увеличить количество компонентов, состояний и регрессий, которые нужно осмысленно проверять.
Есть как минимум пять причин, почему специалист по доступности останется нужен.
1. Доступность зависит от контекста, а не от одного правила
Одинаковая кнопка может быть доступной в одном месте и запутывать в другом. Например, `aria-label="Закрыть"` у кнопки уместен в модальном окне, но не объясняет пользователю, что именно будет закрыто, если на странице несколько панелей. Нужны понимание сценария, информационной архитектуры и способность видеть интерфейс глазами разных пользователей.
2. Важна проверка поведения, а не только кода
Доступность — это порядок фокуса, озвучивание динамических сообщений, работа модальных окон, логика ошибок формы, совместимость с конкретными вспомогательными технологиями. Генеративная модель может предложить правдоподобный фрагмент кода, но не несёт ответственности за то, как он поведёт себя в продукте после интеграции.
3. Нужна человеческая коммуникация
Часто задача специалиста — не найти дефект, а изменить процесс. Объяснить продакт-менеджеру, почему доступность надо заложить до дизайна; помочь дизайнеру выбрать различимые состояния; договориться с frontend-командой о правилах компонента; научить QA замечать регрессии. Это работа с конфликтом приоритетов и ограничениями продукта, а не только с технической спецификацией.
4. Стандарты и требования меняются, а продукты работают в разных юрисдикциях
Для сервисов, работающих на европейском рынке, доступность стала ещё заметнее в контексте European Accessibility Act: требования применяются к определённым продуктам и услугам, размещённым на рынке ЕС после 28 июня 2025 года, включая часть цифровых сервисов, электронной коммерции и ИКТ-продуктов. Конкретная применимость зависит от типа сервиса, страны и исключений, поэтому специалисту важно не выдавать общий совет за юридическое заключение. (europa.eu)
5. Реальные пользователи не сводятся к набору «персон»
Даже формально соответствующий критериям интерфейс может быть тяжёлым для человека с когнитивными особенностями, временной травмой руки, плохим интернетом, ярким светом или небольшим экраном. Включение пользователей с разным опытом в тестирование даёт информацию, которую нельзя надёжно вывести только из DOM-дерева или скриншота.
Устойчивые навыки: во что вкладываться на старте
Если вы хотите войти в профессию, не стройте план вокруг одного инструмента или одного промпта. Более долговечна связка из технической базы, исследовательского мышления и навыка делать рекомендации выполнимыми.
Техническая основа
- Semantic HTML. Заголовки, списки, формы, кнопки, таблицы и ссылки должны применяться по смыслу, а не ради внешнего вида.
- CSS и адаптивность. Контраст, масштабирование текста, видимость фокуса, состояния элементов, отсутствие зависимости от одного способа ввода.
- JavaScript и динамические интерфейсы. Модальные окна, уведомления, валидация форм, раскрывающиеся списки, одностраничные приложения.
- ARIA. Не набор «магических» атрибутов, а понимание, когда нативного HTML достаточно и почему лишняя ARIA может ухудшить опыт.
- Тестирование с клавиатурой и скринридером. Важен не только запуск программы чтения с экрана, но и умение услышать, что именно пользователь получает в каждом шаге.
Навыки анализа и продукта
- переводить WCAG-критерий в понятный риск для пользовательского пути;
- выбирать репрезентативные экраны и состояния, а не тестировать случайные страницы;
- отличать критичный блокер оплаты или регистрации от косметической проблемы;
- оформлять дефект так, чтобы его можно было повторить и исправить;
- смотреть на доступность до разработки: в макетах, требованиях и дизайн-системе.
Навыки, которые особенно усиливаются на фоне ИИ
- Проверка результата, а не доверие к нему. Умение спросить: что именно проверил инструмент, чего он не мог увидеть и как подтвердить вывод?
- Формулирование хороших задач. ИИ полезнее, когда специалист задаёт точный контекст: компонент, пользовательский путь, целевой стандарт, технологический стек, ограничения.
- Редактура рекомендаций. Автоматически сгенерированное объяснение может быть длинным и уверенным, но технически неверным. Нужна дисциплина сверки со стандартом и продуктом.
- Системное мышление. Исправить один экран недостаточно, если ошибка живёт в общем компоненте библиотеки.
- Эмпатия без догадок. Не «представить, как живут все пользователи», а проверять гипотезы, изучать реальные сценарии и вовлекать пользователей в исследования.
Как использовать ИИ профессионально и безопасно
Полезная позиция: воспринимать ИИ как младшего помощника, чьи результаты всегда требуют ревью. Он может помочь быстрее начать работу, но не должен быть единственным основанием для решения о соответствии требованиям.
Подходящий сценарий: вы выгружаете список проблем из сканера и просите ИИ сгруппировать повторяющиеся ошибки, подготовить короткие черновики для тикетов и предложить вопросы для разработчика. Затем вручную воспроизводите каждый критичный дефект, сверяете рекомендации с WCAG и проверяете исправление в рабочей сборке.
Рискованный сценарий: вы отправляете в публичный чат-бот скриншоты внутреннего кабинета, персональные данные, закрытые макеты или исходный код, а затем переносите предложенные правки в production без ревью. Здесь риск не только в доступности, но и в конфиденциальности, безопасности и качестве кода.
Полезное правило: ИИ может готовить гипотезу; специалист отвечает за решение и его последствия.
План входа в профессию: не только теория
Начать можно из QA, дизайна, контент-дизайна или frontend-разработки. Срок зависит от исходной базы: человеку с опытом веб-разработки проще быстрее освоить семантику и ARIA, а сильному QA — построить тестовые сценарии. Но всем нужно практиковаться на работающих интерфейсах.
Пример стартового плана на 8–12 недель:
- Освойте каркас. Разберите принципы WCAG: воспринимаемость, управляемость, понятность и надёжность. Не пытайтесь выучить все критерии наизусть: сначала поймите, какую пользовательскую проблему решает каждый из частых критериев.
- Тренируйте ручную проверку. Каждый день проходите один небольшой сценарий без мыши: поиск, форма, фильтр, карточка товара, диалоговое окно. Записывайте порядок фокуса и непонятные места.
- Изучите семантику на коде. Возьмите простую форму и соберите две версии: с `div`-элементами и с нативными контролами. Затем сравните их клавиатурой и скринридером.
- Сделайте мини-аудит. Выберите публичный сайт, определите границы проверки, зафиксируйте 8–12 находок, распределите их по серьёзности и предложите исправления. Не публикуйте обвинительные выводы о «недоступности всего сайта» по нескольким экранам.
- Оформите портфолио. Покажите не только список ошибок, но и ход мысли: сценарий, шаги воспроизведения, влияние на пользователя, критерий, вариант исправления, результат повторной проверки.
- Учитесь разговаривать с командами. Перепишите один технический дефект в трёх версиях: для разработчика, дизайнера и продакт-менеджера. Смысл один, язык и акцент разные.
Чек-лист: подходит ли вам эта специализация
Отметьте пункты, которые скорее про вас:
- [ ] Мне нравится разбираться, почему интерфейс ведёт себя неожиданно, а не только фиксировать «баг есть».
- [ ] Я готов(а) сочетать ручную проверку с изучением HTML, CSS и поведения браузера.
- [ ] Мне интересно тестировать продукт не только привычным способом — без мыши, с увеличением, со скринридером.
- [ ] Я умею спокойно объяснять команде, почему небольшая на вид деталь может заблокировать важное действие.
- [ ] Я не рассчитываю, что один сканер или ИИ-ассистент даст финальный ответ о качестве интерфейса.
- [ ] Мне ближе профилактика проблем через дизайн-систему и процесс разработки, чем бесконечный поиск дефектов перед релизом.
- [ ] Я готов(а) к тому, что на российском рынке роль может быть частью более широкой позиции QA, UX или frontend, а не отдельной вакансией.
Если вы отметили пять или больше пунктов, стоит попробовать практический аудит и несколько недель регулярного тестирования. Если же вам совсем неинтересны детали поведения интерфейса, документация и переговоры о правках, социальная значимость профессии сама по себе не сделает ежедневную работу комфортной.
Честный вывод
ИИ снижает ценность механического труда: копировать однотипные замечания, вручную собирать базовый отчёт, искать очевидные нарушения в десятках похожих страниц. Но это не означает, что профессия специалиста по цифровой доступности исчезает. Скорее меняется точка, в которой человек приносит наибольшую пользу.
Сильный специалист будущего — не «человек, который знает все атрибуты ARIA» и не «оператор ИИ-проверки». Это человек, который умеет соединить стандарт, код, дизайн, реальный пользовательский путь и бизнес-приоритеты; использовать автоматизацию для охвата, но не путать её с полноценной оценкой. W3C описывает эффективную оценку доступности именно как сочетание инструментов, ручной экспертизы и, по возможности, участия пользователей с инвалидностью. (w3.org)
Для карьерного выбора это нишевая, но содержательная траектория. Она особенно подходит QA-специалистам, UX-дизайнерам и frontend-разработчикам, которым интересны качество продукта, техническая глубина и влияние работы на то, сможет ли человек вообще воспользоваться цифровым сервисом. Рынок отдельных ролей может быть уже, чем у общего тестирования или разработки, поэтому разумная стратегия — строить двойную компетенцию: например, QA + accessibility, frontend + accessibility или UX + inclusive design.