https://dev.opera.com/articles/introduction-to-wai-aria/

Оригинальная статья

Введение в WAI ARIA

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

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

Журнал обновлений

Обновление от 8 октября 2008 г .: Список ролей ориентира документа обновлен, чтобы отразить изменения в спецификации.

Обновление от 1 апреля 2009 г .: Раздел aria-channelи aria-live=”rude”значение удалены, чтобы отразить изменение в спецификации. Оба были удалены из спецификации.

Вступление

Язык разметки гипертекста (HTML) изначально не предназначался для создания веб-приложений. HTML имеет ограниченный набор элементов управления интерфейсом и основан на модели последовательного взаимодействия клиент-сервер. Разработчики веб-приложений обошли эти ограничения, создав свои собственные пользовательские компоненты (виджеты), используя JavaScript для добавления поведения к виджетам.

К сожалению, методы, используемые для преодоления этих ограничений, были недоступны. Хотя настраиваемые виджеты могут выглядеть и вести себя как обычные виджеты настольных приложений, такие как виджет в виде дерева, роль (что делает виджет), состояние (его уникальная конфигурация, например checked) и другие важные свойства недоступны для вспомогательных технологий, например программы чтения с экрана. Это то же самое, что оформление обычного текста так, чтобы он выглядел как заголовок, а не использование элемента заголовка – простой текст выглядит как заголовок, но не отображается как заголовок для вспомогательных технологий.

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

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

Краткая история HTML

Изначально HTML был разработан как гипертекстовая система для структурирования и обмена связанными документами. Ранние черновики HTML определяли теги, такие как заголовки, абзацы, списки и привязки, для добавления структуры в текстовые документы. Первое предложение спецификации HTML от IETF также включало img элемент, позволяющий отображать графику в строке. Первой формальной спецификацией HTML был HTML 2 , основанный на ранних черновиках HTML. Эта спецификация представила формы и определила небольшой набор компонентов интерфейса для создания полей редактирования, кнопок, флажков, переключателей и раскрывающихся списков. Небольшой набор компонентов интерфейса, определённых в HTML 2, практически не изменился по сравнению с набором, который мы сейчас используем в HTML 4.01 .

Модель коммуникации для HTML основана на модели клиент-сервер. В модели клиент-сервер клиент отправляет запросы и может получать ответы; сервер прослушивает запросы, обрабатывает запрос на сервере и отправляет ответы клиенту. Поскольку в HTML не было уровня поведения, предполагалось, что обмен данными будет последовательным – клиент запрашивает страницу с сервера; сервер обрабатывает запрос и отправляет страницу клиенту.

Веб-приложения

Веб-приложения пытаются имитировать обычные настольные приложения, за исключением того, что веб-приложения запускаются внутри другого обычного настольного приложения – браузера. Есть также два фундаментальных различия между HTML и его моделью взаимодействия и обычным настольным приложением:

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

Эмуляция обычных настольных приложений

Фоновые запросы к серверу

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

Эмуляция богатых компонентов

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

Рисунок 1. Диалоговое окно с флажком для трех состояний.

Рисунок 2 – Виджет ползунка, который может использоваться для индикации качества услуги.

Проблемы доступности с эмуляцией внешнего вида и ощущений

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

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

WAI-ARIA спешит на помощь

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

Клавиатура навигации

Наряду с предоставлением альтернативного текста для нетекстовых объектов, возможность взаимодействия с элементами интерфейса, используя только клавиатуру, является одним из основных условий доступности. Разработчики, понимающие специальные возможности, могут создавать собственные виджеты, используя компоненты, которые могут получать фокус, например input элемент со type значением атрибута image ( <input type=”image” …>). К сожалению, большинство виджетов не создаются с использованием компонентов, доступных с клавиатуры, а вместо этого используют такие элементы, как img элемент, или могут состоять из составных элементов, которые должны находиться в элементе контейнера, таком как a div, который не может получить фокус клавиатуры.

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

ARIA расширяет атрибут tabindex, чтобы его можно было использовать для всех видимых элементов. ARIA также позволяет указывать отрицательное значение для элементов, которые не должны появляться в порядке табуляции на клавиатуре, но могут быть программно сфокусированы (передать фокус элементу с помощью сценария). Поскольку фактическое значение отрицательного числа неважно (элемент никогда не получает фокус клавиатуры), значение-1 обычно используется для элементов, которые не должны включаться в порядок табуляции, но могут потребовать программной фокусировки. Например, вы можете создать виджет меню, в котором само меню находится в порядке табуляции и получает фокус путём перехода к нему, но элементы меню не находятся в порядке табуляции на клавиатуре. Вместо этого пункты меню могут быть запрограммированы таким образом, чтобы по ним можно было перемещаться с помощью клавиш курсора. Таким образом, пользователям не нужно переходить по всем пунктам меню табуляцией, и они могут лучше перемещаться по документу. Это верно для всех виджетов, которые имеют ряд компонентов, которым требуется доступ с клавиатуры, например дерево.

Добавление к естественному порядку табуляции

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

…</div>

Отрицательный tabindex

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

…</div>

В этом примере div элемент не размещается в порядке табуляции, но его tabindex значение атрибута -1 означает, что он может получить программный фокус. В следующем фрагменте кода JavaScript выбирается элемент, определённый выше, и используется focus метод для наведения фокуса на элемент.

var objDiv = document.getElementById(‘progaccess’);// Focus on the element

objDiv.focus();

Что я?

ARIA представляет role атрибут, помогающий определять виджеты, такие как ползунок, и определять структуру страницы, такую как раздел навигации. Одна из основных проблем веб-приложений заключается в том, что любой элемент можно использовать для создания виджета. HTML – элементы уже имеют предопределённые роли. Роль элемента – это то, что он делает – роль, которую он играет в структуре. Например, вспомогательные технологии хорошо понимают роль заголовка. Когда виджеты создаются из существующих элементов, роль элемента – это то, что раскрывается вспомогательной технологией, а не то, что он визуально представляет в виджете. Например, если ползунок для ползунка создаётся с использованием элемента изображения с соответствующим альтернативным текстом, то программа чтения с экрана, скорее всего, объявит элемент управления как “Рисунок, большой палец”, в отличие от чего-то более значимого, например”ползунок, значение 16 процентов”.

Рисунок 3 – Ползунок на типичном элементе управления.

Роль, заданная role атрибутом, превосходит роль собственного элемента. В следующем примере input элемент имеет role атрибут slider (мы рассмотрим некоторые другие свойства ARIA позже в этой статье) – роль, предоставляемая вспомогательной технологии slider, а не input.

<input type=“image”

src=“thumb.gif”

alt=“Effectiveness”

role=“slider”

aria-valuemin=“0”

aria-valuemax=“100”

aria-valuenow=“42”

aria-valuetext=“42 percent”

aria-labelledby=“leffective”>

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

Роли ориентира документа

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

Рисунок 4 – Типичная страница с заголовком, боковой панелью и областью основного содержимого.

ARIA определяет следующие роли ориентира документа.

article

Контент, который имеет смысл сам по себе, например, полное сообщение в блоге, комментарий в блоге, сообщение на форуме и т. д.

banner

Контент, ориентированный на сайт, например заголовок страницы и логотип.

complementary

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

contentinfo

Детский контент, такой как сноски, авторские права, ссылки на заявление о конфиденциальности, ссылки на предпочтения и т. Д.

main

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

navigation

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

Этот раздел содержит форму поиска для поиска на сайте.

В следующем примере указываются роли ориентира banner, navigationи mainдля создания структуры страницы, показанной на рисунке 4.

…</div><div role=“navigation”>

…</div><div role=“main”>

…</div>

Состояния и свойства ARIA

Состояния и свойства ARIA позволяют передавать дополнительную информацию о виджете вспомогательной технологии, чтобы помочь пользователю понять, как взаимодействовать с виджетом. Состояние определяет уникальную конфигурацию информации для объекта. Например, aria-checked свойство имеет три значения состояния; true, false и mixed.

В приведённом выше примере слайдера мы включили различные свойства aria, показанные ниже, которые помогли описать виджет вспомогательным технологиям.

aria-valuemin

Сохраняет самое низкое значение диапазона.

aria-valuemax

Сохраняет максимальное значение диапазона.

aria-valuenow

Сохраняет текущее значение в диапазоне.

aria-valuetext

Сохраняет читаемый текст, чтобы помочь пользователю понять контекст. Например, “30 dollars”.

aria-labelledby

Хранит idатрибут текстовой метки, содержащий соответствующее приглашение для этого виджета.

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

// Set the ARIA property values when the thumb is// moved on the slider

objThumb.setAttribute(‘aria-valuenow’, iValue);

objThumb.setAttribute(‘aria-valuetext’, iValue + ‘ %’);

Добавление ролей и атрибутов ARIA не будет проверяться в HTML 4.01 или XHTML 1.0, но это нормально, поскольку ARIA добавляет важную информацию в спецификации, которые были написаны давно. Ведется работа по определению DTD, которое можно использовать с модульным XML , таким как XHTML 1.1. В спецификации ARIA есть полный список состояний и свойств, помогающих определить доступные виджеты.

Активные области

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

ария-live

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

off

Это значение по умолчанию, которое указывает на то, что область не активна.

polite

Это нормальная работа и ожидаемое поведение для живых областей. Значение politeу казывает, что нет необходимости отвечать, пока пользователь не завершит своё текущее действие.

assertive

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

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

aria-atomic свойство

aria-atomic свойство является необязательным свойством живых областей, которые могут иметь значение true или false (по умолчанию, если это свойство не задано). Когда область обновляется, aria-atomic свойство используется, чтобы указать, должны ли вспомогательные технологии предоставлять пользователю все или часть изменённой области. Если для этого свойства установлено значение true, вспомогательные технологии должны представлять весь регион в целом; в противном случае изменённая часть региона может быть объявлена сама по себе.

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

<ul aria-atomic=“true”

aria-live=“polite”>

aria-busy свойство

aria-busy свойство является необязательным свойством живых областей, которые могут иметь значение true или false (по умолчанию , если это свойство не задано). Если несколько частей живой области необходимо загрузить до того, как изменения будут объявлены пользователю, для aria-busy свойства можно установить значение до true тех пор, пока не будет загружена последняя часть, а затем установить значение, false когда обновления будут завершены. Это свойство не позволяет вспомогательным технологиям объявлять об изменениях до завершения обновлений.

<ul aria-atomic=“true”

aria-busy=“true”

aria-live=“polite”>

aria-relevant свойство

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

additions

Узлы добавляются в DOM внутри области.

removals

Узлы удаляются из DOM внутри области.

text

Текст добавляется или удаляется из модели DOM.

all

Все вышеперечисленное (добавления, удаления, текст) применимо к этой области.

При отсутствии явного aria-relevant свойства по умолчанию предполагается наличие изменений и дополнений текста ( aria-relevant=”text additions”). В следующем примере будут объявлены изменения только в том случае, если узлы добавлены в DOM в пределах области. При изменении текста или удалении узлов в области пользователь не будет уведомлен.

<ul aria-relevant=“additions”

aria-atomic=“true”

aria-live=“polite”>

Когда можно использовать ARIA?

Использование ARIA не вызывает никаких негативных побочных эффектов, поэтому вы можете сразу приступить к его использованию. Все четыре основных браузера реализовали поддержку ARIA или планируют реализовать поддержку ARIA. Opera 9.5 и Firefox 1.5+ уже включают поддержку ARIA. Internet Explorer 8 Beta имеет поддержку ARIA, а WebKit, фреймворк приложений с открытым исходным кодом, лежащий в основе Safari, объявил, что они начали добавлять поддержку ARIA.

ARIA также получает широкую поддержку со стороны вспомогательных технологий. JAWS 7.1+, Window-Eyes 5.5+, NVDA , Zoomtext 9+ и другие имеют базовую поддержку ARIA, и ситуация должна улучшиться.

Будьте одним из первых

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

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

На моем личном сайте, я включил роли документ знаковые для main, navigation, searchи secondary. Рассмотрим следующую структуру документа.

…</div><div id=“nav”>

…

</form>

…</div><div id=“content”>

…</div>

Мы могли бы записать role атрибут для ориентиров нашего документа прямо в разметку.

…</div><div id=”nav” role=“navigation”>

…

</form>

…</div><div id=“content” role=“main”>

…</div>

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

function addARIARole(strID, strRole){

// Find the element to add a role property to

var objElement = document.getElementById(strID);

if (objElement)

{

// Add the role property to the element

objElement.setAttribute(‘role’, strRole);

}

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

function setupARIA(){

// Add ARIA roles to the document

addARIARole(‘content’, ‘main’);

addARIARole(‘nav’, ‘navigation’);

addARIARole(‘searchform’, ‘search’);

addARIARole(‘ads’, ‘banner’);

}window.onload = setupARIA;

Укажите обязательные поля

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

<label for=“contactname”>Name</label><input type=“text”

id=“contactname”

name=“contactname”

size=“30”

aria-required=“true”>

WordPress начал использовать aria-required атрибут для обязательных полей в разделе комментариев для записей блога.

Добавить другие соответствующие свойства

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

<h2 id=“limg”>Paragliding</h2><p id=“dimg”>

A long description of our paragliding trip …</p><div><img src=“takeoff.png”

alt=“Getting ready to take off”

aria-labelledby=“limg”

aria-describedby=“dimg”></div>

Приоритет разметки

Разметка ARIA имеет приоритет над разметкой основного языка. Это означает, что если aria-labelledbyиспользуется рядом label for=””, aria-labelledby будет иметь приоритет. Этот label элемент по-прежнему рекомендуется для старых браузеров, которые не поддерживают ARIA. Простой способ избежать конфликтов – использовать aria-labelledby атрибут для ссылки на a label- это гарантирует доступность метки независимо от поддержки ARIA.

<label id=“lblef” for=“effectiveness”>Effectiveness</label><input type=“image”

role=“slider”

id=“effectiveness”

aria-labelledby=“lblef”

…>

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

Все вместе сейчас

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

Независимо от того, разрабатываете ли вы полноценные веб-приложения со сложными виджетами и живыми разделами или у вас самый простой веб-сайт, вы можете начать использовать ARIA прямо сейчас, чтобы принести пользу пользователям с ограниченными возможностями.

Дальнейшее чтение

Гез Лимон

Опубликовано в 1 августа 2008 г. в статьях . Отредактируйте эту статью на GitHub . Под лицензией Creative Commons Attribution, Non Commercial – Share Alike 2.5 Generic .