Введение
Третьего марта 2026 года W3C опубликовал очередной рабочий черновик WCAG 3.0. Я потратил немало времени, изучая документ, и могу сказать точно: после нескольких лет наблюдений за тем, как делаются колбаса и стандарты, у этого черновика наконец-то появился хребет.
Сразу важное предупреждение. WCAG 3.0 — все еще сырой и неполный документ. Модель соответствия не утверждена, таблицы спецификации зияют пустотами, а финальная рекомендация появится не раньше 2028 года. Использовать его в реальных проектах сейчас нельзя, и единственное, что стоит делать — следить за развитием.
Но направление задано верно. Впервые за долгие годы стандарт обещает решить проблемы, с которыми практики по доступности сталкиваются каждый день: проклятие бинарного выбора «соответствует — не соответствует», полное игнорирование процессов в угоду точечным проверкам и когнитивная доступность как что-то второсортное. И что важнее всего — уже сейчас понятно, как готовиться к новым правилам, не дожидаясь 2028 года.
Пока чиновники и рабочие группы согласовывают формулировки, любой вменяемый владелец продукта может делать три вещи, которые окупятся при любом раскладе. Документировать свои процессы по доступности. Тестировать интерфейсы на реальных людях с инвалидностью и сохранять отчеты. Внедрять стандарты ясного языка в контенте и интерфейсах. Это не требует утверждения WCAG 3.0, зато ровно это от вас и будут ждать, когда он наконец вступит в силу.
Дальше я детально разберу, что именно в новом стандарте сделано правильно, а что пока остается на уровне благих намерений. И почему инвестиции в процессы сегодня избавят вас от головной боли завтра.
Руководства наконец-то звучат как цели
Критерии успеха WCAG 2.x написаны для спецификационных юристов и фанатов доступности. Фраза «Нетекстовый контент, представленный пользователю, имеет текстовую альтернативу, служащую эквивалентной цели» — это технически точно, но попробуйте объяснить продакт-менеджеру, что именно он должен построить. WCAG 2.x всегда требовал переводчика, чтобы стать хоть сколько-нибудь пригодным для реальной работы. Туда же относится и вечная проблема с пониманием того, что вообще означает этот ваш «уровень».
WCAG 3.0 переписывает руководства как формулировки результата. «У пользователей есть эквивалентные альтернативы для изображений». Это фраза, которую можно вставить в документ с требованиями к продукту без звездочки, ведущей к трем абзацам разъяснений.
Но важнее другое. В черновик включены деревья решений, которые проводят вас по тому, какие именно требования применимы к конкретному фрагменту контента. Руководство по альтернативам для изображений, например, начинается с вопроса «Повлияет ли удаление изображения на понимание страницы?», а дальше ветвится на обработку декоративных изображений, программную определяемость и требования к текстовым альтернативам. Когда сам стандарт формализует такой рабочий процесс — это не просто улучшение. Это резко снижает вероятность того, что разработчик и тестировщик поймут требование по-разному.
Подтверждения (Assertions) наконец-то признают, что процессы имеют значение
Это самая интересная и одновременно самая спорная идея WCAG 3.0. Подтверждения — это формальные, документированные и привязанные к ответственным лицам заявления о том, что ваша организация следовала определенным процессам в области доступности. Проводили ли вы юзабилити-тестирование с людьми с инвалидностью? Ведете ли вы гайд по стилю оформления субтитров? Проверяют ли авторы контента свои медиаальтернативы?
В WCAG 2.x это все не имеет значения для соответствия стандарту. Вы можете вообще не иметь никакого процесса по доступности, случайно наткнуться на соответствующий требованиям продукт и заявить об уровне AA. И наоборот: можно вести лучшую в мире программу по доступности, проводить обширные исследования с пользователями, вкладываться в обучение — и все равно провалить соответствие из-за одной пропущенной подписи к полю формы на странице настроек. Потому что в WCAG 2.x соответствие работает по принципу «все или ничего».
Подтверждения меняют уравнение. Они признают то, что каждый практикующий специалист по доступности знает и так: организации, которые встраивают доступность в свои процессы разработки, производят более доступные продукты в долгосрочной перспективе, чем те, кто относится к ней как к списку правок в конце проекта.
Черновик приводит примеры подтверждений. Ведение гайда по стилю для медиаальтернатив с конкретными требованиями к документации о том, что должен покрывать такой гайд. Проведение пользовательского тестирования с документированием демографических данных участников, типов инвалидности, дат и примеров исправленных проблем. Проверка контента самими создателями.
Требования к документации достаточно конкретны, чтобы быть осмысленными, но не настолько жесткие, чтобы превращаться в пустую формальность. Например, подтверждение по пользовательскому тестированию медиаальтернатив запрашивает типы инвалидности каждого пользователя, количество пользователей по каждому типу, дату тестирования и примеры исправленных проблем. Это разумный набор доказательств, демонстрирующий реальную работу с реальными пользователями. И это дает слой защиты от хищнических исков.
Есть важный контраргумент: подтверждения можно сымитировать. Кто-то может задокументировать поверхностный процесс, поставить галочку и жить дальше. Согласен. Но старая система тоже имитируется — автоматическими оверлейными инструментами, которые обещают соответствие WCAG 2.x через впрыскивание JavaScript, не трогая структурные проблемы. VPATы регулярно заполняются с щедрой интерпретацией того, что значит «поддерживает» и «частично поддерживает». Ни одна система не застрахована от недобросовестных игроков.
Вопрос в другом: стимулирует ли система правильное поведение у добросовестных игроков? И здесь подтверждения выигрывают. Потому что разница в качестве имитации колоссальная. Навесить оверлей на сайт можно за час, не меняя процессов. А чтобы подделать подтверждение с требованиями к документации, нужно создавать сложную, поддающуюся проверке инфраструктуру лжи. Это повышает планку для недобросовестных игроков на порядок.
Для организаций, которые уже готовятся к Европейскому акту о доступности (European Accessibility Act), делающему упор на встраивание доступности в культуру и процессы организации, подтверждения — естественная вещь. EAA и WCAG 3.0 сходятся к одному выводу: соответствие как снимок состояния продукта в моменте менее ценно, чем соответствие как свидетельство организационных обязательств.
Когнитивная доступность получает реальное покрытие
WCAG 2.x всегда обделял внимание когнитивные нарушения и нарушения обучаемости. В версию 2.2 добавили некоторые улучшения, но это были заплатки на каркасе, который проектировался в первую очередь под сенсорные и моторные нарушения.
WCAG 3.0 относится к когнитивной доступности как к задаче первого сорта. Одно только руководство по ясному языку (Clear Language) включает требования об отсутствии лишних слов, отсутствии вложенных clauses, использовании общеупотребительных слов вместо жаргона, объяснении сокращений, избегании небуквального языка, наличии визуальных подсказок и включении заключений. И это дополняется подтверждениями о наличии гайдов по ясному языку, политик обучения и процессов ревью на предмет простого языка.
Руководство по избеганию обмана (Avoid Deception) не менее важно. Оно касается изменений в соглашениях, вводящих в заблуждение формулировок, искусственного давления, скрытых предвыборов и манипуляции. По сути, это встраивание принципов борьбы с темными паттернами прямо в стандарт доступности. И это превращает борьбу с обманом пользователей из вопроса этики в вопрос соблюдения стандарта, что дает юристам и защитникам прав людей с инвалидностью новый, мощный инструмент. Темные паттерны непропорционально сильно бьют по людям с когнитивными нарушениями, которым сложнее распознать манипулятивные интерфейсы.
Руководство по завершению процессов и задач (Process and Task Completion) покрывает избегание непосильных когнитивных задач, предоставление достаточного времени, устранение лишних шагов и сохранение информации между сессиями. Эти требования отражают реальность: многие цифровые продукты избыточно сложны не из-за технических ограничений, а из-за дизайн-решений, рассчитанных на узкий диапазон когнитивных стилей.
Ничего из этого было невозможно достичь в рамках WCAG 2.x. Критерии успеха должны быть тестируемы, а требования к когнитивной доступности принципиально сложнее сводятся к бинарным проверкам «да-нет». Многослойная модель WCAG 3.0 с подтверждениями, дополняющими основные требования, создает структурное пространство для работы с когнитивными потребностями без необходимости пропускать все через одну и ту же парадигму тестирования.
Область применения совпадает с тем, как люди реально используют технологии
WCAG 2.x — это стандарт для веб-контента. Это прямо указано в названии. Доступность мобильных устройств обеспечивается через интерпретации и отсылки к EN 301 549. Носимые устройства, интернет вещей, виртуальная реальность, дополненная реальность и голосовые интерфейсы существуют за пределами концептуальных границ спецификации.
WCAG 3.0 явно покрывает десктопы, ноутбуки, планшеты, мобильные устройства, носимые гаджеты и другие устройства веба вещей. Он адресует статический, динамический, интерактивный и стриминговый контент, аудиовизуальные медиа, виртуальную и дополненную реальность, альтернативные способы представления и управления. И он вбирает в себя территории, которые раньше покрывались отдельными стандартами — UAAG 2.0 для пользовательских агентов и ATAG 2.0 для инструментов для создания авторских текстов.
Это важно, потому что искусственная граница между «веб-контентом» и «всем остальным» размывалась годами. Компания, которая выпускает веб-приложение на React, мобильное приложение на React Native, голосовой навык и приложение для умных часов — на самом деле создает один продукт на нескольких поверхностях. Когда для каждой поверхности действуют разные стандарты доступности или не действуют никакие, возникают разрывы, нестыковки и оправдания для того, чтобы не заниматься не-веб-опытом всерьез.
Требования к окружению на 360 градусов — хороший пример того, как область применения заглядывает в будущее. Черновик требует, чтобы в 360-градусных цифровых средах субтитры оставались прямо перед пользователем, а визуальные индикаторы показывали направление звука или речи, доносящихся из-за пределов текущего обзора. Доступность VR и AR — действительно сложная проблема, и тот факт, что рабочая группа устанавливает четкие обязательные требования, пока технология еще только формируется, гораздо лучше, чем попытки вписать требования задним числом, когда целая экосистема уже построена без их учета.
Градуированное соответствие отражает реальность
В WCAG 2.2 соответствие бинарно. Вы либо выполняете все требования заявленного уровня, либо нет. Один провал по любому критерию успеха на любой странице в пределах области действия технически ломает вашу декларацию о соответствии. Все в индустрии знают, что это не имеет ничего общего с тем, как доступность реально работает в масштабе. В больших приложениях сотни экранов, контент постоянно меняется, сторонние компоненты приносят проблемы вне вашего прямого контроля, а сроки исправления измеряются спринтами, а не днями.
На выходе декларации о соответствии WCAG 2.x либо амбициозны (мы работаем над уровнем AA), либо юридически выхолощены (соответствие декларируется для определенного подмножества страниц, протестированных на конкретную дату), либо откровенно фиктивны. Модель «все или ничего» не поощряет инкрементальный прогресс, не отличает организацию с тремя нерешенными проблемами от организации с тремя сотнями и не стимулирует делать больше обязательного минимума.
Предложенная в WCAG 3.0 модель с уровнями Bronze, Silver и Gold меняет эту динамику. Bronze — выполнение всех базовых требований — задуман как примерно соответствующий WCAG 2.2 AA. Уровни Silver и Gold требуют дополнительных дополнительных требований и подтверждений, создавая путь для организаций, которые хотят демонстрировать прогрессирующую вовлеченность. Рабочая группа изучает механизмы оценки, которые позволят декларациям о соответствии отражать степень выполнения требований, а не просто факт наличия или отсутствия единичного провала.
Это выигрыш для всех. Организации получают модель соответствия, которая признает грязную реальность крупномасштабной разработки. Закупщики получают более полезную информацию о продукте и его поставщике. А люди с инвалидностью выигрывают, потому что система стимулирования теперь поощряет непрерывное улучшение, а не минимально возможное соответствие.
Модульная архитектура обновлений давно назрела
WCAG 2.0 был опубликован в 2008 году. WCAG 2.1 вышел в 2018. WCAG 2.2 — в 2023. Пятнадцать лет жизненного цикла с двумя инкрементальными обновлениями за период, в котором веб прошел путь от плагинов jQuery до одностраничных приложений, адаптивного дизайна, веб-компонентов, прогрессивных веб-приложений, фреймворков для серверного рендеринга и контента, сгенерированного искусственным интеллектом.
Медленный цикл обновлений — не потому, что рабочая группа ленива. Это структурная проблема. В WCAG 2.x техники жестко привязаны к нормативной спецификации. Добавление новой достаточной техники требует тщательного анализа, не меняет ли она интерпретацию критерия успеха. Новые критерии успеха требуют полной новой версии. В итоге стандарт не поспевает за технологиями, которые пытается регулировать.
WCAG 3.0 разделяет методы (технологически-специфичные руководства по реализации) и нормативные требования. Методы можно добавлять, обновлять или удалять без пересмотра самого стандарта. Новый метод для доступных React-компонентов или для работы с доступностью в новом AR-фреймворке может быть опубликован, как только он подтвержден, без ожидания следующей большой версии WCAG.
Это правильная архитектура для технологического ландшафта, который меняется быстрее, чем любой орган по стандартизации успевает публиковать документы. Команды на уровне предприятий выигрывают, потому что руководство по реализации остается актуальным для их реального технологического стека, а новые техники не требуют переоценки всей их позиции по соответствию.
Маркировка по функциональным потребностям предотвращает выборочные улучшения
Одна из недооцененных фич WCAG 3.0 — система маркировки требований по функциональным потребностям. Каждое требование и каждое подтверждение помечены тегами, указывающими, какие функциональные потребности они адресуют: зрение, слух, моторика, когнитивные способности, сенсорика и так далее. Предложенная модель соответствия требует, чтобы для достижения Bronze было выполнено минимальное количество дополнительных требований внутри каждой категории функциональных потребностей.
Это прямой ответ на реальную проблему. Организации часто вкладываются преимущественно в визуальную доступность, потому что автоматические инструменты легко ее проверяют, и потому что большинство исков подается людьми с нарушениями зрения. При этом когнитивные, моторные или слуховые потребности остаются на втором плане. В WCAG 2.x технически можно достичь уровня AA, относясь ко всем критериям успеха одинаково, но на практике организации приоритезируют те критерии, которые проще тестировать и которые лучше видны автоматическим сканерам.
Маркировка по функциональным потребностям превращает равномерное покрытие из культурного стремления в структурное требование. Вы не можете получить Bronze, закрыв все визуальные требования, но проигнорировав когнитивную доступность. Это тот случай, когда системное дизайн-решение дает больший эффект, чем любое отдельно взятое требование.
Чего все еще не хватает
Мне искренне нравится направление WCAG 3.0. Но нравится направление и возможность использовать продукт — разные вещи, и интеллектуальная честность требует перечислить, сколько работы еще впереди. Это не критика рабочей группы. Разработка стандартов — это адски трудная работа, основанная на консенсусе и выполняемая в основном волонтерами, у которых гораздо больше терпения, чем у меня.
Модель соответствия — это пока эскиз, а не спецификация. Bronze, Silver и Gold описаны концептуально, но механика, которая сделает их реальными, еще не определена. Как агрегируются баллы? Какие пороговые значения определяют каждый уровень? Как взвешиваются категории функциональных потребностей? Отменяет ли критическая ошибка соответствие полностью? Рабочая группа публиковала слайды и дискуссионные заметки, исследуя подходы на основе баллов, процентов и модулей, но ни один не выбран. Нельзя построить программу соответствия на модели, в которой еще нет цифр.
Таблицы спецификации пусты. Руководство по текстовому отображению включает таблицы, которые должны определять конкретные значения для читаемого текста: высота строк, длина строк, размер шрифта, выравнивание, межбуквенные расстояния для пяти языков. Почти каждая ячейка пуста. В самом черновике сказано, что метрики в следующих таблицах еще предстоит определить. Это не мелкие детали на границах. Это значения, которые будут проверять автоматические инструменты, под которые будут кодить разработчики и по которым будут измерять аудиторы. Без них требования остаются направленческими стремлениями, а не тестируемыми критериями.
Проверяемость подтверждений не решена. В черновике прямо сказано, что результаты процесса, описанного в подтверждении, не могут быть протестированы, и что соответствие WCAG не требует проверки подтверждающей документации. Логика понятна: вы не можете независимо воспроизвести результат юзабилити-исследования так же, как вы можете перепроверить коэффициент контрастности цветов. Но это создает реальный пробел в подотчетности. Если я заявляю, что моя команда провела пользовательское тестирование с восемью участниками с инвалидностью, что мешает недобросовестному игроку сфабриковать это утверждение? В черновике ответа нет. Сторонним аудиторам, закупщикам и регуляторам всем понадобится ответ на этот вопрос, прежде чем подтверждения смогут нести осмысленный вес.
Классификация на базовые и дополнительные требования не завершена. Какие требования попадут в базовый набор, обязательный для Bronze, а какие в дополнительный набор для более высоких уровней, определит, поднимет WCAG 3.0 практическую планку по сравнению с WCAG 2.2 AA или опустит. Рабочая группа активно это обсуждает, включая вопрос, должны ли какие-то подтверждения быть базовыми. Пока эти классификации не сделаны, никто не может оценить, будет ли Bronze строже, эквивалентен или мягче текущих ожиданий уровня AA.
Покрытие автоматического тестирования сократится. Это следствие того, что стандарт покрывает правильные вещи. Качество ясного языка, избегание обмана, алгоритмическая справедливость, подтверждения процессов, когнитивная сложность задач — все это важные аспекты доступности, которые сопротивляются автоматизации. Но корпоративные программы, которые сегодня сканируют тысячи страниц еженощно и сбрасывают баги в Jira, должны понимать: модель тестирования станет значительно более трудозатратной. Экосистема инструментов для WCAG 3.0 пока не существует, и ее создание потребует принципиально новых подходов, выходящих за рамки инспекции DOM и расчета контрастов. Я достаточно оптимистичен насчет ИИ, но не вижу, чтобы этот разрыв закрылся искусственным интеллектом в ближайшие несколько лет.
Тайминг оптимистичен. Рабочая группа целится на статус кандидата в рекомендации в четвертом квартале 2027 и полную рекомендацию не ранее 2028. Учитывая объем открытых вопросов, я бы закладывался на 2029 как самый ранний срок для готового стандарта, с принятием регуляторами еще через один-три года после этого.
Руководства по миграции пока нет. Рабочая группа обещала предоставить материалы поддержки перехода, возможно, включая маппинги между критериями WCAG 2.2 и требованиями WCAG 3.0. В текущем черновике их нет. Организации, которые годами вкладывались в программы соответствия WCAG 2.x, нуждаются в понятном мосте, чтобы понять, что переносится, что меняется, а что появляется с нуля. Пока этот маппинг не опубликован, планирование миграции остается гаданием.