Впервые я начал работать с веб-доступностью еще в 2015 году в американском гиганте розничной торговли. Он только что получил серьезный иск, поскольку его веб-сайт не соответствовал Закону об американцах с ограниченными возможностями (ADA). После этого мы с моей командой много работали над соответствием ADA, когда я познакомился со многими принципами веб-доступности.

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

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

В этой статье 2 раздела: Что такое веб-доступность? и 3 прагматических правила веб-доступности. В первом разделе я хочу напомнить о доступности Интернета и поделиться своим опытом с этим. Но если вы предпочитаете перейти к делу, сразу переходите ко второму занятию: 3 прагматических правила веб-доступности.

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

Как я уже упоминал, еще в 2015 году мою компанию подали в суд за несоблюдение ADA.

ADA - это закон о гражданских правах, который

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

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

В контексте Интернета любой общедоступный веб-сайт в США, не соответствующий требованиям ADA или Раздела 508, на самом деле исключает несколько групп пользователей с различной степенью нарушений.

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

Кого может поддержать a11y?

Согласно Всемирному докладу об инвалидности, опубликованному в 2011 году Всемирной организацией здравоохранения (ВОЗ), по оценкам, 15% населения мира живет с той или иной формой инвалидности. Из них от 2 до 4% испытывают значительные трудности в функционировании.

Прекрасная статья великого Адди Османи Доступные компоненты пользовательского интерфейса для Интернета описывает четыре основные области инвалидности, которые следует рассматривать в контексте a11y:

1. Проблемы со зрением: могут варьироваться от неспособности различать цвета до полного отсутствия зрения.

2. Проблемы со слухом: означает, что у пользователя могут быть проблемы со слухом, исходящим от страницы.

3. Проблемы с мобильностью: могут включать невозможность работы с мышью, клавиатурой или сенсорным экраном.

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

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

Чтобы узнать больше, я рекомендую пройти бесплатный курс Веб-доступность на сайте Udacity от Google. Вот видео из курса, который охватывает эти области инвалидности:

Хорошо, а как мы можем обеспечить надежную поддержку?

К тому времени, когда мы получили иск в 2015 году, в ходе аудита было обнаружено несколько проблем. Наша команда прошла однодневный тренинг по специальным возможностям, на котором мы узнали о Руководстве по доступности веб-контента (WCAG, в настоящее время находится в версии 2.1), которые общеприняты в качестве стандарта для обеспечения соответствия требованиям.

WCAG поддерживается Инициативой веб-доступности (WAI) консорциума World Wide Web (W3C). Эта же группа разработала Доступные полнофункциональные Интернет-приложения (WAI-ARIA или просто ARIA, в настоящее время версия 1.1), которые представляют собой спецификацию того, как увеличить размер веб-страниц за счет добавления к HTML в качестве ролей и атрибутов ARIA.

Эти рекомендации делятся на три уровня соответствия:

  • A (должен поддерживать)
  • AA (должен поддерживать) и
  • AAA (может поддерживать).

Многие законы о доступности по всему миру основаны на уровнях WCAG. Например, в январе 2017 года Раздел 508 принял соответствие с уровнем AA WCAG 2.0.

Подробное изложение рекомендаций можно найти в Контрольном списке WCGA 2 WebAIM, где каждый критерий указывает соответствующий ему уровень соответствия.

Насколько сложно изучить WCAG и WAI-ARIA?

Я хотел бы воспользоваться моментом, чтобы поделиться своим опытом обучения a11y.

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

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

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

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

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

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

Другими словами, мы создавали исключения, что происходит, когда мы решаем проблемы, используя наши собственные предубеждения, согласно Microsoft Inclusive Design.

Исключение

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

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

Обычно регулярная сдача крови длится около 10 минут, а сдача тромбоцитов длится около 90 минут. Нам потребовалось около 20 минут, чтобы заметить, что у меня взорвалась вена, так как моя рука была покрыта одеялом (потому что возвращение крови заставляет вас чувствовать себя холодно).

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

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

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

И затем, как раз в этот момент, я вспомнил, как в прошлом работал с a11y и позволял этим исключениям пройти. О чувак!

Уровни исключений

Согласно Microsoft's Inclusive 101 Toolkit, существует три уровня исключения:

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

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

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

Кодирование изменений

Наконец, я понял: реализация a11y означает вклад в более инклюзивный мир! Вот несколько вещей, которые мы можем сделать как инженеры:

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

3 прагматических правила веб-доступности

Итак, вот я и моя миссия - разделить все на 3 практических правила, которые останутся у вас на уме. Из этих правил вы сможете извлечь остальные знания и найти руководство по внедрению a11y в свой проект.

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

Опять же, чтобы научиться всему, я всем сердцем рекомендую пройти бесплатный курс Веб-доступность на сайте Udacity от Google:



Доступность в Интернете | Udacity
Получите практический опыт создания доступных веб-приложений. Вы поймете, когда и зачем пользователям нужны специальные возможности… www.udacity.com



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

1) Настаивайте на семантических HTML-элементах или сделайте сам

Для меня это золотое правило доступности.

Семантические элементы - это элементы, которые передают определенное значение вместе с содержанием, которое они представляют, например <button>, <input>, <a>, <h1> и <p>. Они предоставляют некоторый контекст для пользовательского агента (браузер, устройство или вспомогательные технологии, такие как программа чтения с экрана), поэтому он будет знать, как взаимодействовать с этими элементами и чего ожидать от них.

Они отличаются от нейтральных элементов, таких как <div> и <span>, или презентационных элементов, таких как <center> и <big>, которые не предоставляют такой контекст пользовательскому агенту.

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

  • правильная обработка фокуса с помощью клавиши табуляции.
  • реагирование на события клавиатуры (как Enter, Esc, пробел, клавиши со стрелками).
  • представляет семантическую информацию (имя, роль, состояние и значение), чтобы вспомогательные технологии могли ее понять.
  • соответствие требованиям цветового контраста со стилем по умолчанию.

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

Это означает, что вам нужно будет делать что-то вроде:

  • добавьте tabindex="0", чтобы компонент был частью естественного порядка табуляции, и используйте focus(), display: none или aria-hidden, чтобы избежать ловушек фокуса. Узнайте о tabindex в разделе Использование tabindex.
  • прикрепите прослушиватели ожидаемых событий клавиатуры. Проверьте ожидания для вашего компонента в Шаблоны дизайна и виджеты WAI-ARIA.
  • используйте роль, чтобы предоставить некоторую семантику и ценность для SEO. Изучите все возможные роли в разделе Классификация ролей WAI-ARIA.
  • укажите атрибуты ARIA для описания состояния и значения. Узнайте, какие атрибуты ARIA применяются к каждой роли в Определении ролей WAI-ARIA.
  • следите за цветовым контрастом и индикатором фокуса, особенно при использовании outline: 0 (что не рекомендуется).

Что касается семантических элементов, вот еще несколько вещей, о которых следует помнить:

  • используйте теги секционирования, чтобы структурировать вашу страницу по разделам, в противном случае вам нужно предоставить ориентиры ролей.
  • используйте теги заголовков для организации вашего текстового контента, чтобы вы могли выразить взаимосвязь между разделами и их порядок важности. Для справки: на каждой странице должен быть только один <h1>.
  • используйте <label for="..."> с полями формы как <input>, <select> и <textarea>.
  • используйте подходящий инструмент для работы, например, если это ссылка, используйте <a href=""> и никогда <span onclick="...">, а если это кнопка, используйте <button> и никогда <a href="#" onclick="...">.

Ну, семантические элементы кажутся более удобными, не правда ли?

2) Предоставьте альтернативы изображениям, цвету, звуку и движению.

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

  • Для изображений предоставьте альтернативный текст. Вы можете использовать alt="description" для информативных изображений (тех, которые имеют значение, например, изображения или отдельного значка) и alt="" для декоративных изображений (тех, которые не имеют значения , как значок внутри кнопки и рядом с ее текстом). Это особенно важно для ссылок на изображения.
  • Продолжайте использовать изображения, полагаясь на них при взаимодействии с пользователем, предоставьте альтернативу аудио или узнайте, как перестать полагаться на них. Вы можете, например, проверить Google reCaptcha.
  • Для цветов при указании состояния проверки, обозначенной области или просто различения элементов добавьте вторичный индикатор, например информативный текст, значок или даже всплывающую подсказку.
  • Продолжая работать с цветами, узнайте коэффициент контрастности вашего текста и проверьте, соответствует ли он стандарту, которому вы следуете. Например, уровень AA WCAG требует как минимум 4,5: 1 для обычного текста и 3: 1 для крупного текста.
  • Для звуковых дорожек и видео используйте текстовые подписи или расшифровку, если они доступны. Для звуков действий предоставьте визуальную альтернативу.
  • Что касается движений пользователя, каждый раз, когда мы ожидаем, что пользователь выполнит определенные жесты, сделайте их необязательными или предоставьте альтернативы взаимодействия с помощью клавиатуры.
  • Для автоматического движения избегайте вспышек, миганий, перемещения содержимого и новых окон. Когда это неизбежно, добавьте элементы управления, чтобы настроить время, приостановить или скрыть этот контент. Кроме того, используйте aria-live, чтобы программа чтения с экрана могла уведомлять пользователя всякий раз, когда происходит прерывание.

3) Сделайте привычкой использовать в своей работе разные инструменты.

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

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

Я рекомендую вам использовать в основном 3 типа инструментов:

а) Для вашего контрольного списка развития

  • Плагин ax chrome: простая в использовании программа проверки, которая находит проблемы и предоставляет предлагаемые исправления.
  • Волна: удобный инструмент оценки, который обеспечивает визуальную обратную связь о доступности вашего веб-контента путем добавления значков и индикаторов на вашу страницу.
  • DevTools (панель специальных возможностей, коэффициент контрастности и аудит): эти 3 функции DevTools позволяют перемещаться по дереву доступности и просматривать свойства каждого элемента, проверять коэффициент цветового контраста для текстовых элементов и выполнять полностраничный аудит доступности. (и другие показатели).
  • Плагин NoCoffee chrome: имитирует проблемы, с которыми сталкиваются люди с незначительными или очень серьезными проблемами зрения.
  • Подключаемый модуль High Contrast chrome: позволяет просматривать веб-страницы с помощью нескольких высококонтрастных цветных фильтров, разработанных для облегчения чтения текста, чтобы вы могли проверить, как ваш сайт работает для пользователей, которым требуется поддержка высокой контрастности.

б) Для тестирования вручную с помощью настоящих программ чтения с экрана

  • Mac VoiceOver (входит в состав macOS).
  • Windows NVDA (бесплатно) и JAWS (платно).

в) Для автоматического аудита

  • Google Lighthouse: автоматизированный аудитор, аналог DevTools Audits.
  • Ax: автоматическая проверка тех же самых правил, что и в плагине ax chrome.
  • Pa11y Dashboard: веб-интерфейс, который помогает вам контролировать доступность ваших веб-сайтов.

Учить больше