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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

<div> <div>Recipes<span>98</span></div> <div>Menu Items<span>1</span></div> <div>Grocery Products<span>1</span></div>
</div>

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

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

<nav role="navigation"> <ul role="menubar"> <li> <button role="menuitem">Recipes<span>98</span></button> </li> <li> <button role="menuitem">Menu Items<span>1</span></button> </li> <li> <button role="menuitem">Grocery Products <span>1</span> </button> </li> </ul>
</nav>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

<!-- Wrong markup -->
<button></button> <!-- Accessible markup -->
<button aria-label="Close layer"></button> <!-- Alternative accessible markup -->
<button style="text-indent:100%;overflow:hidden;padding:0;white-space:nowrap;">Close layer</button>

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

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

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

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

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

<!-- Search Field -->
<input type="text" placeholder="search something" autocomplete="off" role="combobox" aria-describedby="unibox-controls-description" aria-owns="unibox-suggest-box" aria-expanded="true" aria-activedescendant="unibox-active">
<!-- Search Suggestions -->
<div id="unibox-suggest-box" role="listbox"> <section aria-labelledby="unibox-suggest-cluster-heading-recipes"> <h3 id="unibox-suggest-cluster-heading-recipes">Recipes</h3> <div aria-selected="false" role="option"> <img src=[...] alt="" aria-hidden="true" role="presentation"> </div> <a href=[..]>Chicken Curry</a> </div> <div aria-selected="true" role="option" id="unibox-active"> <img src=[...] alt="" aria-hidden="true" role="presentation"> </div> <a href=[..]>Curried Chicken</a> </div> </section> </div>
<!-- Announce search suggestions have been changed -->
<span aria-live="polite" aria-atomic="true" role="status" class="ss360-sr-only">2 Search Suggestions Shown</span>
<!-- Suggest Box User Interface Controls -->
<span id="unibox-controls-description" class="ss360-sr-only">
Use up and down arrows to select available result. Press enter to go to the selected search result.</span>

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

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

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

if (window.matchMedia && window.matchMedia ("(prefers-reduced-motion: reduce)"). match) { animationSpeed = 0; }

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

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

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

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

Что делать:

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

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

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

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

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

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

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

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

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

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

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