Веб-доступность

Веб-доступность

(accessibility, сокращённо a11y)

практика разработки веб-сайтов и приложений, доступных для всех пользователей, включая людей с ограниченными возможностями

Основные группы пользователей, которым нужна доступность

  • Люди с нарушениями зрения
    • Полная слепота (используют экранные дикторы, например, NVDA, VoiceOver)
    • Слабовидящие (используют увеличение экрана, контрастные темы)
    • Дальтоники (некоторые цвета могут быть неразличимы)
  • Люди с нарушениями слуха
    • Нуждаются в субтитрах или текстовых альтернативных описаниях аудиоконтента

Веб-доступность

(accessibility, сокращённо a11y)

практика разработки веб-сайтов и приложений, доступных для всех пользователей, включая людей с ограниченными возможностями

Основные группы пользователей, которым нужна доступность

  • Пользователи с двигательными ограничениями
    • Не могут использовать мышь, полагаются на клавиатуру, голосовые команды, специальные
  • Люди с когнитивными и неврологическими особенностями
    • Дислексия, расстройства аутистического спектра, синдром дефицита внимания
    • Важно избегать сложных навигационных структур, обеспечивать понятный интерфейс

Важность доступности

Этический аспект

каждый человек должен иметь равные возможности при использовании веба

Юридические требования

в разных странах действуют законы, предписывающие соблюдение доступности

  • WCAG (Web Content Accessibility Guidelines) – международный стандарт
  • ADA (Americans with Disabilities Act, США) – требует доступности цифровых продуктов
  • Section 508 (США) – обязательные стандарты для федеральных сайтов
  • EAA (European Accessibility Act, ЕС) – регулирует доступность сервисов в Европе

Важность доступности

Бизнес-преимущества

улучшенная доступность увеличивает аудиторию, улучшает SEO и снижает юридические риски

  • Шире аудитория – доступные сайты могут использовать больше людей
  • SEO-оптимизация – доступные сайты лучше индексируются поисковиками
  • Снижение юридических рисков – компании могут избежать судебных разбирательств

WAI-ARIA

Web Accessibility Initiative – Accessible Rich Internet Applications

набор атрибутов, разработанных для улучшения доступности сложных веб-приложений

  • Разрабатывается и поддерживается W3C в рамках инициативы Web Accessibility Initiative (WAI).
  • Делает сложные элементы (модальные окна, вкладки, меню, слайдеры) доступными для экранных дикторов и клавиатурной навигации.

Когда необходимо использовать WAI-ARIA

Когда семантического HTML недостаточно

Например, <div role="tablist"> может понадобиться в случаях, когда <button> и <nav> не решают задачу

Когда нужно описать состояние элемента

Например, aria-expanded="true" помогает экранным дикторам понять, открыт ли выпадающий список

Когда элемент динамически изменяет своё поведение

Например, aria-live используется для уведомлений, которые появляются без обновления страницы

Ограничения WAI-ARIA

ARIA не делает элементы интерактивными

например, <div role="button"> не обрабатывает нажатие Enter/Space, пока разработчик сам не добавит это через JavaScript


ARIA не заменяет семантический HTML

Использование <button> предпочтительнее, чем <div role="button">

Основные концепции WAI-ARIA

Роли

определяет, как элемент воспринимается вспомогательными технологиями, такими как экранные дикторы

Категории ролей

Лэндмарки

определяют основную структуру страницы

  • banner – верхний заголовок сайта
  • main – основной контент страницы
  • navigation – область навигации
  • complementary – дополнительный контент, связанный с основным

Категории ролей

Интерактивные элементы

создают доступные пользовательские интерфейсы

  • button – кнопка.
  • link – ссылка.
  • menu – меню навигации.
  • tab, tabpanel, tablist – вкладки.
  • progressbar, slider, tree – сложные виджеты
Структурные роли

группируют элементы

  • region – логически связанная область контента.
  • group – объединяет связанные элементы (например, радиокнопки)

Категории ролей

Состояния

описывают текущие характеристики элемента

  • aria-disabled="true" – элемент отключён
  • aria-expanded="true" – раскрыт ли элемент (например, выпадающее меню)
  • aria-hidden="true" – скрыт ли элемент для вспомогательных технологий
Свойства

предоставляют дополнительную информацию

  • aria-label="Описание" – описание элемента для экранного диктора
  • aria-labelledby="id" – связывает элемент с другим, который его описывает
  • aria-describedby="id" – предоставляет дополнительную информацию

Категории ролей

Живые регионы

автоматически сообщают пользователям о появлении нового контента

  • aria-live Определяет, как контент будет озвучиваться скринридером (polite, assertive)
  • aria-relevant Что именно изменяется (например, additions, removals)
  • aria-atomic Сообщать ли весь контент целиком

Использование WAI-ARIA

Семантический HTML всегда предпочтительнее

<div
    role="button"
    tabindex="0"
    onclick="alert('Clicked!')">
        Click me
</div>

< 


<button>Click me</button>

Доступная кнопка с ARIA


<button aria-pressed="false" onclick="toggleState(this)">Toggle</button>
<script>
  function toggleState(btn) {
    const pressed = btn.getAttribute("aria-pressed") === "true";
    btn.setAttribute("aria-pressed", !pressed);
  }
</script>

Доступные вкладки


<div role="tablist">
  <button role="tab" aria-selected="true">Tab 1</button>
  <button role="tab" aria-selected="false">Tab 2</button>
</div>

Доступное модальное окно


<div role="dialog" aria-labelledby="modal-title" aria-hidden="true">
  <h2 id="modal-title">Modal Window</h2>
  <p>Content here...</p>
</div>

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

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

  • Lighthouse (встроен в Chrome DevTools)
  • axe DevTools (расширение Chrome)
  • WAVE (онлайн-анализатор доступности)

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

  • Скринридеры:
    • Windows: NVDA, JAWS
    • Mac: VoiceOver
    • Chrome: ChromeVox
  • Тестирование клавиатурой:
    • Tab – переключение между элементами
    • Enter/Space – активация кнопок
    • Arrow keys – перемещение по сложным виджетам