Web Accessibility in action. Знакомимся с WCAG-стандартом и тестированием доступности

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті.

Всем привет. Меня зовут Женя Поляков, я QA Lead в компании Astound Commerce и уже больше двух лет я занимаюсь развитием направления web accessibility testing. В материале я хочу поделиться своими мыслями, почему этот вопрос важен не только для бизнеса, но и для социума. Поскольку сегодня вопросы diversity и принятия всех групп общества обсуждают на всех мировых площадках, и это не могло не повлиять на IT-бизнес.

Что такое Accessibility testing

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

  • кто наши пользователи;
  • каким образом они пользуются сайтом;
  • какие потенциальные проблемы могут у них возникнуть.

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

1) Пользователи с очень плохим зрением, с определёнными формами расстройства зрения, а также с полным отсутствием зрения. Обычно, такие пользователи веб-решений используют Screen Readers. Эти приложения позволяют пользователям читать то, что находится на экране. К тому же пользователи этой категории обычно используют только клавиатуру без мыши.

2) Для людей с проблемами слуха нужна визуализация звука, будь то транскрипт или субтитры. У такой группы пользователей может возникнуть необходимость посмотреть видео, на котором есть звуковая дорожка, или послушать подкаст, и при этом нужно понять о чём говорят. Для решения этой задачи используются транскрипты видео и субтитры (речь идет о captions, а не subtitles, поскольку они также покрывают эффекты, музыку и т. д.)

3) Онлайн-решениями могут пользоваться и пожилые люди, которым необходимо больше времени для совершения каких-либо действий. Например, на сайте есть pop-up, который исчезает через три секунды после появления и нужно успеть на него нажать. Не все пользователи смогут быстро на него отреагировать. В таких случаях могут добавлять визуальные таймеры, которые показывают сколько времени осталось до окончания сессии или закрытия поп-апа. А также увеличивают время доступности контента

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

Для того, чтобы нормализировать подходы к доступности был создан стандарт WCAG (Web Content Accessibility Guidelines). Это общедоступный стандарт, в основу которого легли принципы доступности и инклюзивности.

Зачем бизнесу доступность?

На данный момент более одного миллиарда людей (15% всего населения) — люди с ограниченными физическими возможностями или же особыми потребностями. Из них самое большое количество людей с разными формами расстройства зрения. Какое количество потенциальных пользователей и покупателей теряют сайты/онлайн-магазины, которые не занимаются доступностью? Много. И это только одна из проблем.

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

Рис. 1 — Доступность в законодательстве разных стран. [Карта доступна по ссылке]

В 2017 году около 800 раз было подано в суд на компании или бренды по поводу доступности их сайтов. В 2018 и 2019 годах количество таких исков перевалило за 2200 обращений. На данный момент пока нет конкретных данных за 2020-ый, но ожидается что это количество будет около 2000. Из известных случаев в 2012 году было подано в суд на компанию Netflix. Пару лет назад пользователь с отсутствием зрения не смог заказать пиццу у Domino’s Pizza и подал на них в суд, тяжба длится до сих пор. В 2018 году подали в суд на компанию Apple потому, что их сайт, как заявили, не является совместимым со скрин ридерами.

Кратко о стандарте WCAG

Существует три уровня WCAG (Web Content Accessibility Guidelines) стандарта — A, AA, AAA:

  • Уровень A включает в себя 30 базовых пунктов WCAG. Это минимальный рекомендованный уровень. Его можно достичь без сильного влияния на дизайн. Из популярных пунктов: не текстовый контент должен иметь доступное имя (Accessible Name), функциональность должна быть доступна для пользователей, которые используют только клавиатуру. Все поля форм должны иметь ярлыки.
  • Стандарт является прогрессивным, поэтому уровень АА включает в себя 20 новых пунктов стандарта, а также 30 пунктов уровня А. Для данного уровня возможны изменения дизайна, чтобы соответствовать требованиям по контрасту. Так же добавляются требования по видимому фокусу, статус сообщениях и т.д.
  • Уровень ААА, который соответственно включает в себя АА и А уровни, добавляет еще 28 пунктов, которые сильно ужесточают требования по контрасту, для сложного текста должна быть упрощенная версия, не должно быть текста как части изображения и др. Данный уровень подразумевает жесткие ограничения по контенту и по структуре онлайн решения. Уровень AAA обычно не требуется, а имеет больше рекомендательный характер, поскольку для определённого контента он недостижим. Детальнее об этом по ссылке.

Стандарт WCAG поделен на четыре ключевых раздела:

  • осознаваемый (Perceivable);
  • работоспособный (Operable);
  • понятный (Understandable);
  • надёжный (Robust).

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

Рис. 2 — Пример сайта, который прошел соответствие WCAG уровню ААА

Живые кейсы

Ниже приведены примеры по некоторым пунктам WCAG стандарта.

Пункт 2.3.1 — Three Flashes or Below Threshold — Level A

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

Рис. 3 — Кейс доступности на примере аниме Покемоны

Япония, 1997 год, дети с нетерпением сидят у экрана и ожидают новую серию популярного аниме. Главный герой попадает в компьютерный мир и в определенный момент происходит серия взрывов. На экране красно-синие вспышки, которые занимают практически весь экран на протяжении четырех секунд. И как следствие, 685 людей по всей Японии забрали скорые с абсолютно разными симптомами: у кого-то болела голова, у кого-то были головокружения, приступы. Показ сериала прекратили на 4 месяца, затем восстановили, а эту серию удалили. В интернете, конечно же, эту серию можно найти и сейчас.

Как же это тестировать? Достаточно тяжело определить на глаз есть ли проблема на самом деле, или же её нет. Существует приложение, которое может помочь в этом — PEAT (Photosensitive Epilepsy Analysis Tool). Приложение бесплатное. По какой-то причине не работает с Chrome, но хорошо работает с Firefox. Вы запускаете сайт, оно сначала записывает видео, а потом уже его анализирует. Существует определенная safe-зона трех вспышек в секунду времени, которая считается безопасной для пользователя. Если я вижу мигающий контент на сайте, который тестирую, то я прогоняю видео через этот tool и смотрю действительно ли есть какие-то проблемы.

Рис. 4 — Пример работы приложения PEAT с проблемной серией Покемонов

Пункт 1.4.3 — Contrast (Minimum) — Level AA

Рассмотрим контраст. Есть определенные правила для контраста, которые также определяется стандартом. Приемлемый контраст маленького текста (маленьким считается текст 18pt или 14pt bold) равен 4,5:1, для большого текста — 3:1. Есть достаточно много приложений и сайтов, с помощью которых можно определить контраст. Даже с помощью DevTools в Chrome это можно достаточно легко проверить. Я лично часто использую WebAim contrast checker. Нужен только цвет фона и цвет текста.

Примеры:

Рис. 5 — Gucci — Контраст текста «May we help?» и «FStore» к фону 2.3:1

Рис. 6 — Cartiers — контраст текста на кнопке — 2.55:1

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

Рис. 7 — Правительственный портал Украины

И на этом можно было закончить, но вы можете обратить внимание на кнопку в правом верхнем углу — «Людям із порушенням зору». Если её нажать, то вся страница становится монохромной и контрастность увеличивается до приемлемого уровня:

Рис. 8 — Правительственный портал Украины в контрастном режиме

Наличие переключателя на вариант с большей контрастностью — это тоже вариант соответствия стандарту.

Пункт 1.4.1 — Use of Color — Level A

Это требование говорит о том, что нельзя, чтобы объекты на странице выделялись только цветом.

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

Для того, чтобы протестировать такое требование можно использовать разнообразные плагины для Chrome. Как пример, tool Colorblindly — позволяет посмотреть на сайт в разной цветовой гамме.

Рис 9. — Инструмент Colorblindly для просмотра сайта в разной цветовой гамме

Пункт 2.4.7 — Focus Visible — Level AA

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

Рис. 10 — Focus Visible на примере сайта Amazon

Пункт 2.5.1 — Pointer Gestures — Level A

Это требование в стандарте появилось с версией 2.1. Оно говорит о том, что для любого сложного действи — свайп, пинч, слайд и др. — должно быть альтернативное, более простое действие. Зачем это надо? Пользователям с когнитивными нарушениями могут тяжело даваться такие действия. Как пример решения — стрелочки на карусели с продуктами.

Рис. 11 — Пример соблюдения требования по Pointer gestures

Заключение

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

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

👍НравитсяПонравилось1
В избранноеВ избранном7
LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Короткая статья о том, какие тулзы можно использовать для проверки accessibility
dev.to/...​I-_THd_hr6KPhkjLLy-7MO1-E

Lighthouse report показав accessibility score 87 для visionaustralia.org
Як можна перевірити чи сайт пройшов AAA валідацію?

Насправді автоматичні перевірки покривають ну приблизно відсотків 30 всього (+ залежить ще ж як у вас сконфігуровано lighthouse, ну і 87 то малувато трохи). Тому треба проводити аудити вручну щоб впевнитись шо всі вимоги і правда покриваються. Ось вам цікава стаття про accessibility score :) www.matuzo.at/...​perfect-lighthouse-score

Мабуть. Але на даний моент lighthouse report показує досить валідні зауваження. Такі як послідовно спадаючий порядок хедінгів, accessible name кнопки чи пропущені [aria-*] атрибути

Звичайно валідні. Але недостатні

Цей сайт проходив аудит по версії 2.0 у жовтні 2013. Не думаю, що сайт змінився з 2013 року, але, звісно, зараз можуть бути додаткові проблеми. Сайт приведений лише як візуальний приклад обмежень які з’являются з рівнем ААА.
Також ця компанія займається наданням послуг для людей з порушеннямин зору в Австралії. Тому їм було потрібно пройти ААА аудит.
www.w3.org/...​entation_id=25#evaluation

Знайшов ще два приклади з репортами по версії 2.1. Lighthouse report дає 100 баллів. Можливо вони були би кращими прикладами.
www.lflegal.com
www.a11yportal.com

Результат аудита
www.w3.org/...​ion?implementation_id=121
www.w3.org/...​ion?implementation_id=180

O, круто. Дякую за приклади
До речі, а як можна зробити аудит свого веб-сайту?

Є 2 можливих варіанта:
1. Заказати сторонній аудит. Є багато компаній, які цим займаються.
Плюси: Ви отримаєте репорт з проблемами. Але цей репорт частіше всього потребую час на те, щоб зрозуміти проблему.
Мінуси: Це, звісно, коштує грошей. Також необхідно витратити час на вибір аудитора та на аналіз репорту. Також частина такіх організацій, нажаль, тестують лише за допомогою автоматичних інструментів. Жоден інструмент не зможе покрити 100% стандарту.
2. Зробити аудит самому. Частіше всього це робиться наступним чином. Сайт ділиться на однорідні типи сторінок. Потім кожен тип сторінок тестується згідно кожного пункту стандарту залежно від того, який рівень ви хочете досягнути.
Плюси: У Вас більше контексту ніж у сторонньої організаціі, тому ви можливо зможете знайти більше проблем. Не потрібно платити сторонній організації. Але це може бути спірним, адже Ваш час теж коштує грошей.
Мінуси: Потрібен час не те, щоб розібратись із стандартом.

Зрозуміло. Дуже дякую за інформацію

Такою можна використовувати тулзи, які вставляєш на сторінку та вона видає репорт: axe, ibm equal access

github.com/dequelabs/axe-core
github.com/IBMa/equal-access

Непоганий виклад інформації, дякую.
Цікаво би було почути як ви в команді робите асесмент аксесибілі проблем на сторінках.
Чи є якийсь вироблений підхід і послідовність для цього?
Також цікавить як ви працюєте з мобільними рідерами та десктопними.

Дякую.
Ми опрацювали кожен пункт стандарту для того, щоб зрозуміти що саме необхідно тестувати та розробили декілька чеклістів, що допомагають нам у тестуванні.
Наведу приклад процесу який ми використовуємо на моєму проекті.
Є декілька моментів:
1. Декілька років тому, коли ми тільки почали займатися доступністю, нам необхідно було зробити первинний аудит. Тоді ми почали вивчати стандарт та створювати чеклісти по ньому. Провели аудит та виправили більшість проблем.
Так як я писав вище, що це не одноразова робота, то далі ми змінили частину процесу для включення тестування доступності до загального складу тестування.
2. Тепер вимоги до доступності є частиною аналізу будь-яких вимог. Частина проблем вирішується ще перед початком розробки функціональності
3. Тестування доступності є частиною тестування кожної функціональності.
4. Десь кожні 6-9 місяців ми витрачаємо час на додатковий повний аудит.
Стосовно самого процесу аудиту. Ми ділимо сайт на типи сторінок і тестуємо кожний тип сторінки по всім пунктам стандарту.

Стосовно скрін рідерів. Переважно використовуємо NVDA, тому що він є одним з популярних рідерів згідно звіту (webaim.org/...​ects/screenreadersurvey8) WebAim 2019 року. Не рекомендую використовувати плагін ChromeVox тому що він читає тільки на рівні браузеру, в той час як NVDA читає на рівні системи.
З мобільних ми частіше всього використовуємо VoiceOver. Більшість проблем з доступністю є загальною як для мобільних так і для десктопа. На мобільних ми переважно тестуємо функіональність яка є унікальною для мобільних, наприклад бургер-меню.

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

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

А может кто-то на английский, русский, украинский или любой другой человеческий язык это перевести?

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

Подписаться на комментарии