Веб-доступность определяется как создание функциональных сайтов для широкого круга пользователей в т.ч. для людей с ограниченными физическими возможностями. Когда сайт корректно создан, закодирован и отредактирован, все посетители без исключения могут в равной степени им пользоваться. Например, если у сайта понятная семантическая кодировка HTML, а все изображения и ссылки сопровождаются текстовыми эквивалентами, это позволяет слепым пользователям использовать программы для чтения с экрана (тест-в-речь программы и/или тест-в- Шрифт Брайля оборудование).

Веб-доступность довольно запутанная тема в области веб-разработок. Пытаясь определить свой сайт как веб-доступный, сталкиваешься с большим количеством стандартов и рекомендаций: 508, WCAG, WCAG 2.0, WAI Priority 1, 2 & 3.

Теперь есть стандарт WAI-ARIA от W3C  (Web Accessibility Initiative – Accessible Rich Internet Applications).

Простейшее определение ARIA это добавление пользовательскому интерфейсу семантики посредством атрибутов HTML элементов. Все просто, вы добавляете <div role=»navigation»> или <form role=»search»> к определенным  HTML элементам, чтобы подробней объяснить контент программам чтения с экрана.

Спецификация ARIA огромна (160 страниц), так что я не буду детально рассматривать все. Вот четыре пункта, которые я подробно разберу: landmarks, required, invalid и live regions.

ARIA Landmarks

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

Вот один пример типичной разметки страницы:

[php]
<div id="header">
<div> <h1>My Awesome Website</h1>
<form> </form>
</div>
<div id="content">
<ul id="nav"></ul>
My website rocks!
</div>
<div id="footer"></div></div>
[/php]

А вот как это выглядит с ARIA Landmarks:

[php]
<div><div id="header" role="banner">
<h1>My Awesome Website</h1>
<form role="search"> </form>
</div>
<div id="content" role="main">
<ul id="nav" role="navigation"></ul>
My website rocks!
</div>
<div id="footer"></div></div>
[/php]

Что, я сделал, так это добавил ARIA “role” к определенным частям страницы (шапке сайта, навигации, поисковой форме, основному контенту). Т.к. “role” оговорена в спецификации, программы чтения с экрана могут проанализировать страницу благодаря “role” и тем самым позволят пользователю переходить к нужной части сайта, без необходимости просматривать весь контент.

ARIA “Required” и “Invalid”

Другая часть спецификации ARIA это атрибуты  ‘aria-required’ и ‘aria-invalid’. Эти атрибуты  необходимы программам чтения с экрана, чтобы сообщать какие поля формы обязательны к заполнению (required), а какие ошибочно заполнены (invalid). При этом, пользователю не надо искать дополнительный текст или указатель рядом с полем (к примеру, не надо искать звездочки рядом с полем обязательным к заполнению). Программа чтения с экрана сама предупредит о том, что поле надо заполнить или оно неверно заполнено.

[php]
<div><form id="searchform" role="search">
<p>You did not enter a search term</p>
<input name="query" value="" aria-required="true" aria-invalid="true" />
</form></div>
[/php]

Код указанный сверху имеет атрибуты ‘aria-required’ and ‘aria-invalid’ установленные на  “true”. Когда программе попадется этот код, она прочтет “требуется к заполнению” или “неверно заполнено”.

ARIA Live

Особенно затруднительной частью при обеспечении доступности сайта является AJAX. Как общаться с программами чтения с экрана, если контент постоянно подгружается или меняется? Благодаря ARAI Live Regions это довольно просто.
Пример:

[php]<div id="sidecontent" aria-live="polite"> AJAX контент находит тут… <div>[/php]

Добавляя ‘aria-live’атрибут к элементу, мы предупреждаем программу, что контент изменится в данной зоне и что его необходимо озвучить, когда он изменится. У атрибута ‘aria-live’ есть несколько уровней “вежливости”, что позволяет вам установить насколько вежливо пользователь будет оповещен об обновлениях контента. Эти уровни:

  • off – пользователь не оповещается
  • polite – оповещается в случае, если пользователь ничего не делает.
  • assertive – оповещается при первой возможности, но не перебивая работу пользователя

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

Итог

Конечно, это лишь краткий обзор  ARIA , но я невероятно рад тем возможностям, что он открывает. Теперь контент может быть передан более ясно, раскрыто. Есть огромное количество других аспектов ARIA, таких как: виджеты (slider, checkbox), структурные приложения (alerts, log, progressbar) и структура документа (статьи, сетка, определения) и это восхитительно.
Дополнительная информация

  • Подробный обзор ARIA
  • Спецификация ARIA
  • Установка программы чтения экрана Setting up a screen reader
  • Доступные виджеты с ARIA

Источник

От переводчика. Я взялась за перевод данной статьи, после того, как заметила использование “role” в шаблоне разработанном HTML5 Boilerplate. Если честно, то я не знала до этого о существовании спецификации ARIA. Поэтому и решила разобраться что к чему. На мой взгляд, обеспечение доступности сайта очень важный этап в создании сайта, который не следует опускать. Конечно на этапе первичной верстки удержать в голове все не возможно и можно забыть о дополнительных атрибутах. Но вот уже на этапе конечной корректировки сайта довольно просто добавить соответствующие атрибуты к тегам. Я хочу сказать, что всего несколькими строчками кода можно значительно упростить работу с сайтами людям с ограниченными возможностями.