Доступность – во главу угла: как создать доступные WordPress-темы

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

Это – не всеобъемлющее руководство по доступности. Вы не станете экспертом в сфере доступности после прочтения статьи. Однако я хотел бы поделиться своим опытом, который я получил, создавая доступные темы WordPress. Хотелось бы надеяться, что это позволит кому-либо создавать более доступные темы, и мы сможем делиться идеями по поводу того, как сделать сеть комфортным местом для всех нас.

Большую часть своего опыта я получил от таких экспертов, как Джо Долсон и Дэвид Кеннеди. Они оба помогают команде доступности WordPress и любезно отвечают на вопросы в Github и Twitter. Наша цель – понять основы доступности, а также узнать, как подготовить темы к тому, чтобы они получили официальную метку accessibility-ready.

Что такое «доступность» и почему мы должны беспокоиться о ней?

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

Вильями Салминен рассказал о различных методах ввода, а также о производительности, в своей статье, которая называется «The Many Faces of the Web»:

«Если брать более крупный масштаб, мы должны сделать наши сайты доступными для всех. Чтобы эти сайты работали с разными техниками ввода, такими как сенсорные дисплеи, мышь, клавиатура или голосовое управление. Чтобы сайты быстро загружались. Чтобы они предлагали всем доступ к обширной сети связанных между собой вещей. И если мы не станем бороться за это, какой смысл тогда вообще улучшать сеть?»

Если все это вас не убеждает, вы должны хотя бы подумать о деньгах! Брэд Фрост раскрыл это в своей статье о доступности и маломощных устройствах:

«Хотите получить больше клиентов?»  На этот вопрос я всегда слышу ответ: «Да». Когда я спрашиваю: «Хотите ли вы, чтобы ваш сайт загружался молниеносно?», то слышу в ответ: «Да». Доступность и производительность – невидимые аспекты опыта взаимодействия, однако они должны быть рассмотрены даже в том случае, когда они не являются явными целями проекта.

Сделайте опыт взаимодействия в сети более доступным и производительным – заработайте больше!»

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

.screen-reader-text для скрытия текста

Использование .screen-reader-text фактически не требуется, однако я прибегну к нему в нескольких примерах. WordPress использует CSS класс .screen-reader-text для обработки любого HTML-вывода, который предназначен для программ чтения с экрана. Основная цель такого текста – предложить дополнительный контекст для ссылок, структуры документа, а также полей формы. Это полезно для тех, кто использует программы чтения с экрана при просмотре сети.

Начиная с WordPress 4.2, класс .screen-reader-text используется и в коде фронтэнда, а не только в бэкэнде. К примеру, comments_popup_link() может выводить по умолчанию нечто следующее:

4 Comments<span class="screen-reader-text"> on My article about accessibility</span>

Заметили класс .screen-reader-text? Текст «on My article about accessibility», как предполагается, должен быть скрыт на обычных дисплеях, но при этом он будет выводиться в программах чтения с экрана. Он дает некоторый контекст о том, что означает «4 Comments», и о какой статье мы ведем речь.

Если в файле style.css вашей темы отсутствует .screen-reader-text, ничего страшного. В таком случае все пользователи будут видеть весь текст целиком (4 Comments on My article about accessibility). Есть также отдельный плагин, который добавляет поддержку .screen-reader-text.

Добавляем .screen-reader-text в style.css своей темы

Следующий фрагмент является рекомендуемым методом для добавления класса screen-reader в стили вашей темы. Вы можете также воспользоваться темой Underscores или другими рекомендуемыми методами:

/* Text meant only for screen readers. */
.screen-reader-text {
	clip: rect(1px, 1px, 1px, 1px);
	position: absolute !important;
	height: 1px;
	width: 1px;
	overflow: hidden;
}
 
.screen-reader-text:hover,
.screen-reader-text:active,
.screen-reader-text:focus {
	background-color: #f1f1f1;
	border-radius: 3px;
	box-shadow: 0 0 2px 2px rgba(0, 0, 0, 0.6);
	clip: auto !important;
	color: #21759b;
	display: block;
	font-size: 14px;
	font-size: 0.875rem;
	font-weight: bold;
	height: auto;
	left: 5px;
	line-height: normal;
	padding: 15px 23px 14px;
	text-decoration: none;
	top: 5px;
	width: auto;
	z-index: 100000; /* Above WP toolbar. */
}

Вы можете стилизовать :focus по-другому, однако этого кода хватит для начала.

Заголовки и их иерархия

Заголовки – важный способ навигации по вашему сайту. Именно на них ориентируются пользователи, которые используют программы чтения с экрана. Обычные пользователи также могут быстрее перемещаться по сайту, если он имеет структурированные заголовки.

Однако заголовки и структура заголовков могут вылиться в проблему, с чем я и сам столкнулся на своем опыте. Должны ли мы использовать единственный h1 элемент на каждой странице? Может быть, лучше будет, если их будет несколько? Что по поводу других заголовков: H2, H3 и т.д.?

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

<h1>Blog</h1>
 
-- <h2 class="screen-reader-text">Primary Menu</h2>
 
-- <h2>Article title 1</h2>
-- <h2>Article title 2</h2>
-- <h2>Article title 3</h2>
 
-- <h2 class="screen-reader-text">Posts navigation</h2>
 
-- <h2 class="screen-reader-text">Sidebar</h2>
   -- <h3>Widget title 1</h3>
   -- <h3>Widget title 2</h3>

И для отдельных записей:

-- <h2 class="screen-reader-text">Primary Menu</h2>
 
<h1>Article title 1</h1>
 
-- <h2>Heading 1 in article</h2>
-- <h2>Heading 2 in article</h2>
-- <h2>Heading 3 in article</h2>
   -- <h3>Sub heading 1 for heading 3 in article</h3>
 
-- <h2 class="screen-reader-text">Post navigation</h2>
 
-- <h2 class="screen-reader-text">Sidebar</h2>
   -- <h3>Widget title 1</h3>
   -- <h3>Widget title 2</h3>

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

Прочитайте текст про иерархию заголовков и придерживайтесь этой иерархии в своей теме.

Роли ARIA

Роли ARIA позволяют программно определить разделы страницы. Это дает возможность пользователям ассистивных технологий переходить к различным секциям страницы.

Есть следующие общие роли:

• Хэдер: role=»banner»
• Основной контент: role=»main»
• Сайдбары: role=»complementary»
• Футер: role=»contentinfo»
• Форма поиска: role=»search»
• Навигационные меню: role=»navigation»

Если одна и та же роль представлена на странице несколько раз, вы должны задать aria-label для этой роли:

<nav role="navigation" aria-label="<?php esc_html_e( 'Header Navigation', 'textdomain' ); ?>">
<nav role="navigation" aria-label="<?php esc_html_e( 'Footer Navigation', 'textdomain' ); ?>">

Старайтесь не использовать слишком много разных ролей ARIA. Иначе пользователи программ чтения с экрана вряд ли смогут легко перемещаться по вашему сайту. От десяти до пятнадцати ролей вполне достаточно.

Пример того, как будет выглядеть HTML-структура с ARIA ролями:

<html>
<body>
 
  <header role="banner"> </header>
 
  <nav role="navigation" aria-label="<?php esc_html_e( 'Primary Navigation', 'textdomain' ); ?>"></nav>
 
  <main role="main"> </main>
 
  <aside role="complementary"> </aside>
 
  <footer role="contentinfo"> </footer>
 
</body>
</html>

На скриншоте представлен сайт инспектора ARIA:

Текст ссылок

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

Использование функции the_content()

По умолчанию функция the_content() выводит текст «more…», если используется конструкция <!–more–> в контенте записи. Вы можете менять данный вывод, используя первый параметр функции: $more_link_text. Мы рекомендуем использовать в нем заголовок записи для дополнительного контекста.

<?php
/* translators: %s: Name of current post */
the_content( sprintf(
	__( 'Read more %s', 'textdomain' ),
	the_title( '<span class="screen-reader-text">', '</span>', false )
) );

Вывод будет следующим: Read more <span class=»screen-reader-text»>My Article Name</span>, а не просто повторяющееся Read More. Обратите внимание, что мы снова использовали класс screen-reader-text, который означает, что заголовок записи может быть скрыт (если тема поддерживает это), однако программы чтения с экрана все равно смогут считать его.

Использование функции the_excerpt()

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

function prefix_excerpt_more() {
	/* Translators: %s: Name of current post */
	$text = sprintf( __( 'Read more %s', 'textdomain' ), '<span class="screen-reader-text">' . get_the_title() . '</span>' );
	$more = sprintf( '&hellip; <p><a href="%s" class="more-link">%s</a></p>', esc_url( get_permalink() ), $text );
	return $more;
}
add_filter( 'excerpt_more', 'prefix_excerpt_more' );

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

Дескриптивный текст ссылки

Старайтесь использовать максимально дескриптивный текст ссылки – не стоит использовать голые URL-адреса в качестве анкора.

Плохой пример:

Join <a href="https://poststatus.com/">https://poststatus.com</a> and get the best news about WordPress.

Хороший пример:

Join <a href="https://poststatus.com/">Post Status club</a> and get the best news about WordPress.

Элементы управления

Пусть ссылки остаются ссылками, кнопки – кнопками, блоки div – блоками div, span’ы – span’ами, чтобы добиться совместимости с клавиатурой и взаимодействия с программами чтения с экрана. Ссылки в статье, div’ы и span’ы не должны быть кнопками.

Все элементы управления должны иметь текст, определяющий природу элемента, однако он также может быть скрыт в класс .screen-reader-class.

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

<button id="nav-toggle"><?php _e( 'Menu', 'textdomain' ); ?></button>

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

<button id="nav-toggle"><span class='dashicons dashicons-menu'></span></button>

Текстовые иконки сами по себе не несут никакого смысла для программ чтения с экрана. Вообще, лучшая иконка – это текстовый label.

Вместо этого вы можете использовать следующий код:

<button id="nav-toggle"><span class="screen-reader-text"><?php _e( 'Menu', 'textdomain' ); ?></span></button>

Затем уже добавьте текстовую иконку с помощью псевдо-элемента, такого как, к примеру, #nav-toggle::before.

Вы можете также использовать текстовую иконку и .screen-reader-text в комплексе:

<button id="nav-toggle"><span class='dashicons dashicons-menu'></span><span class="screen-reader-text"><?php _e( 'Menu', 'textdomain' ); ?></span></button>

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

Навигация с клавиатуры

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

Я предлагаю вам отставить в сторону мышь и попробовать протестировать свой сайт. Сможете ли вы переходить по ссылкам, выпадающим меню, элементам управления форм с помощью клавиш tab и shift + tab? Enter может использоваться для активации ссылок, кнопок и других интерактивных элементов.

:focus очень важен

Обратите внимание, что по умолчанию фокус могут получать только ссылки, кнопки и поля форм. Именно по этой причине я говорил вам, что ссылки должны быть ссылками, а кнопки – кнопками. Не пытайтесь заместить их div’ами или span’ами. Элементы должны иметь визуальные эффекты, позволяющие отразить их состояние, когда пользователи перемещаются по вашему сайту с помощью клавиатуры. Именно для этих целей и применяют :focus.

Плохая реализация:

/* Bad example. */
a:focus {
	outline: 0;
}

Она отключает стили контура для всех ссылок! Вот это будет в разы лучше:

/* Good example. */
a:focus {
	outline: thin dotted;
}
a:active,
a:hover {
	outline: 0;
}

Теперь пользователи могут насладиться визуальным эффектом – контуром из точек вокруг ссылки – когда ссылка будет в фокусе. Вы можете стилизовать ссылки по-другому, однако не убирайте стилизацию совсем. Помните, что вы можете, конечно, стилизовать кнопки с помощью CSS — к примеру, сменить фон во время :focus.

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

Выпадающие меню и клавиатурная доступность

Пытались ли вы когда-либо получить доступ к вашим подменю в выпадающем меню с помощью одной клавиатуры? Если вы не можете эффективно выполнить это, давайте посмотрим, как это улучшить. Начнем мы с того, что приведем текущие требования к навигационным меню.

Неправильно: выпадающие навигационные меню скрыты с помощью display:none; и выводятся на экран во время :hover

Удовлетворительно: Навигационные меню скрыты с помощью position: absolute; и выводятся на экран во время :hover и :focus, также по ним можно перемещаться при помощи tab.

Идеально: Выпадающие навигационные меню скрыты с помощью position: absolute;, выводятся на экран во время :hover, :focus, по ним можно перемещаться при помощи tab, а также при помощи стрелочек на клавиатуре.

Опять же, тема Underscores содержит прекрасный пример разметки выпадающих меню, по которым можно перемещаться с помощью клавиши Tab. Я надеюсь, что в ней появится поддержка стрелочек в ближайшем будущем. Я обычно использую Responsive Nav для создания адаптивных, доступных меню.

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

• Всякий раз, когда ссылка меню получает фокус или теряет его, задаем или удаляем класс .focus для ссылки меню. Делается это с помощью функции toggleFocus().
• Когда меню имеет стили :hover, добавляем класс .focus в стилевую таблицу.
• Вы можете перемещаться по меню и подменю с помощью клавиш tab и Shift + tab.

Есть и другие аспекты, которые нам нужно рассмотреть для создания более доступных меню:

• Используем ARIA разметку по типу aria-haspopup=”true” в пунктах меню, которые имеют подменю.
• Что по поводу сенсорных устройств? Пробовали ли вы получить доступ к подменю с iPad, когда меню находятся в режиме Desktop? Я надеюсь, что поддержка сенсорных устройств также появится в ближайшее время в теме Underscores.

Здесь можно написать целую статью по поводу созданию доступных адаптивных меню, поэтому мы двинемся дальше.

Контрасты

Цветовой контраст – то, ради чего мы пойдем на компромисс в нашем веб-дизайне. Нам нужно обеспечить достаточный контраст между цветом текста и фона, чтобы текст могли прочитать люди с умеренно плохим зрением. Есть много красивых тем, которые используют, к примеру, светло-серые цвета, однако вряд ли они выполнят требования цветового контраста.

Авторы тем должны гарантировать, что все цветовые контрасты фона/текста находятся на уровне AA коэффициента контрастности (4.5:1), который определен в Web Content Accessibility Guidelines (WCAG) 2.0 для яркости цвета.

Я протестировал цветовой контраст с помощью специального инструмента Джо Долсона. Доступность не сделает ваш сайт уродливым или некрасивым, вы должны это помнить! Однако доступность выставляет некоторые требования, которые мы должны соблюдать. У Аарона Джорбина было прекрасное выступление по поводу теории цвета и доступности на WordCamp Chicago 2014.

Ссылки «пропустить»

Базовый контент веб-сайта обычно находится не в самой верхней области страницы. Над ним располагаются разные выпадающие меню, формы поиска, а также другая информация. Пользователям клавиатуры или программ чтения с экрана будет раздражать тот факт, что им нужно всякий раз перемещаться вниз по этому многочисленному содержанию, чтобы перейти наконец к вашему основному контенту. Именно по этой причине темы должны включать в себя ссылку «пропустить», которая поможет перейти сразу к основному контенту. Такая ссылка обычно добавляется в header.php после body или первого тега div.

<a class="skip-link screen-reader-text" href="#content"><?php esc_html_e( 'Skip to content', 'textdomain' ); ?></a>

Убедитесь в том, что ссылка – один из первых элементов на странице, который выводится на экран, когда клавиатурный фокус переходит на ссылку. Мы уже сделали так, когда добавили класс .screen-reader-text к стилевой таблице.

Также нужно перенести фокус на область основного контента страницы, когда активируется ссылка «пропустить». Я считаю, что до сих пор в WebKit-браузерах осталась ошибка, которая препятствует переносу фокуса. Тема Underscores дает хороший пример этого переноса.

Формы

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

Я скрывал кнопку поиска с помощью .search-submit { display: none; }. Не делайте этого, если вы хотите, чтобы ваш контент был доступен программам чтения с экрана.

Лучший вариант – использовать фильтр get_search_form, а также добавить класс .screen-reader-text к кнопке формы поиска.

<?php
/**
 * Add a `screen-reader-text` class to the search form's submit button.
 *
 * @since Twenty Fifteen 1.0
 *
 * @param string $html Search form HTML.
 * @return string Modified search form HTML.
 */
function twentyfifteen_search_form_modify( $html ) {
	return str_replace( 'class="search-submit"', 'class="search-submit screen-reader-text"', $html );
}
add_filter( 'get_search_form', 'twentyfifteen_search_form_modify' );

Если вы используете произвольный файл searchform.php в своей теме, задавайте всегда соответствующие подписи полей (label); не устанавливайте только текстовые иконки для кнопки Submit!

<?php
// Bad example because there is no label
<input type="search" class="addsearch search-field" name="s" value="<?php echo trim( get_search_query() ); ?>">

// Better with the label.
<label>
  <span class="screen-reader-text"><?php _ex( 'Search for:', 'label', 'textdomain' ); ?></span>
  <input type="search" class="addsearch search-field" name="s" value="<?php echo trim( get_search_query() ); ?>">
</label>
 
// Bad example when using only font icon as button label
<button type="submit" class="search-button"><span class="genericon genericon-search"></span></button>
 
// Better with screen reader text
<button type="submit" class="search-button"><span class="genericon genericon-search"></span><span class="screen-reader-text"><?php _e( 'Search', 'textdomain' ); ?></button>

Если приводить пункты руководства:

• Используйте элементы управления формы, которые явно связаны с label.
• Создайте механизмы обратной связи (к примеру, через AJAX), которые предложат некоторый ответ для программ чтения с экрана. Рассмотрите техники с ARIA для получения дополнительной информации.

Также следите за набором паттернов для создания доступных WordPress-тем. Как, к примеру, доступная форма комментариев, выполненная при помощи JavaScript и ARIA.

Изображения и альтернативный текст

Мне не удалось добавить альтернативный текст (атрибут ALT) к моим изображениям в контексте – по крайней мере, хороший текст. Я обещаю улучшить это! Незрячие люди вряд ли смогут разглядеть ваши изображения. Компьютеры и программы чтения с экрана не могут понять, что представляет собой изображение. Вот почему и был создан ALT атрибут, а также руководства по изображениям.

• Если в разметке шаблонов имеются изображения, такие как миниатюры, они должны использовать атрибут ALT. Или предлагать конечному пользователю ввести ALT-текст.
• Все декоративные изображения должны быть добавлены через CSS, а не с помощью встраивания. Примеры декоративных изображений – линии, фоновые изображения.
• Обратите внимание, что иногда пустой атрибут alt=”” является лучшим выбором.

Медиа-элементы

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

Не поддерживаются

Есть несколько вещей, которые не поддерживаются

• Любые положительные атрибуты tabindex. Отрицательные значения tabindex или ноль разрешены в некоторых ситуациях (все зависит от конкретного случая).
• Включение атрибута accesskey
• Выдача новых окон или вкладок без уведомления пользователя

Создание доступных тем

Мы изучили требования для получения официальной метки accessibility-ready при отправке тем в каталог WordPress. Все было не так уж и сложно!

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

Источник: https://poststatus.com/