Доступность в Интернете и судебные иски

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

- Тим Бернерс-Ли

Введение

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

Сегодня веб-разработка развивается быстрее, чем несколько лет назад. Время от времени мы видим появление новых технологий, новых фреймворков и библиотек. При проектировании или разработке продуктов мы, как правило, не учитываем часть пользователей. По состоянию на 2020 год 10% населения мира (~ 650 миллионов человек) живут с той или иной формой инвалидности. Если мы даже возьмем небольшой процент людей, которые могут использовать Интернет, это все равно будет большое количество.

Руководство по доступности веб-контента (WCAG) - это рекомендация W3C для разработки доступных веб-сайтов. Последняя опубликованная версия - WCAG 2.1 ️.

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

HTML - основа доступности

Семантический HTML:

Многие проблемы доступности можно решить, правильно реализовав HTML - «Семантический HTML».

С момента появления HTML5 были введены новые теги для определенных частей веб-страницы, таких как ‹header›, ‹nav›, ‹footer›, ‹section›, ‹main›, ‹aside› и многие другие. Использование тегов в правильных местах не только гарантирует, что программы чтения с экрана правильно интерпретируют данные, но и улучшают SEO.

Поскольку HTML-теги могут иметь обширные стили, мы должны использовать правильный HTML-тег для предполагаемой функции. Например, наличие ‹div› вместо ‹button› может быть не интуитивно понятным для программ чтения с экрана. Также мы теряем параметры уровня браузера для этого тега.

Другой пример - использовать какой-нибудь другой тег для отображения ссылок вместо тега привязки ‹a›. Я лично столкнулся с этой проблемой при использовании Twitter.

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

Альтернативный текст:

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

<img src="/scenery.png" alt="A scenic village with a mountain backdrop during sunset">

Кроме того, атрибут «title» может использоваться для предоставления подробных описаний и будет виден при наведении курсора мыши.

ВАЙ-АРИЯ:

Инициатива веб-доступности - доступные полнофункциональные интернет-приложения - еще одна спецификация, написанная W3C. ARIA вступает в игру, когда можно предоставить больше информации о вспомогательных технологиях, используемых пользователем, и повысить доступность.

Например, в месте, где мы не можем использовать ‹button› и должны довольствоваться ‹span›, можно задать атрибут aria, чтобы помочь идентифицировать ‹span› как кнопку.

<span tabindex="0" role="button">Click me!</span>

Атрибут «role» сообщает программам чтения с экрана, что диапазон работает как кнопка. Обратите внимание на атрибут tab-index? Это дается для преобразования диапазона в фокусируемый элемент при использовании клавиатуры для навигации. Это значение можно изменить на -1, если фокусировка не требуется.

Существует множество атрибутов aria, которые можно использовать для повышения доступности, и они доступны в документах W3C и MDN.

Больше информации..

Наличие метки указывает на соответствующий ввод с помощью атрибута «для».

<label for="first_name">First Name</label><input type="text" id="first_name">

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

<input type="tel">
<input type="search">
<input type="email">

В приведенном выше примере на первом будет отображаться цифровая клавиатура мобильного устройства, а на втором - обычная клавиатура с кнопкой поиска на ней. Последний будет иметь символ «@» внизу клавиатуры. Кроме того, он автоматически проверяет электронную почту и может быть оформлен с помощью CSS с использованием псевдоклассов «: valid» и «: invalid».

Доступность CSS и JS

После того, как база установлена ​​правильно, CSS и JS могут сделать или сломать нативную функциональность HTML. Существует ряд проблем с доступом, которые могут возникнуть из-за неправильного обращения с ними.

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

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

*:focus{
    outline: none;
}

Приведенный выше код - первая ошибка, которую многие разработчики (в том числе и я в том числе) совершали при разработке новой страницы. Добавление этого кода удалит состояние фокуса со ВСЕХ элементов формы и особенно тега привязки. Это помешает пользователям, использующим только клавиатуру, просматривать веб-контент, поскольку не будет состояния фокуса. Если возникает неизбежная ситуация с удалением контура, мы можем предоставить другие стили, такие как цвет границы или тень блока, которые будут значительно отличать нормальное состояние от состояния фокусировки тега.

Типографика, цвет и интервалы

• Наличие большего количества семейств шрифтов на каждой веб-странице может отвлекать пользователя.
• Использование менее контрастного цвета и цвета фона - дальтоники могут не различать и затруднять чтение.
• Отсутствие достаточной высоты строки для абзацев может затруднить четкое чтение.
• Использование внезапных вспышек цвета при переходе или анимации - у некоторых людей может вызвать судороги.

Обработка событий

Некоторые функции будут написаны для конкретного устройства ввода (мышь / клавиатура). Если пользователь намеревался выполнить действие с другими устройствами ввода, это не сработает.

someTag.onmouseover = showfunction()
someTag.onmouseout = hidefunction()
someTag.onfocus = showfunction()
someTag.onblur = hidefunction()

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

Законы и стандарты

Как упоминалось ранее, WCAG наблюдает за аспектом доступности в Интернете. В некоторых местах это является обязательным, а некоторые даже регулируются законом, например ADA (Закон об американцах с ограниченными возможностями). Многие компании столкнулись с судебными исками за несоблюдение правил в этом отношении. Некоторые из них включают:

• Домино Пицца
• Цель
• Спайсология
• Бейонсе

На всех перечисленных выше веб-сайтах отсутствовал один общий аспект доступности - «атрибут альтернативного текста». Интересно, что 85,4% веб-сайтов, против которых предъявляются иски, относятся к типу B2C (розничная торговля и общественное питание).

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

• Amazon, Walmart, Food Panda и Uber полностью доступны с помощью только клавиатуры.
• Flipkart, Myntra, Swiggy, Zomato и Ola практически не имеют доступа к клавиатуре.

Индийским игрокам предстоит долгий путь в обеспечении доступности.

Вывод

Есть еще много способов и шагов, чтобы сделать веб-страницу максимально доступной. Достижение 100% доступности не может быть достигнуто в каждом сценарии. Но чем больше, тем лучше. Проектирование с сочувствием и обучение пользователя на каждом этапе пути сделают веб-сайты более доступными.

Использованная литература:

Документы MDN для обеспечения доступности - https://developer.mozilla.org/en-US/docs/Web/Accessibility

Рекомендации WCAG 2.1 - https://www.w3.org/TR/WCAG21/

Основы WAI-ARIA - https://developer.mozilla.org/en-US/docs/Learn/Accessibility/WAI-ARIA_basics