Мобильные устройства и доступность: зачем ей столько внимания и что с ней делать

Мобильные устройства и доступность

От автора: Мобильность изменила коренным образом метод нашего пользования Вебом. Особенно это касается пользователей-инвалидов, которым мобильные устройства открывают дверь к совершенно новому взаимодействию.

 

И они с удовольствием пользуются этой возможностью. Опрос в июле 2013г. (PDF) взрослых пользователей с инвалидностью, проведенный Исследовательским инженерным центром беспроводной реабилитации (Wireless Rehabilitation Engineering Research Center), обнаружил, что 91% людей с физическими недостатками пользуются «беспроводным устройством, таким как мобильный телефон или планшет». Среди таких пользователей самое привычное дело – использование скринридеров даже на мобильных устройствах.

Исследование среди 1782 пользователей экранных чтецов, проведенное Web Accessibility in Mind (WebAIM) в 2012г., показало, что 71,8% из них пользовались ими на своих мобильных устройствах. И мы говорим не о каком-то маленьком количестве людей. По итогам переписи в США в 2010г. обнаружено, что почти каждый пятый – человек с физическими недостатками!

Результаты исследования WebAIM по использованию экранных чтецов (источник: WebAIM)

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

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

Убедиться, что все работает с клавиатуры,

Создать формы семантическим путем,

Обеспечить высокую контрастность,

Гарантировать, что экранные чтецы понимают команды элементов управления,

Протестировать свой веб-сайт на настоящем скринридере.

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

1. Убедимся, что все работает с клавиатуры

Хотя клавиатуру мы обычно ассоциируем с традиционными настольными компьютерами и ноутбуками, ситуация уже не так проста. Встроенная в обложку клавиатура имеется в планшете Microsoft Surface, клавиатуры Bluetooth сделаны для безупречной работы в iOS и Android, а некоторые клавиатуры даже можно складывать при путешествии.

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

Поддержка клавиатуры важна даже на мобильных устройствах.

Отложите в сторону мышь и попытайтесь посетить свой веб-сайт. Можно ли выполнить все задания лишь с клавиатуры? Если нет, то и ваши пользователи этого не смогут. Две основные проблемы препятствуют навигации по Сети с клавиатуры. Давайте обсудим каждую из них.

ПРИМЕНЕНИЕ НЕПРАВИЛЬНОГО ЭЛЕМЕНТА ДЛЯ ЗАДАНИЯ

Веб-браузеры действительно хорошо могут заставить работать автоматически навигацию с клавиатуры, если вы пользуетесь семантически подходящими элементами. В частности, по умолчанию в фокус попадают следующие элементы: button, a (с атрибутом href), input, select и textarea. С этими элементами навигация с клавиатуры работает безо всяких дополнительных усилий. Однако часто разработчикам не удается должным образом использовать эти элементы, а конкретно button и a.

Кнопки нужно применять для элементов управления, выполняющих действия, тогда как ссылки следует использовать для тех элементов управления, с помощью которых пользователи переходят к другим документам. Однако разработчики часто неправильно применяют родовые элементы, такие как span и div, для выполняющих эти действия элементов управления. Рассмотрите целевую страницу iPhone от Fidelity, банковской организации.

Эти кнопки находятся на целевой странице Fidelity для iPhone или нет?

Два элемента управления этой страницы, несомненно, выглядят как кнопки, но в действительности генерируются следующей разметкой.

<div id="download_button">
	<div id="download_text" onclick="goToStore();">Download the Fidelity App</div>
</div>

<div id="no_thanks_button" onclick="goHome();">
	<div id="no_thanks_text" onclick="goHome();">No thanks</div>
</div>

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

<div id="download_button">
	<button id="download_text" onclick="goToStore();">Download the Fidelity App</button>
</div>

<div id="no_thanks_button" onclick="goHome();">
	<button id="no_thanks_text" onclick="goHome();">No thanks</button>
</div>

Хотя чаще всего такое случается с кнопками, ссылки тоже нередко используются неправильно. Рассмотрим всплывающее окно, которое появляется при посещении домашней страницы American Express на iPad’е:

American Express показывает пользователям iPad на своей домашней странице вот такое всплывающее окно.

Несмотря на то, что ссылка «Click here to download the American Express app» совсем обычная, American Express применяет следующий HTML:

<div class="asl-link" role="link">
	<div class="asl-app-store" title="...">
		Click here to download the American Express® App
	</div>
</div>

Ссылка сделана в JavaScript’е с помощью обработчика щелчка, который меняет window.location. Из-за использования div клавиатуры не cпособны добраться до элемента управления, но могли бы, если бы применялся элемент a.

<div class="asl-link">
	
		Click here to download the American Express® App
	
</div>

(Отметим, что кнопка «закрыть» на всплывающем окне American Express’а также является div, так что пользователи с клавиатуры не в силах ни выполнить действие на всплывающем окне, ни закрыть его.)

Также American Express мог бы воспользоваться одобренным Apple методом информирования пользователей о доступности приложения с помощью meta-тэга apple-itunes-app.

<meta name="apple-itunes-app" content="app-id=myAppStoreID, affiliate-data=myAffiliateData, app-argument=myURL">

Вообще-то браузеры автоматически гарантируют семантическим элементам доступ с клавиатуры. А что, если вы примените более сложные элементы, чем простые button или a?

НАПИСАНИЕ СОБСТВЕННЫХ СЛОЖНЫХ ВИДЖЕТОВ

Как веб-разработчики, для сложного взаимодействия в своих интерфейсах мы часто пользуемся виджетами. Иногда это делается для того, чтобы обойти недостатки платформы (например, чтобы встроить более пользовательский элемент select), а иногда для того, чтобы встроить мощный элемент пользовательского интерфейса (например, сетку, закладку или график). Давайте рассмотрим замещение элемента select. На первый взгляд кажется, что такой виджет легко написать:

Создайте div.

Создайте ul с элементом li для каждой замены option.

При щелчке по div откройте меню.

При щелчке по элементу li снова переведите значение в div.

Легко. Однако рассмотрите все элементы управления клавиатуры, которые есть у элемента select:

Клавиша пробела открывает меню опций.

Стрелки вверх-вниз открывают меню и циклически перемещают по опциям.

Кнопки page-up и page-down циклически перемещают по целым страницам опций в длинных списках.

Клавиша Escape закрывает меню.

Печать значений запускает опции автозаполнения при нахождении элемента в фокусе.

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

Чтобы эти сложные взаимодействия стали возможны, имеется специальный набор атрибутов HTML, который обеспечивает скринридеры необходимым контекстом. Они известны как Accessible Rich Internet Applications, или атрибуты ARIA.

Основной атрибут ARIA, role, сообщает браузерам и вспомогательным устройствам общий тип объекта — например, диалоговое окно, слайдер или предупреждение. Отсюда применение некоторого количества атрибутов aria-* для более детального информирования о состоянии элемента. Ниже приведен шаблон разработки доступного замещения select.

<span tabindex="0" id="button" role="combobox"
	aria-expanded="false" aria-autocomplete="list" aria-owns="menu"
	aria-haspopup="true" aria-activedescendant="option-1"
	aria-labelledby="option-1" aria-disabled="false">
		One
</span>

<ul aria-hidden="true" aria-labelledby="button" id="menu"
	role="listbox" tabindex="0" aria-activedescendant="option-1"
	style="display: none;">
		<li id="option-1" role="option" tabindex="-1">One</li>
		<li id="option-2" role="option" tabindex="-1">Two</li>
		<li id="option-3" role="option" tabindex="-1">Three</li>
</ul>

Экранные чтецы пользуются такими атрибутами ARIA для того, чтобы помочь пользователям с клавиатуры оперировать этими элементами управления. Например, так как у span из этого примера role имеет значение «combobox», VoiceOver в OS X читает «Сейчас вы находитесь в комбинированном окне, впишите текст или нажмите Control-Option-Space для отображения списка меню. VoiceOver знает о доступном перечне альтернатив, потому что у span есть атрибут aria-owns, установленный на «menu» — id содержащего опции ul’а.

Но, как видно, существует огромное множество атрибутов ARIA, с которыми приходится считаться; так что из-за сложности понимания этого момента многие разработчики для получения таких элементов управления чаще прибегают к применению библиотеки пользовательских интерфейсов JavaScript, а не делают их сами. Многие большие библиотеки гарантируют автоматическую доступность таких средств управления путем применения соответствующих ролей ARIA и клавиш быстрого вызова клавиатуры. Например, элемент пользовательского интерфейса jQuery selectmenu и элемент интерфейса Kendo DropDownList – оба генерируют доступные замещения select.

На этом закончим рассматривать поддержку навигации с клавиатуры. Хотя этот набор принципов, конечно, не является всеобъемлющим, он обязан помочь вам заставить работать должным образом самые важные части вашего веб-сайта. Для получения более исчерпывающего списка доступных с клавиатуры возможностей прочтите полное руководство W3C. Далее мы рассмотрим еще одну часто забываемую лучшую практику: построение семантических форм.

2. Семантическая разметка форм

Наряду с распространением одностраничных приложений — особенно мобильных — все меньшее количество веб-сайтов использует «родное» представление форм HTML. Вместо этого данные отправляются на сервер с помощью инициированных JavaScript’ом XMLHttpRequest’ов. Хотя по сути в этом нет ничего плохого, но остается важным использование той же семантической разметки, которой вы бы пользовались, если бы приходилось отправлять данные с помощью исконных форм HTML.

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

Username: <input type="text" id="username" name="username">
Password: <input type="password" id="password" name="password">
<button>Submit</button>
<script>
	document.querySelector( "button" )
		.addEventListener( "click", function() {
			// Пошлите запрос AJAX для входа пользователя
		});
</script>

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

АССОЦИИРОВАНИЕ МЕТОК С INPUT-АМИ

Большинству скринридеров требуется, чтобы элементы формы — input, select и textarea — ассоциировались с описывающими их метками label. У каждого элемента label должен быть атрибут for, соответствующий подходящему атрибуту элемента формы id, как показано здесь:

<label for="field">Field:</label>
<input id="field">

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

Username: <input type="text" id="username" name="username">

Когда ввод имени пользователя input попадает в фокус, экранный чтец NVDA читает просто «Редактировать текст. Пустое поле» (“Edit text, blank”). К сожалению, весьма распространенная ситуация. К примеру, у Amazon есть облегченный веб-сайт, amazon.com/access, «оптимизированный к скринридерам и мобильным устройствам».

Веб-сайт, соответственно, простой, с единственным полем поиска и коротким списком ссылок. Ирония ситуации состоит в том, что несмотря на перенаправление пользователей экранных чтецов на эту страницу, Amazon не добавил к вводу поиска input метку label; таким образом, многие пользователи скринридеров понятия не имеют о том, что для поиска можно воспользоваться вводом input.

Доступный веб-сайт Amazon’а не ассоциирует метку «Поиск» (“Search”) с текстовым полем.

(Заметка: Как у браузеров, у скринридеров варьируется поддержка шаблонов разметки. В вышеприведенном примере VoiceOver читает текст «Поиск» (“Search”), а NVDA – нет. Позже в этой статье мы обсудим тестирование совместимости.)

Можно легко решить эту проблему в нашем образце формы с элементами label:

<label for="username">Username:</label>
<input type="text" id="username" name="username">

<label for="password">Password:</label>
<input type="password" id="password" name="password">

<button>Submit</button>
<script>
	document.querySelector( "button" )
		.addEventListener( "click", function() {
			// Send AJAX request to log user in
		});
</script>

Теперь все экранные чтецы станут ассоциировать каждый элемент формы с описывающей его меткой. Эта практика выгода не только для пользователей вспомогательных устройств. Любой браузер достаточно умен, чтобы превратить щелчки по элементу label в ассоциируемые элементы input, select или textarea.

У вас возникали когда-нибудь проблемы при щелчке по чекбоксу размером 10 × 10 пикселей, где требуется принять условия пользования сервисом? На веб-сайтах с семантической разметкой вместо этого можно щелкнуть по метке чекбокса гораздо большего размера. На мобильных устройствах крупными пальцами можно дотронуться до увеличенного объекта:

Щелчком по метке наводится фокус на соответствующий элемент управления.

Так решается одна из проблем формы входа. Но требуется обсудить еще один вопрос.

УПРАВЛЕНИЕ КНОПКОЙ «ВВОД» (“ENTER”)

Вы замечали, что некоторые формы входа в Вебе можно отправить, нажав на кнопку «Ввод» (“Enter”) в текстовом поле, а некоторые нельзя? Что заставляет кнопку “Enter” работать на отправку?

Отправка формы с помощью кнопки «Ввод» (“Enter”) известна как подразумеваемая отправка и поддерживается всеми браузерами — даже мобильными. Для работы подразумеваемой отправки нужно соблюсти всего два требования.

Все элементы input должны быть в form.

Если в форме имеется более одного элемента — input, select или textarea — то у form должна быть кнопка «Отправить» (“Submit”).

У нашей формы-образца уже имеется кнопка отправки “Submit” (по умолчанию вид type кнопки button — это submit). Следовательно, нам нужно всего лишь добавить форму form.

<form method="POST">
	<label for="username">Username:</label>
	<input type="text" id="username" name="username">

	<label for="password">Password:</label>
	<input type="password" id="password" name="password">

	<button>Submit</button>
</form>
<script>
	document.querySelector( "button" )
		.addEventListener( "click", function( event ) {
			// Prevent the default form submission
			event.preventDefault();

		// Пошлите запрос AJAX
	});
</script>

Вам стоит запомнить пару моментов:

При подразумеваемой отправке браузер выполняет щелчок по кнопке «Отправить» (“Submit”) form’ы. Следовательно, для выполнения действия отправки можно спокойно прослушивать события щелчка click кнопки «Submit». Как альтернативу, можно прослушивать событие submit элемента form.

Хотя JavaScript перехватит отправку формы, все равно недвусмысленно заявляется method=»POST». В случае отказа JavaScript (из-за неподдерживающих браузеров, проблем с сетью и т.д.) нам не нужно, чтобы браузер отправил запрос GET, который поместит предоставленное пользователем имя и пароль в строку запроса.

Возможность подразумеваемой отправки экономит на щелчках мобильных пользователей. На изображении ниже показаны два элемента input, один в элементе form, а второй – нет. Заметьте, что в примере с form можно делать отправку во время нахождения ввода input в фокусе — не требуется дополнительных касаний и поиска кнопки отправки “Submit”.

Подразумеваемая отправка формы работает только с истинными элементами формы.

На этом мы завершаем рассматривать построение доступных форм. Что касается доступа с клавиатуры, то эти принципы далеки от исчерпывающих, но решают некоторые наиболее часто возникающие проблемы с формами. Для получения полного списка наилучших практик прочтите руководства по сбору данных ввода от пользователей W3C.

Далее мы рассмотрим проблему, с которой не раз сталкивалось большинство пользователей смартфонов: низкая контрастность.

3. Обеспечьте мощную контрастность

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

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

Как адаптировать свой веб-сайт к разному окружению? В отличие от множества субъективных аспектов, степень контрастности можно рассчитать, и у W3C имеется множество руководств по этому вопросу в «Принципах доступности веб-контента» (Web Content Accessibility Guidelines) (WCAG) – серии рекомендаций по созданию более доступного Веба для людей с физическими недостатками.

Руководство WCAG определяет три уровня соответствия: Уровень A, Уровень AA и Уровень AAA. Согласно спецификации, чтобы веб-сайт соответствовал, требования Уровня A должны выполняться, требованиям Уровня AA следует соответствовать, а требования Уровня AAA могут выполняться.

Степень контрастности Уровня A установлена на 3:1; Уровня AA – на 4.5:1, а Уровня AAA – на 7:1. В качестве контрольной точки спецификацией рекомендована степень контрастности 4.5:1 для пользователей со зрением 20/40, которое обычно бывает у пожилых людей.

Это значит, что следует сделать уровень контрастности по меньшей мере 3:1, а в идеале – 4.5:1 или больше. Но как в точности это посчитать?

ПОДСЧЕТ СТЕПЕНИ КОНТРАСТНОСТИ

К частью, Леа Веру (Lea Verou) создала инструмент простого подсчета степени контрастности.

Им легко пользоваться. Введите фоновый цвет и цвет текста, а инструмент подсчитает контрастность:

Инструмент Леа Веру определяет степень контрастности текста и его фона.

Нужно запомнить, что:

Инструмент поддерживает любой цвет CSS, который поддерживает браузер. Поэтому принимаются любые ключевые слова (например, white), HEX, RGB, RGBa, HSL и HSLa.

По мере ввода валидных значений инструмент генерирует уникальные URL’ы. Это свойство идеально для разработчика: можно заявить дизайнеру, что серый цвет на светло-сером фоне – это плохая идея.

Хотя высокая контрастность – это обычный здравый смысл, на деле отыщется достаточно плохого контраста даже у важных веб-сайтов. Нижний колонтитул сайта Square’s не соответствует Уровню A:

У нижнего колонтитула Square очень низкая контрастность.

Нижний колонтитул Square не соответствует Уровню A.

Обвинить можно даже Facebook. Ссылки в его верхнем колонтитуле на настольном компьютере тоже не соответствуют Уровню A:

Текст верхнего колонтитула Facebook’а имеет очень низкую контрастность.

Верхний колонтитул Facebook’а не соответствует Уровню A.

Таким образом, назначив своему тексту степень контрастности по меньшей мере 3:1 (а в идеале – 4.5:1 или выше), вы сделаете его доступным для слабовидящих, а также сделаете более читаемым для прочих пользователей. Инструмент Леа Веру идеально подходит для подсчета степеней контрастности и обсуждения результатов с другими людьми.

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

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

4. Убедитесь, что скринридеры понимают то, что делают ваши элементы управления

До этого мы рассматривали исследование WebAIM, которое показывает, что 71,8% пользователей экранных чтецов также применяют их на мобильных устройствах. В том же исследовании пользователей опросили о самых распространенных проблемах, с которыми те сталкиваются в Сети. Третьей и четвертой проблемами в этом списке следуют:

Бессмысленные ссылки и кнопки,

Изображения с отсутствующим или неправильным описанием (текст alt).

(На первом и втором месте в этом списке – Flash и CAPTCHA. Пожалуйста, не применяйте их.)

В следующем фрагменте кода показаны обе эти проблемы.

<style>
	button {
		background: url('search.png') no-repeat;
	}
</style>
<button></button>

<img src="ABC123.jpg">

Кнопка button для пользователя со скринридером не имеет никакого смысла – не будет прочтено ничего. Из img экранные чтецы прочтут буквально ABC123.jpg, что не слишком поможет пользователю.

Методы исправления этих проблем очень хорошо задокументированы. Для решения проблемы с button можно добавить в свой элемент управления текст и применить одну из многих техник замещения изображения для того, чтобы этот текст не был виден пользователям с нормальным зрением. В нижеприведенном фрагменте кода показана одна из таких техник: применение правила большого отрицательного отступа текста text-indent.

<style>
	button {
		background: url('search.png') no-repeat;
		text-indent: -9999px;
	}
</style>
<button>Search</button>

Решение проблемы img очень простое – добавление атрибута alt, описывающего изображение.

<img src="ABC123.jpg" alt="A view of the trees outside my window in Lansing, Michigan">

Несмотря на то, что эти проблемы широко известны и их можно легко решить, они все еще часто встречаются. Как доказательство давайте рассмотрим несколько реально существующих веб-сайтов. Я живу в великом американском штате Мичиган, известном своей «большой тройкой» автопрома: Ford, GM и Chrysler. Естественно, у этих больших компаний есть доступные мобильные веб-сайты, где требования лучших практик не нарушаются … правда?

ПРАКТИЧЕСКИЙ СЛУЧАЙ: «БОЛЬШАЯ ТРОЙКА» АВТОПРОМЫШЛЕННИКОВ

Начнем с GM. Ее мобильный веб-сайт показан ниже. Текст в кавычках показывает то, что на самом деле читает VoiceOver в OS X при выборе соответствующего элемента.

У мобильного сайта GM проблемы с доступностью. В кавычках показано, что на самом деле читает VoiceOver в OS X.

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

GM действительно обеспечивает эти изображения атрибутами alt, но, что странно, они установлены на имена файлов изображений. Например, вот источник изображения Cadillac’а:

<img title="HomepageBrand_Cadillac_290x170.jpg" height="85"
alt="HomepageBrand_Cadillac_290x170.jpg" class="side-gutters"
src="/content/dam/gm/Global/master/mobilesite/en/home/Homepage/HomepageBrand_Cadillac_290x170.jpg">

Таким образом, при выборе этого изображения VoiceOver читает буквально «Homepagebrand underscore Cadillac underscore two nine zero x one seven zero dot jpeg».

Значит, GM с треском провалил наше тестирование. Далее, давайте опробуем Ford, чей мобильный веб-сайт показан ниже.

Мобильный веб-сайт Ford’а также страдает от проблем с доступностью. В кавычках написано, что читает VoiceOver в OS X.

Некоторые проблемы Ford’а совпадают с больными точками GM. Его баннер – это ссылка без текста и изображение без атрибута alt, поэтому VoiceOver читает «index.html image».

Ниже у Ford’а показан причудливый 3-D куб с изображениями автомобилей. К сожалению, он выполнен при помощи множества div’ов, с background-image и JavaScript’ом, который при щелчке уводит пользователя в сторону. Поэтому скринридеры совершенно не понимают, что происходит в этом большом сегменте экрана. Если дотронуться до этого занимающего половину экрана «куба», VoiceOver в iOS издает всего лишь писк.

И наконец, «ссылки» внизу экрана на самом деле ссылками не являются; это div’ы с атрибутами onclick, меняющие window.location для пользовательской навигации. В общем, эти элементы управления недоступны с клавиатуры и только сбивают экранных чтецов с толку.

Вы подумали, что хуже быть уже не может, но давайте рассмотрим последнего из «большой тройки» автопромышленников, Chrysler. Его мобильный веб-сайт показан ниже.

Мобильный сайт Chrysler’а также страдает от проблем доступности. В кавычках показано, что читает VoiceOver в OS X.

Видите, на сайте Chrysler’а почти ничего не обеспечивает скринридеры контентом. Так нам еще раз напоминают о важности значимых атрибутов alt. Один из атрибутов alt, который действительно имеется — “This Is the Hero Carousal” — не менее беспомощен. Даже хуже – все изображения карусели имеют в точности одинаковые атрибуты alt; так что пользователи скринридеров не сообразят, что представлены разные ссылки. И еще новое оскорбление – слово “carousel” неправильно написано (“carousal”) и неверно произносится.

Карусель изображений занимает более половины пространства на экране iPhone’а и наверняка является самым активно используемым элементом управления. Атрибут alt должен говорить пользователю хоть что-то о видимом им изображении, а также о том, куда он попадет после щелчка по ссылке.

Например:

<img src="/path/to/TnC.jpg" alt="Learn more about the J.D. Power 2013 award-winning Chrysler Town & Country">

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

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

Почему?

Одна из причин заключается в том, что последствия нарушения таких практик неочевидны. Для зрячих пользователей сенсорных экранов все эти веб-сайты нормально работают. Во-вторых, не существует хорошего способа автоматизировать доступность веб-сайта. Валидатор W3C предупредит вас об отсутствии атрибутов alt, но не сможет протестировать более сложные сценарии, такие как кнопки-иконки и отсутствие функциональности клавиатуры. Он также не сможет проверить, значимы ли атрибуты alt в действительности.

Следовательно, мы должны доверять веб-разработчикам в том, что они изучили и помнят о необходимости применения методов доступности, у которых отсутствуют явные преимущества. Как видно из этого практического примера, зачастую они этого не делают.

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

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

5. Тестируйте свой веб-сайт на настоящем экранном чтеце

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

Это стыд и позор, потому что лучший способ понять, доступен ли ваш сайт – это опробовать его так, как это сделал бы пользователь-инвалид. Лично я не понимаю, почему скринридеры покрыты такой завесой тайны; на самом деле ими довольно легко пользоваться.

Если у вас Mac, для активации VoiceOver напишите Command + F5 . Пройдитесь по этой странице с помощью клавиши Tab и посмотрите, что тут читаемо. Также можно нажать Control + Option плюс левая или правая кнопка-стрелка для того, чтобы добраться до содержимого, отсутствующего в порядке перехода по клавише табуляции. Есть и более продвинутые виды управления, но получить общее представление можно и с помощью этих базовых элементов.

Если у вас Windows, можно скачать и пользоваться бесплатным NVDA. Самый популярный платный чтец – это JAWS; у него можно опробовать бесплатно режим демонстрации.

Мобильные устройства чуточку отличаются из-за того, что у них отсутствует клавиатура по умолчанию. Следовательно, применение экранного чтеца заставит вас продумать взаимодействие со своим устройством. Давайте выясним это, рассмотрев скринридеры, встроенные в iOS и Android —соответственно VoiceOver и TalkBack.

ПРИМЕНЕНИЕ VOICEOVER В IOS

VoiceOver – это основной помощник доступности в iOS для любых приложений, а не только для Сети. Так как большинство пользователей его не применяют, по умолчанию VoiceOver деактивирован. Чтобы его включить, перейдите в Settings → General → Accessibility → VoiceOver. Вы увидите такой экран:

Экран установок VoiceOver в iOS

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

Когда VoiceOver включен, одно касание экрана выберет элемент, но не активирует его. Например, если коснуться иконки Safari, VoiceOver прочтет “Safari”, но не запустит приложение. После выбора потребуется двойное касание для запуска приложения. Это имеет смысл, если вы в перспективе представляете себе того, кто не может видеть иконку. Такому человеку перед активацией элемента требуется подтверждение, что он выбрал его правильно.

Другое важное отличие VoiceOver’а состоит в том, что при прокрутке вам придется пользоваться тремя пальцами. Почему? Потому, что в режиме VoiceOver iOS слушает однопальцевые жесты «смахивания» во всех четырех направлениях:

«Вверх» (“Up”) — переместиться к предыдущему элементу согласно роторной установке

«Вниз» (“Down”) — переместиться к следующему элементу согласно роторной установке «Вправо» (“Right”)
переместиться к предыдущему элементу

«Влево» (“Left”) — переместиться к следующему элементу

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

Еще интереснее дело обстоит с ротором VoiceOver’а, средством конфигурирования методов навигации по элементам экрана.
Для активации ротора повращайте двумя пальцами по экрану, как будто набираете номер на дисковом телефоне. Ротор и его опции по умолчанию показаны ниже.

Роторное средство управления в VoiceOver для iOS

Установив ротор, можно менять способ навигации по странице «смахиваниями» вверх и вниз. Например, если ротор установлен на ссылки (“Links”), то движения вверх и вниз будут циклически перемещать вас по ссылкам на странице и ничего более. В данном случае ротор действует как фильтр, давая пользователю возможность отсеять тот контент, который ему интересен.

Ротор доказывает важность семантической разметки. Если ваши ссылки в действительности не являются тэгами a, то они не покажутся в установке ротора для ссылок (“Links”). Если элементы управления формой не являются настоящими элементами формы, то не будут показаны в установке ротора для элементов управления формой (“Form Controls”).

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

ПРИМЕНЕНИЕ TALKBACK В ANDROID

Подобно VoiceOver, TalkBack – это служба доступности для пользователей с ослабленным зрением, которая является «родной» для устройств Android. Так как большинству людей эта служба не требуется, она также отключена по умолчанию. Чтобы включить ее, перейдите в Settings → Accessibility → TalkBack и дотроньтесь до показанного ниже переключателя.

Страница настроек для TalkBack в Android’е

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

Элементы управления TalkBack очень похожи на элементы VoiceOver’а. Одно касание выбирает элемент, а двойное – активирует его. Прокрутка у TalkBack требует двух пальцев (помните, что для VoiceOver требуются три), и TalkBack слушает те же самые действия смахивания для перемещения по элементам страницы.

Хотя у TalkBack’а нет ничего похожего на ротор VoiceOver’а, для настройки навигации он поддерживает множество дополнительных жестов.

Краткое заключение

В этой статье мы обсудили несколько лучших практик улучшения доступности ваших веб-сайтов. Как применить эту информацию к вашим существующим или новым сайтам? Вот несколько элементов оперирования:

Клавиатура

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

Используйте семантические элементы — button для кнопок и a для ссылок.

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

Формы

Пользуйтесь настоящим элементом form.

Ассоциируйте все элементы формы (input, select и textarea) с меткой label.

Убедитесь, что для отправки формы может использоваться клавиша ввода “Enter”.

Контрастность

Обеспечьте весь текст степенью контрастности не менее 3.0 с помощью инструмента Леа Веру Contrast Ratio. В идеале, отвечать этому критерию должны любые тексты, но сначала обратите внимание на основное содержимое.

Изображения

Включите атрибуты alt, описывающие изображения.

Ссылки и кнопки

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

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

Наконец, самый лучший метод проверить свой веб-сайт – воспользоваться настоящим скринридером. Затратив несколько минут на то, чтобы выучить команды, вы узнаете в подробностях, как взаимодействует в Вебе значительная часть населения.

Автор: TJ VanToll

Источник: http://www.smashingmagazine.com/

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

Практика HTML5 и CSS3 с нуля до результата!

Получите бесплатный пошаговый видеокурс по основам адаптивной верстки с полного нуля на HTML5 и CSS3

Получить

Метки:

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

Комментарии Facebook:

Комментарии (1)

  1. Елена

    И как всегда, спасибо за урок! С уважением, Елена.

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Можно использовать следующие HTML-теги и атрибуты: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Я не робот.

Spam Protection by WP-SpamFree