Ещё
Аудит доступности: основы
Татьяна Фокина, Василий ДудинОнлайн-обучение: советы студентам
Алёна Батицкая
К тому моменту, как мы получили иск в 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-разметку.
Эти спецификации включают три уровня соответствия и приоритетов:
Многие законы о доступности во всём мире основаны на критериях выполнения WCAG. Например, в январе 2017 года Section 508 был принят в соответствии с критерием AA WCAG 2.0.
Прим. переводчика: Не исключение и «ГОСТ Р 52872–2012 Интернет-ресурсы. Требования доступности для инвалидов по зрению». Он разработан на основе WCAG.
Отлично обобщает все рекомендации чек-лист WebAIM WCGA. В нём для каждого критерия указан уровень соответствия.
Я хотел бы поделиться своим опытом в изучении доступности.
Хотя наш курс был довольно комплексным и его проводили чрезвычайно компетентные люди, мы просто сидели на нём часами и слушали детальные обзоры WCAG, пункт за пунктом. Презентация была огромной, и мы быстро переходили от одного слайда к другому. Если честно, она была перегружена, ведь WCAG нельзя назвать маленьким документом.
Короче говоря, мы были готовы решить много задач, и сразу же начали работать над исправлениями. Однако скоро это стало чем-то повторяющимся, механическим, просто ответом на стимулы. Мы тонули в море доступности.
Каждый знал как хорошо мы стали разбираться в доступности, поэтому никто не критиковал нашу работу. История с доступностью подходила к концу, и у нас появились новые приоритеты. Ожидалось, что мы вынесем многое из проделанной работы. Какое-то время так и было.
Со временем кто-то ушёл из команды, присоединились новые люди, а ещё появилось новое руководство. Рынок быстро развивается. Мы изменили наши приоритеты и командный дух, не говоря уже о том, что были заняты новыми задачами, которые отодвинули доступность на второй план.
Всё было настолько плохо, что шесть месяцев спустя у нас был новый аудит, который показал, что мы всё ещё сидим на огромной куче проблем с доступностью! Скоро мы осознали, что, хотя старые ошибки исправлены, у большей части нового кода — проблемы. Кроме того, мы никогда не включали доступность в наш регламент разработки и новые члены команды не обучались этому.
Вывод: мы просто позволили этому случиться. Доступность проигнорировали и её ключевые идеи не укоренились в нас.
Другими словами, мы оказались изолированы в пузыре наших представлений. Такое случается, когда мы решаем проблемы, руководствуясь своими предубеждениями, как отмечено в методологии Microsoft Inclusive Design.
Иногда вам нужно что-то испытать на собственном опыте, чтобы лучше это понять. Это и случилось со мной.
Я регулярно сдаю кровь на тромбоциты. У меня первая положительная группа крови, так что я могу помочь многим людям. Один раз в мою вену неправильно вставили катетер, и в этом месте на левой руке появился большой болезненный синяк.
Обычно сдача донорской крови занимает 10 минут, но забор тромбоцитов длится примерно 90. Так как моя рука была накрыта одеялами (потому что при заборе крови становится холодно), персоналу потребовалось около 20 минут, чтобы заметить, что моя вена повреждена.
После того, как это обнаружилось, сдачу тромбоцитов прервали. Мою левую руку раздуло, она стала очень чувствительной на несколько дней. Настолько, что я просто не мог заставить себя ей пользоваться.
После этого я пытался всё делать правой рукой. Неожиданно я заметил, что переключаться с клавиатуры на мышь неудобно, и мне было бы проще выполнять все задачи, используя что-то одного.
Вскоре я обнаружил, что использую только клавиатуру, и обратил внимание, как много сайтов просто не поддерживают её. Тогда до меня дошло: я столкнулся с изоляцией, хотя мои трудности были просто временными.
И тогда, именно в этот момент, я вспомнил как раньше работал над доступностью и не думал о поддержке клавиатуры. Блин!
В соответствии с Microsoft’s Inclusive 101 Toolkit существует три уровня изоляции:
Мои временные ограничения раскрыли мне глаза, ведь я никогда не сталкивался с такой проблемой во время работы.
Тем не менее, я находился в невероятно выгодном положении, ведь мои трудности длились всего пару дней, тогда как миллионы людей во всём мире изолированы в течение всей жизни.
Наконец, до меня дошло: реализация доступности вносит вклад в более инклюзивный мир! Вот несколько вещей, которые мы можем сделать как разработчики:
Это моя попытка свести доступность к трём простым правилам, которые вы запомните. Из этих правил можно вынести основные идеи и найти рекомендации по внедрению доступности в ваш проект.
Внимание! Эти правила не заменят необходимости изучения доступности. Они не исчерпывающие и станут только основой для того, что вы дальше будете изучать самостоятельно.
Повторюсь, чтобы научиться доступности, рекомендую ознакомиться на Udacity с бесплатным курсом Web Accessibility от Google.
Итак, три полезных правила доступности. Надеюсь, вы сможете взять их на вооружение и использовать каждый день в своей работе:
1. Настаивайте на семантических HTML-элементах, или DIY
Для меня это золотое правило доступности, для этого не нужно прикладывать никаких усилий.
Семантические элементы — те, которые передают определённое значение с помощью содержимого, которое они представляют. Например, <button>
, <input>
, <a>
, <h1>
и <p>
. Они передают контекст агенту пользователя (браузеру, устройству или вспомогательной технологии вроде скринридера), поэтому он будет знать как взаимодействовать с такими элементами и чего от них ждать.
Они отличаются от семантически нейтральных элементов, таких как <div>
и <span>
, или от презентационных, вроде <center>
и <big>
, которые не дают агентам представления о контексте.
В большинстве случаев семантические теги уже доступны (и дружественны для SEO). Это означает, что они отвечают многим принципам доступности прямо из коробки, например:
Когда вы не используете семантические элементы, вам нужно вручную задать ему всё это, чтобы сделать доступным.
Значит вам потребуется:
tabindex="0"
, чтобы компонент стал частью естественного порядка табуляции, и использовать focus()
, display: none
или aria-hidden
для того, чтобы избежать ловушек для фокуса. Про атрибут tabindex
читайте в Using Tabindex».role
, чтобы придать семантическое значение элементу и улучшить SEO-значимость. Узнайте обо всех возможных значениях role
в WAI-ARIA Categorization of Roles.outline: 0
(что не рекомендуется).Продолжаем разговор о семантических элементах. Вот ещё несколько вещей, которые нужно иметь в виду:
<h1>
.<label for="…">
для элементов форм <input>
, <select>
и <textarea>
.<a href="">
и никогда <span onclick="…">
. А если это кнопка, то <button>
, а не <a href="#" onclick="…">
.Что ж, семантические элементы кажутся более удобными, не так ли?
2. Обеспечьте альтернативу для картинок, цветов, звуков и движения
Вспомогательные технологии лучше всего работают с текстом. Когда вы используете что-то ещё, всегда добавляйте для них текстовые эквиваленты, например:
alt="description"
для информативных изображений (которые несут смысл, как фотографии или иконки без текста) и alt=""
для декоративных изображений (которые не несут смысловой нагрузки, например иконки внутри кнопок или дополненные текстом). Это особенно важно для ссылок в виде картинок.3) Привыкните использовать инструменты для проверки доступности в повседневной работе
Это, пожалуй, самое полезное правило, которое поможет понять, что вы упустили что-то в двух предыдущих.
Я перечислю здесь несколько инструментов для проверки доступности. Попробуйте их использовать, запустите на своём сайте, посмотрите, что вы можете узнать благодаря им и попробуйте остановиться на каком-то из них. В основном встречается три типа инструментов, которые я рекомендую использовать:
а. Для вашего регламента разработки
б. Для ручного тестирования с реальными скринридерами
в. Для автоматического аудита