Web accessibility: standards, guidelines, testing & evaluation tools

Предыстория

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

Что такое accessibility? А как пользователи с ограниченными возможностями взаимодействуют с вебом? Пользуются специальными приложениями? Или могут воспринимать тот же контент, что и мы? Кто заботится о них? Кто является ответственным за то, чтобы они могли полноценно воспринимать контент? Как можно сделать контент доступным? Это сложно? Можем ли мы помочь?

Уже через пару месяцев я знала ответы на все эти вопросы и сейчас поделюсь этой информацией с вами. Меня удивляет: как получилось, что я так долго оставалась в неведении. Хочется сделать эту тему более популярной, чтобы таких, как я, было как можно меньше…

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

ТестированиеСкопировать ссылку

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

• Accessibility best practices for screenreader testing — Шери Бирн-Хабер с кратким описанием основных принципов тестировании доступности.
• Web Accessibility Evaluation Tools List — список W3C WAI со всеми одобренными ей инструментами для оценки доступности.
• A Complete Guide To Accessibility Tooling — Ник Чан разбирает самые популярные инструменты для автоматического тестирования, проверки контрастности, линтеры и другие полезные тестерские штуки.
• Accessibility Support — аналог Can I Use в мире доступности. Можно проверить поддержку ARIA-атрибутов и ролей, а также HTML-элементов и атрибутов в разных скринридерах.
• База поддержки HTML-элементов PowerMapper Software, также на сайте есть базы по атрибутам, ARIA и WCAG.
• Гайдлайн BBC по тестированию в скринридерах — поэтапное описание, как проводить тестирование скринридеров на разных платформах.
• Шорткаты и жесты в скринридерах — есть JAWS, NVDA, Narrator, VoiceOver и TalkBack.

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

Убедитесь,что ваше веб-приложение может полностью работать только с клавиатурой:

WebAIM рассказывает о доступности клавиатуры

Фокус клавиатуры и контур фокуса

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

Используйте только CSS, который удаляет этот контур, например, устанавливая , если вы заменяете его другой реализацией контура фокуса.

Механизмы перехода к желаемому содержанию

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

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

WebAIM-Пропустить навигационные ссылки

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

Подробнее об использовании этих элементов для повышения доступности можно прочитать здесь:

Доступные достопримечательности

Программное управление фокусом

Наши React приложения непрерывно изменяют HTML DOM во время выполнения,что иногда приводит к потере фокуса клавиатуры или установке неожиданного элемента.Чтобы это исправить,нам необходимо программно подтолкнуть фокус клавиатуры в нужном направлении.Например,путем сброса фокуса клавиатуры на кнопку,которая открывала модальное окно после закрытия этого модального окна.

MDN Web Docs рассматривает это и описывает, как мы можем создавать виджеты JavaScript с возможностью навигации с клавиатуры .

Чтобы установить фокус в React, мы можем использовать ссылки на элементы DOM .

Используя это,мы сначала создаем ссылку на элемент в JSX класса компонента:

class CustomTextInput extends React.Component {
  constructor(props) {
    super(props);
    
    this.textInput = React.createRef();
  }
  render() {
  
  
    return (
      <input
        type="text"
        ref={this.textInput}      />
    );
  }
}

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

focus() {
  
  
  this.textInput.current.focus();
}

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

function CustomTextInput(props) {
  return (
    <div>
      <input ref={props.inputRef} />
    </div>
  );
}

class Parent extends React.Component {
  constructor(props) {
    super(props);
    this.inputElement = React.createRef();
  }
  render() {
    return (
      <CustomTextInput inputRef={this.inputElement} />
    );
  }
}


this.inputElement.current.focus();

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

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

Other Points for Consideration

Setting the language

Indicate the human language of page texts as screen reader software uses this to select the correct voice settings:

WebAIM — Document Language

Setting the document title

Set the document to correctly describe the current page content as this ensures that the user remains aware of the current page context:

WCAG — Understanding the Document Title Requirement

We can set this in React using the React Document Title Component.

Color contrast

Ensure that all readable text on your website has sufficient color contrast to remain maximally readable by users with low vision:

• WCAG — Understanding the Color Contrast Requirement
• Everything About Color Contrast And Why You Should Rethink It
• A11yProject — What is Color Contrast

It can be tedious to manually calculate the proper color combinations for all cases in your website so instead, you can calculate an entire accessible color palette with Colorable.

Both the aXe and WAVE tools mentioned below also include color contrast tests and will report on contrast errors.

If you want to extend your contrast testing abilities you can use these tools:

• WebAIM — Color Contrast Checker
• The Paciello Group — Color Contrast Analyzer

Why is Mobile Web Accessibility Important?

If you’re like me and millions of other people, you may find that a majority of your browsing is performed on a mobile device. Statistics show that > 50% of web traffic is coming from mobile devices. Also, it’s interesting to note that 39% of smartphone users are more likely to browse or purchase products from vendors who have a quality mobile web experience.

Mobile devices are not going away anytime soon and, in fact, they seem to be growing in popularity and usage. This is a critically important concept for organizations that want to reach their audience in a more effective way. An accessible mobile web experience ensures that everyone using a mobile device (plus any assistive technologies) has equal access to the content.

Быть в курсеСкопировать ссылку

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

СообществаСкопировать ссылку

• Статьи и посты о доступности на CSS-Tricks.
• Категория «Accessibility» на Smashing Magazine.
• Блог The A11Y Project — опенсорсный проект, посвящённый всем аспектам веб-доступности.
• Посты по тегу «a11y» на DEV Community.
• Статьи «Веб-стандартов» по тегу «a11y» — авторские статьи и переводы, да вы и сами знаете.
• Хаб про доступность на Хабре — авторские посты и переводы статей про доступную разработку.

Подкасты и стримыСкопировать ссылку

• A11y Rules Podcast.
• 13 Letters — подкаст об универсальном дизайне, законодательстве и лучших практиках цифровой доступности со специалистами из разных стран.
• Подскаст «Веб-стандарты» — не концентрируется только на доступной разработке, но новости и события из мира доступности обсуждаются почти в каждом выпуске.
• Accessibility Talks — стримы о доступности.
• Стримы Some Antics на Twitch и их записи на YouTube — проект Бена Майерса о доступной разработке в формате дискуссий с разработчиками, тестировщиками, дизайнерами и всеми, кто занимается доступностью.
• Technica11y — стримы про проблемы и хитрости, связанные с технической доступностью.
• .

Конференции и митапыСкопировать ссылку

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

• Inclusive Design 24 — 24-часовая онлайн-конференция об инклюзивном дизайне и доступности.
• Axe-con — конференция Deque о доступности для разработчиков, дизайнеров, менеджеров и всех неравнодушных.
• #a11yTO Conf — трёхдневная онлайн-конференция, состоящая из тщательно отобранного «плейлиста» из лекций, демо и лайтнингов.
• Accessibility Club Minsk — русскоязычный митап о доступности, часть международной сообщества Accessibility Club. Записи митапов на YouTube.
• Pitera11y_meetup — митап о доступности в Санкт-Петербурге. Плейлист записей докладов на YouTube.
• на The A11Y Project.

Персональные блогиСкопировать ссылку

Много технический деталей прячется в персональных блогах.

• Tink — блог Леони Уотсон, директора TetraLogical, члена W3C Advisory Board и BIMA Inclusive Design Council, а также сопредседателя W3C Web Applications Working Group.
• Блог Скотта О’Хары, бывшего дизайнера, который сейчас специализируется на доступной разработке и UX.
• Блог Бена Майерса, веб-разработчика и адвоката доступности.
• Accessabilly — блог Мартина Менгеле, фронтенд-разработчика и консультанта по доступности.
• Блог Сары Суайдан, разработчицы пользовательских интерфейсов и дизайн-систем, автора статей и спикера. Блог не посвящён доступности, но она часто становится темой статей.
• Блог Эрика Бэйли, адвоката доступности и инклюзивного дизайна, мэйнтейнера The A11Y Project.
• HTML Accessibility — блог Стива Фолкнера, технического директора TPGi, ведущего разработчика Web Accessibility Toolbar, члена W3C Web Platforms Working Group и W3C ARIA Working Group.
• Блог Адриана Розелли, консультанта, автора статей, спикера, члена нескольких рабочих групп W3C. Например, W3C HTML Accessibility Task Force и W3C Accessible Rich Internet Applications Working Group.

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

РассылкаСкопировать ссылку

Здесь собраны рассылки, на которые я подписана. Другие можете поискать у .

• Accessibility Weekly — еженедельная рассылка с полезными статьями, постами и новостями за неделю. Приходит по понедельникам.
• The WebAIM Newsletter — ежемесячная рассылка.

Более сложные виджеты

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

Здесь нам необходимо знать а также состояния . Это наборы инструментов, заполненные атрибутами HTML, которые полностью поддерживаются в JSX и позволяют нам создавать полностью доступные, высокофункциональные компоненты React.

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

• Пикеринг Хейдона-АРИА Примеры
• Инклюзивные компоненты

Исправление недоступных веб-сайтов

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

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

How People with Disabilities Use Links

While screen readers can read a full page to a user, screen reader users may prefer to instead listen to a list of links. In that case, a screen reader may only read the link text and not the surrounding text.

Speech recognition software allows a user to avoid using a mouse. Users can speak the text of the link that they would like to follow.

Keyboard-only users may not be able to use a mouse to click links. They use a keyboard’s tab button to navigate through a page’s links, buttons, and form inputs. For such users, it is very important for them to see which item has focus at all times.

Colorblind users may not be able to perceive color cues. Typically, pages present links as a different color than their surrounding text. Adding underlines or other non-color indicators help users who may not see color. Users who are not comfortable with technology may also appreciate having links underlined.

Работа с событиями мыши¶

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

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

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

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

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

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

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

Что ещё почитать о доступности

Главный источник информации о доступности в интернете — раздел Web Accessibility Initiative на сайте W3C. Здесь есть стандарты, гайдлайны, учебные пособия, тесты, рекомендации для дизайнеров, разработчиков, авторов текстов. Основной документ — Web Content Accessibility Guidelines (WCAG). В нём представлен универсальный набор стандартов доступности.

Интенсив «Погружаемся в DevOps. Знакомство с основными инструментами за 3 дня»
14–16 марта, Онлайн, Беcплатно

tproger.ru

События и курсы на tproger.ru

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

Уровни изоляции

В соответствии с Microsoft’s Inclusive 101 Toolkit существует три уровня изоляции:

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

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

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

Инструменты для разработки и тестирования¶

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

Тестирование клавиатуры

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

1. Отключите мышь.
2. Используйте и для перемещения по странице.
3. Используйте для активации элементов.
4. Там, где необходимо, используйте клавиши со стрелками, например, для работы с меню или выпадающими списками.

Инструменты разработчика

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

eslint-plugin-jsx-a11y

Плагин eslint-plugin-jsx-a11y для ESLint выполняет проверку абстрактного синтаксического дерева JSX на предмет поиска проблем, связанных с доступностью контента. Многие среды разработки могут интегрироваться с этим инструментом и выводить сообщения линтера в окно анализа кода или прямо в окно исходного кода.

В Create React App этот плагин используется с заранее установленным набором правил. Если необходимо задействовать дополнительные правила, вам нужно создать в корне проекта файл со следующим кодом:

Тестирование доступности контента в браузере

Существуют инструменты для аудита доступности контента веб-страниц в браузере. Используйте их совместно с теми инструментами для проверки HTML, которые были описаны выше.

aXe, aXe-core и react-axe

Компания Deque Systems предлагает модуль aXe-core для автоматизированного и сквозного тестирования веб-приложений. Этот модуль имеет интеграцию с Selenium.

На основе разработан продукт компании Deque Systems под названием The Accessibility Engine или aXe. Это расширение для браузеров, предназначенное для комплексного тестирования доступности контента сайтов.

Также вы можете использовать модуль react-axe для вывода сообщений от aXe в консоль в процессе программирования или отладки.

WebAIM WAVE

Web Accessibility Evaluation Tool ещё одно расширение для браузера, которое используется для улучшения доступности контента веб-сайтов.

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

Дерево доступности — это подмножество DOM-дерева. В нём содержатся объекты, которые нужны для работы технологий поддержки доступности контента, например, для экранных считывающих устройств.

В некоторых браузерах можно легко получить информацию обо всех элементах в дереве доступности:

• использование инспектора доступности в Firefox
• активация инспектора доступности в Chrome
• использование инспектора доступности в OS X Safari

Экранные считывающие устройства

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

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

Общедоступные экранные считыватели

NVDA в Firefox

NonVisual Desktop Access или NVDA — это широко распространённый экранный считыватель с открытым исходным кодом для Windows.

Вот несколько руководств по работе с NVDA:

• WebAIM — использование NVDA для улучшения доступности контента
• Deque — сочетания клавиш для NVDA

VoiceOver в Safari

VoiceOver — это экранный считыватель, встроенный в продукты Apple.

Здесь приведены руководства по активации и использованию VoiceOver:

• WebAIM — использование VoiceOver для улучшения доступности контента
• Deque — сочетания клавиш для VoiceOver в OS X
• Deque — комбинации жестов для VoiceOver в iOS

JAWS в Internet Explorer

Job Access With Speech or JAWS — это экранный считыватель, который чаще всего используется в Windows.

Руководства по JAWS:

• WebAIM — использование JAWS для улучшения доступности контента
• Deque — сочетания клавиш для JAWS

Прочие экранные считыватели

ChromeVox в Google Chrome

ChromeVox — это встроенный экранный считыватель для ноутбуков Chromebook. Он доступен для Google Chrome в виде расширения.

Ссылки на руководства по ChromeVox:

• Google Chromebook — как использовать встроенную программу чтения с экрана
• Сочетания клавиш для ChromeVox

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

• 10.1 (приоритет 2) Избегайте использования всплывающих окон или открывания ссылки в новом окне, не предупредив пользователя (пока браузеры не научатся блокировать открывание новых окон).
• 10.2 (приоритет 2) Пока браузеры не будут корректно отображать явные связи между текстовыми метками и полями ввода, помещайте текстовые метки прямо перед соответствующими им полями ввода в коде страницы.
• 10.3 (приоритет 3) Давайте альтернативное представление для всех таблиц, которые теряют смысл, будучи прочитаны последовательно (ячейка за ячейкой).
• 10.4 (приоритет 3) Пока браузеры не будут корректно обрабатывать пустые элементы ввода (INPUT, TEXTAREA), наполняйте элементы ввода заполнителям (некоторые старые браузеры не позволяют пользователю попасть в поле ввода, не содержащее текста).
• 10.5 (приоритет 3) Пока браузеры (включая спецбраузеры) не будут корректно обрабатывать смежные ссылки, помещайте читаемые символы между соседними ссылками.

Учитывая, что стандарт разработан в 1999 году, большинство требований совместимости устарели. Вторая версия стандарта WAI-WCAG, находящаяся сейчас в черновом варианте будет включать актуальные на сегодня рекомендации совместимости.

Гайдлайн 6. Убедитесь в доступности страниц, использующих новые технологии.

Для того, чтобы протестировать пункт 6.1, мы использовали текстовый браузер lynx, входящий в большинство дистрибутивов Linux (windows-версии также доступны). Выглядит вполне читаемо, см. скриншот.

6.2 (приоритет 1) Убедитесь, что эквивалент динамического содержимого обновляется при обновлении динамического контента.

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

• 6.3 (приоритет 1) Убедитесь, что страницы можно использовать при выключенных скриптах, апплетах или других программных элементах.
• 6.4 (приоритет 2) Убедитесь, что обработчики событий в скриптах и апплетах не зависят от устройства ввода. Cтарайтесь использовать события уровня приложения, такие как onfocus, onblur, onselect. Обработчики событий, зависящие от устройства используйте парно: onmousedown вместе с onkeydown, onmounseup вместе с onkeyup, onclick вместе с onkeypress.
• 6.5 (приоритет 2) Убедитесь, что динамическое содержание доступно в различных клиентских средах или предоставьте альтернативное представление страницы. Например, во многих случаях, серверные скрипты обеспечивают более высокую доступность, чем клиентские скрипты.

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

Настройка языка

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

WebAIM-Язык документов

Установка названия документа

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

WCAG-Понимание требований к заголовку документа

Мы можем установить это в React с помощью компонента React Document Title .

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

Убедитесь,что весь читаемый текст на вашем сайте имеет достаточный цветовой контраст,чтобы оставаться максимально читаемым пользователями с плохим зрением:

• WCAG-Понимание требований к цветовому контрасту
• Все о цветовом контрасте и почему ты должен переосмыслить его.
• A11yProject-Что такое цветовой контраст?

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

Упомянутые ниже инструменты aXe и WAVE также включают в себя тесты на контрастность цвета и сообщат об ошибках,связанных с контрастностью.

Если вы хотите расширить свои возможности тестирования контрастности,вы можете использовать эти инструменты:

• WebAIM-Проверка цветового контраста
• Пациэльская группа-анализатор цветового контраста

Кто и зачем должен внедрять accessibility?

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

• UX/UI дизайнеры — проектируют интерфейсы, следуя гайдлайнам доступности
• Программисты — пишут правильную разметку/вёрстку страниц, следят чтобы у всех элементов были необходимые теги и атрибуты
• Тестировщики — проводят accessibility-тестирование.

Основные мотивации внедрения accessibility:

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

Конкурентное преимущество: повышение процента удовлетворённых пользователей.Как я упоминала ранее, до 15% пользователей имеют постоянные, временные или ситуационные препятствия при взаимодействии с интернетом

Неважно, на чём именно сфокусирована ваша компания — сайты, мобильные или десктопные приложения и сервисы — при внедрении доступности вы достигаете увеличения процента пользователей, которые могут успешно взаимодействовать с вашим ресурсом.Помимо прочего, accessibility является одним из современных трендов в мире IT, применение которого улучшает имидж вашей компании.

Закон: необходимое условие при разработке продуктов для крупных международных проектов. В большинстве стран ЕС, а также в Великобритании, США, Канаде, Австралии, Бразилии и Индии стандарты accessibility закреплены законодательно.В России тоже действует стандарт, призывающий разрабатывать интернет-ресурсы доступными: «ГОСТ Р 52872-2012

Требования доступности для людей с инвалидностью и других лиц с ограничениями жизнедеятельности». На настоящий момент доступными обязаны быть сайты социальных и образовательных учреждений. С дальнейшим распространением IT-технологий стоит ожидать увеличения количества требований, касающихся доступности для пользователей как в России, так и в других странах.

Web Accessibility Laws and Regulations

In the United States, it’s the Americans with Disabilities Act (ADA). However, the Act doesn’t presently state any explicit laws for web accessibility. Nevertheless, in 2006 the court ruled that commercial websites like Target are required by the Act and state laws to make their websites accessible (that happened when three visually blind people set a precedent by bringing a lawsuit alongside the National Federation of the Blind (NFB)).

In the UK, it’s the Equality Act that states that any type of information including those on the websites should be accessible to people with disabilities.

Other laws include Section 508 in the US and the European Accessibility Act in the European Union.

Section 508 is an amendment made in 1998 to the US Rehabilitation Act of 1973, which requires disability compliance for governmental organizations or those receiving federal funding. In 2017, the Section received a major update and incorporated specific types and uses of technology and the explicit recommendation to adhere to Level A and Level AA of the WCAG 2.0 guidelines.

The European Accessibility Act is a directive for a legislative framework for accessibility in line with the United Nation’s Convention on the Rights of Persons with Disabilities (CRPD). The European Accessibility Act covers many types of technologies, including websites, ATMs, ticketing machines, and more.

Thanks to WCAG 2.0 and 2.1, the guidelines have become more accessible to a general audience without much of legal jargon and now serve as valuable checks for testing website development and maintenance for accessibility issues.

WCAG is based on four principles, so-called POUR:

• Perceivable — Information and user interface components must be presentable in a way the users can perceive (being able to access);
• Operatable — User interface components and navigation must be operatable (being able to use);
• Understandable — Information and the operation of user interface must be understandable (being able to understand);
• Robust — Content must be robust so it can be interpreted by assistive technologies (being able to interpret).

WCAG has multiple levels of compliance:

• Level A: the lowest (minimum) level of conformance • Level AA: the middle level of conformance, satisfying both Level A and Level AA criteria • Level AAA: the highest level of conformance, satisfying Level A, Level AA, and Level AAA criteria

ATAG is the Authoring Tool Accessibility Guidelines, which was created by the W3C for those producing content management systems. ATAG ensures the authoring element of the site is accessible and helps users produce accessible content.