Это последний принцип, который мы рассмотрим. Вообще говоря, в нем говорится, что содержание и навигация сайта должны быть понятными. Хотя ответственность за реализацию многих из этих рекомендаций лежит на «конечном пользователе» плагина или темы (или на том, кто публикует контент), существуют рекомендации, которые разработчики этих плагинов и тем могут реализовать.
Читаемый (3.1)
Первое руководство гласит, что контент должен быть «читабельным и понятным». Многие рекомендации касаются уровня чтения контента и использования необычных слов, сокращений и аббревиатур, ни одна из которых не имеет отношения к разработчикам.
Одна рекомендация, которую мы можем реализовать, заключается в том, что человеческий язык веб-страницы должен быть программно идентифицирован. Для этого язык должен быть указан в элементе <html> через атрибут lang . Кроме того, атрибут dir должен использоваться, чтобы указать, является ли содержимое справа налево.
WordPress делает это легко, предоставляя language_attributes() , который печатает необходимые атрибуты. В header.php вашей темы:
|
1
|
<html <?php language_attributes();
|
Функция language_attributes() устанавливает язык сайта и, при необходимости, направление и фильтрует выходные данные, позволяя плагинам (например, многоязычным плагинам) изменять атрибут соответствующим образом.
Предсказуемый (3.2)
Второе руководство гласит, что веб-сайт должен быть представлен и вести себя предсказуемым образом. Многие рекомендации могут быть выполнены, если разметка темы HTML хорошо структурирована и логична. В сочетании с этим существует множество рекомендаций «не делай», которые запрещают вносить изменения, которые нарушают естественное и логическое поведение веб-страницы.
Фокус Поведение
Мы упоминали, что не использовали tabindex в четвертой статье этой серии («Действующий»). Эта рекомендация основывается на том, чтобы утверждать, что, когда элемент получает фокус, это не должно считаться триггером для некоторого изменения состояния страницы.
Например, кнопка формы, получающая фокус, не должна вызывать отправку этой формы, а ссылка, получающая фокус, не должна вызывать активацию этой ссылки. Это не означает, что всплывающие подсказки или, в случае навигационных меню, подменю не должны появляться, когда соответствующий элемент получает фокус. Эти примеры не представляют собой изменение состояния. Грубо говоря, вы можете приравнять идеи к предмету, получающему фокус, и предмету, находящемуся над ним.
Не мешать фокус
Вы должны избегать удаления фокуса с элемента, который его получает. Например, вы никогда не должны делать что-то вроде следующего:
|
1
|
$(‘a’).on(‘focus’,function(){ $(this).blur(); });
|
Помощь пользователям, когда требуется ввод пользователя (3.3)
Убедитесь, что ошибки определены
По умолчанию единственными формами, которые имеют отношение к разработчикам тем, являются формы входа / регистрации, поиска и комментариев. Из них только последним двум обычно уделяется какое-либо внимание разработчиком темы. Поскольку поисковые формы никогда не приводят к «ошибке», мы сосредоточимся в этом разделе на формах комментариев.
WordPress отлично справляется с уведомлением пользователей об ошибке и точно сообщает им, что это за ошибка. Тем не менее, он делает это, позволяя пользователям покинуть исходную страницу и представляя им страницу с ошибкой «тупик».
Если пользователи вернутся на исходную страницу, форма потеряет фокус, и им придется найти ее снова. Лучшим решением было бы запретить пользователям отправлять форму, пока они не заполнили ее правильно. Однако при этом важно донести до пользователей, что введенное значение недопустимо, иначе вы по сути их поймаете в ловушку.
Доступно множество клиентских сценариев проверки, а также очень легко создать свой собственный простой сценарий проверки. Что важно это:
- Сообщения об ошибках, которые появляются после того, как пользователь покидает поле с недопустимым значением (или пытается отправить форму), должны сообщать как о наличии ошибки, так и о том, где эта ошибка (т.е. идентифицировать поле).
- Сообщения об ошибках должны быть определены как оповещения с использованием атрибута ARIA:
role="alert". - При необходимости сообщения об ошибках должны быть как можно более явными при информировании пользователя о том, почему введенное значение не было принято.
Вот простой пример, основанный на собственном примере доступной проверки формы в WebAIM (который я рекомендую вам прочитать), который добавляет сообщение об ошибке, если поле имени пусто.
|
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
|
jQuery(document).ready(function($) {
$(‘#author’).on( ‘blur’, function( e ){
var value = $(this).val();
if( !value ){
if( $(‘#author-error’).length > 0 ){
$(‘#author-error’).remove();
}
$( ‘<p id=»author-error» class=»alert alert-error» role=»alert»></p>’ )
.insertAfter( $(‘#author’) )
.text( ‘Name field error: Please provide a name’ );
}else if( $(‘#author-error’).length > 0 ){
$(‘#author-error’).remove();
}
});
});
|
Пример WebAIM также запрещает пользователям оставлять поле недействительным и возвращает их в поле для исправления ошибки. Если вы сделаете это, я бы порекомендовал вам не возвращать пользователя в поле, если значение пустое, иначе вы расстроите пользователей, которые случайно указали фокус поля, но не собираются отправлять форму.
Как отмечалось ранее в этой серии, вы не должны полагаться только на цвет или положение, чтобы передать смысл. В этом контексте сообщения об ошибках должны быть явно из текста, как и поля, к которым они относятся.
Предоставить этикетки
Темы должны использовать только comment_form() для отображения форм комментариев, и это обрабатывает метки доступным способом. Точно так же поисковая форма по умолчанию тоже не нуждается в дальнейшей работе. Однако при настройке или оформлении этих форм вы должны:
Убедитесь, что ярлыки всегда видны
Ярлыки должны быть видны всегда. В частности, это означает, что заполнители не составляют метку и не должны использоваться в качестве поиска. На это есть несколько причин:
- Непоследовательная поддержка программ чтения с экрана.
- Заполнители обычно имеют приглушенный цвет и могут быть трудно читаемыми.
- Поскольку заполнитель исчезает, когда поле получает фокус, это может создать проблемы с удобством использования для людей с когнитивными нарушениями.
Где это уместно, предоставьте дальнейшие инструкции
Если для поля формы требуются дополнительные инструкции, они могут быть предоставлены после поля, но при этом явно связаны с ним с помощью атрибута aria-describedby описаныby. Содержимое элемента, на который ссылается этот атрибут, читается после метки поля.
Как пример с сайта W3C:
|
1
2
3
4
5
6
7
8
|
<form>
<label for=»fname»>First name</label>
<input name=»» type=»text» id=»fname» aria-describedby=»fname-description»>
<p id=»fname-description»>A bit of instructions for this field linked with aria-describedby.
</form>
|
Тем не менее, вы должны знать, что это противоречивая поддержка среди программ чтения с экрана.
Определите обязательные поля
Обязательные поля должны быть помечены как таковые с атрибутом aria-required="true" . Форма комментариев WordPress по умолчанию, созданная comment_form() уже обрабатывает это, поэтому здесь не нужно предпринимать никаких действий. Тем не менее, вы должны знать об этом, если вы решите настроить формы комментариев.
Вывод
Эта статья завершает наше грубое руководство для разработчиков тем о принципах доступности W3C и о том, как их можно реализовать. В последней статье этой серии мы рассмотрим несколько простых способов пойти еще дальше, активно поощрять и помогать конечному пользователю нашей темы (или плагина) создавать доступный контент.