Как можно сделать свой сайт более доступным

Как можно сделать свой сайт более доступным

От автора: будучи дизайнером, разработчиком или даже менеджером продукта, вы имеете кучу обязанностей. Каждый проект требует большого внимания — макет для десктопа, макет мобильных устройств, макет для iPhone X (спасибо, Apple), поддержка IE, поддержка Safari … И всегда нужно знать, как сделать сайт доступным.

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

Вот несколько фактов:

Около 15% населения мира живет с той или иной формой инвалидности, из которых 2-4% испытывают значительные трудности в функционировании (по данным Всемирной организации здравоохранения).

Иногда вы можете быть временно недееспособны — в некотором смысле, — допустим, вы порезали палец или пытаетесь читать на своем низко контрастном экране в солнечный день.

В некоторых случаях доступность может требоваться по закону.

И самое главное:

Мы все становимся пользователями клавиатуры, когда одной рукой едим, а другой — управляем мышкой. — Adrian Roselli

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

Не изобретайте велосипед

Мы в Site Search 360 разработали плагин, который позволяет клиентам легко интегрировать наше поисковое решение в существующий веб-сайт.

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

Доступность недостаточно просто «включить».

Но не волнуйтесь. Даже если вы никогда не думали о доступности в своем текущем проекте, некоторые улучшения не займут много времени. Я не могу сказать, сколько времени мы потратили, чтобы сделать плагин более доступным, но это было не более нескольких рабочих дней (и около 30 коммитов).

Теперь я проиллюстрирую весь процесс (на основе нашего плагина JavaScript, а не веб-сайта), поэтому вам не нужно начинать с самого начала. Но сперва:

Что такое доступность?

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

Доступность — это искусство сделать продукт полезным для всех.

Кто эти «все»? Какие виды инвалидности нужно учитывать?

Слепота и цветовая слепота

Когнитивные нарушения

Физические недостатки

Нарушения слуха (да, видео требует субтитров)

Возраст

Несколько простых шагов

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

Создание семантической разметки

Это, наверное, самый важный шаг. HTML5 есть уже несколько лет, поэтому нет причин (и никаких оправданий), чтобы не использовать его. Section, article, header, nav, banner и многие другие теги — все они должны использоваться.
Вероятно, вы видели такую разметку (я пропустил классы и идентификаторы, поскольку у них нет семантической цели):

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

У этой разметки существует несколько проблем. Как может кто-то, кто зависит от вспомогательных технологий, запросить навигацию? Никак. Является ли активный элемент представленным div? Да. Посмотрите на следующий фрагмент разметки:

Гораздо лучше, не так ли? Теперь рассмотрим наиболее важные понятия семантической разметки:

Используйте семантических элементов

Всегда используйте <main role = «main»>, чтобы отметить основной контент

Добавьте атрибут role для поддержки старых браузеров

Используйте sections вместо divs, где это необходимо

Span — это не button    — не переставляйте значение элементов (без особой необходимости)

Используйте button  для внутристраничных взаимодействий

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

Я не собираюсь перечислять все изменения, которые мы сделали (их довольно много), но вы всегда можете спросить об этом в комментариях.

Что делать: просмотрите текущую разметку, проверьте структуру содержимого и заголовка, убедитесь, что интерактивные элементы представлены button  или элементами и используют семантические теги HTML5.

Обеспечьте доступность всех функций с помощью клавиатуры

Это также очень важно. Каждое взаимодействие должно быть возможно с помощью клавиатуры.

Рассмотрим пример, аналогичный предыдущему. У нас была кнопка «Показать больше результатов», которая на самом деле не была кнопкой. Вы можете догадаться почему? Да, это был стилизованный div.

Можем ли мы поддерживать управление клавиатурой для такого элемента? Да, мы могли бы сделать это с помощью фокуса и обработать события click и keyup при проверке нажатия клавиши ввода или пробела.

Тем не менее, это еще сложнее, чем просто изменить разметку с div на button -  в этом случае вам просто нужно привязать событие click и не вынуждать элемент DOM быть сфокусированным (и как бонус — не нужно писать кучу стилей).

Все функциональные возможности должны быть доступны с клавиатуры

Не удаляйте контуры у сфокусированных элементов (если вам не нравятся эти контуры, их всегда можно стилизовать)

Взаимодействие на странице должно быть представлено button 

Внестраничные взаимодействия (ссылки) должны быть представлены якорем ( <a> )

* Кнопки предназначенные для запуска с помощью щелчка, ввода и пробела, должны быть привязаны к нажатию ввода и щелчку

Что делать: убедитесь, что все интерактивные элементы доступны (и управляемы) с помощью клавиатуры, выделены сфокусированные элементы, и порядок вкладок логичен.

Поддержка скрин ридеров

Взгляните на следующее изображение:

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

Вы уже видели полное изображение, поэтому знаете, какое действие должна выполнять одна и та же кнопка. Можете сказать, посмотрев на второе изображение? Нет — крестик рендерится с помощью CSS свойства background-image, а в button вообще нет внутреннего контента.

Для этого нужны aria — атрибуты. Увеличивая разметку кнопки с помощью простого атрибута aria-label, вам не нужно стараться скрыть внутренний текст кнопки в слое презентации.

Вы заметили, что я также удалил изображения с экрана скрин ридера? Вы можете пометить их, используя ту же технику (где aria-labeled больше подходит). Я удалил эти изображения, потому что в нашем случае они не имеют семантической цели и помечены role=”presentation”. Даже если у них есть семантическая цель, мы обычно этого не знаем. Большинство этих изображений будут иллюстративными, а их маркировка излишней — заголовок уже имеет такое значение.

Атрибуты, которые вы должны знать:

role - полезен для обозначения цели элемента

aria-hidden — использует вспомогательные технологии, чтобы игнорировать элемент

aria-label, aria-labeledby  - ярлык элемента

aria-describeby  - используйте это для описания нестандартных элементов управления пользовательским интерфейсом

aria-owns  - обозначает связь между двумя элементами

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

Как протестировать: использование скрин ридера в качестве ограниченного человека может показаться неестественным, поэтому сначала потратьте немного времени и ознакомьтесь с программным обеспечением (можно протестировать наиболее распространенные из них -  VoiceOver на Mac, NVDA, Jaws на Windows и TalkBack на Android). После этого попробуйте перейти на сайт только с помощью программного обеспечения для чтения с экрана (выключите монитор). Даже короткий тест поможет вам понять, насколько хорошо работает сайт, и выявить наиболее значительные проблемы.

Бонус: Вот короткий (и немного упрощенный) пример того, как мы увеличили аутсорсинг. Выделенные части (и два ) были добавлены как часть наших улучшений доступности.

Упрощение презентации

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

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

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

Передача информации только по цвету сделает её недоступной для людей с цветовой слепотой.

Ниже приведен пример того, как мы изменили стандартный макет для нашего представления о переходе — более короткие блоки текста и более высокие коэффициенты контрастности.

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

Что делать:

Убедитесь, что блоки текста не более 80 символов, и используйте высоту строки, которая примерно в 1,5 раза больше размера шрифта (который также должен быть достаточно большим — от 16 пикселей и более)

Разрешите масштабирование (по крайней мере, до 200%)

Проверьте коэффициенты контрастности

Убедитесь, что ваши цели касания достаточно велики (44 x 44 пикселя — это эмпирическое правило)

Если цвет передает информацию, убедитесь, что также есть и альтернативный способ получить ту же информацию

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

Забудьте о капчах …

Оценивайте, развивайте и интегрируйте свой рабочий процесс

Этот раздел здесь только потому, что «5 шагов» звучит лучше, чем «4 шага». Независимо от этого, всегда сосредотачивайтесь на доступности в ежедневном (или, по крайней мере, еженедельном) рабочем процессе.

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

Тестирование

Существует множество инструментов, которые помогут вам оценить, насколько доступен сайт. Я бы порекомендовал Tenon.io, FAE и Lighthouse для Google Chrome (открыть Dev Tools, перейти в Audits и нажать «Perform an audit…»).

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

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

Хорошо, вот и все. Если вас интересуют точные изменения, которые мы сделали, просто спросите в комментариях. И если вы ищете решение для поиска по сайту, которое заботится о доступности (или просто для альтернативной поисковой системы Google), то для этого есть Site Search 360.

Автор: Jaroslav Vaňkát

Источник: //medium.freecodecamp.org/

Редакция: Команда webformyself.

Метки:

Похожие статьи:

Комментарии Вконтакте: