Это может быть шоком, но я говорю вам: сеть изменилась! За последние восемь лет выросли Ajax, JavaScript, HTML5 и бесчисленное множество интерфейсных сред. Следовательно, Интернет больше не является местом статичных HTML-страниц, как это иногда смешно. Скорее, он стал площадкой для сложных, почти настольных веб-приложений, у каждого из которых есть свои виджеты, элементы управления и поведение.
Большинство из нас принимают это как должное и доводят веб-разработку до предела. Тем не менее, есть также немалое количество людей с ограниченными возможностями, которые все еще борются с этими новыми методами. Это не связано с отключенным JavaScript или недостаточными возможностями современных вспомогательных технологий (AT). Напротив, в 2012 году WebAIM обнаружил, что более 98 процентов пользователей программ чтения с экрана поддерживают JavaScript. Кроме того, AT, такие как программы чтения с экрана или обновляемые дисплеи Брайля , становятся лучше с каждым годом.
Проблема заключается в ограниченной способности HTML размечать веб-приложения, которые интенсивно используют JavaScript и создают огромное количество динамического контента. Когда AT работают с приложениями JavaScript, можно выделить четыре основных препятствия:
- Неизвестная функциональность компонентов
- Неизвестные состояния и свойства компонентов
- Незаявленное изменение динамического контента
- Плохая доступность клавиатуры
Введите WAI-ARIA .
WAI-что?
ARIA, как ее иногда называют, обозначает Accessible Rich Internet Applications . Это технологическая спецификация, разработанная в рамках Инициативы доступности веб-сайтов (часть WAI, которая завершает аббревиатуру) в W3C (Консорциум всемирной паутины), и теперь она является рекомендацией W3C .
Вы можете представить ARIA как набор атрибутов, которые будут включены в ваш обычный HTML-код. Эта дополнительная семантика помогает AT идентифицировать свойства, отношения и состояния в ваших пользовательских интерфейсах. Таким образом, ARIA решает проблемы доступности, упомянутые выше, и позволяет разработчикам сделать современные веб-приложения более удобными для людей с ограниченными возможностями.
Теперь давайте взглянем на виджет панели вкладок Bootstrap и подробно рассмотрим, как ARIA помогает нам расширять данную HTML-структуру, чтобы сделать ее более доступной. Мы будем решать каждую из вышеупомянутых ключевых проблем на этом пути.
1. Функциональность через роли
ARIA предоставляет богатую роль таксономии, которая позволяет вам, как разработчику, классифицировать в противном случае бессмысленные теги. Это подготавливает теги для AT, раскрывая функциональность или роль, которую они играют в общем веб-документе.
Bootstrap использует неупорядоченный список, чтобы разметить навигацию с вкладками. Фреймворк также использует список ролей ARIA и tab правильно.
<ul id="myTab" class="nav nav-tabs" role="tablist"> <li class="active"> <a href="#home" role="tab" data-toggle="tab">Home</a> </li> <li> <a href="#profile" role="tab" data-toggle="tab">Profile</a> </li> <li> <a href="#articles" role="tab" data-toggle="tab">Articles</a> </li> </ul>
Эти роли переопределяют обычный список и тип элемента списка и предоставляют этот фрагмент HTML для представления списка вкладок. Мы должны сделать этот шаг вперед, чем Bootstrap. Вот HTML-код для панелей, в который мы добавим правильные роли ARIA:
<div id="myTabContent" class="tab-content"> <div class="tab-pane fade in active" id="home" role="tabpanel"> <p>Welcome!</p> </div> <div class="tab-pane fade" id="profile" role="tabpanel"> <p>My profile.</p> </div> <div class="tab-pane fade" id="articles" role="tabpanel"> <p>My articles.</p> </div> </div>
Примечание: пожалуйста, игнорируйте имена классов, такие как active и tab-pane ; они принадлежат Bootstrap и предназначены только для презентаций.
Роли помогают установить прочную основу, но это еще не все.
2. Состояния и свойства
ARIA состояния и свойства предлагают пользователю дополнительную информацию о том, как взаимодействовать с конкретным виджетом. Это все о раскрытии отношений и состояний нашего приложения пользователям на клавиатурах и средствах чтения с экрана. К счастью, W3C предоставляет нам подробные рекомендации WAI-ARIA, которым нужно следовать.
Пока у нас есть список вкладок и несколько панелей. Однако связь между ними существует только потому, что JavaScript Bootstrap связывает их вместе. Другими словами, нет никаких врожденных отношений. ARIA приходит на помощь со свойствами aria-labelledby и aria-labelledby .
Свойство aria-controls используется для связи элемента управления с регионом, которым он управляет. Свойство aria-labelledby используется для указания элемента, который работает как метка для элемента.
Вот улучшенная разметка для вкладки:
<li class="active"> <a id="tab1" href="#home" role="tab" aria-controls="home" data-toggle="tab">Home</a> </li>
А вот новая разметка для отдельной панели:
<div class="tab-pane fade in active" id="home" role="tabpanel" aria-labelledby="tab1"> <p>Welcome!</p> </div>
Обратите внимание, как эти элементы связаны, используя значение соответствующих атрибутов id .
Что еще мы должны описать явно? Можно сказать, что в любой момент времени выбрана только одна вкладка и видна только соответствующая панель. К счастью, aria-selected aria-hidden здесь, чтобы спасти день! Они логические и могут быть установлены в true или false . Они могут быть изменены с помощью JavaScript на соответствующих вкладках, и для разметки можно установить в разметке для начала.
3. Живые регионы для динамического контента
Обнаружение динамически обновляемого контента без перезагрузки страницы является одним из самых больших препятствий для программ чтения с экрана, особенно во времена Ajax, Node и одностраничных приложений. Как с этим следует обращаться? Должна ли быть повторена вся страница? Или АТ ничего не должен делать, рискуя тем, что пользователь пропустит важные обновления?
Даже такая простая вещь, как наш маленький список вкладок, может быть сложной. Представьте, что мы используем функцию таймера, чтобы пройти через наш интерфейс с вкладками (аналогично слайдеру изображений). Это приведет к отображению различного содержимого в зависимости от выбранной в данный момент вкладки.
Чтобы восполнить этот пробел, ARIA разработала концепцию живых регионов, которая позволяет AT получать уведомления всякий раз, когда происходят изменения в этой конкретной части документа.
Давайте реализуем живую область в div которая содержит видимую в данный момент панель вкладок:
<div id="myTabContent" class="tab-content" aria-live="polite"> ... </div>
Если для свойства aria-live задано polite значение, программа чтения с экрана будет ожидать объявления об изменении только в том случае, если пользователь не занят выполнением другой задачи на странице. Значение assertive будет немедленно уведомлять пользователя.
4. Улучшенная клавиатурная навигация
В старые времена HTML4 единственными элементами, которые могли фокусироваться на клавиатуре с помощью клавиши TAB, были ссылки и элементы формы. Это имело некоторые серьезные последствия для людей, которые были вынуждены управлять веб-страницей без мыши. Как они должны перемещаться, чтобы span или div элементы, которые могут представлять собой вкладки или выпадающие меню?
В результате ARIA включил каждый элемент HTML, чтобы получить фокус клавиатуры, расширив атрибут tabindex . Сегодня это часть спецификации HTML5.
Добавление некоторого JavaScript завершает наш пример и делает виджет панели вкладок Bootstrap доступным с клавиатуры. Посмотрите демонстрацию CodePen и попробуйте управлять виджетом только с помощью клавиши TAB и клавиш со стрелками.
Примечание. Вы можете использовать отрицательное число в качестве значения tabindex . Элементы с отрицательным tabindex не могут быть достигнуты с помощью клавиши TAB, но только с помощью JavaScript. Это удобно, когда вы хотите раскрыть функциональность по мере прохождения пользователем вашего приложения.
Обязательно ознакомьтесь с разделом « Навигация по клавиатуре» в сети разработчиков Mozilla, чтобы узнать больше рекомендаций.
Ария и HTML5
HTML5 (также называемый живым стандартом HTML) добавил несколько полезных семантических тегов и атрибутов к языку, например, элемент progress и nav и required атрибут. В настоящее время не всегда рекомендуется добавлять код ARIA, когда HTML охватывает вас.
Следующие примеры считаются плохой практикой:
<div role="navigation"></div> <!-- don't repurpose, use <nav> instead --> <h2 role="button"></h2> <!-- don't change semantics, use <button> -->
Если подходящий HTML-элемент или атрибут уже реализован, но поддержка доступности еще не доступна, конечно, разрешается и рекомендуется использовать ARIA.
Есть еще много ситуаций, когда ARIA оказывается полезной. Не упустите возможность прочитать мысли вдохновителя доступности по этой теме Стива Фолкнера — более 4 лет, все еще в силе!
Могу ли я использовать ARIA без риска?
Абсолютно! ARIA была разработана, чтобы быть узнаваемой только благодаря вспомогательным технологиям и никак не влияет на DOM или ваш стиль. Это, однако, не означает, что вы не можете использовать роли и свойства ARIA с помощью CSS для стилизации своего приложения соответствующим образом:
.button[aria-hidden="true"] { display: none; }
Что касается поддержки браузера , вы можете начать использовать ARIA прямо сейчас.
Вывод
ARIA была разработана для поддержки, но при этом проста в реализации. Он никак не ограничит ваш рабочий процесс, предоставляя вам набор ролей, атрибутов и семантики для создания многофункциональных, но доступных веб-сайтов.
Если вам нужно немного убедительнее, попробуйте эту симуляцию чтения с экрана и почувствуйте, как она зависит от вашей вспомогательной технологии и, следовательно, от правильно реализованных веб-приложений. Мы, как ответственные разработчики, должны вступить и проложить путь!