Если после всего этого вы все еще сомневаетесь, какой элемент применить, проштудируйте классную блок-схему по элементам разметки блоков в HTML5 [33]. Разработчики – Оли Студхолм и Петр Петрус. Распечатайте ее, приколите на стену, и вы всегда будете знать, какой элемент использовать.

Как обычно, вы захотите провести валидацию кода HTML, чтобы он был без ошибок.

Я предпочитаю это делать через Validator.nu [34].

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

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

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

Я ни в коем случае не позиционирую себя как эксперта по стандартам доступности. Но очень постараюсь внятно и серьезно объяснить вам, почему важность стандарта WAI-ARIA не ограничивается только вопросами доступности. Если вы когда-нибудь пользовались блочными элементами, которые описаны в этом разделе, то, скорее всего, встречались с чем-то вроде этого:

Тракторы: Интерактивное руководство

Обслуживание тракторов

Заметили? У документа два тега header, и оба использованы правильно. Вся проблема в CSS:

hheader {

margin: 0 2em;

}

Этот селектор элемента описывает оба тега header. Мы могли бы использовать селектор наследования (т. е. body> header), но это кажется немного тяжеловесным, не говоря уже о том, что верхний заголовок может стать «шапкой» целого сайта. Здесь мы можем выгодно использовать роль WAI-ARIA, просто добавив role=”banner”в HTML:

Тракторы: Интерактивное руководство

Обслуживание тракторов

Этот ролевой атрибут говорит о том, что элемент

header [role=”banner”] {

margin: 0 2em;

}

Из-за того, что теги headerи footerмогут использоваться во многих местах, пожалуй, мы бы остались без тега для основного контента. И снова спасибо ролям ARIA, которые предоставляют богатый выбор.

Добавляя роль “main”к article(таким образом, получаем

Вы, вероятно, уже отметили изящество этого подхода. Описание контента становится более детальным, и мы можем применять стили к нашим новым тегам, не особо напрягаясь. Третья из ролей ARIA – это contentinfo, которая часто применяется для конфиденциальных заявлений, уведомления об авторских правах и общей информации о текущей странице сайта. (Некоторые называют это «метаинформацией»).

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

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

А теперь поговорим об абсолютно новой теме: хранилище на стороне клиента в HTML5. На сегодняшний день мы имеем невеликий выбор средств для хранения данных у пользователя. Наиболее распространенным способом стала скромная куки-сессия. Но этому методу сопутствует множество маленьких проблем. И самые выматывающие из них – это следующие:

• Данные, которые вы сохраняете в сессии, перемещаются туда и обратно между клиентом и сервером при каждом запросе.

• Данные, которые вы сохраняете, имеют лимит в 4 kB.

• Все куки ограничены во времени.

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

С localStorageи sessionStorage, у нас есть два JavaScript API для сохранения строк для браузера. SessionStorageочищается, когда заканчивается сеанс пользователя (т. е. когда «вкладка» или «браузер» закрываются), а в это время localStorageхранится, пока разработчик (через JavaScript) или пользователь (через свои браузерные настройки) не решают удалить его.

Интерфейсы API виртуально идентичны – единственная разница будет в сроках хранения. Откройте свою панель инструментов разработчика в современном браузере (имеется в виду выпуска последних трех лет).

Введите localStorage.setItem (“name”, “Ben”). В Webkit-браузерах вы увидите мое имя, сохраненное под вкладкой «Ресурсы» (для этого вам нужно будет раскрыть “Local Storage”). Вы только что сохранили свой первый элемент данных в localStorage.

А теперь давайте извлечем то, что вы сохранили, используя localStorage.getItem(“name”). Вы увидите “Ben”, четко напечатанное в консоли.

И, наконец, чтобы очистить все после себя, воспользуйтесь либо localStorage.deleteItem(“name”), чтобы удалить мое имя, либо localStorage.clear(), чтобы убрать все из localStorage. Когда пользователи вызовут localStorage.clear(), они лишь очистят его для текущего домена.

Итак, если пользователь сохраняет какие-либо данные на сайте, расположенном на example.com, а потом переключают вкладки на google.com, они увидят, что у них нет доступа к данным, сохраненным ими на вкладке example.com.