Всем привет! В этой статье мы разберем одну из важнейших тем при разработке любого веб‑сайта — доступность.

Она позволяет сделать наш сайт или веб‑приложение доступным максимальному количеству пользователей. И под максимальным количеством имеются ввиду не только пользователи со слабыми устройствами или интернетом, для которых мы должны предоставить максимально оптимизированное решение, но и пользователи с ограниченными (постоянными или временными) возможностями: люди без слуха, зрения, без возможности использовать мышь или клавиатуру для взаимодействия с контентом веб‑сайта.

Для чего же нам нужно работать над доступностью? Ответ напрашивается сам собой — расширение аудитории и привлечение новых клиентов (если вы, например, оказываете услуги). По данным AccessiCart, при улучшенной доступности мы увеличиваем потенциальную аудиторию до 25%. (Ссылка на статью)

Помимо расширения аудитории, улучшение доступности положительно влияет на органический трафик (переходы на сайт из поисковых систем). Исследование, проведенное Semrush, показало, что 73,4% сайтов, внедривших решения по доступности, зафиксировали рост органического трафика, при этом 66,1% из них отметили увеличение трафика от 1% до 50%. (Ссылка на статью)

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

Семантическая разметка

Самое первое, что можно учесть при разработке — это семантика. Если коротко, то главная суть семантики в HTML — использование смысловых тегов по назначению.

Перед тем, как мы разберем основные семантические теги, посмотрим на то, как же семантика сказывается на доступности нашего сайта.

Важность семантики

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

Рассмотрим простой пример. У нас есть список дел, который оформлен двумя способами: семантически и с использованием div, не несущим в себе смысла.

<div>Задачи</div>
<div>
    <div>Помыть посуду</div>
    <div>Постирать белье</div>
    <div>Купить Lamborghini</div>
</div>

<h1>Задачи</h1>
<ol>
    <li>Помыть посуду</li>
    <li>Постирать белье</li>
    <li>Купить Lamborghini</li>
</ol>

Если сравнить 2 варианта, то семантический блок кода выглядит более читаемым и понятным, нежели список размеченный с помощью <div>.

Но теперь проверим, как скринридер прочитает оба эти списка и озвучит пользователю. Будем использовать скринридер NVDA — самый популярный бесплатный скринридер.

Первый вариант он прочитает примерно так:

Задачи
Помыть посуду
Постирать белье
Купить Lamborghini

И второй вариант:

Заголовок 1: Задачи
Список из 3 элементов
Помыть посуду
Постирать белье
Купить Lamborghini
Конец списка

Можем заметить, что второй вариант наполнен большим количеством информации: скринридер сообщает о заголовке, озвучивает количество пунктов в списке, завершает список.

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

Семантические теги

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

<header> — используется для шапки страницы или раздела. Обычно содержит логотип, навигацию и другие элементы (смена темы, поиск, вход в аккаунт и т. п.).

<nav> — задает область навигации по сайту. Внутри размещаются меню и ссылки на страницы или разделы сайта.

<footer> — нижняя часть страницы или раздела, также называется подвалом сайта. Обычно содержит контактную информацию, ссылки, копирайт.

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

<section> — логически отделённый блок контента, часто с заголовком. Используется для организации основного контента страницы.

Пример 2х секций со статьями и новостями. MDN

<article> — автономный, самодостаточный блок контента, например, пост, новость, статья. Можно использовать внутри section.

<aside> — дополнительная информация, не связанная напрямую с основным содержимым. Часто используется для боковых панелей.

Боковая панель для навигация по категориям. MDN

<h1>—<h6> — заголовки разного уровня. h1 — самый важный, далее по убыванию.

<a> — тег ссылки. Используется для перехода по другим страницам или разделам сайта.

<button> — интерактивная кнопка. Применяется для отправки форм или запуска действий на странице.

<ul>, <ol>, <dl> — теги для создания списков.

<p> — используется для абзацев текста. Основной тег для размещения текстовой информации.

Структура заголовков

Логическая иерархия заголовков сильно влияет на понимание структуры контента при чтении скринридерами.

Для создания структуры заголовков используются теги <h1> — <h6>.

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

Это изображение идеально подойдет для иллюстрации использования заголовков.

Название книги — самый главный и единственный заголовок такого типа. На веб‑странице мы же будем использовать тег <h1>, который будет озаглавливать всю страницу.
Вся книга состоит из частей, при этом каждая часть является заголовком одного уровня — так и на веб‑странице, для озаглавливания логических секций мы будем использовать тег <h2>.
Каждая часть состоит из глав — на веб‑странице мы можем представить список статей внутри определенной секции, и каждая статья будет иметь свой заголовок. Здесь будем использовать тег <h3>.

Остальные теги заголовков используются по тому же принципу, но чаще всего вложенность останавливается на <h3> — <h4>.

Также структура заголовков помогает продвижению сайта в органическом поиске (SEO). Поисковые роботы сканируют страницу и определяют ее содержимое именно по иерархии заголовков. Благодаря этому, наш сайт может появиться на первых строчках по запросу пользователя на эту тему.

Пример хорошей структуры заголовков представлен ниже:

<h1>Статьи о Frontend разработке</h1>

<section>
  <h2>HTML</h2>
  
  <article>
    <h3>Структура HTML</h3>
  </article>
  
  <article>
    <h3>Основные теги</h3>
  </article>
</section>

<section>
  <h2>CSS</h2>
  
  <article>
    <h3>Что такое селектор?</h3>
  </article>
  
  <article>
    <h3>Специфичность</h3>
  </article>
</section>

Клавиатурная навигация и фокус

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

Для самых базовых интерактивных элементов в HTML уже существуют специальные теги:

button — кнопка, служит для запуска скриптов JavaScript.
a — ссылка, нужна для перехода на другие страницы или разделы сайта.
input — поле для ввода информации.

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

Если вдруг возникнет случай, когда необходимо добавить возможность фокусирования на другие элементы, можно использовать универсальный атрибут tabindex="0".

<div tabindex="0">Интерактивный элемент</div>

Также стоит избегать очистки браузерных стилей фокуса на элементе, без предоставления альтернативного решения:

❌ Очистили браузерные стили

button:focus {
  outline: none;
}

✅ Убрали браузерные и подключили свои стили

button:focus {
  outline: none;
  background: green;
}

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

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

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

В верстке для этого используется атрибут alt:

<img src="image-1.png" alt="Мое замечательное изображение">

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

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

Название товара, как описание изображения

<img src="shoes.jpg" alt="Белые кроссовки Nike Air Max">

Название иконки

<img src="search-icon.svg" alt="Поиск">

Но иногда бывает необходимость не добавлять альтернативный текст, например для декоративных изображений. В таком случае можно оставить атрибут alt пустым и скрыть изображение от прочтения скринридером с помощью атрибута aria-hidden:

<img src="decorative.svg" alt="" aria-hidden="true">

Доступность в формах

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

Для каждого поля ввода необходимо предоставить подпись, которая нужна для скринридеров, для удобства выбора поля (особенно если это радио‑кнопка или чекбокс) и для визуального обозначения поля.

Для добавления подписи используется тег <label> и 2 способа связи подписи с полем для ввода:

Первый способ: помещаем input внутрь label

<label>
  <span>Ваше имя</span>
  <input type="text" name="name">
</label>

Второй способ: с помощью атрибутов id и for

<label for="name-input">Ваше имя</label>
<input type="text" name="name" id="name-input">

При ошибках в заполнении полей формы необходимо сообщать о них пользователю. Малое, что мы можем сделать — вывести ошибку на экран, но также мы можем добавить атрибуты, которые пойдут на пользу доступности:

role="alert" заставляет скринридер немедленно прочитать сообщение
aria-invalid="true" сообщает, что поле содержит ошибку

<label for="email">Email</label>
<input type="email" id="email" aria-describedby="email-error" aria-invalid="true">
<span id="email-error" role="alert">Введите корректный email</span>

ARIA-атрибуты: когда действительно нужны

Сами по себе ARIA‑атрибуты предназначены для улучшения доступности, но при работе с ними важно запомнить одно правило:

Никогда не используйте ARIA, если можно обойтись нативным HTML.
— WAI‑ARIA Authoring Practices

Посмотрим на простой пример, когда стоит использовать нативные элементы вместо ARIA‑атрибутов:

<div role="button" tabindex="0">
  Показать больше
</div>

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

<button type="button" disabled>Показать больше</button>

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

Часто используемые ARIA-атрибуты

ARIA‑атрибутов очень много, и наврятли Вы будете использовать полный их список. Давайте взглянем на 5 самых часто используемых ARIA‑атрибутов

aria-label — Альтернативная подпись, когда текста нет (например в кнопке используем декоративное изображение).
<button aria-label="Закрыть окно">✖</button>
aria-hidden="true" — Скрыть элемент от прочтения скринридером.
aria-expanded — Сообщает, раскрыт или скрыт элемент, например — выпадающее меню. Скринридер озвучит состояние как «раскрыто» или «свернуто».
aria-live — Определяет, как часто скринридер будет озвучивать обновления в элементе. Часто используется для уведомлений и сообщений. Имеет три значения: "polite" — зачитает, когда пользователь закончит текущее действие. "assertive" — зачитает сразу.
"off" — ничего не зачитывает.
aria-checked‑Применяется к кастомным чекбоксам или переключателям, чтобы указать, отмечено ли значение.
aria-current — Показывает, что элемент — текущий выбранный пункт (например, активная вкладка или страница).
Значения: "page", "step", "location", "date", "true".

Мобильная и сенсорная доступность

Все больше и больше пользователей посещает сайты, используя мобильные устройства. Их количество составляет целых 63% по данным StatCounter. Поэтому мы обязательно должны принять во внимание доступность на мобильных устройствах.

Размер интерактивных элементов

Минимальный размер интерактивной области — 44×44 пикселя. Это официальная рекомендация WCAG. При создании мобильного дизайна стоит опираться на это значение.

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

Удобное расположение элементов

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

Основные действия лучше размещать внизу экрана — так легче дотянуться большим пальцем.
Соблюдайте отступы между кликабельными элементами для избежания случайных нажатий.
Не полагайтесь на hover‑состояния — на мобильных устройствах их нет.
Добавляйте визуальную обратную связь при нажатии на интерактивные элементы.

И, конечно, это может прозвучать очевидным, но также важно адаптировать страницы под разные разрешения с помощью медиа‑запросов, а не сохранять десктопную верстку на всех разрешениях (наверняка вы встречали такие сайты, которые вызывают раздражение и содержат слишком мелкий текст).

Производительность

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

Почему это так важно:

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

Теперь рассмотрим способы улучшения производительности сайта.

Оптимизация ресурсов

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

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

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

<img src="image.png" alt="" loading="lazy">

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

Основные инструменты для проверки сайта на доступность

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

Для проверки верстки на валидность можно использовать ресурс — W3C. Кроме валидации верстки, он показывает структуру заголовков.
LightHouse — встроенный в Chrome инструмент. Позволяет полностью проанализировать производительность сайта и доступность. Доступен из DevTools.
NVDA — бесплатный скринридер. Можно воспользоваться для проверки доступности сайта без его визуального представления.

Итог

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

Буду очень рад, если статья оказалось полезной для Вас, и Вы смогли узнать для себя что‑то новое. Если хотите узнавать больше о Frontend‑разработке, можете присоединиться к моей группе ВК, где публикуются другие обучающие материалы и видео‑уроки — https://vk.com/sanwed.

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

Доступная вёрстка: как сделать сайт удобным для всех пользователей