• Статья
Учебник по специальным возможностям в Интернете и WAI-ARIA

Эмили Льюис (Emily P. Lewis) | 15 июня 2010 г.

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

Что не вызывает сомнений, так это причины этого явления: отсутствие понимания важности специальных возможностей, а также недостаток знаний о том, как реализовать требования по предоставлению специальных возможностей. Между тем, согласно опросу 2008 года среди создателей веб-сайтов, проведенному интернет-журналом List Apart, 46% респондентов утверждали, что имеют знания по специальным возможностям.

Конечно, 46% — неплохое число (это почти половина), но я сомневаюсь, что этот показатель отражает реальную картину по всем веб-дизайнерам и разработчикам. Реальный процент может быть и гораздо ниже. Кроме того, даже если человек верит, что знает о специальных возможностях, это еще не значит, что он их реализует.

Итак, давайте попробуем это изменить.

Что такое специальные возможности в Интернете?

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

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

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

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

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

  • Отсутствует альтернативный (alt) текст для изображений на основе текста.
  • Отсутствует функциональность клавиатуры.
  • Отсутствует воспроизведение текста для восприятия на слух.

И все это в основном относится к контенту в Интернете. Когда в веб-приложениях требуется взаимодействие, то проблема еще острее.

Для кого предназначены специальные возможности?

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

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

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

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

Это тоже еще не полная картина. Специальные возможности в Интернете связаны с сегодняшними рекомендациями и помогают:

  • выполнять веб-разработку для мобильных устройств;
  • обеспечивать удобство и простоту использования;
  • обеспечивать независимость от устройств;
  • оптимизировать поисковую систему (SEO).

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

Итог

Несмотря на цифры, упомянутые мной в начале этой статьи, я согласна с Марком Твеном в его отношении к статистике. Поэтому давайте рассмотрим реальный сценарий. Несколько лет назад национальная федерация слепых (National Federation of the Blind) предъявила иск корпорации Target в связи с тем, что веб-сайт корпорации недоступен для людей, использующих вспомогательные технологии. Иск был удовлетворен, и корпорации Target был выставлен счет на 6 миллионов долларов в качестве компенсации за убытки истцов.

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

И давайте не забывать о спросе. Согласно приведенным сведениям об американцах с ограниченными возможностями, существует 51 миллион заблокированных потребителей, могущих потратить 175 миллионов долларов. И это только в США! Нет никаких разумных оснований исключать рынок с такой покупательной способностью, не говоря уже о потенциальных юридических последствиях для веб-сайтов, где не реализованы специальные возможности.

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

Доступный контент: WCAG 2.0

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

Web Accessibility Initiative(WAI — программа специальных возможностей в Интернете) установила правила специальных возможностей доступа к контенту в Интернете (WCAG), которые должны служить стандартом для специальных возможностей доступа к веб-контенту. Эти правила строятся на четырех принципах, каждый из которых посвящен одному из распространенных барьеров для специальных возможностей доступа к веб-контенту.

  • Воспринимаемость: контент доступен для восприятия (с помощью зрения, слуха и осязания).
  • Функциональность: интерфейсные формы, элементы управления и элементы навигации работоспособны.
  • Понятность: контент и интерфейс доступны для понимания.
  • Надежность: контент может надежно использоваться разнообразными пользовательскими агентами, включая предоставляющие специальные возможности.

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

  • все изображения, в том числе используемые для кнопок и гиперкарт, должны иметь соответствующий альтернативный текст;
  • декоративные изображения должны иметь пустой альтернативный текст или быть реализованы посредством фонов CSS.

В сущности, эти правила означают, что при наличии изображения, содержащего текст, необходимо назначить атрибуту alt значение, соответствующее тексту в изображении:

<img src="registernow.png" alt="Register Now!" />

А также при наличии чисто декоративного изображения, в котором нет никакого текста, атрибуту alt следует назначить пустое значение:

<img src="businessman.jpg" alt="" />

Аналогично, возможно вы уже следуете правилам для создания понятного контента, включая указание языка страницы:

<html lang="en">

Или используете в разметке семантику, а не представление:

<ul id="navigation">
    <li><a href="/">Home</a></li>
    <li><a href="/About/">About</a></li>
    ...
</ul>

Или предоставляете расшифровку для сокращений:

<abbr title="Hypertext Markup Language">HTML</abbr>

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

Если вас устраивает язык технических терминов, обратитесь к спецификации WCAG 2.0. Лично для меня этот язык невыносим, как и язык, которым написаны все спецификации W3C. Я предпочитаю иметь дело с контрольным списком WebAIM, который предоставляет более простое и понятное объяснение.

Доступные приложения: WAI-ARIA

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

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

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

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

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

На помощь приходят Accessible Rich Internet Applications (доступные полнофункциональные интернет-приложения) (ARIA) WAI, устанавливающие правила для создания более доступного современного динамического контента и расширенных элементов управления. Лично мне нравится такая аналогия: WAI-ARIA подобны микроформату для специальных возможностей. Правила ARIA просто определяют атрибуты разметки, которые предоставляют семантические сведения для специальных возможностей, необходимых для того, чтобы сделать приложения более доступными.

Определение структуры. Роли ориентиров документов

В современной разметке отсутствует способ семантического указания структуры документа, например области навигации или основного контента. Это определенно затрудняет пользователям программ чтения с экрана переход непосредственно в определенную часть страницы. Фактически такой недостаток структуры и привел к появлению «ссылок пропуска».

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

  • role="banner" назначается элементам, содержащим ориентированный на сайт контент, такой как имя сайта, заголовок и эмблема.
  • role="navigation" назначается элементу, содержащему навигационные ссылки.
  • role="main" должна назначаться основному контенту.
  • role="search" назначается элементу, содержащему поиск по сайту.
  • role="article" назначается автономному контенту; это целесообразно вне контекста в оставшейся части документа.
  • role="complementary" назначается контенту, который дополняет основной контент.
  • role="contentinfo" назначается метаданным дочернего контента, таким как нижние колонтитулы и уведомления об авторских правах.
  • role="application" назначается областям страницы, содержащим контент и функциональность приложения. Обратите внимание, что эта роль уникальна по двум причинам: 1) при назначении всей странице она не воспринимается как ориентир для навигации, и 2) она сообщает программам чтения с экрана, что следует переключиться с «режима просмотра» на «режим интерфейса приложения».

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

Более того, эти роли не ограничиваются веб-приложениями. Многие веб-сайты сегодня могут добавлять эти атрибуты для поддержки специальных возможностей, независимо от интерактивности приложений. Например, на сайте, использующем неупорядоченный список ссылок для навигации, можно повысить доступность, добавив атрибут role="navigation":

<ul role="navigation">
    <li><a href="/">Home</a></li>
    <li><a href="/About/">About</a></li>
    ...
</ul>

Что насчет HTML5?

Если вы экспериментировали с HTML5 или читали о нем, то возможно отметите некоторое пересечение ролей документов в WAI-ARIA и новых элементов секционирования в HTML5. И будете правы … отчасти.

HTML5 на самом деле включает замечательные семантические элементы <header>, <nav>, <article> и <aside>, которые могут казаться непосредственно связанными с некоторыми приведенными мной ролями макета документа. Однако большей частью эта связь только кажущаяся. Фактически для большинства ролей нет прямого эквивалента в HTML5.

В настоящее время я нахожу наиболее полезным справочное руководство консалтинговой группы Paciello Group Comparison of ARIA landmark roles and HTML5 structural elements (Сравнение ролей ориентиров ARIA и структурных элементов HTML5). В сущности оно устанавливает, что имеются только следующие прямые эквиваленты:

  • <nav> и role="navigation"
  • <aside> и role="complementary"
  • <footer> и role="contentinfo"

В таких случаях, если специальные возможности поддерживают HTML5, то соответствующую роль документа ARIA можно пропустить.

Будьте внимательны

Как всегда при появлении новейших технологий, их обсуждают достаточно бурно. Некоторые серьезно убеждены в том, что роли документов WAI-ARIA напрямую противоречат структурным элементам HTML5и могут привести к последующим конфликтам в пользовательских агентах. Другие, например Paciello Group, видят различия.

Кроме того, идут споры по поводу ориентиров документов, поскольку они не проходят проверки HTML 4 и XHTML с помощью средства проверки W3C. Также не выполняются проверки и в HTML5.

Итак, что следует делать? Определите свои приоритеты. Вы вообще используете HTML5? Что для вас важнее, проверка или специальные возможности?

Навигация с помощью клавиатуры посредствомtabindex

Кроме содействия навигации путем определения структуры документа, WAI-ARIA также помогает разрешить проблемы навигации с помощью клавиатуры, расширяя использование атрибута tabindex.

В HTML 4 атрибут tabindex можно применять к элементам <a>, <area>, <button>, <input>, <object>, <select> и <textarea>, задавая значения от 0 до 32767. Это помогает выполнять навигацию с помощью клавиатуры, начиная с элемента с самым маленьким номером и переходя к элементам с большими номерами.

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

Кроме того, в WAI-ARIA атрибут tabindex может иметь отрицательное значение, например -1. Это позволяет элементам получать программный фокус с помощью element.focus(), но при этом не быть включенными в естественный порядок навигации.

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

<ul tabindex="0">          
<li>Item 1
<ul>
<li>Item 1.1</li>
<li>Item 1.2</li>            
</ul>
</li>
...
</ul>

Я не хочу, чтобы по вложенным элементам меню можно было перемещаться с помощью клавиши Tab. Перемещаться по ним следует с помощью клавиш-стрелок, поэтому я назначаю атрибуту tabindexотрицательное значение:

<ul tabindex="0">          
<li tabindex="-1">Item 1
<ul>
<li tabindex="-1">Item 1.1</li>
<li tabindex="-1">Item 1.2</li>            
</ul>
</li>
...
</ul>

Определение ролей мини-приложений

Мы уже изучали использование атрибута role для указания структуры документа и для упрощения навигации. В WAI-ARIA роли также используются, чтобы описать, что делает элемент в мини-приложении, т. е. для указания типа элемента управления (меню, панель инструментов, ползунок, всплывающая подсказка или дерево).

Специальные возможности уже понимают роли элементов HTML. Например, <dl> понимается программой чтения с экрана как список определений X элементов, где значение <dt> равно значению <dd>. Но поскольку мини-приложения могут использовать любые элементы, специальным возможностям требуются дополнительные сведения для понимания, что эти элементы делают.

Для примера с меню в виде дерева я могу применить роль как к главному элементу, так и ко вложенным:

<ul tabindex="0" role="tree">          
<li tabindex="-1">Item 1
<ul>
<li tabindex="-1" role="treeitem">Item 1.1</li>
<li tabindex="-1" role="treeitem">Item 1.2</li>            
</ul>
</li>
...
</ul>

Некоторые самые распространенные роли мини-приложений WAI-ARIA:

  • progressbar
  • slider
  • button
  • tree
  • textfield
  • checkbox
  • alert
  • dialog

Остальные роли см. в полном списке ARIA.

Определение состояний и свойств

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

Давайте рассмотрим простую форму, в которой пользователь должен вводить адрес электронной почты. Без ARIA специальные возможности не имеют сведений о том, что некоторое поле является обязательным. Но если мы добавим атрибут мини-приложения aria-required, то пользователи уведомляются о том, что поле обязательно:

<input type="text" name="email" aria-required="true" />

Состояния и свойства ARIA включают атрибуты, назначаемые элементам управления пользовательским интерфейсом, такие как атрибут мини-приложения aria-required, а также:

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

Подробное рассмотрение динамических областей

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

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

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

<p aria-live="polite">

Значение assertive сообщает специальным возможностям, что следует уведомлять пользователей об обновлении немедленно, хотя это значение следует использовать с осторожностью, поскольку оно будет прерывать текущие задачи пользователя:

<p aria-live="assertive">

И если свойство aria-live не назначено, или если ему задано значение off, то пользователь вообще не будет уведомляться:

<p aria-live="off">

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

  • aria-atomic указывает, должна ли пользователю представляться вся измененная динамическая область, или только ее часть;
  • aria-busy указывает, что динамическая область обновляется в текущий момент;
  • aria-relevant указывает, какие изменения динамической области являются релевантными.


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

Обязательно ли это использовать?

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

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

Это уже поддерживается в следующих инструментах:

  • Firefox 1.5+
  • Opera 9.5+
  • IE8+
  • Webkit
  • JAWS 7.1+
  • Windows-Eyes 5.5+
  • NVDA
  • Zoomtext 9+
  • FireVox

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

Дополнительные материалы

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

Инструменты

Следующие материалы помогут в путешествии по специальным возможностям.