Стандарт предоставления возможности полноценного использования Интернета людьми с физическими ограничениями (WAI-ARIA)
Стандарт WAI-ARIA предназначен главным образом для решения проблем доступности динамического контента на веб-странице. Он предоставляет для специализированных виджетов (динамических разделов в веб-приложениях) средства описания ролей, состояний и свойств, чтобы они стали узнаваемыми и годными к использованию теми пользователями, которые применяют вспомогательные технологии.
Например, если выведенный на экран виджет показывает постоянно обновляемые биржевые котировки, то как незрячий пользователь получит доступ к странице, чтобы узнать об этом? Стандарт WAI-ARIA пытается решать проблемы подобного рода.
Не используйте роли для семантических элементов. Ранее рекомендовалось добавлять значимые роли к заголовкам и подвалам:
<header role="banner">A header with ARIA landmark banner role</header>
Но теперь это считается излишним. Если заглянуть в спецификацию для любого из ранее перечисленных элементов, там есть специально выделенный раздел разрешенных значений ARIA-атрибута role — Allowed ARIA role attributes. В качестве примера можно привести разъяснения из раздела элемента:
«Разрешенные значения ARIA-атрибута role: region role (по умолчанию не устанавливается), alert, alertdialog, application, contentinfo, dialog, document, log, main, marquee, presentation, search или status».
Основной частью здесь является «role (по умолчанию не устанавливается)». Это означает, что явное добавление этой ARIA-роли к элементу не имеет никакого смысла, поскольку она подразумевается самим элементом. Теперь это поясняется примечанием к спецификации:
«В большинстве случаев установка ARIA-атрибута role и/или атрибута aria-*, соответствующего исходной подразумеваемой ARIA-семантике, является излишней и не рекомендуется, поскольку эти свойства уже установлены браузером».
Если вы не в состоянии запомнить более одной рекомендации
Самое простое, что можно сделать с прицелом на применение вспомогательных технологий, — это пользоваться везде, где это возможно, правильными элементами. Элемент <header> окажется намного полезнее, чем div class="Header". Точно так же, если у вас на странице есть кнопка, воспользуйтесь элементом <button>, а не элементом <span> или другим элементом, стилизованным под кнопку. Готов признать, что элемент <button> не всегда позволяет применять конкретное стилевое оформление (его, к примеру, нельзя настроить с помощью инструкций display: table-cell или display: flex), но тогда выберите следующий более подходящий элемент, в качестве которого обычно выступает тег <a>.
Развитие стандарта ARIA
ARIA не ограничивается одной лишь ориентацией в отношении ролей. Развивать стандарт помогают полный перечень ролей и краткое описание их пригодности к использованию, доступные по адресу http://www.w3.org/TR/wai-aria/roles.
Чтобы проще было разобраться в теме, я также рекомендую прочитать книгу Хейдона Пикеринга (Heydon Pickering) Apps For All: Coding Accessible Web Applications (доступна на сайте https://shop.smashingmagazine.com/products/apps-for-all-coding-accessible-web-applications).
совет
Можно бесплатно протестировать свою конструкцию с помощью невизуального доступа к Рабочему столу (non-visual desktop access (NVDA)).
Если разработка ведется под платформу Windows и возникает желание протестировать конструкции, доработанные согласно стандарту ARIA с помощью экранного диктора, можно совершенно свободно воспользоваться средством NVDA. Оно доступно по адресу http://www.nvda-project.org/.
Google теперь также поставляет бесплатное инструментальное средство для разработки доступных сайтов под названием Accessibility Developer Tools, предназначенное для браузера Chrome (доступны также кросс-платформенные версии), которое также стоит проверить в деле.
Существует также постоянно пополняемый арсенал средств, помогающих быстро протестировать ваши собственные конструкции на использование их людьми с нарушенным цветовосприятием. Например, по адресу https://michelf.ca/projects/sim-daltonism/ находится Mac-приложение, позволяющее переключать типы нарушения цветовосприятия и просматривать предварительные результаты на плавающей палитре.
И наконец, OS X также включает утилиту VoiceOver, позволяющую тестировать ваши веб-страницы.
Надеюсь, краткое введение в WAI-ARIA и WCAG обеспечило вам достаточный объем информации, чтобы появилось больше идей о том, как можно подойти к поддержке вспомогательных технологий. Возможно, добавление поддержки таких технологий к вашим следующим проектам на HTML5 окажется проще, чем вы думали.
И в заключение укажу на еще один ресурс, касающийся всех вопросов доступности, содержащий массу полезных ссылок и советов, находящихся на домашней странице проекта A11Y по адресу http://a11yproject.com/.
Медиавозможности, встроенные в HTML5
Многие услышали об HTML5, когда Apple отказалась добавлять поддержку для Flash на свои iOS-устройства. Технология Flash получила на рынке доминирующее положение (некоторые утверждают, что она захватила рынок) в качестве дополнительного модуля для обслуживания видео в браузере. Но вместо использования технологии, являющейся собственностью компании Adobe, Apple в вопросах вывода на экран сложного медиасодержимого решила положиться на HTML5. Наряду с тем что в HTML5 был достигнут неплохой прогресс в данной области, публичная поддержка HTML5 со стороны Apple дала этой версии языка могучий толчок и помогла ее медиаинструментам стать привлекательными для широких кругов потребителей.
Несложно предположить, что Internet Explorer 8 и более ранние версии этого браузера не поддерживают аудио и видео HTML5. Большинство других современных браузеров (Firefox 3.5+, Chrome 4+, Safari 4, Opera 10.5+, Internet Explorer 9+, iOS 3.2+, Opera Mobile 11+, Android 2.3+) справляются с этой задачей вполне успешно.
Добавление видео и аудио средствами HTML5
Работать с видео и аудио в HTML5 довольно просто. Единственной реальной трудностью, связанной с HTML5-медиа, было перечисление альтернативных медиаформатов, поскольку различные браузеры поддерживают разные форматы файлов. Сегодня повсеместной поддержкой как на обычных, так и на мобильных платформах пользуется формат MP4, что делает включение медиаинформации в ваши веб-страницы посредством HTML5 простым и легким. Вот пример ссылки на видеофайл на вашей странице из разряда «проще некуда»:
<video src="myVideo.mp4"></video>
В HTML5 со всей трудной работой справляется один-единственный тег <video></video> (или <audio></audio> для аудио). Между открывающим и закрывающим тегами можно вставить текст, информирующий пользователей при возникновении проблем. Существуют также дополнительные атрибуты, которые обычно хочется добавить, например, высота и ширина. Добавим их:
<video src="myVideo.mp4" width="640" height="480">What, do you mean
you don't understand HTML5?</video>
Теперь, если добавить предыдущий фрагмент кода на страницу и посмотреть на его работу в Safari, видео появится, но без элементов управления его проигрыванием. Для получения исходных элементов управления проигрыванием нужно добавить атрибут controls. Мы также можем добавить атрибут autoplay (что не рекомендуется делать, поскольку всем известно, с каким раздражением воспринимаются видео с автовоспроизведением). Все это демонстрируется в следующем фрагменте кода:
<video src="myVideo.mp4" width="640" height="480" controls autoplay>
What, do you mean you don't understand HTML5?</video>
Результат выполнения этого фрагмента показан на следующей копии экрана.
В число прочих атрибутов входят preload для управления предварительной загрузкой медиа (те, кто пользовался ранними версиями HTML5, заметят, что preload пришел на смену autobuffer), loop для повторения видео и poster для определения кадра заставки для видео. Он пригодится при ожидаемой задержке воспроизведения видео (или когда какое-то время будет затрачиваться на буферизацию). Для применения атрибута достаточно вставить его в тег. Вот как выглядит пример, включающий все эти атрибуты:
<video src="myVideo.mp4" width="640" height="480" controls autoplay
preload="auto" loop poster="myVideoPoster.png">What, do you mean you
don't understand HTML5?</video>
Резервная возможность для старых браузеров. Тег <source> позволяет при необходимости предоставлять резервные возможности. Например, наряду с предоставлением версии видео в формате MP4 при желании обеспечить удобную замену для Internet Explorer 8 и более ранних версий можно добавить резервное видео в формате Flash. Кроме того, если у пользователя в браузере нет подходящей технологии проигрывания, можно предоставить ссылки на скачивание самих файлов. Рассмотрим следующий пример:
<video width="640" height="480" controls preload="auto" loop
poster="myVideoPoster.png">
<source src="video/myVideo.mp4" type="video/mp4">
<object width="640" height="480" type="application/x-shockwave-
flash" data="myFlashVideo.SWF">
<param name="movie" value="myFlashVideo.swf" />
<param name="flashvars" value="controlbar=over&image=myVideo
Poster.jpg&file=myVideo.mp4" />
<img src="myVideoPoster.png" width="640" height="480"