Веб-доступность: почему стандарты W3C часто игнорируются

Опубликовано: 2022-03-11

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

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

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

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

1. Что означает «доступный дизайн»?

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

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

При рассмотрении доступного контента для пользователей рассмотрите следующие сценарии:

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

2. Как обеспечить хорошую веб-доступность

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

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

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

Чтобы проиллюстрировать, как это работает, давайте рассмотрим простой пример кода:

 <a href="#” class=”button”>Delete</a>

Этот простой код для людей, использующих программу чтения с экрана, не имеет большого значения. Это даже вводит в заблуждение и читается только как ссылка с текстом « Удалить ». Чтобы помочь пользователям понять, какой метод используется для выполнения действия, мы можем использовать атрибуты ARIA (Assistive Rich Internet Applications) (указанные на https://www.w3.org/TR/wai-aria/) для отменить исходную роль. Мы меняем значение ссылки на кнопку, добавляя атрибут role="button" . Таким образом, программы чтения с экрана будут читать его как кнопку, а не как ссылку. Что более уместно.

Короче говоря, атрибут ARIA:

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

Что такое доступность в веб-дизайне?

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

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

Отметьте разные состояния: включено, отключено, только для чтения.
Отметьте элемент, когда он получает состояние фокуса/наведения.
Отметьте каждый элемент опции, когда он получает состояние фокуса/наведения.
Убедитесь, что содержимое по-прежнему читабельно, когда только текст увеличен до уровня 200%.
Убедитесь, что между текстом и его фоном достаточно контраста. Это помогает людям с умеренно слабым зрением или на устройствах в экстремальных условиях освещения, например, под прямыми солнечными лучами или на дисплее с низкой яркостью, читать содержимое.

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

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

3. Тестирование доступности: с чего начать?

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

Определение проблем

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

Плохой пример: пользователь не может использовать клавиатуру на странице.

Хороший пример: невозможно использовать навигацию с помощью клавиатуры в главном меню.

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

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

Приоритизируйте проблемы веб-доступности

Приоритеты важны, потому что они определяют, какие проблемы должны быть устранены в первую очередь. Например, WCAG делится на три уровня соответствия: A, AA, AAA, что означает, что вы должны начать с минимального уровня A, но это не означает автоматически, что уровни AA и AAA просто «приятно иметь». Все уровни важны, и важно не расставлять приоритеты, предполагая, что одного уровня А достаточно.

Тем не менее, уровни WCAG (или любые другие рекомендации) иногда могут быть довольно сложными для понимания, и, чтобы немного упростить их, вы также можете рассмотреть следующие определения приоритетов:

Критические — проблемы, которые мешают пользователям использовать приложение. Нет доступных обходных путей.
Серьезные — проблемы, которые усложняют использование приложения и/или дезориентируют его, но не мешают пользователю выполнить операцию.
Незначительные — проблемы, которые раздражают, но не мешают использованию, или улучшения, которые можно внести в приложение.
Информация – не придерживается лучших практик. Общие рекомендации по доработкам.

Решения

Ни одно из руководств — под которыми я подразумеваю WCAG, Section 508 или ADA — не даст вам прямого решения с точки зрения технического кода того, как должна быть устранена определенная проблема. Они определяют только ожидаемое поведение. Тем не менее, WCAG дополнительно определила процедуры тестирования, которые должны помочь понять, как воспроизвести проблему, и существует группа сообщества Automated WCAG Monitoring, сообщество W3C, занимающееся разработкой надежных правил тестирования доступности веб-сайтов, как автоматизированных, так и полуавтоматических.

Пример метода WCAG G4 («Разрешение приостанавливать и перезапускать содержимое с того места, где оно было приостановлено»):

Тестовая процедура

На странице с движущимся или прокручиваемым содержимым

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

Ожидаемые результаты

№ 2 и № 4 верны.

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

Руководящие принципы веб-доступности и стандарты W3C

Отправной точкой должны стать следующие основные веб-стандарты:

Наиболее распространенным является Руководство по доступности веб-контента, известное как WCAG. WCAG 2.0 — это «стабильный технический стандарт, на который можно ссылаться. Он состоит из 12 руководящих принципов, организованных по 4 принципам: воспринимаемый, работоспособный, понятный и надежный. Для каждого руководства существуют поддающиеся проверке критерии успеха, которые относятся к трем уровням: A, AA и AAA».
Techniques for WCAG 2.0 — это исчерпывающее руководство для авторов веб-контента.
Требования пользователей к доступности медиаконтента W3C — в этом документе представлены требования к доступности для пользователей с ограниченными возможностями в отношении аудио и видео в Интернете.
Закон XXI века о средствах связи и доступности видео — CVAA разделен на два широких заголовка или раздела. Раздел I касается доступа к средствам связи, чтобы сделать продукты и услуги, использующие широкополосную связь, полностью доступными для людей с ограниченными возможностями. Раздел II закона о доступности открывает новые горизонты, облегчая людям с ограниченными возможностями просмотр видеопрограмм по телевидению и в Интернете.
Раздел 508 — требования доступности для информационных и коммуникационных технологий (ИКТ), которые применяются ко всем федеральным агентствам, когда они разрабатывают, закупают, обслуживают или используют электронные и информационные технологии.
Доступность веб-сайтов в соответствии с Разделом II Закона об американцах-инвалидах (ADA) — здесь вы узнаете, как требования о недискриминации Раздела II Закона об американцах применяются к веб-сайтам государственных и местных органов власти.

Тестирование веб-доступности: как узнать, доступен мой контент или нет?

Вот основные, основные контрольные точки, которые должны помочь вам сделать ваш веб-контент более доступным с первого шага:

Подтвердите свой HTML. Убедитесь, что структура HTML не содержит ошибок, так как вспомогательные технологии могут иметь проблемы с интерпретацией содержимого страницы.
Протестируйте только с клавиатурой. Убедитесь, что все активные элементы доступны только с клавиатуры. Кроме того, вы должны иметь возможность выполнять все действия с помощью клавиатуры, например, отправлять форму.
Тестируйте с помощью инструментов тестирования доступности и валидаторов. Используйте инструменты, которые сканируют и проверяют потенциальные ошибки доступности.
Динамический контент. Уведомлять пользователей программы чтения с экрана о динамических изменениях, например, когда изменились результаты поиска.
Не полагайтесь на цвета, чтобы описать значение. Используйте цвет вместе с описанием, например, [желтое поле] предупреждение.
Не удаляйте контур в фокусе. Это обычно удаляемая функция с использованием структуры свойства CSS outline: 0; Не делайте этого, так как пользователи клавиатуры потеряют ориентацию на странице. Вы можете рассмотреть возможность удаления контура фокуса для пользователей, не использующих клавиатуру, но всегда предоставляйте контур фокуса для пользователей клавиатуры.
Сообщения об ошибках. Всегда сообщайте пользователю, как исправить ошибку. Не просто заявите, что данные недействительны.
Порядок вкладок. Убедитесь, что навигация на основе вкладок соответствует соглашениям, установленным в графическом пользовательском интерфейсе. Как минимум, он должен следовать направлению чтения языка приложения по умолчанию. В английском, например, порядок чтения сверху вниз, слева направо; по-арабски сверху вниз, справа налево.
Увеличить. Убедитесь, что содержимое страницы по-прежнему читаемо при увеличении текста до 200%.
Отключите изображения. Вы все еще можете использовать страницу удобным способом? Есть ли альтернативные тексты для всех изображений?
Читатель экрана. Проверьте, можете ли вы читать содержимое и перемещаться по нему с помощью хотя бы одного средства чтения с экрана, например VoiceOver, экранного диктора Windows или NVDA.
Режим высокой контрастности. Проверьте, читаемо ли содержимое при переключении в режим высокой контрастности.
Размер шрифта. Убедитесь, что размер шрифта на странице не меньше 10 пикселей.

4. Распространенные ошибки в веб-доступности

Самая распространенная ошибка — неспособность определить требования доступности до начала разработки . К сожалению, чем позже доступность станет частью разработки, тем сложнее будет реализовать решения.

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

Нет возможности перемещаться по содержимому, используя только клавиатуру .
Неправильное использование свойства структуры CSS. В большинстве случаев outline: 0; используется, что означает, что контур вокруг каждого активного элемента больше не виден. Не использовать outline: 0; или outline: 0 !important; . Пользователь потеряет возможность видеть элемент, сфокусированный в данный момент, во время навигации по содержимому, если нет другой альтернативы этому, например, с использованием CSS-свойства border .
Потеря фокуса с текущего элемента, например, из-за манипуляций с DOM или использования метода blur() . Это часто случается с одностраничными приложениями.
Нет уведомлений для пользователей программы чтения с экрана о том, что что-то изменилось, например, содержимое было загружено с помощью XMLHttpRequest API и были отображены новые изменения в пользовательском интерфейсе, но пользователь не был уведомлен. Это часто происходит с одностраничными приложениями.
Недоступный выбор даты. Во многих случаях используются недоступные средства выбора даты. Пользователи не могут перемещаться по параметрам календаря с помощью клавиатуры.
Использование расширений , которые утверждают, что автоматически устраняют проблемы с доступностью . Используйте их осторожно и проверьте результаты. Неправильное их использование может создать больше проблем, чем решений.
Добавление к элементу атрибута tabindex с порядковым номером больше 0. Цель использования tabindex с порядковым номером больше 0 — в основном «корректировать» путь навигации. Однако рассмотрите возможность изменения структуры HTML, чтобы получить естественный путь навигации. Манипулирование им с помощью tabindex может привести к проблемам с обслуживанием и непредсказуемому пути навигации.
Неправильная иерархия заголовков. К сожалению, это все еще довольно часто встречается, но иерархия заголовков не выстроена должным образом, например, <h1> , <h5> и <h2> . Пользователи программ чтения с экрана используют заголовки для навигации по разделам, а неправильная структура сбивает с толку, поскольку трудно понять контекст.
Отсутствует высококонтрастная поддержка. Есть люди, которые используют свое программное обеспечение в режиме высокой контрастности. Убедитесь, что ваш контент по-прежнему воспринимается.
Использование недоступного решения CAPTCHA. К сожалению, все известные мне CAPTCHA либо недоступны, либо очень сложны в использовании.
Слишком много анимаций и/или их нельзя приостановить. Автовоспроизведение видео, рекламы или каруселей изображений очень отвлекает.
Большие куски текста. Текст, сжатый в очень большой единый блок, без пробелов, запятых и точек. Очень тяжело читать. Разделение на более мелкие фрагменты, большее количество абзацев и подзаголовков помогает лучше организовать текстовое содержимое.
Проблемы с масштабированием. Убедитесь, что содержимое по-прежнему читаемо и по нему можно перемещаться при увеличении до 200%.
Опираясь на цвета. Очень часто состояние элемента отмечается только цветом, например, состояние предупреждения отмечается только желтым маркером; этот цвет не так воспринимается дальтониками.
Маленькие целевые объекты, на которые можно нажимать/нажимать. Области, на которые можно нажимать/нажимать, часто слишком малы. Увеличение размера позволит пользователям легче активировать их.

Но как улучшить доступность в Интернете?

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

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

Служба проверки разметки W3C — Просто чтобы убедиться, что в содержимом HTML нет ошибок. Если в структуре HTML есть ошибки, вывод будет непредсказуемым и не сможет быть правильно обработан, особенно с помощью различных вспомогательных технологий.
https://www.w3.org/WAI/ER/tools/ — список программ или онлайн-сервисов, которые помогут вам определить, соответствует ли веб-контент правилам доступности.
А мой инструмент ASLint https://www.aslint.org/ поможет вам найти проблемы с доступностью.

Всегда помните, что ни один инструмент доступности не может заменить ручное тестирование , так как не все сценарии могут быть полностью или вообще автоматизированы, например, проверка коэффициента яркостной контрастности на элементах с position: fixed; .

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

Почему важно сделать контент доступным

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

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

Наконец, вот некоторые статистические данные, которые вам нужно учитывать:

Более одного миллиарда человек во всем мире имеют ту или иную форму инвалидности.
Старение населения. Прогнозируется, что в период с 2015 по 2030 год число пожилых людей — в возрасте 60 лет и старше — в мире вырастет на 56 процентов, с 901 миллиона до более чем 1,4 миллиарда человек.
Универсальный дизайн — это важно. Универсальный дизайн относится к широкому спектру идей и практик для производства услуг, продуктов и сред, которые изначально доступны и пригодны для использования людьми с любым уровнем способностей.
Типы инвалидности: существует пять широких категорий инвалидности, включая зрение, подвижность, речь, познание и слух.

Нам всем нужны качественные услуги. Доставим и их .