Доступность сайтов (WCAG): Руководство 2026

Доступность сайтов (WCAG): Полное руководство 2026

Доступность в вебе — это уже не опциональное пожелание, а юридическая обязанность, этическая ответственность и реальное бизнес-преимущество. В Австрии около 1,4 миллиона человек живут с инвалидностью, в масштабах Европы — более 87 миллионов. К ним добавляются миллионы пожилых пользователей и людей с временными ограничениями. Доступный сайт охватывает всех этих людей — и одновременно обеспечивает лучший пользовательский опыт для каждого посетителя.

В GoldenWing мы уже более 3 лет создаём доступные сайты и знаем все трудности, законодательные требования и практические решения. В этом подробном руководстве вы узнаете всё, что нужно знать о доступности сайтов в 2026 году.

Что такое доступность сайтов?

Доступность сайтов (Web Accessibility) означает, что сайт спроектирован и разработан таким образом, что им могут пользоваться все люди — независимо от физических, сенсорных или когнитивных способностей. Это касается людей с:

• Нарушениями зрения: слепота, слабое зрение, цветовая слепота
• Нарушениями слуха: глухота, тугоухость
• Двигательными ограничениями: нарушенная мелкая моторика, параличи, тремор
• Когнитивными ограничениями: нарушения обучаемости, СДВГ, аутизм, деменция
• Временными ограничениями: сломанная рука, воспаление глаз, шумная обстановка
• Ситуативными ограничениями: солнечные блики на экране, управление одной рукой в транспорте

Эффект пандуса (Curb-Cut Effect)

В градостроительстве существует «эффект пандуса»: съезды с тротуаров были созданы для инвалидов-колясочников, но ими в равной мере пользуются родители с колясками, курьеры с тележками и велосипедисты. Точно то же происходит и в вебе: доступные сайты удобнее для ВСЕХ.

Чёткая иерархия заголовков помогает не только пользователям скринридеров, но и спешащим читателям. Хорошие контрасты облегчают чтение на солнце. Навигация с клавиатуры — это быстрее для продвинутых пользователей, чем мышь. Доступность — это не особый случай, а качественный веб-дизайн.

Законодательные требования: ЕС, Австрия и регион DACH

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

European Accessibility Act (EAA)

European Accessibility Act (Директива (ЕС) 2019/882) действует с 28 июня 2025 года во всех государствах — членах ЕС. Он обязывает компании, предлагающие цифровые продукты и услуги, обеспечивать доступность. Под действие попадают, в частности:

• Сайты электронной коммерции и интернет-магазины
• Банковские услуги и финансовые продукты
• Телекоммуникационные услуги
• Электронные книги и ридеры
• Услуги пассажирских перевозок
• Продукты с цифровым интерфейсом

Важно: EAA касается не только крупных концернов. Под регулирование попадают также МСБ с 10 и более сотрудниками или годовым оборотом от 2 миллионов евро. Микропредприятия освобождены, но всё равно должны относиться к доступности серьёзно.

Австрийское законодательство: Закон о веб-доступности (WZG)

В Австрии дополнительно действует Закон о веб-доступности (WZG), реализующий Директиву ЕС 2016/2102. Он обязывает все государственные учреждения обеспечивать доступность сайтов и приложений в соответствии с WCAG 2.1 Level AA. Это охватывает:

• Федеральные, земельные и муниципальные органы власти
• Государственные предприятия (например, OBB, Wiener Linien)
• Учреждения, финансируемые государственными органами
• Все сайты и мобильные приложения этих организаций

Санкции: Жалобы могут быть поданы в соответствующий орган по медиации. За нарушения грозят административные штрафы.

Германия: Закон об усилении доступности (BFSG)

Немецкий BFSG реализует EAA и действует с 28 июня 2025 года. Он впервые распространяет обязанность обеспечения доступности на частный сектор. Особенно актуально для австрийских компаний, продающих также в Германии: интернет-магазины и цифровые услуги должны соответствовать WCAG 2.1 Level AA.

Последствия несоблюдения

• Предупреждения: Организации по защите прав потребителей и пострадавшие могут подать иск
• Штрафы: До 100 000 евро в Германии, аналогичные суммы в Австрии
• Репутационный ущерб: Публичная критика со стороны организаций инвалидов и СМИ
• Конкурентный недостаток: Государственные заказчики всё чаще требуют сертификаты доступности
• Потеря выручки: Исключение 15–20% населения с инвалидностью из числа потенциальных клиентов

WCAG 2.2: Действующий стандарт

Web Content Accessibility Guidelines (WCAG) — это международно признанный стандарт доступных сайтов, разработанный World Wide Web Consortium (W3C). Актуальная версия WCAG 2.2 была опубликована в октябре 2023 года и содержит 9 новых критериев успеха.

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

Level A (Минимум): Базовая доступность. Если эти критерии не выполнены, определённые группы пользователей полностью лишены доступа. Примеры: альтернативные тексты для изображений, доступность с клавиатуры, информация не только через цвет.

Level AA (Рекомендуемый и юридически требуемый): Стандарт, который требуют законы WZG и EAA. Включает Level A плюс дополнительные требования: достаточные контрасты (4,5:1), масштабирование текста до 200% и единообразная навигация.

Level AAA (Оптимальный): Наивысший стандарт. На практике полное соответствие AAA для целых сайтов едва достижимо, но отдельные критерии следует реализовывать по возможности. Примеры: контраст 7:1, видео на жестовом языке, расширенные аудиоописания.

Новые критерии в WCAG 2.2

WCAG 2.2 содержит важные дополнения:

• 2.4.11 Focus Not Obscured (Minimum): Индикатор фокуса элемента не должен быть полностью перекрыт (например, фиксированным заголовком).
• 2.4.12 Focus Not Obscured (Enhanced): Индикатор фокуса вообще не должен быть перекрыт.
• 2.4.13 Focus Appearance: Индикатор фокуса должен иметь определённый минимальный размер и контраст.
• 2.5.7 Dragging Movements: Функции, требующие перетаскивания, должны быть доступны и без него.
• 2.5.8 Target Size (Minimum): Интерактивные элементы должны быть не менее 24x24 CSS-пикселей.
• 3.2.6 Consistent Help: Механизмы помощи должны быть размещены единообразно.
• 3.3.7 Redundant Entry: Уже введённая информация не должна запрашиваться повторно.
• 3.3.8 Accessible Authentication (Minimum): Аутентификация не должна требовать когнитивных функциональных тестов.
• 3.3.9 Accessible Authentication (Enhanced): Расширенные требования к доступной аутентификации.

4 принципа POUR доступности

WCAG основан на четырёх фундаментальных принципах, известных как POUR. Каждый критерий успеха относится к одному из этих принципов.

1. Perceivable (Воспринимаемость)

Информация и компоненты пользовательского интерфейса должны быть представлены так, чтобы все пользователи могли их воспринять. Слепой пользователь не может видеть изображения — значит, ему нужны альтернативные тексты. Глухой пользователь не может слышать аудио — значит, ему нужны субтитры.

Основные требования:

• Альтернативные тексты для всего нетекстового контента (изображения, иконки, графики)
• Субтитры и транскрипции для аудио- и видеоконтента
• Контент представим различными способами (например, без потери информации при увеличении)
• Достаточные контрасты между текстом и фоном
• Не использовать текст в виде изображения (за исключением логотипов)

2. Operable (Управляемость)

Все элементы навигации и интерактивные возможности должны быть доступны всем пользователям. Тот, кто не может использовать мышь, должен иметь возможность полностью управлять сайтом с клавиатуры. Тот, кому нужно больше времени, не должен быть заблокирован таймерами.

Основные требования:

• Полная доступность с клавиатуры (Tab, Enter, Escape, стрелки)
• Отсутствие ловушек для клавиатуры (пользователь не должен «застревать» в элементе)
• Достаточное время для взаимодействий (таймеры с паузой или продлением)
• Отсутствие контента, вызывающего судороги (без мерцающих эффектов свыше 3 Гц)
• Чёткая, единообразная навигация и ориентация
• Видимый индикатор фокуса при навигации с клавиатуры

3. Understandable (Понятность)

Информация и управление интерфейсом должны быть понятны. Язык должен быть ясным, навигация предсказуемой, а ошибки — предотвращены или понятно объяснены.

Основные требования:

• Язык страницы определён в HTML (lang="de")
• Иноязычные фрагменты размечены
• Навигация единообразна на всех страницах
• Поля форм подписаны, сообщения об ошибках понятны
• Помощь и предотвращение ошибок при вводе данных

4. Robust (Надёжность)

Контент должен быть достаточно надёжным для корректной интерпретации различными пользовательскими агентами (браузерами, скринридерами, альтернативными устройствами ввода).

Основные требования:

• Валидный HTML (корректная вложенность, уникальные ID)
• ARIA-роли и атрибуты корректно использованы
• Статусные сообщения программно доступны
• Совместимость с актуальными и будущими технологиями

Практическая реализация: Пошаговое руководство

Теория важна, но решает практика. В этом разделе мы покажем конкретно, как реализовать основные требования доступности. Доступный сайт начинается с UX-дизайна и продолжается в разработке.

Контрасты и цвета

Самая частая ошибка доступности: недостаточные контрасты. По данным исследования WebAIM, 83% всех сайтов имеют проблемы с контрастом. Требования WCAG:

Инструменты проверки контрастов:

• WebAIM Contrast Checker (онлайн)
• Colour Contrast Analyser (десктоп-приложение)
• Chrome DevTools (Accessibility Inspector)

Практические советы:

• Никогда не используйте цвет как единственный признак различия (например, красные сообщения об ошибках дополнительно помечайте иконкой или текстом)
• Текст-заполнитель в формах часто имеет слишком низкий контраст — используйте видимые подписи
• Предлагайте тёмный режим, но также следите за контрастами
• Ссылки в тексте обозначайте не только цветом, но и подчёркиванием

Альтернативные тексты для изображений

Каждому изображению нужен alt-текст, но не каждый alt-текст должен быть описательным:

Информативные изображения: Alt-текст описывает содержание и назначение. «Диаграмма показывает рост выручки на 35% в Q3 2025» вместо «Диаграмма» или «chart.png».

Декоративные изображения: Пустой alt-текст (alt=""), чтобы скринридер пропускал изображение. Применяется к фоновым паттернам, разделителям, чисто декоративным элементам.

Функциональные изображения (ссылки, кнопки): Alt-текст описывает функцию, а не изображение. «На главную» вместо «Логотип» для логотипа-ссылки.

Сложные изображения (диаграммы, инфографика): Краткий alt-текст плюс подробное описание в окружающем тексте или через aria-describedby.

SVG-иконки: Используйте aria-label или title внутри SVG-элемента. Декоративные иконки скрывайте с помощью aria-hidden="true".

Доступность с клавиатуры

Многие пользователи не могут использовать мышь и навигируют исключительно с клавиатуры. Протестируйте свой сайт, отложив мышь и используя только клавиатуру:

Базовое управление с клавиатуры:

• Tab: Переход к следующему интерактивному элементу
• Shift+Tab: К предыдущему элементу
• Enter: Активация ссылки или кнопки
• Пробел: Переключение чекбокса, активация кнопки
• Стрелки: Навигация внутри меню, вкладок, радиокнопок
• Escape: Закрытие модала/выпадающего списка

Управление фокусом:

• Каждый интерактивный элемент должен иметь видимый индикатор фокуса
• Порядок табуляции должен быть логичным (следует DOM, а не визуальной раскладке)
• В модальных окнах фокус должен быть ограничен модалом (Focus Trap)
• После закрытия модала фокус должен вернуться к элементу, вызвавшему его

Частые проблемы:

• Кастомные выпадающие списки без управления с клавиатуры
• Слайдеры/карусели, недоступные стрелками
• Гамбургер-меню, которое невозможно открыть с клавиатуры
• Фокус перескакивает в начало страницы после закрытия модала
• Удалён outline (outline: none) без альтернативы

Правильное использование ARIA

ARIA (Accessible Rich Internet Applications) расширяет HTML атрибутами, улучшающими доступность динамического контента. Но внимание: неправильно применённый ARIA вредит больше, чем помогает.

Первое правило ARIA: Не используйте ARIA, если нативный HTML-элемент выполняет ту же функцию. Элементу button не нужен role="button". Элементу nav не нужен role="navigation".

Важные ARIA-атрибуты:

• aria-label: Подпись для элементов без видимого текста (например, кнопки-иконки)
• aria-labelledby: Связывает элемент с другим элементом в качестве подписи
• aria-describedby: Дополнительное описание (например, подсказки к полям формы)
• aria-hidden="true": Скрывает декоративные элементы от скринридеров
• aria-expanded: Указывает, открыт или закрыт раскрывающийся элемент
• aria-live: Определяет «живые» регионы, объявляемые при изменении
• role: Определяет роль элемента (например, role="alert", role="tabpanel")

Пример — доступный аккордеон:

<h3>
  <button aria-expanded="false" aria-controls="section1">
    Раздел 1
  </button>
</h3>
<div id="section1" role="region" hidden>
  <p>Содержание раздела 1</p>
</div>

Доступное оформление форм

Формы часто являются главным препятствием для пользователей с ограниченными возможностями. Доступные формы требуют:

Подписи (Labels): Каждое поле ввода должно иметь видимую, программно связанную подпись (label for="id"). Текст-заполнитель (placeholder) НЕ является заменой подписей.

Сообщения об ошибках: Ошибки должны быть чётко описаны (не просто «Ошибка в поле 3», а «Пожалуйста, введите корректный адрес электронной почты»). Сообщения об ошибках должны быть программно связаны с полем (aria-describedby).

Группы: Связанные поля объединяйте с помощью fieldset и legend (например, поля адреса, радиокнопки).

Валидация: Клиентская валидация с aria-invalid и aria-describedby. Сводка ошибок в начале формы с ссылками на проблемные поля.

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

Адаптивный дизайн и доступность

Доступность и адаптивный дизайн отлично дополняют друг друга. Важные аспекты в контексте Core Web Vitals и производительности:

• Текст должен масштабироваться до 200% без горизонтальной прокрутки
• Области нажатия (touch targets) должны быть не менее 44x44 px (WCAG рекомендует 48x48 px)
• Соблюдайте расстояния между областями нажатия (мин. 8 px)
• Контент не должен обрезаться или накладываться при масштабировании и увеличении
• Поддерживайте медиа-запросы prefers-reduced-motion и prefers-color-scheme

Инструменты тестирования доступности

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

Автоматизированные инструменты тестирования

Ручное тестирование

Автоматизированные инструменты обнаруживают лишь около 30% проблем доступности. Следующие ручные тесты обязательны:

Тест клавиатурой: Пройдите весь сайт, используя только клавиатуру. Все ли функции доступны и управляемы? Всегда ли виден индикатор фокуса? Есть ли ловушки для клавиатуры?

Тест скринридером: Тестируйте с NVDA (Windows, бесплатно), VoiceOver (macOS/iOS, встроен) или JAWS (Windows, коммерческий). Весь ли контент зачитывается корректно? Описаны ли изображения? Работают ли формы?

Тест масштабированием: Увеличьте страницу до 200% и 400%. Всё ли читаемо? Накладываются ли элементы? Пропадает ли контент?

Когнитивные тесты: Понятен ли язык? Ясны ли инструкции? Легко ли исправить ошибки? Единообразна ли навигация?

Тестирование с участием людей с инвалидностью

Самый показательный метод тестирования: пригласите людей с различными формами инвалидности протестировать ваш сайт. Организации, такие как MAIN (Medienarbeit Integrativ) в Австрии, предоставляют тестировщиков с инвалидностью. Такие тесты выявляют проблемы, которые не найдёт ни один автоматический инструмент и ни один разработчик без инвалидности.

Доступность и SEO: Идеальная синергия

Доступность и поисковая оптимизация — естественные союзники. Многие меры по обеспечению доступности одновременно улучшают позиции в Google. Почему? Потому что боты поисковых систем «читают» сайты аналогично скринридерам — они не могут видеть изображения, смотреть видео и интерпретировать JavaScript (или делают это ограниченно).

Пересечения доступности и SEO

Конкретные преимущества

Более низкий показатель отказов: Доступные сайты более удобны в использовании. Пользователи быстрее находят нужное и остаются дольше. Google расценивает это как положительный пользовательский сигнал.

Более широкая аудитория: 15–20% населения имеют инвалидность. Доступный сайт обращается к этой аудитории и генерирует больше трафика, конверсий и выручки.

Лучшее техническое качество: Валидный HTML, корректная иерархия заголовков и семантическая разметка важны как для доступности, так и для SEO.

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

Частые ошибки при реализации

По нашему опыту в GoldenWing, мы постоянно встречаем эти ошибки — даже на сайтах, которые должны быть «доступными»:

Топ-10 ошибок доступности

1. Отсутствие или бессмысленные alt-тексты: «Bild1.jpg» или «DSC_4023» — это не alt-тексты. Равно бесполезны alt-тексты, которые лишь повторяют ключевое слово, не описывая изображение.

2. Недостаточные контрасты: Особенно в современном минималистичном дизайне со светло-серыми тонами на белом фоне. Дизайн и доступность не противоречат друг другу — они лишь требуют осознанного дизайна.

3. Отсутствие доступности с клавиатуры: Кастомные компоненты (выпадающие меню, вкладки, модалы) без управления с клавиатуры. Особенно часто при использовании JavaScript-фреймворков, заменяющих нативные HTML-элементы на div и span.

4. Удалённый outline: CSS outline: none для :focus без альтернативы. Индикатор фокуса критически важен для пользователей клавиатуры. Никогда не удаляйте его без равноценной замены.

5. Автовоспроизведение медиа: Видео и аудио, запускающиеся автоматически, не только раздражают, но и особенно проблематичны для пользователей скринридеров.

6. Недоступные PDF: Сайт может быть идеально доступен — но если связанные PDF-документы таковыми не являются, остаётся существенный барьер.

7. CAPTCHA без альтернативы: Традиционные CAPTCHA недоступны для многих пользователей. Используйте доступные альтернативы, такие как hCaptcha Accessibility или невидимые CAPTCHA.

8. Динамический контент без ARIA-live-регионов: Обновления корзины, сообщения об ошибках и индикаторы загрузки не объявляются скринридерами, если отсутствует aria-live.

9. Отсутствие Skip-ссылок: Пользователи клавиатуры вынуждены на каждой странице проходить через всю навигацию табуляцией, прежде чем добраться до основного контента. Ссылка «Перейти к основному содержанию» решает эту проблему.

10. Язык не определён: Атрибут lang в HTML отсутствует, из-за чего скринридеры используют неправильное произношение.

Затраты и трудоёмкость

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

Новый сайт с учётом доступности

Дополнительные затраты по сравнению с недоступным сайтом: 10–20%. Основные трудозатраты — в планировании, семантической разработке и тестировании. Если доступность учитывается с самого начала, дополнительные усилия вполне управляемы.

Доработка существующего сайта

Стоимость: 20–50% от первоначальных затрат на разработку. Доработка всегда дороже новой разработки, так как требуется переписать существующий код, адаптировать дизайн и переработать контент. Аудит доступности определяет наиболее критичные барьеры как отправную точку.

Текущие расходы

• Регулярные аудиты: 1–2 раза в год, 1 500–5 000 евро
• Создание контента: Alt-тексты, субтитры, доступные PDF — постоянная работа
• Обучение: Обучение сотрудников в редакции, дизайне и разработке
• Инструменты мониторинга: 100–500 евро/мес для автоматического наблюдения

ROI доступности

Инвестиция в доступность окупается:

• 15–20% большая аудитория (люди с инвалидностью)
• Лучшие позиции в SEO (см. синергии выше)
• Более низкий показатель отказов (лучший пользовательский опыт)
• Юридическая безопасность (предотвращение штрафов и предупреждений)
• Позитивный имидж бренда (социальная ответственность)

Чек-лист: Доступный сайт

Этот чек-лист обобщает основные пункты:

Воспринимаемость:

• Все изображения имеют описательные alt-тексты
• Видео имеют субтитры и/или транскрипции
• Контрасты соответствуют WCAG AA (4,5:1 для обычного текста)
• Цвет никогда не является единственным отличительным признаком
• Текст масштабируется до 200%

Управляемость:

• Все функции доступны с клавиатуры
• Индикаторы фокуса видимы
• Skip-ссылки присутствуют
• Отсутствуют ловушки для клавиатуры
• Временные ограничения настраиваемы

Понятность:

• Язык страницы определён (lang="de")
• Навигация единообразна
• Формы имеют видимые подписи и понятные сообщения об ошибках
• Контент написан ясно и понятно

Надёжность:

• HTML валиден
• ARIA корректно применён
• Сайт работает с актуальными скринридерами
• Динамический контент использует aria-live

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

Часто задаваемые вопросы (FAQ)

Обязан ли мой сайт быть доступным?

С июня 2025 года European Accessibility Act (EAA) обязывает многие частные компании обеспечивать доступность своих цифровых продуктов. Особенно это касается электронной коммерции, финансовых услуг и телекоммуникаций — исключены лишь микропредприятия с менее чем 10 сотрудниками И менее 2 миллионов евро годового оборота. Государственные учреждения в Австрии обязаны с момента принятия WZG. Даже если юридически вы не обязаны, доступность окупается экономически и этически.

Сколько стоит аудит доступности?

Профессиональный аудит WCAG 2.2 стоит от 1 500 до 8 000 евро в зависимости от объёма сайта. Базовый аудит для корпоративного сайта с 10–30 страницами обычно составляет 2 000–3 500 евро и включает автоматические тесты, ручную проверку и детальный каталог мер с приоритизацией. В GoldenWing мы предлагаем аудиты от 2 500 евро.

Достаточно ли автоматизированного инструмента тестирования для доступности?

Нет, автоматизированные инструменты, такие как axe или WAVE, обнаруживают лишь около 30% проблем доступности. Они находят отсутствующие alt-тексты или ошибки контрастов, но не могут оценить, осмыслен ли alt-текст, логичен ли порядок табуляции или понятен ли контекст пользователю скринридера. Автоматические тесты — важная отправная точка, но ручное тестирование и в идеале тестирование с участием людей с инвалидностью незаменимы.

Доступность — это разовый проект или непрерывный процесс?

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

Вредит ли доступность дизайну?

Распространённый миф. Доступность и привлекательный дизайн не исключают друг друга — наоборот. Многие самые успешные сайты (Apple, BBC, GOV.UK) являются образцами доступного И эстетичного дизайна. Ключ — в осознанном дизайне: достаточные контрасты, ясная типографика и продуманные паттерны взаимодействия улучшают дизайн для всех пользователей, а не только для людей с инвалидностью.

Сколько времени нужно, чтобы сделать существующий сайт доступным?

Зависит от исходного состояния и сложности. Для типичного корпоративного сайта с 20–50 страницами закладывайте 4–8 недель на аудит плюс реализацию критических мер. Полное соответствие WCAG AA для сложных сайтов с множеством интерактивных элементов может занять 2–4 месяца. Мы рекомендуем поэтапный подход: сначала устранить критические барьеры (Level A), затем постепенно расширять до Level AA.

Правильное использование ARIA-атрибутов: Практическое руководство

ARIA (Accessible Rich Internet Applications) — мощный инструмент для обеспечения доступности веб-приложений для скринридеров и других вспомогательных технологий. Однако ARIA часто применяется неправильно, что скорее ухудшает доступность, чем улучшает.

Золотое правило: Отсутствие ARIA лучше, чем неправильный ARIA

Перед использованием ARIA-атрибутов всегда проверяйте, выполняет ли нативный HTML-элемент ту же функцию. `<button>` всегда лучше, чем `<div role="button">`. Нативные элементы автоматически обеспечивают доступность с клавиатуры, управление фокусом и поддержку скринридеров.

Важнейшие ARIA-роли для современных сайтов

Landmark-роли структурируют страницу для пользователей скринридеров:

• `role="banner"` — соответствует `<header>`, шапка страницы
• `role="navigation"` — соответствует `<nav>`, области навигации
• `role="main"` — соответствует `<main>`, основной контент
• `role="contentinfo"` — соответствует `<footer>`, подвал страницы
• `role="complementary"` — соответствует `<aside>`, дополнительный контент

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

ARIA-состояния и свойства на практике

aria-expanded: Для раскрывающихся меню, аккордеонов и выпадающих списков:

• Устанавливайте `aria-expanded="false"` в закрытом состоянии
• Изменяйте на `aria-expanded="true"` при открытии
• Связывайте управляющий элемент с управляемой областью через `aria-controls`

aria-live: Для динамических изменений контента (уведомления, статусные сообщения):

• `aria-live="polite"` — изменение объявляется, когда пользователь неактивен (стандарт для большинства случаев)
• `aria-live="assertive"` — изменение объявляется немедленно (только для критических сообщений, таких как ошибки)

aria-label и aria-labelledby: Для элементов без видимого текста:

• `aria-label="Закрыть главную навигацию"` для кнопок-иконок
• `aria-labelledby="section-heading"` для связи элемента с видимым заголовком

Частые ошибки ARIA и их исправление

• Избыточные роли: `<nav role="navigation">` — двойное указание. Используйте просто `<nav>`
• Отсутствие доступности с клавиатуры: `role="button"` на `<div>` не делает его автоматически управляемым с клавиатуры. Нужно добавить `tabindex="0"` и обработчики событий клавиатуры
• aria-hidden="true" на видимом контенте: Скрывает содержимое от скринридеров, хотя оно видимо
• Отсутствие live-регионов: Динамические сообщения об ошибках в формах без `aria-live` не распознаются скринридерами

Workflow тестирования ARIA-реализаций

1. Автоматическое тестирование: axe DevTools или Lighthouse выявляют базовые ошибки ARIA
2. Тест скринридером: Тестируйте с NVDA (Windows, бесплатно) или VoiceOver (macOS, предустановлен)
3. Навигация с клавиатуры: Проверьте каждую интерактивную область только с клавиатуры
4. DevTools браузера: Панели доступности в Chrome и Firefox показывают вычисленное ARIA-дерево

Доступные формы и интерактивные элементы

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

Основные правила доступных форм

Корректная связь подписей и полей ввода:

Каждое поле ввода должно иметь однозначно связанную подпись (label). Связь осуществляется через атрибут `for` у label и соответствующий `id` у поля ввода. Текст-заполнитель (placeholder) не является заменой подписи — он исчезает при вводе и не обеспечивает надёжной маркировки.

Доступное оформление сообщений об ошибках:

• Сообщения об ошибках должны быть программно связаны с ошибочным полем (через `aria-describedby`)
• Используйте `aria-invalid="true"` для ошибочных полей
• Размещайте сообщения об ошибках перед или рядом с полем, а не только в начале формы
• Устанавливайте фокус на первое сообщение об ошибке после отправки

Логическая структура групп полей:

• Используйте `<fieldset>` и `<legend>` для связанных полей (например, данные адреса, платёжные данные)
• Радиокнопки и чекбоксы всегда должны быть в группе полей

Доступные кастомные компоненты

Выпадающие меню / альтернативы Select:

• По возможности используйте нативный элемент `<select>`
• Для кастомных выпадающих списков: реализуйте полную спецификацию WAI-ARIA Combobox
• Управление с клавиатуры: стрелки для навигации, Enter для выбора, Escape для закрытия

Выбор даты (Datepicker):

• Нативный `<input type="date">` — наиболее доступный вариант
• Кастомные datepicker должны быть полностью управляемы с клавиатуры
• Всегда предлагайте ручной ввод текста как альтернативу

Слайдеры / Range-поля:

• Используйте `<input type="range">` где возможно
• Для кастомных слайдеров: реализуйте `role="slider"`, `aria-valuemin`, `aria-valuemax`, `aria-valuenow` и `aria-valuetext`

Доступные многошаговые формы

Для длинных форм (например, процесс оформления заказа) действуют дополнительные требования:

• Индикатор прогресса: Используйте `aria-current="step"` для текущего шага
• Навигация по шагам: Обеспечьте возврат к предыдущим шагам с клавиатуры
• Сохранение ввода: Уже заполненные поля должны сохраняться при возврате назад
• Резюме: Предоставьте доступную сводку всех данных перед финальной отправкой

Доступность для E-Commerce: Как сделать интернет-магазины доступными

С 28 июня 2025 года вступает в силу Закон об усилении доступности (BaFG) в Австрии, реализующий Директиву ЕС European Accessibility Act (EAA). Интернет-магазины попадают под его действие напрямую.

Законодательные требования для австрийских интернет-магазинов

BaFG действует для всех предприятий, кроме микропредприятий (менее 10 сотрудников и менее 2 млн евро годового оборота). Затронутые интернет-магазины должны:

• Соблюдать уровень соответствия WCAG 2.1 AA
• Опубликовать заявление о доступности
• Предоставить механизм обратной связи по проблемам доступности
• За нарушения грозят административные штрафы до 80 000 евро

Критические области в E-Commerce

Страницы товаров:

• Все изображения товаров должны иметь содержательные alt-тексты (не просто «Изображение товара», а «Синяя мужская рубашка-поло, размер M, из органического хлопка»)
• Селекторы размеров и цветов должны быть управляемы с клавиатуры
• Информация о ценах не должна передаваться только визуально (например, зачёркнутая цена)

Корзина и оформление заказа:

• Изменение количества и функции удаления должны быть доступны с клавиатуры и для скринридеров
• Статусные сообщения («Товар добавлен в корзину») реализуйте как `aria-live`-регионы
• Платёжные формы должны быть полностью доступными — включая поля ввода кредитной карты

Фильтрация:

• Фасетные фильтры должны быть управляемы с клавиатуры
• Изменения фильтров должны динамически объявляться (`aria-live`)
• Количество результатов после фильтрации должно быть озвучено

Поиск:

• Подсказки автозаполнения должны быть навигируемы с клавиатуры
• Результаты поиска должны объявляться как live-регион
• Сообщения «Ничего не найдено» должны распознаваться скринридерами

Аудит доступности для существующих магазинов

Проведите структурированный аудит в четыре фазы:

1. Автоматическое сканирование: Инструменты axe, WAVE или Lighthouse выявляют примерно 30–40% проблем доступности
2. Ручное тестирование: Навигация с клавиатуры по всем критическим пользовательским сценариям (поиск, выбор товара, корзина, оформление заказа)
3. Тестирование вспомогательных технологий: Тесты скринридером с NVDA/VoiceOver и программами увеличения
4. Пользовательское тестирование: Тесты с участием людей с инвалидностью — минимум 3–5 человек с различными видами инвалидности

ROI доступных интернет-магазинов

Доступность — не только юридическая обязанность, но и экономически целесообразна:

• 15–20% населения имеют ту или иную форму инвалидности — это значительная группа клиентов
• Доступные магазины в среднем показывают на 12% более высокие коэффициенты конверсии (лучшая юзабилити для всех)
• Преимущества SEO: Доступные сайты, как правило, ранжируются лучше (чистая разметка, alt-тексты, семантический HTML)
• Сниженный правовой риск: Избежание штрафов и административных санкций

Создание и поддержка заявления о доступности

Заявление о доступности (Accessibility Statement) с июня 2025 года обязательно для большинства австрийских сайтов и интернет-магазинов. Оно документирует текущий статус доступности и показывает пользователям, что вы серьёзно относитесь к этой теме.

Правовая основа и требования

Закон об усилении доступности (BaFG) и Закон о веб-доступности (WZG) в Австрии обязывают компании к публикации заявления о доступности. Оно должно:

• Быть найдено на каждом сайте (в идеале ссылка в подвале)
• Быть написано простым языком
• Регулярно обновляться (минимум ежегодно)
• Содержать контактную информацию для обратной связи

Обязательное содержание заявления о доступности

1. Область применения:

Опишите, для какого сайта (сайтов) или приложения (приложений) действует заявление. Укажите точные URL-адреса.

2. Статус соответствия:

Выберите одну из следующих формулировок:

• «Полностью соответствует» — все критерии WCAG 2.1 AA выполнены
• «Частично соответствует» — большинство, но не все критерии выполнены
• «Не соответствует» — существенные критерии не выполнены

На практике большинство сайтов «частично соответствуют». Будьте здесь честны — прозрачное заявление лучше ложного.

3. Известные ограничения:

Конкретно перечислите, какие области не полностью доступны:

• «Видео в настоящее время не содержат субтитров (исправление планируется до Q3 2026)»
• «Выбор даты в функции бронирования не полностью управляем с клавиатуры»
• «PDF-документы, созданные до 2024 года, не подготовлены для доступности»

4. Механизм обратной связи:

Предоставьте чёткий канал связи:

• Выделенный адрес электронной почты (например, barrierefreiheit@firma.at)
• Контактная форма (которая сама должна быть доступной)
• Телефонный номер как альтернатива

5. Процедура обжалования:

Укажите ответственный орган в Австрии: Австрийское общество содействия исследованиям (FFG) как орган рассмотрения жалоб по цифровой доступности.

Шаблон заявления о доступности

Используйте генератор Европейской комиссии как отправную точку и адаптируйте его к вашей ситуации. W3C также предоставляет подробный шаблон на сайте WAI.

Поддержка и обновление

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

Лучшие практики из региона DACH

Образцовые заявления о доступности можно найти на:

• oesterreich.gv.at: Очень детальное, с конкретными мерами и сроками
• Deutsche Bahn (bahn.de): Прозрачная коммуникация известных ограничений
• Wiener Linien (wienerlinien.at): Чёткая структура с контактными данными

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

Доступность при редизайне: Доработка существующих сайтов

Многие австрийские компании стоят перед задачей сделать существующий сайт доступным, не начиная весь проект с нуля. С вступлением в силу Закона об усилении доступности (BaFG) в июне 2025 года доработка для многих предприятий — уже не вопрос выбора, а юридическая обязанность. Хорошая новость: системный подход делает доработку планируемой и экономически реализуемой.

Инвентаризация: Где сейчас находится ваш сайт?

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

• Автоматические сканирования инструментами axe DevTools, WAVE или Lighthouse выявляют примерно 30–40 процентов всех барьеров — прежде всего отсутствующие alt-тексты, недостаточные контрасты и ошибочные ARIA-атрибуты
• Ручная навигация с клавиатуры: пройдите весь сайт исключительно с клавиатуры. Можете ли вы достичь каждого интерактивного элемента? Всегда ли виден фокус?
• Тесты скринридером: прослушайте ваши страницы с VoiceOver (macOS/iOS) или NVDA (Windows). Логичен ли порядок озвучивания? Корректно ли описаны изображения и формы?
• Аудит контента: проверьте тексты на понятность, структуру заголовков и корректную разметку языка

Документируйте каждый обнаруженный барьер в структурированном списке с степенью серьёзности (критическая, серьёзная, умеренная, незначительная), затронутым типом страницы и критерием успеха WCAG. Этот список станет вашей дорожной картой для доработки.

Приоритизация: Правильный порядок мер

Не все барьеры имеют одинаковую срочность. Приоритизируйте по принципу Impact-Effort:

Реализовать немедленно (Quick Wins с высоким Impact):

• Добавить отсутствующие alt-тексты для изображений — часто затрагивает сотни изображений, но реализуется относительно быстро
• Скорректировать контрасты — часто достаточно небольших изменений в CSS-файле
• Добавить отсутствующие подписи форм — технически просто, но критически важно для пользователей скринридеров
• Встроить Skip-навигацию — один компонент, помогающий всем пользователям клавиатуры

Среднесрочная реализация (умеренная сложность):

• Исправить иерархию заголовков — требует изменений в шаблонах и существующем контенте
• Корректно установить ARIA-landmarks и роли — требует технического понимания, значительно улучшает структуру
• Переработать управление фокусом при динамическом контенте (модалы, аккордеоны, вкладки) — необходимы доработки JavaScript
• Обеспечить адаптивное поведение при масштабировании до 200 процентов

Долгосрочное планирование (высокие трудозатраты):

• Полная переработка интерактивных компонентов: кастомные выпадающие списки, datepicker, карусели
• Оснащение видео- и аудиоконтента субтитрами и транскрипциями
• Подготовка PDF-документов для доступности или замена на HTML-альтернативы
• Обеспечение доступности сложных визуализаций данных

Техническая доработка: Пошаговый подход

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

Шапка и навигация: Навигация — наиболее используемый элемент сайта. Убедитесь, что меню управляемо с клавиатуры, подменю закрываются по Escape, а текущий раздел отмечен `aria-current="page"`. В мобильных гамбургер-меню фокус при открытии должен перемещаться в меню, а при закрытии — возвращаться к вызвавшему элементу.

Формы и страницы контактов: Каждое поле ввода нуждается в программно связанной подписи. Сообщения об ошибках должны быть видимы и для скринридеров — используйте `aria-describedby` для текстов ошибок и `aria-invalid="true"` для ошибочных полей. Обязательные поля обозначайте не только звёздочкой, но и `aria-required="true"`.

Области контента: Убедитесь, что все заголовки образуют логическую иерархию (H1 -> H2 -> H3, без пропусков). Списки используют корректные HTML-элементы (`ul`, `ol`, `dl`). Ссылки имеют содержательные подписи — «Подробнее» без контекста бесполезно для пользователей скринридеров.

Адаптация CMS для редакционной доступности

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

• Alt-текст как обязательное поле — загрузка изображения без альтернативного текста невозможна
• Шаблоны заголовков с предопределённой корректной иерархией
• Редакционное руководство с чёткими требованиями к подписям ссылок, оформлению таблиц и форматам документов
• Автоматические проверки в CMS, сообщающие о нарушениях контрастов или отсутствующих подписях перед публикацией

Реалистичное планирование затрат и сроков

Для типичного австрийского корпоративного сайта с 30–80 страницами рассчитывайте на следующие трудозатраты:

• Аудит и инвентаризация: 2–4 рабочих дня
• Реализация Quick Wins: 3–5 рабочих дней
• Компонентная доработка: 10–20 рабочих дней, в зависимости от сложности
• Доработка контента: 5–10 рабочих дней (сильно зависит от объёма)
• Тестирование и финальная доработка: 3–5 рабочих дней

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

Итог: Доступность — это не препятствие, а возможность

Доступность сайтов по WCAG 2.2 в 2026 году — уже не добровольная программа, а обязанность — юридическая, экономическая и этическая. Компании, которые инвестируют сейчас, выигрывают от расширенной аудитории, лучшего SEO, более низких показателей отказов и позитивного имиджа бренда. Затраты управляемы, возврат инвестиций измерим.

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