Перевод подготовила Ольга Кудрявцева.
Данная статья представляет собой краткий обзор новых критериев успеха в редакторской версии WCAG 2.2 (Руководство по обеспечению доступности веб-контента версии 2.2). Мы расскажем о каждом новом критерии, опишем требования к ним простым языком и обсудим, как можно добиться практического внедрения критериев.
Не похоже, что на данном этапе произойдут какие-то нормативные изменения в Руководстве, скорее будут внесены небольшие правки перед тем, как документ перейдет на стадию рекомендаций. Вероятнее всего, это произойдет через несколько месяцев, поэтому сейчас самое время начать планирование интеграции новых критериев успеха в процессы тестирования или разработки.
По сравнению с WCAG 2.1 Руководство WCAG 2.2 содержит относительно небольшие добавления. Было внесено 9 новых критериев успеха: 2 на уровне соответствия А, 5 на уровне АА и 2 на уровне ААА.
- 2.4.11 Фокус не скрыт (минимальные требования), уровень АА
- 2.4.12 Фокус не скрыт (расширенные требования), уровень ААА
- 2.4.13 Не закрытый указатель (расширенные требования), уровень ААА
- 2.5.7 Движения при перетаскивании элементов, уровень АА
- 2.5.8 Размер мишени (минимальные требования), уровень АА
- 3.2.6 Единообразие в предоставлении справочной информации, уровень А
- 3.3.7 Доступная аутентификация, уровень АА
- 3.3.8 Доступная аутентификация (без исключений), уровень ААА
- 3.3.9 Избыточный ввод информации, уровень А
Критерий успеха 2.4.11 Фокус не скрыт
Данный критерий посвящен заметности индикаторов указателя. Он частично включает в себя 2 уже существующих критерия успешного применения: 2.4.7 Видимый указатель (который требует, чтобы указатель был видимым) и 1.4.11 Контрастность нетекстовой информации (который, кроме всего прочего, определяет, что обозначение указателя должно иметь коэффициент контрастности не менее 3:1 по сравнению с фоном).
Однако, новый критерий успешного применения имеет также дополнительные требования к контрастности между областью с наведенным указателем и областью без наведения, и возможно, также к форме или толщине самого индикатора указателя. То есть данный критерий идет дальше ранее сформулированных критериев успешного применения и требует не просто того, чтобы указатель был видимым, но и определяет минимальный уровень такой видимости. Это полезно для всех, кто пользуется клавиатурой, но особенно для слабовидящих пользователей.
Существующий критерий 1.4.11 определяет, что индикаторы указателя должны иметь минимальную контрастность, но в явном виде не требует того же при определении границы между областью с наведенным указателем и областью без наведения (хотя, по моим данным, некоторые тестировщики интерпретируют данный критерий таким образом и считают критерий 1.4.11 невыполненным по этой причине). Новый критерий успешного применения 2.4.11 с точностью определяет этот параметр: различие между индикатором указателя и пикселями, которые потребуются, когда индикатор указателя не виден, должно иметь коэффициент контрастности не менее 3:1. Это требование объясняется тем, что низкоконтрастная смена в пределах области может быть сложной для различения некоторыми пользователями; если область элемента с наведенным указателем визуально очень близка к этой же области без наведения указателя, тогда пользователи могут не уловить эту разницу.
Поэтому, например, если кнопка имеет белую границу, которая меняет цвет на голубой при наведении указателя, тогда отличие между белым и голубым цветами должно иметь коэффициент контрастности не менее 3:1, также как и коэффициент контрастности голубого цвета относительно фона должен быть не менее 3:1. Если голубая граница напрямую соприкасается с кнопкой, тогда она также должна иметь коэффициент контрастности не менее 3:1 относительно фона кнопки.
И наконец, критерий 2.4.11 требует, чтобы сам по себе индикатор указателя или четко окружал элемент, или имел достаточную толщину линий, чтобы быть заметным даже без полного окружения элемента. Здесь ключевое слово – четко: пунктирный контур толщиной 1 пиксель не может четко окружить элемент (потому что сам по себе он не настолько заметен), поэтому он не отвечает требованиям данного критерия.
Однако, критерий успешного применения 2.4.11 также предлагает второй вариант соответствия данному критерию через утолщение индикатора указателя в том случае, когда индикатор указателя не четко окружает элемент. В этом случае в качестве индикаторов указателя могут выступать пунктирные контуры, одиночные сплошные линии (например, под элементом или внутри него) или непрямоугольные границы элемента. Они соответствует данному критерию успешного применения в случае, если они занимают достаточно места по сравнению с размером элемента. Точные расчеты для подобных размеров могут быть очень запутанными, поэтому для более детального понимания лучше обратиться к пояснительным документам.
Как соответствовать критерию 2.4.11
Самый простой способ обеспечить соответствие данному критерию успешного применения – использовать четкие контуры для обозначения указателя. Толщина контура размером в 1 пиксель достаточна для соответствия, но я бы рекомендовал использование толщины контура размером в 2 пикселя, чтобы сделать границу еще более ясной.
Контур указателя виден, когда элемент выделен, и не виден, когда выделения нет, то есть в данном случае уровень контрастности между этими двумя вариантами такой же, как и уровень контрастности между контуром и его фоном. Если контур представлен таким образом, что он не касается элемента, тогда уровень контрастности опять же нужно сравнивать с фоном, а не с элементом. Этого можно добиться несколькими путями, используя такие приемы, как: граница, прямоугольная тень или контур-смещение там, где это применимо.
Если контуры указателя созданы подобным образом, тогда существует только 1 необходимый к применению в данной ситуации уровень контрастности: контур относительно фона. А так как обычно четкий контур полностью окружает элемент – это свидетельствует о полном удовлетворении всех требований данного критерия успешного применения.
Если было выявлено соответствие данному критерию, то нет необходимости отдельно тестировать критерий успешного применения 2.4.7 Видимый указатель; соответствие критерию 2.4.11 также означает соответствие критерию 2.4.7. Обратите внимание, что сам критерий 2.4.7 был обновлен в руководстве WCAG 2.2: был изменен его уровень с АА до А.
Критерий успеха 2.4.12 Фокус не скрыт (расширенные требования)
Критерий успешного применения 2.4.12 заключается в том, что выделенные элементы не могут быть закрыты другим контентом. Это применимо только к тем элементам, которые в данный момент действительно выделены, а не ко всем элементам, которые могут быть выделены. Это полезно для всех, кто пользуется клавиатурой, но особенно для пользователей с когнитивными расстройствами или нарушениями памяти для того, чтобы можно было легко определить, где сейчас находится указатель.
Подобная ситуация чаще всего может возникнуть с такими приемами, как: фиксированные липкие заголовки и немодальные диалоги. Например, если вы находитесь на странице с липким заголовком и перемещение по странице заставляет заголовок следовать за вами, при этом полностью закрывая выделенный элемент, – это несоответствие данному критерию. Если выделенный элемент закрыт частично (например, наполовину) – это не свидетельствует о несоответствии данному критерию.
Пояснительные документы для этого критерия успешного применения обращают внимание на тот факт, что сюда не относятся ситуации, когда пользователь сам может передвинуть контент и при этом закрыть выделенный элемент. Например, если перемещаемый немодальный диалог был передвинут пользователем так, что он закрыл выделенный элемент, то это не свидетельствует о несоответствии данному критерию успешного применения; имеет значение только первоначальное состояние элементов.
Также данный критерий можно применить и другим образом: если пользователь может перемещать контент и таким образом открыть закрытый элемент (например, используя курсорные клавиши для прокручивания липкого заголовка) – то это свидетельствует о несоответствии данному критерию успешного применения, потому что это не первоначальное состояние выделенного элемента.
Как соответствовать критерию 2.4.12
Самый простой способ обеспечить соответствие данному критерию успешного применения – это полное отсутствие фиксированного или плавающего контента. (Это также пересекается с критериями 1.4.4 Изменение размера текста и 1.4.10 Изменение формата, в случае если масштабирование страницы приводит к тому, что выделенные элементы или любой другой контент становятся закрытыми).
Однако, такой подход не совместим с реальностью. По какой-то причине фиксированные липкие заголовки являются популярным дизайнерским решением. Поэтому любой контент необходимо тщательно тестировать, вручную перемещаясь по всей странице, чтобы убедиться, что ни один элемент полностью не закрывается, когда он выделен.
Критерий успеха 2.4.13 Не закрытый указатель (расширенные требования)
Критерий успешного применения 2.4.13 похож на критерий 2.4.12 за исключением того, что он более жесткий. Несоответствие предыдущему критерию устанавливается, когда выделенный элемент полностью закрыт, а в случае с критерием 2.4.13 несоответствие устанавливается, когда любая часть выделенного элемента закрыта.
За исключением того, что есть определенная неоднозначность в том, как критерий сформулирован. Нормативное требование для критерия 2.4.12 – компонент не может быть полностью скрыт. Тогда как требование для критерия 2.4.13 – ни одна из частей индикатора указателя не может быть скрыта. То есть гипотетически контент может соответствовать данному критерию, если индикатор указателя полностью видим, а элемент, который он окружает, скрыт.
Однако, пояснительные документы говорят в целом об элементе или компоненте, а не об индикаторе указателя, поэтому к этому можно относиться как к оговорке в формулировке критерия: критерий успешного применения 2.4.13 говорит полностью обо всем элементе, включая его индикатор указателя, а не только об индикаторе указателя.
В любом случае это неоднозначное утверждение. Например, рассмотрим случай, когда есть кнопка и текст на ней является видимой меткой. Если текст на кнопке скрыт, тогда мы видим несоответствие критерию успешного применения 3.3.2 Метки или инструкции, и неважно соответствует он при этом критерию 2.4.13 или нет.
Критерий успеха 2.5.7 Движения при перетаскивании элементов
Критерий успешного применения 2.5.7 касается интерфейсов, в которых используются движения указателя – такие, как перетаскивание или сортировка перетаскиванием. Он определяет, что для любого интерфейса с такой функциональностью должна быть предусмотрена возможность управления только с помощью указателя без использования движений при перетаскивании элементов.
Действующий на данный момент критерий успешного применения 2.5.1 Жесты при работе с указателем не относится к перетаскиванию элементов, так как перетаскивание не является жестом. При использовании данной команды вы берете элемент в одном месте (Точка А) и затем оставляете его в другом (Точка Б), но путь, который проделывает указатель из точки А в точку Б, не важен, поэтому перетаскивание не является взаимодействием, основанном на определении пути.
Новый критерий успешного применения 2.5.7 разработан именно для случаев, использующих движения при перетаскивании элементов, когда само движение может быть сложно выполнимым для некоторых людей, использующих указатель. Даже простейшие движения при перетаскивании требуют достаточно точного контроля над указателем, что может быть невозможно для пользователей, имеющих сложности с мелкой моторикой или использующих вспомогательные технологии, когда движения указателя управляются голосовыми командами или с помощью альтернативных устройств ввода.
Как соответствовать критерию 2.5.7
Скрипт, используемый при перетаскивании, легко доработать для одновременной поддержки другого сценария – «укажи и щелкни». Пользователь может захватить элемент и перетащить его из точки А в точку Б, как и раньше, или он может кликнуть на элемент в точке А, отпустить указатель и затем кликнуть в точке Б – точке, куда он хочет переместить элемент.
Обратите внимание, что доступности команд с клавиатуры недостаточно для соответствия данному критерию успешного применения. Любой интерфейс, использующий перетаскивание, должен иметь альтернативные варианты для управления с клавиатуры (или другой альтернативный интерфейс), но только этого недостаточно для соответствия критерию успешного применения 2.5.7; данный критерий определяет только взаимодействие с указателем.
Критерий успеха 2.5.8 Размер области для наведения указателя (минимальные требования)
Критерий успешного применения 2.5.8 – это упрощенная версия действующего сейчас критерия 2.5.5 Размер мишени (уровень ААА), ослабляющая требования к размеру и превращающая его в контрольную точку уровня АА. В то время как критерий 2.5.5 требует, чтобы большинство интерактивных элементов имели минимальный размер области для наведения указателя 44 на 44 пикселя CSS, новый критерий 2.5.8 определяет минимальный размер области для наведения указателя как 24 на 24 пикселя. Также он содержит исключение в отношении расстояния между различными областями для наведения указателя, когда разрешается делать размер области менее 24 на 24 пикселя при условии, что расстояние между соседними областями для наведения указателя составляет не менее 24 пикселей.
Честно говоря, я думаю, что такое исключение по расстоянию – это полная ерунда. Получается, что область для наведения указателя может быть любого размера, даже 0 на 0, если между двумя соседними областями расстояние составляет 24 пикселя. Мне сложно поверить, что именно в этом заключалась идея данного пункта.
Какой бы я сделал из этого вывод (или правильнее сказать – какой я думаю, должна быть формулировка): при сложении размеров области для наведения указателя и расстояния между соседними областями результат должен быть равен по меньшей мере 48 пикселям, при этом минимальный размер области для наведения указателя равен 24 на 24 пикселя. Таким образом, область для наведения указателя может быть равной 24 на 24 и расстояние между соседними областями равным 24 пикселям, или 36 на 36 и расстояние – 12 пикселей, или 48 на 48 при полном отсутствии расстояния между областями для наведения указателя; но сама область не может быть меньше, чем 24 на 24 при любом размере расстояния между соседними областями.
Это не то, о чем указано в данном критерии успешного применения, но это то, что я считаю – должно быть его практической интерпретацией.
Критерий успеха 2.5.8 не относится к элементам, отображаемым браузером, то есть к исключениям относятся встроенные элементы, такие как радиокнопки и флажки. Однако, кастомные радиокнопки и флажки не являются исключениями, так как они создаются дизайнером, а не браузером. Интерактивные элементы, встроенные в текст (такие, как текстовые ссылки внутри абзаца), также являются исключениями из этого критерия. В случае составных элементов управления, таких как слайдеры, у которых есть небольшой бегунок внутри обрамляющего элемента передвижения, для определения размера области для наведения указателя принимается полностью размер всего элемента управления, то есть слайдера, а не только бегунка внутри него.
Масштабирование страницы не является значимым фактором при определении размера области для наведения указателя. Размер пикселей не изменяется при изменении масштаба, то есть элемент размером 16 на 16 пикселей при 100-процентном увеличении также равен 16 на 16 пикселей при 400-процентном увеличении. То есть в данном случае не может быть использована хитрость: увеличение размера элементов управления при увеличении масштаба страницы пользователем.
Как соответствовать критерию 2.5.8
В связи с отсутствием ясности в требованиях этого критерия успешного применения я бы предложил следующий вариант для наибольшего соответствия: размер всех областей для наведения указателя составляет, как минимум, 24 на 24 пикселя и расстояние между соседними областями составляет, как минимум, 24 пикселя, или если сами элементы управления имеют бОльший размер, то расстояние между ними может быть меньше.
Размер области для наведения указателя не обязательно равен размеру видимой области. Графическая кнопка с размером видимой иконки 16х16, но с 4-хпиксельными отступами со всех сторон имеет общий размер области для наведения указателя 24 на 24.
Однако, размер 24 на 24 все же небольшой и может создавать сложности для пользователей, имеющих проблемы с мелкой моторикой. Поэтому наилучший совет, который я могу дать: полностью игнорировать этот критерий успешного применения и добиваться соответствия требованиям критерия 2.5.5 Размер области для наведения указателя (минимум 44 на 44).
Соответствие критерию 2.5.5 будет автоматически означать соответствие критерию 2.5.8.
Критерий успеха 3.2.6 Единообразие в предоставлении справочной информации
Критерий 3.2.6 говорит о логичном размещении информации, цель которой – оказать помощь пользователям, особенно если это касается контактной информации. К такой информации относятся, например, номер телефона или адрес электронной почты, по которым пользователи могут получить помощь по работе с сайтом или сведения по услугам компании. Данный критерий не требует обязательного размещения подобной информации, но если она есть – она должна быть размещена в понятном месте. Это полезно для всех пользователей, но особенно важно для людей с когнитивными нарушениями или проблемами с памятью.
Поэтому, например, если у вас работает горячая линия для пользователей и ее телефонный номер расположен в заголовке сайта, тогда он всегда должен быть на одном и том же месте в заголовке на каждой странице, где этот заголовок появляется. Это касается случаев, когда информация повторяется на нескольких страницах; если информация представлена только на одной странице, то критерий 3.2.6 не применим.
Обратите внимание, что критерий 3.2.6 не затрагивает вопросы, связанные с контекстной помощью, такие как примечания или подсказки, всплывающие под полями формы и помогающие в ее заполнении. Требования к контекстной помощи такого рода уже определены в существующем критерии успешного применения 3.3.5 Помощь.
Как соответствовать критерию 3.2.6
Соответствие данному критерию успешного применения сводится к единому дизайну и созданию шаблонов. Если вы предлагаете помощь или размещаете контактную информацию на нескольких страницах, то убедитесь, что она всегда на одном и том же месте. Высока вероятность, что вы уже так и делаете.
Не имеет значения, размещена ли эта информация непосредственно на странице (например, номер телефона) или в виде ссылки на другую страницу, где ее можно найти, – требования критерия успешного применения 3.2.6 распространяются на оба этих случая.
Формулировка данного критерия несколько размыта. Название критерия относится к помощи, но требования, изложенные в нем, в основном касаются контактной информации. Проще говоря, контакт не всегда подразумевает помощь. Но в критерии 3.2.6 особо подчеркивается, что речь идет о контактной информации для получения помощи. То есть размещенный на нижнем колонтитуле сайта корпоративный адрес организации не подпадает под действие этого критерия, если он в явном виде не позиционируется как канал для получения помощи.
Критерий успеха 3.3.7 Доступная аутентификация
Критерий 3.3.7 определяет условия для применения когнитивных тестов, используемых для аутентификации пользователей, таких как капча, когда необходимо напечатать последовательность символов или выделить определенный тип предметов на похожих изображениях, например, отметить все изображения парковочных счетчиков.
Подобные тесты могут быть трудны или даже невозможны для выполнения некоторыми пользователями, например, если у них наблюдаются проблемы с памятью, чтением, счетом или обработкой информации. Данный критерий успешного применения устанавливает, что если подобные тесты используются, то либо должна быть предоставлена альтернатива, которая не связана с когнитивным тестом, либо доступен механизм, который помогает пользователям успешно справиться с тестом.
Исключением из данного критерия распознавания объектов являются случаи, когда когнитивный тест основывается на контенте, предоставленном самим пользователем. Например, если пользователь ранее загрузил изображения в свой аккаунт, то данные изображения могут быть использованы для когнитивного теста, и это не будет являться несоответствием критерию успешного применения, так как ожидается, что пользователь сможет распознать предоставленные им самим изображения.
Если обратиться к определению «когнитивного теста», то к нему относятся любые операции, требующие от пользователя запоминания и дешифровки информации, сюда также входит аутентификация по имени пользователя и паролю. Однако, если на сайте возможно использование менеджера паролей, то это и есть механизм, который помогает пользователям справиться с аутентификацией. Единственный случай, когда можно встретить несоответствие данному критерию, – это когда сайт полностью блокирует использование подобных инструментов, чаще всего это происходит при запрете на копирование и вставку в поля для заполнения имени пользователя и пароля. Некоторые сайты делают это по причинам безопасности, но сейчас подобные ограничения являются явным несоответствием критерию успеха 3.3.7 (по которому не допускаются никакие исключения по причине обеспечения безопасности, к тому же нет никаких рисков, если пользователь копирует и вставляет имя пользователя и пароль в предназначенные для этого поля).
Особым исключением из этого критерия являются поля, где требуется внести ФИО пользователя, его электронный адрес или номер телефона; это все относится к персональным данным, которые не изменяются в зависимости от сайта, на котором они вводятся, поэтому их внесение не относится к когнитивному тесту.
Как соответствовать критерию 3.3.7
Для соответствия данному критерию успешного применения необходимо убедиться, что все формы для ввода информации, используемой для аутентификации (такие, как поля для ввода имени пользователя и пароля), поддерживают возможность копирования и вставки. Также хорошим вариантом является использование атрибута «автозаполнение» во всех полях, которые требуют внесения личной пользовательской информации (как описано в действующем критерии успеха 1.3.5 Указание назначения полей ввода информации), хотя это и не является строгим требованием в критерии 3.3.7.
Помимо этого, лучше избегать использования капчи или похожих инструментов, так как они никогда не будут полностью доступны. Но если вы все же используете подобные механизмы, то убедитесь, что доступны другие формы аутентификации, в частности, хорошим вариантом является двухфакторная аутентификация.
Однако, обратите внимание, что двухфакторная аутентификация также должна соответствовать обозначенным выше требованиям. Например, если предполагается отправка кода пользователю, который затем нужно внести в окно браузера, – только наличие возможности напрямую скопировать и вставить код не будет являться нарушением критерия 3.3.7 (так как в других случаях появляется необходимость дешифровки информации). Если для прохождения двухфакторной аутентификации требуется отдельное устройство, например, на сотовый телефон пользователя высылается код, который затем нужно ввести в окно браузера на ПК, то данная ситуация будет являться несоответствием этому критерию успешного применения. Также ввод только некоторых знаков из цепочки аутентификации (например, первой, третьей и шестой цифр пароля) является несоответствием данному критерию успешного применения, даже если разрешена команда копирования и вставки, так как требуется ввод информации в формате, отличающемся от присланного пароля.
Что-то достаточно простое, как, например, временный URL-адрес, когда пользователю нужно пройти по ссылке из электронного письма или текстового сообщения для подтверждения данных, – тоже является хорошим вариантом. Использование биометрической аутентификации, например, сканирование отпечатков пальцев или распознавание лица также соответствует требованиям данного критерия успешного применения.
Сокрытие информации, необходимой для аутентификации, в процессе ее ввода не является нарушением данного критерия, например, допустимо использование полей type="password", когда автоматически скрываются вводимые символы. Однако, вместе с этим возможно использование функции «Показать пароль», что является хорошей идеей.
Критерий успеха 3.3.8 Доступная аутентификация (без исключений)
Критерий успешного применения 3.3.8 идентичен критерию 3.3.7, единственное отличие состоит в том, что он не делает исключений для контента, предоставляемого пользователем.
Критерий успеха 3.3.9 Избыточный ввод информации
Критерий успешного применения 3.3.9 связан с отсутствием у пользователей необходимости вводить ту же информацию, которую они уже ранее внесли (в ходе одного и того же сеанса), для уменьшения когнитивной нагрузки. Это может быть важно для пользователей с когнитивными нарушениями и проблемами с памятью, а также для пользователей с нарушениями мобильности, которые используют управление голосом или с помощью движений головы, – для них ввод данных является крайне утомительным.
Так, при заполнении многостраничной формы заявки может возникнуть необходимость внести свои ФИО и адрес проживания в нескольких местах. В этом случае ранее введенная информация должна либо автоматически появляться в форме, либо должна предоставляться возможность ее выбора для заполнения поля. Исключениями являются ситуации, когда повторный ввод информации необходим (например, ввод нового пароля дважды для подтверждения того, что пароли совпадают) или когда ранее введенная информация потеряла свою актуальность.
Также данный критерий успешного применения не относится к случаям, когда ранее введенная информация была представлена в другом формате. Например, если при заполнении онлайн-формы требуется загрузить резюме в формате документа и одновременно внести информацию о предыдущих местах работы в самой форме, то эта ситуация не относится к сфере действия критерия 3.3.9.
Однако, этот критерий применяется в случаях, когда пользователь может заполнить поля с использованием функций автозаполнения или чего-то подобного. Этого будет достаточно для соответствия критерию 3.3.7 Доступная аутентификация, но недостаточно для соответствия критерию успешного применения 3.3.9.
Как соответствовать критерию 3.3.9
Достаточно просто добавить в сеанс команды для автоматического заполнения полей с использованием ранее введенной пользователем информации. Альтернативный вариант – это предоставление возможности выбора ранее введенной информации: это может быть установка флажка на поле типа «Используйте адрес для отправки счета для доставки товаров» или это может быть текстовая информация на странице, которую пользователь копирует и вставляет в нужное поле.
Оригинал статьи: New Success Criteria in WCAG 2.2
Об авторе
James Edwards – консультант по веб-доступности с 20-летним опытом. Он разрабатывает, исследует и пишет обо всех аспектах доступной интерфейсной разработки, уделяя особое внимание доступному JavaScript. Он начал свою карьеру как HTML-кодер, затем как разработчик JavaScript, также может заняться PHP и MySQL.
Чем больше я узнавал, тем больше понимал, насколько важно учитывать доступность. Это базовая основа веб-разработки и фундаментальный принцип проектирования самого Интернета. Если информация недоступна, то какой в ней смысл? Программирование — это механика, но доступность — это люди, и именно люди на самом деле имеют значение.
James Edwards