Дата публикации:	20.03.2016
Дата обновления:	23.03.2016

Предварительные замечания

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

Кратко о главном

WAI-ARIA (Web Accessibility Initiative's Accessible Rich Internet Applications) — отдельная спецификация, которая «заполняет дыры» в HTML 4 (или любом другом языке разметки) для повышения доступности приложений и веб-страниц.

Представьте себе, что вы написали скрипт для реализации ползунка. Так как в HTML 4 нет встроенного ползунка, с помощью нескольких HTML-элементов (элемента <input> и изображений) и JavaScript-кода вы создаете то, что выглядит и функционирует как ползунок. Но в таком случае не существует способа сообщить операционной системе, что этот виджет исполняет роль ползунка, и передать сведения о его текущем состоянии и значении. А если система не располагает этой крайне необходимой информацией, вспомогательные технологии (например, программы экранного доступа) не смогут донести ее до пользователя. ARIA представляет собой вариант решения этой проблемы путем добавления целого ряда новых атрибутов, которые могут быть понятны браузерам и вспомогательным технологиям.

примечание: Если вы будете использовать новые ARIA-атрибуты, ваши HTML 4-страницы не будут проходить валидацию. Если в остальном ваша разметка построена правильно, не обращайте на это внимания — доступность важнее валидности.

Итак, используя ужасный древний HTML, можно — теоретически — добавить ARIA в такой код:

<font size="+5" color="red">I should be a -i heading</font>

В результате получится следующее.

<font size="+5" color="red" role="heading" aria-level="2">I should be a heading</font>

Такой код сообщает агенту пользователя, что этот текст является заголовком уровня 2. Конечно же, это абсурд, так как в HTML уже есть абсолютно допустимый и семантический способ создания такой структуры:

<h2>I AM a heading</h2>

Разработчик может по невнимательности не добавить необходимые ARIA-атрибуты, в то время как использование правильного элемента <h2> само по себе подразумевает «заголовочность» и включает сведения об уровне, поэтому такой синтаксис намного надёжнее. ARIA — не панацея и не карт-бланш для тех, кто хочет пренебречь правилами разметки и построить сайт с помощью одних только элементов <div> и <span>. По возможности создавайте правильную разметку и используйте ARIA только в тех ситуациях, когда не существует другого способа отразить семантику элементов (как в случае с ползунком в HTML 4). В спецификации ARIA говорится: «мы надеемся, что с течением времени базовые языки будут развиваться, и в результате семантическими станут даже те объекты, которые сейчас требуют использования WAI-ARIA. Если семантика элемента выражает необходимый признак, разработчик может отказаться от использования WAI-ARIA». Поэтому, например, к HTML5-элементу <nav> не нужно добавлять атрибут aria role=navigation, так как он должен быть встроенным (в идеальном мире). Однако HTML5 вышел относительно недавно, тогда как ARIA уже поддерживается многими вспомогательными технологиями. Так что будет не лишним использовать встроенный элемент вместе с данными ARIA — это поможет пользователям вспомогательных технологий. Поэтому HTML5-валидатор на https.validator.nu/ рассчитан на HTML5 и ARIA (в то время как валидаторы HTML 4 в случае обнаружения ARIA-атрибутов выдают сообщение об ошибке, поскольку HTML 4 был выпущен раньше ARIA).

ARIA-СТРУКТУРА ДОКУМЕНТА И РОЛИ

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

• application;
• article;
• banner;
• complementary;
• contentinfo;
• document;
• form;
• heading;
• main;
• navigation;
• search.

Очевидно, что некоторые из них совпадают с HTML5-элементами: <article>) <form>( <header>) <nav>.

Для других ролей такого явного взаимооднозначного соответствия нет. К примеру, role=banner «обычно содержит логотип или фирменный знак спонсора сайта, а также специфический для данного сайта инструмент поиска. Баннер обычно располагается вверху страницы и занимает всю её ширину». Поначалу это напоминает элемент <header>) но как мы уже знаем, на странице может быть несколько заголовков. Так что атрибут role=banner может применяться только к «заголовку страницы».

Точно так же contentinfo определяется как «большая заметная область, которая содержит информацию о родительском документе. В качестве такой информации могут быть указаны, к примеру, сведения об авторском праве и ссылки на заявление о конфиденциальности». Это напоминает элемент <footer>, Но точнее было бы назвать его «футер страницы», так как другие футеры под это описание не подходят.

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

div[role=main]   {
	color:red; -
	background-color:yellow;  
	font-family: "Comic Sans MS",  cursive; 
}

Наконец-то: доступность и превосходная типографика в совершенной гармонии друг с другом.

КАК СОВМЕЩАТЬ ARIA И HTML

Мы советуем вам придерживаться следующей точки зрения: использование ARIA во всех случаях, где это уместно, является временной мерой, которая улучшает доступность и не влияет на валидность (но обратите внимание на «Замечания по поводу программ экранного доступа», приведенные ниже). Однако в данной книге мы этого не делаем (поскольку мы пытаемся научить вас HTML5, а не ARIA).

...

ЗАМЕЧАНИЯ ПО ПОВОДУ ПРОГРАММ ЭКРАННОГО ДОСТУПА

Хьюстон, у нас проблемы. В 2007 году меня очень беспокоил тот факт, что производители программ экранного доступа не принимают участия в создании спецификации HTML5, и я написал в W3C письмо с просьбой пригласить этих производителей подключиться к работе. В 2009 я спросил разработчика HTML Яна Хиксона, отреагировал ли кто-нибудь на это предложение. Он ответил: «Несколько производителей отреагировали. Но они, к сожалению, сказали, что у них нет на это времени. Правда, после этого компания Apple стала активно заниматься встроенным в Mac OS X программным обеспечением для экранного доступа, и сейчас Apple активно поддерживает с нами связь. Так что, по крайней мере, один производитель вовлечен в этот процесс».

...p>

Моё личное мнение звучит так: если вы следуете правилам спецификации, неспособность браузера или программы экранного доступа адекватно воспринимать контент — не ваша проблема. Но это только моё личное мнение. Вы можете считать иначе; кроме того, в определённых ситуациях вам может потребоваться упростить контент, чтобы разметка соответствовала возможностям этих программ. Конечно, к тому времени, как вы прочитаете эту книгу, часть проблем уже может быть решена. А пока вы сами должны знать своих пользователей и требования в вашей области.

Ссылки по теме

• Введение в WAI ARIA
• Раздел WAI_ARIA в спецификации HTML5
• Спецификация Accessible Rich Internet Applications (WAI-ARIA)
• Стив Фолкнер из The Paciello Group создал список ARIA-информации, которая не встроена в HTML5: www.paciellogroup.com/blog/?p=585.