Начальное руководство по цифровой доступности
5 апреля 2023 г.Что такое веб-доступность?
Определение доступности заключается в том, чтобы сделать что-то доступным и пригодным для использования как можно большим количеством людей. Веб-доступность, в частности, означает, что веб-сайты одинаково удобны для людей с ограниченными возможностями. Это интернет-эквивалент пандусов для инвалидных колясок, зарезервированных парковочных мест, шрифта Брайля на вывесках или субтитров в фильмах.
Стандарты веб-доступности определяются Руководством по обеспечению доступности веб-контента (WCAG) — это глобальный юридический стандарт. Охватываются 4 типа инвалидности: нарушения слуха, нарушения зрения, двигательные нарушения и когнитивные нарушения.
Стандарты включают в себя совместимость с программой чтения с экрана для слепых или слабовидящих, возможность навигации с помощью клавиатуры для людей с двигательными нарушениями, безопасность при приступах для людей с эпилепсией и понятность контента для людей с когнитивными нарушениями и нарушениями обучения.
Почему так важна доступность в Интернете?
С практической точки зрения наличие доступной веб-страницы имеет большое значение, поскольку в противном случае на вас могут подать в суд. Американцы с инвалидностью находятся под защитой Закона об американцах-инвалидах (ADA) — Министерство юстиции считает веб-сайты «общественными помещениями» и к ним применяются те же юридические стандарты доступности, что и к другим общественным помещениям.
Общественные помещения - это любые объекты, которые используются населением в целом. Они могут находиться в государственной или частной собственности. Некоторыми примерами являются рестораны, розничные магазины и спортивные сооружения. В 2022 году владельцам веб-сайтов в рамках ADA было отправлено более 8 000 писем с требованиями и подано более 3 250 судебных исков.
Что еще более важно, это правильный поступок. По оценкам, 20–25% населения в целом имеют инвалидность. Люди с ограниченными возможностями заслуживают доступа к тем же услугам и привилегиям, что и все остальные, и обеспечение доступности вашего веб-сайта помогает создать справедливый мир.
Доступный дизайн
Прежде чем приступить к написанию доступного кода, необходимо принять во внимание некоторые аспекты дизайна пользовательского интерфейса. Если у вас есть дизайнер, с которым вы работаете, разработка специальных возможностей входит в его обязанности. Однако многие фронтенд-инженеры , независимо от того, работают ли они внештатно или работают в небольших компаниях, где у сотрудников может быть много разных обязанностей , также несут определенную ответственность за дизайн пользовательского интерфейса.
Цвет
Две наиболее важные части дизайна для обеспечения доступности касаются цвета. Прежде всего, цветовой контраст должен быть достаточно высоким, чтобы даже люди с плохим зрением могли его различить. Цветовой контраст для текста должен быть не менее 4,5:1 для мелкого текста и 3:1 для крупного текста. Эти коэффициенты контрастности варьируются от 1:1 — «белое на белом» — до 21:1 — «черное на белом». Многие веб-сайты и расширения браузера могут проверять цветовой контраст за вас.
Другое важное соображение, касающееся цвета, заключается в том, что цвет никогда не должен быть единственным, что отличает что-либо. Например, ошибка, которая представляет собой просто красную рамку вокруг ввода вместо границы по умолчанию, или если ссылки имеют другой цвет, но не имеют другого стиля. Пользователи, страдающие дальтонизмом, не могут различать цветовые различия. Лучше было бы добавить другие отличительные признаки, такие как значок предупреждения или сообщение об ошибке, или стиль подчеркивания по умолчанию для ссылки.
Формы
Формы — одна из самых сложных частей при разработке специальных возможностей. Важно помнить о нескольких аспектах форм. Прежде всего, каждый вход должен иметь метку. Заполнители не заменяют метки по нескольким причинам. Во-первых, они исчезают, когда вы начинаете печатать, поэтому у людей с проблемами памяти могут возникнуть проблемы. Во-вторых, текст-заполнитель имеет тенденцию быть светло-серым на белом фоне, что ниже минимального стандарта контрастности и его трудно увидеть людям с нарушениями зрения. Наконец, если есть ошибки — например, если пользователь оставил поле пустым или заполнил его в неправильном формате — а не общее предупреждение или баннер, фокус должен переместиться на ввод с ошибкой, и должно быть ясно, что это так (и, как упоминалось выше, для обозначения этого должно быть нечто большее, чем просто изменение цвета).
Ссылки
Ссылки должны быть описательными — вместо фразы «Нажмите здесь» следует указать «Нажмите здесь, чтобы узнать больше об аляскинских маламутах». Для пользователей, использующих программу чтения с экрана, просто услышать «Нажмите здесь» может сбить с толку. Ссылки, которые ведут на внешние веб-сайты, должны указывать на это —независимо от того, есть ли это значок (например, обычное поле со стрелкой), а также визуальные или арии-метки, которые говорят: «Это открывается в новом окне». В приведенном выше примере ссылка будет выглядеть так: «Нажмите здесь, чтобы узнать больше об аляскинских маламутах», а затем «откроется в новом окне», чтобы быть полностью доступной.
Ярлыки
Все должно иметь визуальную метку, если непонятно, что это такое. Кнопки, выпадающие списки, вводы — все нуждается в визуальной маркировке, чтобы люди с когнитивными нарушениями могли понять. Например, вместо кнопки, которая представляет собой только значок, лучше иметь визуальную метку, чтобы ее могли легко понять люди с когнитивными нарушениями.
Доступный код
Семантический HTML
Большая часть написания доступного кода приходится на написание семантического HTML. Это означает использование описательных тегов html (
Заголовки
Теги заголовков имеют особые правила : на странице должен быть только один h1, а все остальные теги заголовков должны быть последовательными, например, внутри h3 никогда не должно быть h2, и вы должны перейти от h1 к h4. Если вы хотите, чтобы заголовки выглядели определенным образом, используйте для этого стили css. Это также относится к программам чтения с экрана — программа чтения с экрана прочитает пользователям все h2 и позволит пользователям переходить между разделами через заголовки h2, и если заголовки не в порядке, программа чтения с экрана не сможет должным образом организовать страницу. Когда это происходит, люди с нарушениями зрения не могут перемещаться по веб-странице.
Таблицы
Таблицы должны создаваться с тегами таблиц. У них также должен быть установлен заголовок в строке, чтобы, когда программа чтения с экрана считывает данные таблицы пользователю, она сообщала пользователю, какая это строка (т. е. в таблице фильмов и их рейтингов и данных о кассовых сборах каждый заголовок строки будет названием фильма).
Ария
Aria – это сокращение от "Доступные многофункциональные интернет-приложения". По сути, это набор тегов, которые помогают описывать элементы так, как это не может сделать HTML. Например, модальное окно не может быть создано таким образом, чтобы HTML мог передать, что это такое, но если мы добавим role="alertdialog" aria-modal="true", программа чтения с экрана сможет передать то, что происходит с пользователь. Мы не будем вдаваться здесь во все доступные теги, но есть много доступных шпаргалок, таких как это от DigitalA11y.
Метка-ария — это метка, которая не видна на странице, но будет прочитана программой чтения с экрана. Метки-арии можно добавлять к чему угодно, и их следует использовать в любом случае, когда нет текстовой метки или когда текстовая метка может не давать достаточно информации, например, в примере со ссылкой, которая открывается в новом окне. Например, если есть панель поиска, которая имеет только значок увеличительного стекла для ее идентификации, aria-label должен быть установлен на «поиск», чтобы пользователи с нарушениями зрения знали, что делает ввод. Aria-labelledby (используется с идентификатором элемента, имеющего метку) может использоваться, если элемент с меткой не связан иначе. Например, если вы используете h2 для обозначения ввода «Поиск», вы можете использовать aria-labelledby для ссылки на этот h2, а не на aria-label.
Изображения
Все изображения должны иметь теги alt. Эти теги должны быть описательными и не должны включать слово «изображение», потому что программы чтения с экрана уже говорят «это изображение». Если изображение носит исключительно декоративный характер и не выполняет никакой функции (например, если ваш поисковый запрос имеет метку, которая включает в себя как слово «поиск», так и значок увеличительного стекла, этот значок является чисто декоративным), тогда все равно должен быть тег alt, но он должен быть установлен на пустую строку (alt=""). Если у изображения нет тега alt, программа чтения с экрана прочитает полное имя файла, что бесполезно для пользователей. Пустая строка указывает средству чтения с экрана игнорировать изображение.
Специальные возможности клавиатуры
Страницы должны иметь возможность навигации с помощью клавиатуры для пользователей с двигательными нарушениями, которые затрудняют использование мыши. Чтобы перемещаться по странице с помощью клавиатуры, все функции, которые можно щелкнуть, должны быть доступны для фокусировки, и они должны находиться в индексе вкладок соответствующим образом, чтобы они были сфокусированы в правильном порядке.
Чтобы сохранить индекс вкладок, кнопки не должны быть отключены — отключенная кнопка удаляется из указателя вкладок, что сбивает пользователей с толку («Почему в этой форме нет кнопки? Как я ее отправлю?»). Aria-disabled отключит кнопку, не удаляя ее из указателя вкладок. Кроме того, установка tabindex на 0 поместит элемент в обычный поток страницы. Установка tabindex на -1 удалит его из потока страницы (это может быть полезно для чисто декоративных значков и других нефункциональных элементов). В общем, старайтесь не изменять tabIndex слишком сильно, если только что-то явно не сломано или неверно. Слишком сильное изменение tab-index (и аналогично z-index) может привести к кроличьей норе ошибок.
Шрифты
Когда вы устанавливаете размеры шрифта, установка их с помощью rem обеспечивает доступ к странице так, как это не делают пиксели. Шрифты, установленные с помощью rems, будут увеличиваться, если пользователь увеличит размер шрифта по умолчанию в своем браузере, но шрифты, установленные с помощью пикселей, этого не сделают. Пользователям с нарушениями зрения, которым нужен текст большего размера, будет намного легче, когда веб-сайт адаптируется к настройкам размера шрифта браузера по умолчанию. Кроме того, не используйте нестандартные шрифты для общей информации. Простой шрифт гораздо более доступен визуально и когнитивно, чем шрифт с украшением.
Библиотеки компонентов
Если вы используете общую библиотеку компонентов или внешнюю библиотеку, и эти компоненты имеют специальные возможности — всегда используйте их, даже если они необязательны. Они встроены не просто так, и они избавят вас от необходимости вручную управлять специальными возможностями (или иметь недоступные компоненты, потому что вы не можете их изменить).
Язык
Хотя язык не входит в стандарты WCAG, более половины человечества в той или иной степени говорит на нескольких языках. Гораздо проще ориентироваться на веб-сайте на вашем родном языке, чем переводить на ходу язык, который вы, возможно, не понимаете. Здесь на помощь приходят переводчики. Для этого приложения существует множество инструментов, но одна из самых простых реализаций — FormatJS. По сути, вы переносите все строки в эту библиотеку, и библиотека автоматически переводится на различные языки. Это поразительно простая в реализации вещь, которая позволит гораздо большему количеству пользователей с комфортом использовать ваше приложение.
Тестирование доступности
Ручное тестирование
Существует несколько инструментов, помогающих разработчикам проверять доступность своих страниц и приложений. однако, по оценкам, даже самые тщательные инструменты обнаруживают только 40% ошибок. Ручное тестирование — самая важная часть тестирования доступности.
Чтобы протестировать вручную, сначала пролистайте страницу с помощью клавиатуры. Убедитесь, что все, к чему вы можете получить доступ с помощью мыши, также доступно с помощью клавиатуры.
Кроме того, используйте встроенное в компьютер средство чтения с экрана, чтобы попытаться перемещаться по сайту. На компьютерах Mac встроенное средство чтения с экрана называется VoiceOver, а на Windows — экранный диктор.
Автоматическое тестирование
Хотя автоматические тесты выявляют только 40 % проблем с доступностью, лучше их обнаружить, чем пропустить! Есть несколько типов автоматических тестов доступности, которые вы можете настроить в своем проекте.
Линтинг
Линтеры проверяют статический код на соответствие установленным правилам, и многие организации используют их. С точки зрения доступности типы проблем со статическим кодом, которые могут быть обнаружены линтерами, включают семантические ошибки HTML и проблемы с alt-тегами. Существует несколько подключаемых модулей специальных возможностей для es-lint, которые проверят ваш код за вас. Если ваш код написан на React, вам подойдет eslint-plugin-jsx-a11y, eslint-plugin-vuejs-accessibility работает с Vue.js, а angular-eslint работает с Angular. Однако использование такой системы проектирования, как bootstrap, не позволит линтеру обнаружить все потенциальные ошибки.
Модульное и интеграционное тестирование
Модульные и интеграционные тесты включают в себя фактический запуск кода, и эти тесты смогут выявить больше проблем, чем линтер (особенно если вы используете дизайн-систему). 'т).
Компания Deque предоставляет несколько библиотек npm, которые работают с различными средами интерфейса и тестирования (включая Jest, React с библиотекой тестирования React, React с Enzyme, Vue, Angular, Jasmine, Mocha и т. д.). Эти библиотеки запускают проверки доступности, уже определенные в библиотеке, поэтому после установки библиотеки все, что вам нужно сделать, это вызвать тестовый метод из библиотеки, и он запустит все тесты за вас. Вам не нужно вручную создавать какие-либо тесты доступности.
Тестирование браузера
Тестирование в браузере фактически отображает код в браузере и оценивает то, что отображается. Из-за этого он может обнаруживать некоторые ошибки, которые не могут обнаружить линтеры и модульные тесты, например, проблемы с цветовым контрастом.
Как и модульные и интеграционные тесты, существует несколько библиотек, которые вы можете использовать с настройкой тестирования браузера, поэтому вам не нужно вручную писать тесты самостоятельно. Например, если вы используете Cypress, есть пакет cypress-audit/lighthouse. Lighthouse-ci и pa11y-ci — это библиотеки CI.
Кроме того, Deque, который поддерживает библиотеки axe для модульных тестов, упомянутых в последнем разделе, также имеет пакеты axe для Cypress, Selenium и других фреймворков для тестирования браузеров.
Из-за разнообразия людей с ограниченными возможностями существует множество различных аспектов проектирования и создания доступных веб-сайтов, и начать работу с ними может быть сложно. К счастью, на самом деле реализовать доступные компоненты легко, если вы знаете, что делать, а количество библиотек тестирования с уже написанными наборами тестов доступности делает создание и поддержку доступного кода еще проще. Значительная часть населения и ваших потенциальных клиентов имеют инвалидность, и доступ к вашим услугам для всех помогает построить более инклюзивный и справедливый мир.
Соавторы: Даниэль Форд и Элли Крейг
Ресурсы:
Памятка по ролям DigitalA11y Aria
Курс Udemy по тестированию доступности React
Курс Udemy по доступному дизайну
Расширение Chrome для имитации дальтонизма
Интеграция тестирования Axe Core (для модульного и браузерного тестирования)
н
Оригинал