По­лез­ные пра­ви­ла до­ступ­но­сти, ко­то­рые оста­нут­ся в па­мяти

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

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

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

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

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

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

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

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

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

В контексте интернета все публичные сайты США, которые не соблюдают ADA или Section 508, исключают из числа своих посетителей большие группы пользователей с разной степенью нарушений.

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

От переводчикаСкопировать ссылку

В России доступность регулируется тремя документами:

1. Государственный стандарт «ГОСТ Р 52872–2012 Интернет-ресурсы. Требования доступности для инвалидов по зрению». Был введён в 2014. Содержит рекомендации, а не жёсткие требования, как и любой другой ГОСТ.
2. Приказ министерства связи и массовых коммуникаций России № 483 «Об установлении порядка обеспечения условий доступности для инвалидов по зрению официальных сайтов федеральных органов государственной власти, органов государственной власти субъектов Российской Федерации и органов местного самоуправления в сети интернет». Принят в ноябре 2015.
3. Федеральный закон № 419-ФЗ «О внесении изменений в отдельные законодательные акты Российской Федерации по вопросам социальной защиты инвалидов в связи с ратификацией конвенции о правах инвалидов». Вступил в силу в январе 2016.

Кому нужна доступность?Скопировать ссылку

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

В превосходной статье замечательного Эдди Османи «Доступные UI-компоненты для веба», речь идёт о четырёх основных видах нарушений, которые рассматриваются в контексте доступности:

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

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

Если хотите больше об этом узнать, то рекомендую пройти на Udacity бесплатный курс Web Accessibility от Google. Это видео из курса, которое рассказывает об этих видах нарушений:

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

К тому моменту, как мы получили иск в 2015, уже был проведён аудит, который выявил множество проблем с доступностью. Наша команда прошла однодневный курс по доступности, на котором мы узнали о Web Content Accessibility Guidelines (сокращённо WCAG, сейчас в версии 2.1). Это руководство считается стандартом по доступности.

WCAG разработан группой Web Accessibility Initiative (WAI), которая входит в W3C. Она же разработала Accessible Rich Internet Applications (WAI-ARIA или просто ARIA, актуальная версия 1.1). Это спецификация о том, как сделать страницы доступными путём добавления ролей и атрибутов ARIA в HTML-разметку.

Эти спецификации включают три уровня соответствия и приоритетов:

• A (можно поддерживать, низший).
• AA (следует поддерживать, средний).
• AAA (нужно поддерживать, наивысший).

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

Прим. переводчика: Не исключение и «ГОСТ Р 52872–2012 Интернет-ресурсы. Требования доступности для инвалидов по зрению». Он разработан на основе WCAG.

Отлично обобщает все рекомендации чек-лист WebAIM WCGA. В нём для каждого критерия указан уровень соответствия.

Насколько сложно выучить WCAG и WAI-ARIA?Скопировать ссылку

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

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

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

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

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

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

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

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

Оказываясь в изоляцииСкопировать ссылку

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

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

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

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

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

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

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

Уровни изоляцииСкопировать ссылку

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

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

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

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

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

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

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

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

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

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

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

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

1. Настаивайте на семантических HTML-элементах, или DIY

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

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

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

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

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

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

Значит вам потребуется:

• Добавить tabindex="0", чтобы компонент стал частью естественного порядка табуляции, и использовать focus(), display: none или aria-hidden для того, чтобы избежать ловушек для фокуса. Про атрибут tabindex читайте в Using Tabindex».
• Следить за событиями клавиатуры. Проверьте требования для ваших компонентов в WAI-ARIA Design Patterns and Widgets.
• Использовать атрибут role, чтобы придать семантическое значение элементу и улучшить SEO-значимость. Узнайте обо всех возможных значениях role в WAI-ARIA Categorization of Roles.
• Использовать атрибуты ARIA для описания состояний и значений. Узнайте, как используются атрибуты ARIA в WAI-ARIA Definition of Roles.
• Следить за контрастом и фокусом, особенно если используете 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) Привыкните использовать инструменты для проверки доступности в повседневной работе

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

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

а. Для вашего регламента разработки

• Плагин aXe для Chrome: лёгкий в использовании плагин, проверяющий доступность. Находит проблемы и даёт рекомендации о том, как их исправить.
• Wave: инструмент для оценки доступности, который визуализирует доступность контента, добавляя иконки и индикаторы прямо на страницу.
• Панель Accessibility, Audits и контрастность цветов в Chrome DevTools: три инструмента, функции которых позволяют перемещаться по дереву доступности и видеть значения каждого элемента, определять контрастность текстовых элементов и выполнять полностраничный аудит доступности и других параметров.
• Плагин NoCoffee для Chrome: имитирует проблемы, с которыми сталкиваются люди c нарушениями зрения от лёгких до серьёзных.
• Плагин High Contrast для Chrome: позволяет просматривать страницы с цветовыми фильтрами с высокой контрастностью, упрощающими чтение текста. Так вы можете проверить, как выглядит ваш сайт для пользователей, которым нужен высокий уровень контраста.

б. Для ручного тестирования с реальными скринридерами

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

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

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

Читать дальшеСкопировать ссылку

• 508, ADA, WCAG: What’s the difference?
• WHO’s World Report on Disability
• Accessible UI Components For The Web
• Microsoft Inclusive Design
• Web Accessibility free course on Udacity, by Google
• WebAIM’s WCGA 2 checklist
• Using Tabindex
• WAI-ARIA Design Patterns and Widgets
• WAI-ARIA Categorization of Roles
• HTML5 Sectioning Elements