I Love Frontend

Это перевод статьи Web Accessibility — Developing web with empathy автора Param Singh.

От переводчика
Эта статья начинает серию переводов интересных мне статей на тему web и frontend. Надеюсь, такая практика подтянет мой английский и принесет что-то полезное

Даже имея за плечами многолетний опыт разработки, мы забываем одну действительно важную вещь под названием Web Accessibility (Доступность в WEB).

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

Давайте спросим WIKI

Accessibility or A11y refers to the design of products, devices, services, or environments for people who experience disabilities.

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

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

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

WCAG: The Web Content Accessibility Guidelines (руководство по доступности веб-контента) является частью основных принципов доступности веб-сайтов, опубликованых Web Accessibility Initiative(WAI) и консорциумом W3C.

WAI-ARIA: Web Accessibility Initiative — Accessible Rich Internet Applications – это техническая спецификация, опубликованая W3C, которая определяет то, как повысить досутпность веб-страниц, в том числе страниц с динамическим контентом и UI компонентами разработанными с использованием AJAX.

Почему это должно меня волновать?

Мы, разработчики, привыкли работать по принципу БРП (Быстрая Разработка Приложений). Мы постоянно спешим закончить свой проект в установленные сроки дедлайнов и используем для этого ванильные фреймворки и инструменты. И в этой беготне мы забываем об идеях ARIA (Доступные Насыщенные Интернет Приложения) и думаем, что нашим веб-сайтом будут пользоваться такие же люди, как и мы. Эта мысль очень опасная как для вас, так и для ваших пользователей. На самом деле, большинство Frontend разработчиков, которых я знаю и с которыми общался, даже не знают что такое ARIA и вообще доступность, потому что у них нет повода задуматься над этим. Мы рассматриваем это как “допольнительный” функционал для наших приложений. Я тоже привык думать так же еще с тех пор, как начал использовать bootstrap в те старые добрые времена. Я видел эти бесполезные aria-* и role аттрибуты и, если честно, удалял их из своей разметки. Но теперь, узнав их значение, я понимаю всю важность их использования.

Понимайте ваших пользователей

Одним из важных шагов при создании ARIA приложений является понимание разнообразия ваших пользователей. Есть люди, которые ограничены в своих возможностях из-за различных проблем с визуальным восприятием, моторикой, слухом, речью или восприятием информации. Из-за этого их способы взаимодействия с вашим приложением отличаются. Многие из них для работы с вашим приложением используют голосовое чтение с экрана, устройства Брайля или отслеживание направления взгляда. Такие ограничения возможностей у ваших пользователей могут быть временными или постоянными. В действительности, в нашей жизни, мы все оказываемся в такой ситуации в той или иной мере, например, поломав руку, получив проблемы со зрением и т.д. Таким образом, если вы будете разрабатывать ваше приложение с использованием правильных веб-стандартов, это поможет вашим пользователям воспринимать веб-контент без труда, что в противном случае могло быть вообще невозможным.

Как я могу сделать свое веб-приложение доступным?

Окей, достаточно теории, давайте научимся делать на самом деле доступные ARIA веб-приложения. Вот несколько шагов.

Управление фокусом: Первым делом вы должны удостовериться, что вашим приложением можно пользоваться используя лишь клавиатуру. Под этим я имею ввиду использование Tab-ов и фокусов. Элементы интерфейса должны иметь возможность принимать фокус, обрабатывать клик при нажатии Enter или просто принимать ввод текста от нажатий клавиш на клавиатуре. Да, для людей с нарушением моторики или визуального восприятия, тех, кто не в состоянии использовать указатель мыши, крайне важным будем использование клавиатуры для доступа к вашему приложению. Следовательно, управление фокусом в вашем приложении является очень важным шагом на пути к тому, что бы сделать ваше веб-приложение доступным.

Все нативные элементы, такие как кнопки, поля ввода по умолчанию имеют возможность получать фокус, но проблема начинается тогда, когда вы создаете собственные элементы или веб-компоненты (должен сказать, сейчас это является трендом в создании веб-приложений). Я думаю, никто не хочет видеть эти отвратительные переключатели и флажки, автокомплиты, поля для загрузки файлов и т.д. И, идя на поводу UI/UX дизайнеров, мы создаем пользовательские элементы и веб-компоненты, но напрочь забываем об управлении фокусом у этих компнент. На самом деле, существует множество рекомендаций на сайте w3. Следует соблюдать их при создании собственных веб-компонентов.

Говоря о фокусировании на элементе с испоользоваием клавиши Tab для перемещения фокуса вперед, на следующий элемент, и Shift + Tab для перемещения к предыдущенму элементу, мы, как разработчики, должны отдать должное такой важной составляющей доступности. Представьте себе пользователя со слабым зрением, который применяет программу чтения с экрана (screen reader) для того, чтоб узнать что-то о следующем элементе, используя перемещение фокуса, и когда фокус переходит на неподходящий элемент, не несущий полезной информации, такой как иконка оформления в вашем приложении, пользователь может быть сбит с толку. Следовательно, вам бы хотелось предоставлять какую-то осмысленную информацию об элементе, когда пользователь нажимает tab и перемещает фокус. Отличным примером может служить наш любимый github.com.

При нажатии клавиши Tab после загрузки страницы github вы видите “Skip to Content” – div, который скрывается после того, как вы начинаете навигацию по странице.

Это лишь один из примеров, основное применение заметно, когда вы пытаетесь заполнить форму, и эта форма состоит из пользовательских элементов. И если вы не позаботитесь об управлении фокусом, пользователи могут не заполнить форму. Таким образом, очень важно выполнить требования w3 при создании пользовательских компонент. На codepen я создал пример с правильным управлением фокусом по пользовательским компонентам-закладкам, используя технику под названием блуждающий фокус (Roving Focus). Техника заключается в том, что изначальный tabindex для всех элементов (в нашем случае закладок) устанавливается в значение -1, а затем для того элемента, которому нужно передать фокус tabindex устанавливается в 0, при этом смещение осуществаляется прослушиванием нажатием клавиш навигации.

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

В примере выше я не могу переместить фокус в поле ‘Date From’, потому что клик по клавише Tab отлавливается в поле Search Terms. Хорошие UI практики говорят о том, что не должно быть клавиатурных ловушек. Вы должны разрабатывать так, чтоб предусмотреть выход из такой ловушки, используя клавишу Esc. Кроме того, в соответствии с рекомендациями раздела 2.1.2 WCAG клавиатурных ловушек быть не должно.

Порядок следования в DOM и порядок получения фокусов должны быть идентичны.

Изменение порядка следования DOM элементов может сбить с толку ваших пользователей, которые пользуются программами чтения с экрана. Таким образом, это является антипаттерном. На самом деле, ваш tabindex должен всегда находиться в пределах от 0 до -1.

Семантический HTML: Использование HTML5 семантически верных тегов может стать очень полезным. Такие теги как <header>, <main>, <section>, <footer> способствуют интерпритации вашего веб-контента. Кроме того, использование этих семантических тегов рекомендуется для SEO (оптимизации для поисковых систем). Эти теги ничто иное, как <div role=””>, т.е. div c аттрибутом role равным “baner” для <header>, “main” для <main>, “contentinfo” для <footer>. Фактически, это был способ написания семантической разметки до появления HTML5.

ARIA роли: ARIA роли определяют тип элемента и то, для какой цели он используется.

1
2
3

<div role="alert">
    Please upgrade to the latest version of your browser for the best experience.
</div>

Указание роли к элементу помогает браузерам интерпретировать их по своему. Например, если вы добавите роль “button” к div, то он получит свойство получать фокус и начнет вести себя как кнопка.

Для полного понимания ролей и aria аттрибутов в html5 w3 сделали такую простую диаграмку.

ARIA аттрибуты: ARIA аттрибуты используются в сочетании с ролями и несут вспомогательную информцию. Например, чтоб помочь программе чтения с экрана прочесть состояние пользовательского флажка вы могли бы использовать aria-checked свойство, как на примере ниже:

1
2
3
4
5

<span role="checkbox" 
      aria-checked="true"
      tabindex="0"
      id="myCheckbox">
</span>

Также, вы должны при обработке события клика по элементу span изменять значение aria-checked аттрибута вместе с визуальными изменениями элемента.

А здесь показано иное применение aria аттрибутов, использование свойства аттрибута для aria-label:

1

<p aria-label="author name">Param Singh</p>

Дальнейшее изучение классифкации ARIA аттрибутов я предлагаю продолжить здесь.

ARIA правила и рекомендации

Используйте семантический HTML везде, где только это возможно: Всегда используйте тег <header> для шапки вашего приложения потому что у этого тега уже есть роль “banner” установленная не явно. А еще, это хорошо отразится на SEO в будущем.

Один элемент – одна роль: Вы должны назначать одному элементу по одной роле.

Никогада не меняйте нативную роль элемента: Мы никогда не должны делать нечто подобное:

1

<footer role="button">

Не используйте ненативные теги при существовании нативных: Я говорю об использовании тегов blockqoute вместо q:

1
2
3
4
5
6
7
8

<blockquote cite="http://www.imdb.com/character/ch0000672/quotes">
    <p>
        You know the golden rule, don’t you boy? Those who have the gold make the rules.
    </p>
    <footer>
        <a href="http://www.imdb.com/character/ch0000672/quotes">Crazy hunch-backed old guy in Aladdin</a>
    </footer>
</blockquote>

Используйте аттрибут alt для изображений: Мы должны выработать привычку всегда использовать alt внутри тегов <img>, и не только потому, что это правильно с точки зрения ARIA, но еще и для случая, если изображение не удалось загрузить, вы увидите описание этого изображения, такой прием называется Прогрессивным улучшением (Progressive Enhancement). Я не говорю уже о том, что это хорошо для SEO, такие аттрибуты помогают поисковым роботам индексровать ваш контент.

1
2
3
4
5

<img src="dog.jpg" alt="A golden labrador playing in the park">
<figure aria-labelledby="operahouse_1" role="group">
    <img src="operahousesteps.jpg" alt="The Sydney Opera House"/>
    <figcaption id="operahouse_1">We saw the opera <cite>Barber of Seville</cite> here!</figcaption>
</figure>

Цвет и контраст: Заботясь о пользователях со слабым зрением мы должны потратить определенное время на выбор правильной палитры для оформления нашего приложения. Основной и вспомогательный цвет должны иметь хорошую контрастность. Мы должны избегать близких цветов текста и div с фоновым. Вместо этого, следует следовать золотому правилу KISS (Keep is Simple Stupid! Делайте как можно проще). Одним из ярких примеров является сайт Google.com, он очень дружественен к пользователю потому что он действительно очень простой и белый фон способствует упрощению взаимодействия с пользователем.

В соответствии с WCAG 2.0 level AA уровень контрасности должен быть 4.5:1 для нормального текста и 3:1 для текста большого размера. Уровень ААА устанавливает требования к контрасности 7:1 для текста нормального размера и 4.5:1 для текста большого размера. Большим текстом считается текст размером от 14 points (обычно это 18.66px) и более или 18 points (обычно это 24px) и более.

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

Вот пример небольшого приложения которое я создал с заботой о доступности.
https://restaurants-reviewer.herokuapp.com/

Вывод

Одной из тех вещей за что я люблю веб, является то, что веб делает любую информацию в сети доступной. Вы просто должны перейти на веб-сайт. Так что, забота о том, чтоб сделать сайт доступным, находится в нашей зоне ответственности, как разработчика. Запомните одну вещь, создание доступных веб-приложений правильно не только с точки зрения ARIA, но и с точки зрения SEO.

В конце концов, все что я хочу вам сказать – “Будьте внимательнее!”

Спасибо