Выпуск 7

Прошлое и настоящее WCAG

Темы

События

Расшифровка

Таня Фокина: всем привет! С вами «Инклюзивный ананас» — первый русскоязычный подкаст о доступных интерфейсах. Здесь мы обсуждаем всё, что связано с цифровой доступностью и делимся свежими новостями и событиями. Подпишись, чтобы не пропустить новые выпуски.
С вами ведущие подкаста Глаша Жур, фронтенд-тимлид и преподаватель на курсах по веб-доступности, а также Таня Фокина, редактор раздела доступности в Доке, дружелюбном справочнике по фронтенду, и большая любительница поговорить о доступности.

Глаша Жур: вы могли заметить, что WCAG 2.2 не так давно стал официальной рекомендацией. Это произошло в октябре 2023 года. Так что сегодня копнём вглубь истории и проследим за тем, как изменялась структура WCAG вообще со временем. Разберёмся поподробнее с тем, что изменилось в новой версии руководств.

Таня: Начнём с новостей.

Новости

Таня: Chrome со 118 версии поддерживает prefers-reduce-transparency — значение директивы @media, которая отслеживает отключение или уменьшение прозрачности в операционной системе пользователя. С помощью этого значения можете отменять прозрачность, заданную фону через свойство opacity, эффект матового стекла и прочий гласморфизм, а ещё перемещать тексты под блоки с фоновыми картинками и вырвиглазными паттернами.

Глаша: а Tilda — популярный блочный конструктор сайтов, на который мы все всегда ругаемся, что в нём нет доступности, недавно сделал анонс, что доступность, всё-таки, появилась.

Они сделали блоки из своей библиотеки более доступными. Теперь в блоках используются теги для заголовков разного уровня, атрибуты alt у картинок, ориентиры для хедера и футера. Для списков используют теги <ul> и <ol>. У форм появилась доступная валидация и подписи к полям. В слайдерах, вкладках и попапах — ARIA-разметка, которая делает их доступным для пользователей скринридеров. Короче, завезли HTML.

Устройство WCAG

Глаша: Таня, ты признанный эксперт по WCAG, признанный точно мной как минимум. Мы с тобой в прошлом выпуске проводили собеседование на роль эксперта по доступности, там у нас были вопросы по WCAG. И, конечно, когда ты отвечаешь на вопросы по WCAG, у меня все кирпичики становятся в голове на нужное место. Поэтому кто, как не ты, должен рассказать о том, что вообще сейчас такое WCAG? Что это, почему мы этим пользуемся, как он структурирован, какие там есть классные штучки? Поэтому передаю тебе слово.

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

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

Как устроен WCAG? WCAG состоит из базовых принципов. Это такие ключевые вещи, вокруг которых вращается всё остальное во WCAG. И это четыре базовых принципа — воспринимаемость, управляемость, понятность и устойчивость. Дальше внутри руководств есть отдельные руководства, как бы это странно ни звучало. Например, к принципу воспринимаемости относится руководство 1.1. Текстовые альтернативы. Или, например, ко второму принципу «Управляемость» относится руководство 2.1. Доступность с клавиатуры.

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

Важно понимать, что в WCAG состоит из двух больших частей внутри себя. Контент в нём можно разделить на нормативный и ненормативный. Нормативный — это то, что мы точно должны соблюдать. Это, собственно, критерии, они нормативные, а объяснение критериев, как их выполнять, всякие примеры… разметки, документов уже внутри — это не нормативное, не обязательное.

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

И во WCAG второй версии, то есть 2.1, 2.2, 2.0, у нас три уровня: одинарное А, двойное А и тройное А. Одинарное — это самый-самый минимум, вот, например, как субтитры или как альтернативное описание. Двойное А — это, кстати, самый достижимый, наверное, уровень, на который, в принципе, все законы ссылаются про доступность. Это уже чуть более продвинутые критерии, которые всё ещё довольно очевидны. Например, к уровню AA относится критерий 1.2.4. Субтитры к живым трансляциям. И который говорит о том, что если у вас на YouTube-канале, например, идёт стрим, у него должны быть субтитры. И повторюсь, обычно сайты должны стремиться к AA, пока у нас действует WCAG второй версии.

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

Глаша: у нас в Твиттере есть прикольный кейс [случай]. Короче, у нас есть такая девчонка Наташа Давыдова, которая для джунов делает канал свой. Она в комьюнити [сообществе] довольно известная. И они сделали хакатон, и вот он недавно прошёл. И там у них на финальной части хакатона, где нужно презентацию делать, был голосовой стрим полностью. Но в аудитории в одной из команд была девушка с нарушением слуха. Они узнали об этом за пять минут до начала стрима. То есть они ничего не могли сделать, чтобы включить субтитры быстренько, автораспознавание какое-то там технически классное, настроенное.

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

Как развивался WCAG

Таня: давай археологическими раскопками заниматься.

Глаша: cейчас у нас версия WCAG 2.2. Мы очень давно её ждали. Но не так давно, как мы ждали предыдущих всех версий в предыдущие периоды времени.

Всё началось в далёком 1999 году. Ну, чтобы вы понимали, когда зародилась доступность. Потому что до этого же ведь… в 1999 первый WCAG только стал рекомендацией, a до этого его ещё какое-то время разрабатывали. И смешно, но устарел WCAG 1.0 только в 2021 году. И предназначен был этот WCAG, собственно, оттуда его и название, я так полагаю, появилось, Web Content Accessibility Guidelines, он был предназначен только для веб-контента, для авторов веб-страниц, для авторов дизайнов сайтов. И также он был предназначен для разработчиков авторских инструментов.

Сейчас для авторских инструментов, насколько я знаю, есть ATAG — отдельный гайдлайн [руководство], где про авторские инструменты очень подробно написано, что там нужно учесть и что не нужно. Но в целом, да, то есть это было исключительно для веба. Основная цель WCAG была продвижение доступности веба. Почему-то мы всё ещё преследуем эту цель спустя столько лет. Это было сколько лет? 24 года! Мы всё ещё пытаемся продвинуть доступность веба куда-то. Вон Tilda добавила HTML в свои шаблоны (Глаша смеётся).

Глаша: да, WCAG 1.0 содержал 14 рекомендаций, вот тех самых гайдлайнов, руководств. И это были рекомендации по типу общих принципов доступного дизайна. Каждое руководство включало в себя формулировку руководства, обоснования, и некоторые группы пользователей, которым [руководство] может быть полезно. Кстати, во WCAG 2.2, в той описательной части, про которую Таня говорила, куда не обязательно сунуть носик, но очень интересно, там всегда написаны тоже группы пользователей, которым полезен данный конкретный критерий. И оттуда информацию берут уже всякие плагины для тестирования, которые тоже эту информацию в себе содержат, чтобы подсказать вам, кому полезна и удобна та или иная фича.

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

WCAG 1.0 был очень интересным документом, но нужно было что-то менять. В какой-то момент поняли, что недостаточно хороша структура для того, чтобы её блюсти, и на смену WCAG 1.0 в 2008 году пришёл WCAG 2.0. Эти гайдлайны уже предназначены для всех технологий. Да, они всё ещё называются Web Content Accessibility Guidelines, но теперь учитывается не только веб. Хотя, на самом деле, до сих пор мы предполагаем, что учитывается только веб, и всегда говорим, что для мобил WCAG не используется, потому что в мобилах некоторые кейсы вообще по-другому работают, и некоторые критерии WCAG неприменимы к мобильным девайсам, и там к десктопным, например. Но WCAG стремится к тому, чтобы стать гайдлайнами для диджитал-продуктов [цифровых], независимо от платформы.

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

Всего появилось 12 рекомендаций и 61 критерий в общей сложности, из них 38 критериев уровня A и AA, то есть обязательных. Когда вы поддерживаете доступность под законодательство, вы обязаны поддержать A и AA, это вот 38 критериев. И 23 критерия уровня AAA. Получается, что, перемещаясь от WCAG 1.0 к WCAG 2.0, мы получили вот эти четыре основных принципа, по которым все критерии делятся, мы получили список рекомендаций, и у каждой рекомендации появились критерии успеха, и, собственно, появилось разделение на уровни A, AA и AAA. Немножко пересобрали всю структуру и добавили информации. Плюс сконцентрировались больше на всех технологиях, а не только на вебе.

Дальше пришёл к нам WCAG 2.1, он стал рекомендацией в 2018 году. То есть между 2.0 и 1.0 девят лет, получается, перерыва, а тут всего лишь тоже десять лет перерыва… не всего лишь, а в целом. Пользуемся мы гораздо дольше WCAG 2.1. Всё ещё есть законодательства, которые ссылаются на 2.0, к сожалению.

Структура уже не менялась сильно. Добавились новые гайдлайны, новые руководства, их стало 13, и добавлены новые критерии WCAG 2.1. 12 критериев добавили. Мало им критериев. И всё ещё не было критерия про достаточную контрастность фокуса. Мне кажется, это был один из самых частых критериев, по которому мы плакали, что его нет в 2.1. В общей сложности во WCAG 2.1 стало 78 критериев, из них 50 критериев A и AA, и 28 критериев уровня AAA.

В октябре [2023], собственно, в начале октября мы были счастливы анонсировать, что WCAG 2.2 стал рекомендацией, в ней всё ещё 13 гайдлайнов, и было добавлено шесть новых критериев уровня A и AA, и три новых критерия уровня AAA, и один критерий 4.1.1. Парсинг был удалён. Мы в выпуске про доступность с клавиатуры, как раз это был у нас пятый выпуск, Таня объясняла, почему парсинг убрали. В общем-то, потому что, по сути, его подразмазали немножко по другим критериям, и, в целом, кажется, за ним не надо так пристально следить, потому что это больше про правильное написание кода, с моей точки зрения, чем про доступность.

В общем, теперь нам нужно поддерживать 86 критериев, если мы нуждаемся в уровне максимальной доступности AAA, но, если нет, то 57 критериев. Пойди, прочитай, разберись, удачи! Круто проследить именно за датами, что между WCAG 2.0 и 2.1 прошло десять лет, а между 2.1 и 2.2 прошло всего пять. Мы близимся к какому-то сокращению, и надеюсь, что в будущем нас ждут новые рекомендации, но там вообще планируют дикий пересбор WCAG зачем-то снова. А сейчас нам хочется, как и всем, на хайпе рассмотреть, какие же новые критерии появились во WCAG 2.2, и поэтому, Таня, расскажи-ка нам.

Что нового во WCAG 2.2

Таня: давайте быстро пробежимся тогда по критериям, о которых мы уже рассказывали в выпуске про клавиатуру. Это два критерия 2.4.11 и 2.4.12 про фокус, который не должен быть скрыт другим элементом. 2.4.11 — AA и 2.4.12 — продвинутый AAA. Критерии относятся к руководству про навигацию внутри принципа про управляемость, и оба критерия говорят о том, что элементы не должны быть… интерактивные элементы, в частности, кнопки, поля, ссылки, не должны быть перекрыты другими элементами поверх них, например, какими-то немодальными окнами. И на уровне пониже, AА, допускается всё-таки, когда там где-то чуть-чуть ссылочка сбоку перекрыта, наехал на неё выезжающий попап из-за края экрана, то, соответственно, на продвинутом уровне вообще ничего нельзя никем перекрывать.

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

Глаша: я не знала почему-то и думала, что всё хорошо и легко будет нам теперь с этим внешним видом фокуса, но он AAA.

Таня: да, но… Там же были баталии по этому поводу. Сначала он планировался как двойного уровня, AAA, но из-за того, что он был супер сложным, супер объёмным и вообще его не так легко было распарсить не то что браузеру, но человеку, он стал ААА.

Глаша: Но это же не повод делать его ААА. Ну сделайте какое-нибудь простое описание для AA, алё, я столько лет продвигала эту идею, всем говоря, что в 2.2 будет требование к визуальному отображению фокуса. И что теперь делать? Получается, дальше партизанить?

Таня: слушай, ты думаешь почему WCAG 3 будет? Как раз из-за этого, из-за этого, всё из-за внешнего вида фокуса, 100%.

Глаша: угу. Будет у нас золотой критерий… Критерий на вес золота. Спойлеры-спойлеры [Глаша делает отсылку к тому, что во WCAG 3 успешность критерия будет определяться по цветам драгметаллов, и скамый классный — это золотой].

Критерий 2.5.7. Движения перетаскиванием (AA)

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

A там же нет, получается, части AAA, там только AA? Нет никаких дополнительных… нет никакого упрощения требований. То есть если уже у тебя есть драг-н-дроп, ты его делаешь доступным. В общем, всё, что вы можете перетащить, нужно всему этому предоставить альтернативный способ ввода, и этот способ должен иметь что-то одно, чтобы ввести данные, то есть нужно либо тыкнуть куда-то мышкой один раз, либо тапнуть пальцем один раз, либо с клавиатуры нажать одну клавишу, то есть, чтобы вы могли так называемое single pointer движение осуществить, чтобы вам не нужно было зажимать, перетаскивать двумя пальцами что-то куда-то, в общем, чтобы можно было сделать «тык», и, допустим, набрать что-нибудь и сделать второй «тык», а-ля сабмит [принятие], и данные ввелись.

За чем вам нужно следить, чтобы блюсти этот критерий? Этот критерий не только про клавиатуру, он больше про альтернативные способы ввода, такие как трекболы, это могут быть какие-то указатели, которые крепятся к голове, что часто очень используется людьми, которые парализованы ниже шеи, например. Это могут быть какие-нибудь системы, которые трекают передвижение глаз, и это могут быть системы, которые голос ваш трекают, то есть вы голосом ввод какой-то совершаете, конечно же вы не можете дать компьютеру команду «ну-ка перетащи эту карточку из одного места в другое». Вам нужно «выдели карточку», там, «перенеси её в другую колонку», «вставь её в другую колонку», типа того. Вы не должны полагаться только на драг-н-дроп технологии, вы должны предоставить альтернативные способы ввода.

Из примеров это может быть карта, которую вы можете увеличивать, уменьшать, передвигать вверх, вниз, влево, вправо. Обычно мы это делаем какими-нибудь свайпами, тащим её куда-нибудь, либо мышку зажимаем на ней и тащим, но часто в картах есть альтернативный способ — это кнопки. То есть кнопка — это как раз пример single pointer, когда вы просто нажали один раз и всё. Вы нажали кнопку вверх, и сместилась карта немножко вверх. Вы нажали кнопку зума, увеличить карту, и она увеличилась.

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

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

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

Критерий 2.5.8. Размер цели (Минимальный) (AA)

Таня: о следующем критерии, на самом деле, мы немножко говорили чуть ли не в самом первом выпуске нашего подкаста, про размер цели. Повторим самое важное. Это критерий 2.5.8. Размер цели (Минимальный), он AA и относится к руководству про способы ввода. Там, на самом деле, есть ещё критерий про максимальный размер цели: 2.5.5. 2.5.5, соответственно, максимальный, просит вас сделать кнопочки, например, размером 44х44 минимум, а минимальный 2.5.8, о котором хочу подробно поговорить, 24х24 пикселя минимум.

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

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

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

Глаша: прикольно, что они сделали сначала 2.5.5. Target Size, который enhanced [продвинутый], то есть они его не стали переносить ниже, просто добавили 2.5.8.

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

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

Критерий. 3.2.6. Последовательная помощь (A)

Глаша: так, следующий критерий, который мы хотим обсудить, это 3.2.6. Consistent Help он называется. Собственно, консистентная помощь, последовательная помощь. Идея этого критерия в том, что... в целом, все критерии в пункте — про понятность, про то, что ты должен, глядя на страничку и перемещаясь по веб-сайту, понимать, что происходит в каждом моменте. Ты должен встречать меню в том же месте, где оно и было, встречать другие элементы там же, где они и были на предыдущих страницах. Если функциональность повторяется, спрятанная за определённой кнопкой, то она не должна меняться под этой кнопкой дальше на других страницах. То есть, это всё про понятное перемещение по интерфейсам, про предсказуемое перемещение.

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

То есть, пользователь просто должен всегда знать, куда ему тыкнуть, чтобы обратиться за помощью. Если у вас есть всплывашка с чатом, то, если вы её уже расположили на одной странице в нижнем правом углу, имейте совесть, располагайте ёе там всегда на других страницах. Очень часто бывает, когда сайты строятся на нескольких системах, и это особенно в e-commerce [электронной коммерции] часто происходит, когда, допустим, одна страница построена твоей системой управления сайтом, а вторая страница построена каким-нибудь плагином, который ты накинул на эту систему управления. И плагин даёт тебе немножко другие стили, другую навигацию.

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

Такие механизмы помощи могут быть контактами людей, к которым можно обратиться за помощью. Например, номер телефона или e-mail, или часы работы человека, который вам помогает. Это может быть какая-то система месседжей [сообщений], либо чатов. Это может быть также «сам себе помоги» система. К этой системе относятся такие страницы, как FAQ, часто задаваемые вопросы. Кстати, не знала, что есть такие How Do I Pages. Типа, как мне что-то сделать. Это какие-то страницы по саппорту [поддержке]. И ещё могут быть чат-боты. То есть к этому пункту относятся основные механизмы запроса помощи пользователям. К этому пункту не относятся механизмы, которые помогают вам в моменте познакомиться с интерфейсом. То есть есть часто такие библиотечки, которые помогают пошагово изучить интерфейс, с какими-то попапчиками, подсказками и прочим. Это отдельная статья расходов в доступности, которую тоже надо продумать, но там комплексное продумывание: как эти попапы правильно реализовать, чтобы в моменте их чтения не читалось всё остальное тоже. Чтобы это была действительно полезная помощь для всех людей с разными особенностями. Так что, в этом критерии это не учитывается.

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

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

Критерий 3.3.7. Избыточный ввод (A)

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

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

Критерии 3.3.8. Доступная аутентификация (AA) и 3.3.9. Доступная аутентификация (AAA)

Глаша: следующий критерий… на самом деле это два критерия: 3.3.8 и 3.3.9, но они оба об одном. Это доступная аутентификация. Наконец-то мы можем найти себе во WCAG критерии, где есть слово «капча», и пользоваться им налево и направо. В общем, 3.3.8 предполагает уровень доступности AA. 3.3.9 предполагает уровень доступности AAA. То есть, если вы делаете по законодательству, вы обязаны делать AA. Если у вас есть в аудитории требование предоставить интерфейс людям с инвалидностью, то вы тогда AAA обеспечиваете.

Вообще, цель данного критерия — это обеспечение доступного и простого способа входа в систему. Ну, безопасного, естественно. Очень большое количество веб-сайтов используют систему логин-пароль. И дальше, после логина и пароля, начинаются какие-то невероятные заходы типа: «А, может, дополнительно аутентифицируетесь [авторизуетесь]? А, может, как-то своё лицо сфоткайте? Палец покажите? Выберите такси на всех картинках из всех картинок, или, я не знаю, корабли». У меня всегда проблема с проводами, потому что они почему-то цепляются за соседнюю картинку, и непонятно, это часть провода или не часть.

На днях я заполняла капчу, и я прошла её, выбрав две клавиатуры из трёх… предоставленных. То есть, кажется, что капчи стали многоэтапные. То есть, ты на первом этапе выбираешь клавиатуры, потом на втором этапе ты опять выбираешь клавиатуры. И кажется, что неважно им уже все ли ты выбрал клавиатуры. Важно, чтобы на каждом этапе ты выбрал клавиатуры. Может быть, даже не менее двух. Ну, не знаю, в общем, да. В моменте, когда я подумала «Блин, мне сейчас третий этап придётся проходить, потому что я не выбрала третью клавиатуру», мне сказали, что я прошла капчу.

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

Либо другой метод аутентификации, который не зависит от проверки когнитивной функции, и здесь могут быть проверочные коды, например, смски или e-mail. Это могут быть QR-коды, которые можно отсканировать с помощью приложений. Либо у вас есть механизм, который помогает пользователю заполнить этот тест на когнитивные функции, то есть что-то, например, браузер может предоставить какое-то автозаполнение, либо вы можете использовать сторонние менеджеры паролей, чтобы зайти в ваш аккаунт. Дальше тест на когнитивную функцию может заключаться в распознавании объектов, вот это та самая капча. То есть, по идее, капча считается доступным способом в случае, если она с графикой какой-то, то есть она более тогда адекватно воспринимается людьми, ну, не адекватно, но, скажем так… проще её распознать, чем решить пример, либо что-то сложное, не знаю, сделать из разряда, прислать фотку с пальцем, когда у тебя может не быть вообще пальцев, вот это забавные такие кейсы аутентификации.

И ещё в качестве альтернативы можно сделать механизм распознавания нетекстового контента, который пользователь предоставляет сайту. Это может быть вот этот момент, когда вы там картинку какую-нибудь скидываете. Последний способ альтернативный – это предоставление какого-то нетекстового контента для распознавания вашей личности. Это может быть изображение, либо аудио, либо видео, либо геолокация, что-нибудь такое. Кстати, пин-код. Ух ты! Это графические коды, вот эти все прикольные штуки. В общем, в минимальном уровне AA вы всё ещё можете использовать капчу, просто нужно предоставить её доступность в том числе.

У нас недавно в комьюнити незрячий коллега записал видео, как он проходит капчу для ChatGPT, и это прикольно, потому что у них капча доступна для скринридеров. Там в какой-то момент тебя просят определить, какой из звуков принадлежит настоящему коту, и дальше тебе предоставляют несколько сэмплов [образцов] звука, и какой-то из них – это, очевидно, человек делает мяу. Но, честно говоря, не всем доступен такой способ распознавания. Прикольно, что они графическую капчу переделали в звуковую и предлагают распознать что-то отличное от всего остального и выбрать какой-то вариант. Капча… ей придётся переродиться в какой-то момент, но сколько мы об этом говорим уже, конечно, вечность.

Что касается более сурового пункта, то там есть только два исключения из него. В случае, если вам нужно поддерживать уровень AAA, вы можете только вещи две сделать к вашим логину и регистрации. Это предоставить другой метод аутентификации, чем ввод логина и пароля, не основанный на проверке когнитивной функции. То есть вы можете залогиниться с помощью сканирования QR-кода, например. И второе исключение – это когда у вас есть механизм, который помогает пройти тест на когнитивную функцию. Очень важно, что все этапы многофакторной аутентификации должны содержать какие-то альтернативные методы. Очень важно не заставлять людей решать примеры, что-то вспоминать, перезаписывать, вводить руками постоянно.

Очень важно давать возможность копировать и вставлять, потому что часто в формах аутентификации нельзя что-то вставить, либо оно вставляется как-то криво. Но это не относится к тому моменту, когда это нужно для безопасности. Тоже частый кейс, когда нужно повторить e-mail. В случае, когда вы делаете что-то типа двухфакторной аутентификации, которая требует использования второго девайса [устройства]. То есть вы на сайт пытаетесь зайти, вам нужно с телефона что-то сделать, допустим, вам туда код присылают. Нужно иметь ввиду, что для людей может быть сложным скопировать этот код с одного девайса и вставить его на другой. Тут возможно предусмотреть способы отправки этого кода непосредственно на основное устройство, с которого вы аутентификацию совершаете.

И ещё интересный момент, что когда скрываете символы по дефолту [по умолчанию] в полях, допустим, пароль или каких-то секьюрных данных, и не даёте возможности их посмотреть, это может быть большим блокером при проходе аутентификации. Для меня это всегда очень больно, когда я не могу посмотреть пароль, который сейчас ввожу. То есть я не понимаю или не сразу понимаю, на каком языке ввела пароль. Обычно очень много требований к паролю, типа восклицательный знак, большая буква. И ты такой, блин, а куда я эту большую букву вставил? То есть тебе приходится что-то запоминать очень сильно. Ну, дайте, в общем, возможность пользователю посмотреть… чего он сейчас ввёл. Это нормально.

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

События

Таня: события.

Появился плейлист с докладами с Web Accessibility in Mind Conference 2023, так что можете пойти посмотреть, что там интересного было, если пропустили конфу.

И, наконец, открыта регистрация на axe-con 2024. Уже появилась программа, так что можете регистрироваться, добавлять в избранное доклады, которые хотите посмотреть. Она пройдёт с 22 по 24 февраля онлайн и она бесплатная. И очень клёвая.

Таня: с вами был подкаст «Инклюзивный ананас» и его ведущие Глаша и Таня. Вы можете найти нас на любой подкаст-платформе. До встречи в следующем выпуске!