Доступность сайта (a11y) 2026: что требует закон и почему это даст +30% трафика

Что такое a11y простыми словами

Термин a11y — это сокращение английского слова accessibility («доступность»). Цифра 11 — количество букв между «a» и «y». В русскоязычной IT-среде используется как калька: «эйленайн», «доступность», «адаптация для людей с инвалидностью». На практике речь о том, чтобы сайт работал не только для условного «среднего пользователя», но и для тех, кто видит плохо, не слышит, не пользуется мышью или воспринимает информацию иначе.

Категорий пользователей, для которых критична доступность, гораздо больше, чем принято думать. Слабовидящие — увеличивают шрифт, повышают контраст, иногда читают через лупу экрана. Незрячие — пользуются программами-скринридерами (NVDA, JAWS, VoiceOver), которые озвучивают содержимое страницы. Глухие и слабослышащие — нуждаются в субтитрах для видео и в визуальной альтернативе звуковым сигналам. Люди с моторными нарушениями — управляют компьютером только клавиатурой, голосом или специальными переключателями. Люди с когнитивными особенностями — выигрывают от простого языка, чёткой структуры, отсутствия мигания и отвлекающих анимаций.

Я люблю аналогию с пандусом. Когда у входа в магазин делают пандус для инвалидной коляски — это юридическое требование. Но пользуются им все: мама с коляской, курьер с тележкой, бабушка с тяжёлой сумкой, человек на велосипеде. Удобство для одних оборачивается удобством для всех. Точно так же с доступностью сайта: alt-теги нужны слепым через скринридер, но эти же теги индексируют поисковики и видит человек с медленным интернетом, у которого картинка не загрузилась. Контраст шрифта нужен слабовидящим, но он же спасает обычного пользователя, читающего сайт на улице под солнцем с экрана смартфона.

В 2026 году a11y перестал быть «опцией для крупных компаний». Это базовое требование к любому коммерческому сайту в России — и юридическое, и экономическое. Мы дойдём до цифр и кейсов, но сразу скажу главное: правильная доступность ничего не стоит, если внедряется при создании сайта. Дорогим становится переделывание уже готового решения, которое изначально проектировали без a11y.

Регулирование доступности сайтов в РФ 2026

Тема регулирования доступности в России мало известна даже разработчикам. Объясню по слоям, от верхнего к нижнему.

Конституция РФ, статья 19 — гарантирует равенство прав независимо от состояния здоровья. Базис всего остального.

Федеральный закон №419-ФЗ от 01.12.2014 «О внесении изменений в отдельные законодательные акты Российской Федерации по вопросам социальной защиты инвалидов в связи с ратификацией Конвенции о правах инвалидов». Именно этот закон ввёл в правовое поле понятие «доступная среда» — включая информационные технологии и сайты. С тех пор в каждый отраслевой закон постепенно добавляли требования о доступности информации для инвалидов.

Постановление Правительства РФ № 1828 от 30.12.2017 — определило требования к доступности государственных и муниципальных сайтов. Сначала это касалось только госуслуг, но за восемь лет требования расширились на весь госсектор и социально-значимые ресурсы (медицинские учреждения, образовательные организации, банковские сервисы при работе с пенсионерами и инвалидами).

ГОСТ Р 52872-2019 «Интернет-ресурсы и другие информационно-телекоммуникационные сервисы. Требования доступности для инвалидов и других лиц с ограничениями жизнедеятельности» — российская редакция международного стандарта WCAG 2.1. Это не закон, но любая претензия со стороны проверяющих органов будет ссылаться именно на этот ГОСТ как на технический эталон.

Перспектива 2026-2027. Минцифры с 2024 года готовит расширение требований доступности на коммерческие сайты в трёх отраслях: медицина (клиники, лаборатории, аптеки), ЖКХ (управляющие компании, поставщики ресурсов), и банковско-финансовый сектор. Дальше — на ритейл и крупные онлайн-сервисы. Тренд однозначный: за пять лет требования доступности будут такими же обыденными, как требования по 152-ФЗ.

WCAG 2.2 — международный стандарт

WCAG (Web Content Accessibility Guidelines) — стандарт, который разрабатывает консорциум W3C. Версии менялись: WCAG 1.0 (1999), 2.0 (2008), 2.1 (2018), 2.2 (октябрь 2023). В 2026 году актуальная версия — 2.2, она расширила 2.1 девятью новыми критериями (про размер тач-зон, авторизацию без когнитивной нагрузки, видимость фокуса и пр.). Российский ГОСТ Р 52872-2019 формально соответствует WCAG 2.1, но при новых проектах разумно ориентироваться на 2.2 — он более строгий и охватывает мобильные UX.

WCAG строится на четырёх принципах. Запомнить их легко по английскому акрониму POUR.

P — Perceivable, воспринимаемость. Информация должна быть представлена так, чтобы пользователь мог её воспринять. Альтернатива для не-текстового контента (alt у картинок), субтитры для видео, достаточный контраст, возможность увеличения шрифта, поддержка скринридеров.

O — Operable, управляемость. Интерфейс должен быть управляемым. Всё работает с клавиатуры, нет ловушек фокуса, достаточно времени на чтение, нет контента, провоцирующего эпилепсию (быстрое мигание).

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

R — Robust, надёжность. Контент должен быть надёжным — корректно работать в разных пользовательских агентах, включая ассистивные технологии. На практике это значит «семантический валидный HTML», ARIA-атрибуты используются правильно, разметка не ломается у скринридера.

В рамках каждого принципа есть критерии успеха, отсортированные по уровням соответствия: A (минимальный, базовый), AA (стандартный — целевой для большинства сайтов), AAA (расширенный — для специализированных ресурсов). Здравая стратегия для коммерческого сайта — стремиться к AA. Уровень A — это «лишь бы не штрафовали», AAA — избыточный для бизнеса.

Топ-10 нарушений на типичном сайте 2026

За последние пять лет я провёл десятки a11y-аудитов российских сайтов. Картина повторяется. Перечислю топ-10 проблем, отсортированных по частоте.

1. Нет alt у картинок. Картинки в каталоге, фото в блоге, иконки в навигации — всё без alt. Скринридер не понимает, что изображено. Поисковики не индексируют. Решение: каждая значимая картинка получает alt с осмысленным описанием. Декоративные — пустой alt="" (но не отсутствие атрибута).

2. Контраст текста слишком низкий. Дизайнеры любят тонкий серый шрифт на белом фоне или светлый текст на пастельном фоне. Контраст 2.5:1 при норме 4.5:1 для AA. На улице под солнцем такой текст не читается вообще. Решение: проверить инструментом Stark или Chrome DevTools, увеличить контраст.

3. Невозможно навигироваться только клавиатурой. Пользователь нажимает TAB — фокус «прыгает» по элементам непредсказуемо или не показывается вовсе. Кликнуть по бургеру или dropdown без мыши невозможно. Решение: правильная семантика, видимый стиль :focus, логичный tabindex.

4. Формы без label. Поля ввода описаны через placeholder, а тег <label> отсутствует. Скринридер вместо «Введите email» говорит «текстовое поле». Решение: каждое поле получает связанный <label for="id">.

5. Нет skip-link. Первое, что видит незрячий пользователь — длинное навигационное меню, которое скринридер озвучивает на каждой странице. Skip-link «Перейти к основному контенту» решает эту проблему за минуту работы.

6. Кликабельные div вместо button. Программист сделал «кнопку» через <div onClick>, не учтя что скринридер не понимает это как кнопку. Решение: только <button> для действий, только <a> для ссылок.

7. Видео без субтитров. На сайте товарное видео, реклама, обучение — без субтитров. Глухие не понимают содержание. Решение: добавить субтитры через YouTube (автогенерация + ручная правка) или через WebVTT, если видео хостится на своём сервере.

8. Цвет — единственный индикатор. Красная подсветка обозначает ошибку формы. Дальтоники (8% мужчин) не отличают красный от зелёного. Решение: ошибка обозначается одновременно цветом, иконкой и текстом.

9. Маленькие тач-зоны. Кнопки и ссылки в мобильной версии меньше 44×44 пикселей. На смартфоне промахиваются все, особенно люди с моторными нарушениями. WCAG 2.2 ввёл это в обязательные критерии. Решение: минимум 44×44 для всех интерактивных элементов.

10. Запрет масштабирования viewport. В meta-теге написано user-scalable=no или maximum-scale=1. Браузер блокирует щипок для увеличения. Для слабовидящих это катастрофа. Решение: убрать запрет, оставить только width=device-width.

Бонус для SEO — как a11y улучшает позиции

Это самая недооценённая часть истории про доступность. Многие воспринимают a11y как «социалку» и «доброе дело». Между тем, требования доступности и требования поисковой оптимизации пересекаются на 70-80%. Делая сайт доступным, вы автоматически делаете его более seo-friendly.

Alt-теги у картинок. Главный сигнал Яндексу и Google о содержании изображения. Поисковики индексируют alt, показывают картинки в Картинках Яндекса и Google Images, используют alt как сигнал релевантности страницы. На карточке товара alt с описанием «синие беговые кроссовки Nike Air Max 90 размер 42» приносит трафик из поиска картинок.

Семантический HTML. Теги <nav>, <main>, <article>, <aside>, <footer> — это не только для скринридеров. Поисковики используют семантику, чтобы понять структуру страницы и выделить главное. Контент в <main> получает больший вес, чем в неопределённом <div>.

Skip-link. Помогает поисковикам быстрее найти основной контент, минуя многократно повторяющуюся навигацию. Косвенно снижает bounce rate, потому что пользователь быстрее находит, что искал.

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

Правильная иерархия заголовков. H1 один на странице, дальше H2, H3 без пропусков уровней. Это и a11y-требование (скринридер строит навигацию по заголовкам), и сильный SEO-сигнал.

Реальные кейсы прироста SEO после a11y:

• Pinterest — +30% органического трафика после редизайна с фокусом на доступность.
• Tesco UK — +£13M годовой выручки после полной адаптации интернет-магазина (кейс из McKinsey).
• BBC — +24% к engagement у пользователей со слабым зрением, плюс улучшение позиций в Google для News.
• Российская практика: после правильного внедрения семантики и alt на средний интернет-магазин (3000 SKU) — рост органического трафика на 20-30% за 3-4 месяца.

Как проверить ваш сайт за 5 минут

Хорошая новость: для базовой проверки доступности не нужно нанимать аудитора. Минимальный набор инструментов бесплатный и работает в браузере.

WAVE — расширение для Chrome/Firefox от WebAIM. Открываете сайт, нажимаете иконку — получаете список нарушений с подсветкой прямо на странице. Бесплатно, без регистрации.

axe DevTools — расширение от Deque. Считается более строгим, чем WAVE. Особенно хорошо ловит проблемы ARIA. Бесплатная версия имеет ограничения, но для базового аудита её хватает.

Lighthouse — встроен в Chrome DevTools. Кроме accessibility считает Performance, SEO и Best Practices. Очень удобно: один отчёт показывает все слабые места сайта. Целевой балл по Accessibility — 95+ из 100.

NVDA — бесплатный скринридер для Windows. Установите, включите, попробуйте пройти по своему сайту с закрытыми глазами. Это самый честный тест a11y. Если за минуту вы не поняли, что на странице — у вас проблемы.

VoiceOver — встроенный скринридер в macOS и iOS. Включается Cmd+F5 (Mac) или тройным нажатием на боковую кнопку (iPhone). Аналог NVDA для Apple-устройств.

Для разработчиков есть командные инструменты для интеграции в CI/CD:

# Установка axe-cli глобально
npm install -g @axe-core/cli

# Аудит главной страницы
axe https://example.com

# Аудит с конкретным уровнем (AA)
axe https://example.com --tags wcag2a,wcag2aa

# JSON-отчёт для CI
axe https://example.com --save report.json

# Pa11y — альтернатива axe
npm install -g pa11y
pa11y https://example.com --standard WCAG2AA --reporter json

В реальном проекте я обычно ставлю pa11y или axe в pipeline GitHub Actions, чтобы каждый PR проверялся автоматически. Если новый код вводит a11y-регрессию — pipeline падает, разработчик исправляет до merge.

Базовый чек-лист 20 пунктов

Если бы у меня был один час на a11y-аудит сайта без инструментов, я бы прошёлся по этому списку. Минимум 80% проблем покрывается им. Свернул каждый пункт под details — на мобильном устройстве так удобнее.

1. <html lang="ru"> — указан язык страницы

Скринридер выбирает голос и произношение в зависимости от lang. Без этого атрибута он либо берёт системный язык по умолчанию (часто английский), либо начинает «английским голосом» читать русский текст. Проверить можно один раз — посмотреть в исходник любой страницы. Если в шаблоне один lang — все страницы получают правильное значение.

2. alt у всех картинок

Каждый тег <img> должен иметь атрибут alt. Для информативных картинок — осмысленное описание (5-15 слов). Для декоративных — пустой alt="" (атрибут есть, значение пустое). Просто отсутствующий alt — нарушение.

3. Контраст текста минимум 4.5:1 (для AA)

Норма WCAG AA для обычного текста — 4.5:1. Для крупного текста (≥18px жирный или ≥24px) — 3:1. Проверить можно расширением Stark или вкладкой Lighthouse в DevTools. Серый шрифт #999 на белом фоне даёт 2.85:1 — не проходит.

4. Все интерактивные элементы доступны с клавиатуры

Откройте сайт, не трогайте мышь. Жмите TAB. Можете ли вы пройти по всем ссылкам, кнопкам, формам, открыть меню, отправить заявку? Если хоть что-то недоступно — нарушение.

5. Стиль :focus виден

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

6. Формы — label для каждого поля

Либо <label for="email">Email</label><input id="email">, либо <input aria-label="Email">. Placeholder — не замена label, он исчезает при вводе.

7. Skip-link в начале страницы

Первый интерактивный элемент — ссылка «Перейти к содержанию», скрытая визуально и появляющаяся при фокусе с клавиатуры. Реализуется одним блоком CSS и одной ссылкой в HTML.

8. Кнопки — <button>, ссылки — <a>

Кнопка совершает действие на текущей странице. Ссылка ведёт куда-то. Не путать. Никаких <div onClick> или <span onClick>.

9. Без auto-play видео/аудио

Если что-то начинает играть само — это шок для незрячего, который не понимает, откуда звук. Auto-play разрешён только без звука (muted). Включение звука — по клику.

10. Без полностью «графического» текста

Картинка с текстом внутри (JPEG, PNG) не доступна скринридеру и не индексируется. Используйте реальный HTML-текст. Исключение — логотип.

11. Иерархия заголовков H1 → H2 → H3

Один H1 на странице, дальше H2, H3 без пропусков. Не использовать заголовки для стилизации (большой текст — это <p class="big">, а не <h2>).

12. Субтитры для видео

WebVTT или встроенные субтитры YouTube. Минимально — автогенерация + ручная коррекция важных терминов.

13. Транскрипт для аудио

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

14. Тач-зоны ≥ 44×44px

На мобильной версии все кликабельные элементы (кнопки, ссылки, чекбоксы) должны быть не меньше 44×44 пикселя. Это требование WCAG 2.2.

15. Viewport без user-scalable=no

В meta name="viewport" должно быть только width=device-width, initial-scale=1. Никаких maximum-scale=1 или user-scalable=no.

16. Контраст UI-элементов ≥ 3:1

Не только текст, но и иконки, рамки кнопок, индикаторы состояния должны иметь контраст 3:1 относительно фона.

17. Поддержка prefers-reduced-motion

Если пользователь в настройках ОС попросил уменьшить анимации — сайт обязан их выключить. @media (prefers-reduced-motion: reduce) { ... } в CSS.

18. Без зависимости только от цвета

Ошибка формы — красный + иконка + текст. Обязательный пункт — звёздочка + текст «обязательное». Не только цветом.

19. ARIA — там где нужно, не везде

Если можно обойтись семантическим HTML — обходитесь. Кнопке <button> не нужен role="button". ARIA добавляется только когда нативной семантики не хватает (table-навигация, табы, аккордеоны).

20. HTTPS и работающие формы

Скринридер должен слышать подтверждение отправки формы (aria-live="polite"). HTTPS — для всех браузеров и для самих пользователей (без HTTPS многие функции ассистивных технологий работают плохо).

«Виджет accessibility» — почему это не работает

В последние годы появились коммерческие сервисы (AccessiBe, UserWay, EqualWeb и российские аналоги), которые обещают «сделать сайт доступным за один клик». Технически это виджет — JavaScript-плагин, который добавляет на сайт плавающую кнопку. По клику открывается меню с настройками: увеличить шрифт, повысить контраст, переключить курсор, активировать «режим для дислексии» и так далее.

Звучит привлекательно: 5-10 тысяч рублей в месяц, и сайт «доступен». На практике эти виджеты не работают по трём причинам.

Они не исправляют корень проблемы. Если у вас нет alt у картинок — виджет не появит их волшебным образом. Если у вас <div onClick> вместо <button> — виджет не превратит div в кнопку для скринридера. Виджет — это надстройка над сайтом, и он работает только с тем, что уже есть. Кривая семантика остаётся кривой.

Они мешают пользователям, которые уже настроили свои инструменты. Незрячий пользователь NVDA не нуждается в кнопке «активировать режим скринридера». У него уже работает NVDA. Виджет может пытаться «помочь» — переопределять стили, перехватывать события — и в итоге ломает работу скринридера, который без виджета работал бы корректно. В США есть кейсы судебных исков против сайтов, которые поставили AccessiBe, потому что виджет ухудшил доступность.

Они дороже, чем правильное решение. Подписка на виджет — 5-15 тыс ₽/месяц = 60-180k ₽/год. За эти деньги можно один раз сделать правильную семантику и забыть. Через 3 года правильный сайт будет дешевле в 5 раз.

Стоимость внедрения a11y

Конкретные цифры из моей практики и из открытых прайсов российских студий.

Ключевая мысль: сделать новый сайт сразу с a11y дешевле, чем переделывать готовый. Поэтому в моём проекте «сайт под ключ» доступность входит в базу — не как опция за доплату. Дополнительно стоит только если у вас экзотические интерактивные компоненты (drag-and-drop, сложные графики, кастомные плееры) — там нужна индивидуальная настройка ARIA.

Штрафы и риски

КоАП РФ, статья 9.13 «Нарушение требований доступности для инвалидов объектов социальной, инженерной и транспортной инфраструктур и предоставляемых услуг» — штраф для должностных лиц от 2 до 3 тыс ₽, для юр. лиц от 20 до 30 тыс ₽. Сумма выглядит небольшой, но штраф можно получать многократно при повторных проверках, и каждое нарушение фиксируется отдельно.

Прокурорские проверки. Прокуратура регулярно проверяет сайты медучреждений, школ, банков, ЖКХ-компаний. По результатам проверки выдают предписание устранить нарушения. При невыполнении — штрафы, в том числе для руководителя организации лично.

Гражданские иски. Пока редкие в РФ, но они есть. Общественные организации инвалидов подают иски против сайтов, нарушающих закон №419-ФЗ. На Западе это обычная практика — в США количество a11y-исков выросло в 5 раз за последние пять лет (Domino's Pizza проиграла дело о недоступности своего сайта на $400k).

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

Реальные кейсы где a11y дал прирост

Я уже упоминал несколько кейсов выше — повторю их подробнее, добавлю свежие.

Pinterest. В 2017 году провели полную переработку фронтенда с фокусом на доступность. Результат — +30% органического трафика за 18 месяцев. Главный вклад дали alt-теги к миллиардам пинов и улучшенная семантика навигации.

Tesco UK. Британский ритейлер ещё в 2002 году сделал доступную версию интернет-магазина по WCAG AA. Доход с доступной версии за первый год составил £13 млн (кейс из доклада McKinsey).

BBC. Внутренние данные BBC показали, что пользователи со слабым зрением, которым адаптировали интерфейс, увеличили среднее время на сайте на 24% и количество прочитанных статей на 18%. Параллельно — рост позиций в Google для всех страниц.

Российские примеры. Сбер, Яндекс, ЦБ РФ — все они за последние 3-5 лет провели большие работы по a11y. Сбер открыто публикует данные о доступности своих сервисов в годовых отчётах. На уровне небольшого бизнеса я видел кейс интернет-магазина запчастей: после правильной семантики и alt прирост органики Яндекса составил 27% за 4 месяца, без изменений в SEO-стратегии.

План внедрения за 1 месяц

Минимальная программа, которой я обычно следую с клиентами.

Неделя 1: аудит. Прогон WAVE и axe DevTools по всем типам страниц (главная, каталог, карточка, корзина, форма, статья). Lighthouse-отчёт. Ручной тест клавиатурой — пройти все ключевые сценарии без мыши. Тест с NVDA — попробовать сделать покупку с закрытыми глазами. На выходе — отчёт со списком проблем по приоритету.

Неделя 2: исправление топ-10. Самые критичные нарушения, которые дают 80% эффекта: alt, контраст, label, видимый focus, semantic HTML вместо div, skip-link, исправление кликабельных div на button. На этом этапе уже виден существенный прогресс в Lighthouse-отчёте.

Неделя 3: правильная структура. Семантические теги (header, nav, main, article, aside, footer), правильная иерархия заголовков, ARIA там где нужно (но без перебора), формы с правильной разметкой ошибок, медиа с субтитрами и транскриптами.

Неделя 4: тестирование и документация. Полный прогон со скринридером, исправление найденного, документация для команды (как поддерживать a11y в новых фичах), интеграция axe или pa11y в CI/CD pipeline. На выходе — Lighthouse Accessibility 95+, нулевые критичные ошибки axe.

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

Обязан ли мой сайт быть доступным по закону РФ? Если вы государственная или муниципальная организация — да, обязаны (постановление Правительства РФ № 1828). Если социально-значимый сектор (медицина, образование, банки) — фактически да, через отраслевые требования. Если коммерческий ритейл — пока обязанности нет, но требования расширяются, и через 2-3 года это будет норма. Плюс прокурорские проверки могут прийти к любой компании, если поступит жалоба.

Сколько процентов пользователей реально это нужно? По данным Росстата, 12 млн людей с инвалидностью в РФ — 8% населения. Из них примерно 60-70% пользуются интернетом. К этому добавьте людей с возрастными ограничениями (миопия, тремор рук, снижение слуха) — это ещё 10-15% аудитории. Итого 15-20% пользователей выигрывают от правильной a11y.

Достаточно ли установить виджет accessibility? Нет. Виджет — маркетинговый продукт, который не исправляет корень проблемы. Юридически не защищает, технически не помогает скринридерам.

WCAG 2.1 или 2.2 — какой стандарт использовать в 2026? Российский ГОСТ соответствует 2.1, но если делаете новый проект — ориентируйтесь сразу на 2.2 (она строже и охватывает мобильные UX). Разница в 9 новых критериях, все полезные.

Можно ли сделать a11y только частично — главную страницу? Можно, но это не закроет претензии регулятора и не даст полного SEO-эффекта. Минимум — все типы страниц (главная, каталог, карточка, форма обратной связи). Лучше — весь сайт.

Что такое ARIA и когда её использовать? ARIA (Accessible Rich Internet Applications) — набор HTML-атрибутов для сложных компонентов, у которых нет нативной семантики. Используется для табов, аккордеонов, модальных окон, динамических обновлений. Правило: «No ARIA лучше плохой ARIA». Если есть нативный тег — используйте его, ARIA только для специфичных случаев.

Влияет ли a11y на скорость загрузки сайта? Практически нет. Правильная семантика весит столько же, сколько неправильная. Alt-теги — это несколько байт на картинку. Skip-link — 5 строк кода. Виджет accessibility, наоборот, добавляет 100-300КБ JavaScript — он замедляет сайт.

Выводы

Доступность сайта в 2026 году — это не «социалка», а триединое решение. Юридическое — потому что требования расширяются год за годом и проверки уже идут. Экономическое — потому что 15-20% потенциальной аудитории прямо или косвенно выигрывают от a11y, плюс +20-30% к органическому SEO-трафику. Этическое — потому что цифровое пространство должно быть доступно всем.

Главный совет — закладывать a11y с самого начала. Сделать сайт сразу доступным дешевле, чем переделать готовый. Если вы запускаете новый проект — добавьте accessibility-требования в техническое задание. Если у вас уже есть сайт — начните с базового аудита (его можно сделать самому за час с WAVE и axe DevTools), потом приоритизируйте топ-10 проблем.

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

Если у вас есть сайт и нужно понимать, насколько он доступен — напишите мне в Telegram. За день дам отчёт с приоритетами и стоимостью фиксов. Если сайта ещё нет — сделаю под ключ с правильной a11y из коробки, без переплат и без виджетов.