Доступность в реальном мире: HTML5, ARIA и современный веб

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

Что я имею в виду под реальным миром? Это очень просто: доступность не существует и не должна существовать в вакууме. Реальный мир грязный. Это не черный и белый, а все оттенки серого между ними. Это относится как к доступности, так и к нашему ремеслу в целом. Мы должны идти на компромиссы. Мы должны сделать выбор. Мы должны изменить тактику в середине потока. И мы должны закончить это вчера.

И именно поэтому мы ориентируемся на доступность реального мира. Вам нужно знать, что работает сейчас, чтобы вы могли принимать обоснованные решения при внедрении современных веб-технологий. В течение последних двух лет мы фокусировались на реальной доступности для HTML5, CSS3 и ARIA — семинаре, который мы проводим в Австралии в этом месяце.

В рамках подготовки к @feather Tour Down Under 2011 (я @feather в твиттере) мы создали страницу, на которой были выделены содержание и детали того, что вы получите. Это не первый сайт / страница HTML5, который мы создали, но мы хотели сделать что-то, что создало уникальный дизайн, было бы доступно и дало нам возможность опробовать несколько современных методов веб-дизайна и разработки.

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

Семантика HTML5

Я фанат новой семантики, которую HTML5 приносит нам, по большей части. Это открывает новые двери для нас — авторы по всему миру рады использовать семантически обоснованные элементы, которые были введены в HTML5.

И все знают, что основой доступности является семантика, верно? Правильно.

Так что же происходит, когда вы комбинируете достаточно семантически богатый язык, такой как HTML5, с браузерами и вспомогательными технологиями, которые были написаны еще до того, как была рассмотрена семантика HTML5?

Ничего . И это проблема.

Преимущества, которые семантика HTML5 приносит нам, на самом деле не являются благом для доступности, которой они должны быть — пока . (Чтобы узнать, какие элементы HTML5 полностью открыты браузерами и проходят через API специальных возможностей различных операционных систем, обязательно посетите HTML5accessibility.com .)

Доступность продолжает развиваться в HTML5. В W3C есть команда, посвященная доступности HTML5 . И хотя доступность для HTML5 продолжает развиваться, я сделаю все возможное, чтобы убедиться, что то, что мы делаем для доступности, касается не только того, что будет работать в будущем, но и того, что работает в «здесь и сейчас ». Почему? Потому что у нас теперь есть «поддержка» HTML5 в браузерах. А это значит, что люди собираются использовать это сейчас . Что означает, что это должно быть доступно сейчас .

Вот реальная ситуация с доступностью HTML5 на момент написания статьи:

1. Мы можем использовать новые элементы (статью, раздел, отступы, верхний колонтитул, нижний колонтитул, навигация и т. Д.) На наших веб-сайтах и ​​в приложениях прямо сейчас.
2. Мы можем обмануть браузеры, которые изначально не понимают этих элементов, используя HTML5. Да, он использует JavaScript, и нет, это не причина не использовать его. Да, вам нужно рассмотреть сценарий «Отключение JavaScript», но об этом мы поговорим позже.
3. Мы должны знать, что семантика HTML5 НЕ выражена или не интерпретируется прямо сейчас существующими вспомогательными технологиями. Это нормально — поддержка придет, но это займет некоторое время.
4. Пока мы ожидаем поддержки новых технологий, таких как HTML5, нам нужно найти решения, которые работают сейчас.

Правила доступности веб-контента

Я рад, что мы перешли с WCAG 1.0, но мне не хватает одного из его признаков: Руководства по временным решениям . Это сказало нам:

«Используйте временные решения.

Используйте временные решения для обеспечения доступности, чтобы вспомогательные технологии и старые браузеры работали правильно ».

Давайте проясним: мне не нравятся конкретные временные решения, которые пропагандировались в WCAG 1.0. Все эти контрольные точки были о том, «пока пользовательские агенты» не разрешают X или не имеют функциональности для выполнения Y, используйте эти методы. Пользовательские агенты теперь делают эти вещи, поэтому нам не нужно беспокоиться о них с WCAG 2.0. Они настолько неважны, что я даже не буду упоминать их здесь.

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

И это в случае с HTML5 прямо сейчас.

Итак, какие «временные решения» мы можем использовать с HTML5, чтобы помочь вспомогательным технологиям понять семантику?

Использование WAI-ARIA

ARIA ( Accessible Rich Internet Applications ) — это технология, которая используется, чтобы помочь программно определить, какой веб-компонент пользовательского интерфейса (или «виджет») более четко, так что вспомогательные технологии могут придать больше значения своим пользователям.

Его часто называют «мостовой технологией», поскольку он помогает нам преодолеть разрыв между прошлым, настоящим и будущим. Короче говоря, если у нас есть существующее унаследованное веб-приложение, которое использует более старые методы разметки и кодирования, мы можем помочь сделать это более доступным, применяя атрибуты ARIA к разметке без переписывания всего приложения на более современных языках.

Вот как помогает ARIA.

Рассмотрим эту реализацию Google Maps: http://examples.furtherahead.com/aria/slider/index-3.html

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

У нас нет собственного элемента слайдера в HTML (по крайней мере, в настоящее время нет), поэтому мы создали слайдер с использованием HTML, CSS и JavaScript таким образом, чтобы он приближал внешний вид и функциональность элемента управления слайдера. Проблема в том, что когда мы делаем это, мы действительно создаем сложный компонент пользовательского интерфейса, который состоит из семантически бессмысленных элементов div, интервалов, изображений, ссылок и кнопок.

1. Для любого сложного компонента пользовательского интерфейса нам нужно знать три основных элемента информации:
2. Что это за вещь? (его роль)
3. Какие общие характеристики у него есть? (его свойства)
4. Что вы можете рассказать мне об этом прямо сейчас? (его состояние)

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

<a href="#"

      id="handle_zoomSlider">

<span>11</span>

</a>

 <a href="#"

      id="handle_zoomSlider"

      role="slider"

      aria-orientation="vertical"

      aria-valuemin="0"

      aria-valuemax="17"

      aria-valuetext="14"

      aria-valuenow="14" >

<span>11</span>

</a>

 <figure>

<img

      src="../blocklinksvoiceover-500-2.png"

      alt="Screenshot of block links with Voiceover on the Mac.">

<figcaption id="figcaption1">

<strong>Screenshot</strong>: We use block links on the promo page...
In other screen readers, parts of the link aren’t read at all.

</figcaption>

</figure>

 <figure>

<img

      src="../blocklinksvoiceover-500-2.png"

      alt="Screenshot of block links with Voiceover on the Mac."

      aria-describedby="figcaption1">

<figcaption id="figcaption1">

      <strong>Screenshot</strong>: We use block links on the promo page...
      In other screen readers, parts of the link aren’t read at all.

</figcaption>

</figure>