Фрэйн . - HTML5 и CSS3. Разработка сайтов для любых браузеров и устройств. 2-е изд.

Стандарт WAI-ARIA предназначен главным образом для решения проблем доступности динамического контента на веб-странице. Он предоставляет для специализированных виджетов (динамических разделов в веб-приложениях) средства описания ролей, состояний и свойств, чтобы они стали узнаваемыми и годными к использованию теми пользователями, которые применяют вспомогательные технологии.

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

Не используйте роли для семантических элементов.Ранее рекомендовалось добавлять значимые роли к заголовкам и подвалам:

Но теперь это считается излишним. Если заглянуть в спецификацию для любого из ранее перечисленных элементов, там есть специально выделенный раздел разрешенных значений 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-семантике, является излишней и не рекомендуется, поскольку эти свойства уже установлены браузером».

Если вы не в состоянии запомнить более одной рекомендации

Самое простое, что можно сделать с прицелом на применение вспомогательных технологий, — это пользоваться везде, где это возможно, правильными элементами. Элемент

Развитие стандарта 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 простым и легким. Вот пример ссылки на видеофайл на вашей странице из разряда «проще некуда»:

В HTML5 со всей трудной работой справляется один-единственный тег (или для аудио). Между открывающим и закрывающим тегами можно вставить текст, информирующий пользователей при возникновении проблем. Существуют также дополнительные атрибуты, которые обычно хочется добавить, например, высота и ширина. Добавим их: