Role html что это
HTML\CSS → Атрибут role и его значения
Атрибут role в HTML5 позволяет наиболее четко указать семантическое предназначение блока/элемента страницы при взаимодействии пользователя с сайтом.
Возможные значения атрибута role=»
banner — содержит главный заголовок или внутренний заголовок страницы. Например логотип и название сайта. Рекомендуется использовать не больше одного раза на странице.
article — Раздел состоящий из композиции, которая в свою очередь образует самостоятельную часть документа, страницы или сайта.
complementary — информационный блок, отделенный от основного содержания ресурса.
contentinfo — обобщающая информация о содержании страницы (к примеру, footer). Рекомендуется использовать не больше одного раза на странице.
definition — указывает определение термина или понятия.
main — выступает в качестве основного содержания документа. Рекомендуется использовать не больше одного раза на странице.
navigation — набор элементов предназначенных для навигации по документу или связанным документам. Рекомендуется использовать не больше одного раза на странице.
note — заметка ( вспомогательная информация) к основному содержанию ресурса.
search — указывает область для поиска по содержимому.
alert — Сообщение с важной и, как правило срочной, информация. Также см. alertdialog и status.
alertdialog — Сообщение, которое содержит важную информацию, и первоначальный акцент переходит элементу в диалоговом окне. Также см. alert и dialog.
application — Область объявленная как веб-приложение, в отличие от веб-документа.
button — Кнопка, позволяющая пользователю вызвать какие-либо действия. Также см. link.
checkbox — Чекбокс, который имеет три возможных значения: истина, ложь, или смешанное.
columnheader — Ячейка таблицы, содержащая заголовок для столбца.
combobox — Вариация селекта; аналогично textbox, позволяющая пользователям печатать для выбора опции, или при печате добавить новую опцию к списку. Также см. listbox.
dialog — Сообщение, предназначенное для прерывания обработки текующего приложения, для ввода пользователем какой-либо информации или требующее от него какое-либо действие. Также см. alertdialog.
directory — Список ссылок на части группы, например содержание.
document — Область, содержащая информацию, которая объявлена как содержимое документа, в отличие от веб-приложений.
form — Ориентир области, которая содержит коллекцию элементов и объектов, которые, в целом, объединяются, чтобы создать форму. См. также search.
grid — Сетка интерактивного управления, которая содержит элементы сведенные в таблицу данных, в виде строк и столбцов, как таблица.
gridcell — Ячейки в сетке или древовидная сетка.
group — Набор объектов пользовательского интерфейса, которые не предназначены для включения в итоговую страницу или содержимое, вспомогательных технологий.
heading — Заголовок для раздела страницы.
img — Контейнер для набора элементов, которые формируют изображение.
link — Интерактивная ссылка на внутренний или внешний ресурс, который при активации заставляет браузер пользователя перейти к этому ресурсу. См. также button.
list — Группа неинтерактивных элементов списка. Также см. listbox.
listbox — Виджет, который позволяет пользователю выбрать один или несколько элементов из списка вариантов. См. также combobox и list.
listitem — Один элемент в списоке или содержании.
log — Тип интерактивной области, где новая информация добавляется в осмысленном порядке, а старая может исчезнуть. См. также marquee.
marquee — Тип интерактивной области, где не существенная информация часто меняется. См. также log.
math — Контент, который представляет собой математическое выражение.
menu — Тип виджета, который предоставляет выбор списка вариантов для пользователя.
menubar — Представление menu, которое обычно остается видимым и, как правило, представлено горизонтально.
menuitem — Опции в группе выбора содержащиеся в menu или menubar.
menuitemcheckbox — Чекбокс пункта menu, который имеет три возможных значения: истина, ложь, или смешанное.
menuitemradio — Отмечаемый пункт меню в группе menuitemradio, из которых только один может быть выбран одновременно.
option — Выбираемый элемент в списке выбора.
presentation — Элемент чья семантически неявная роль не будет отображаться на доступности API.
progressbar — Элемент, который отображает ход статуса задач, занимающих много времени.
radio — Отмечаемый пункт в группе таких же пунктов, из которых только один может быть выбран одновременно.
radiogroup — Группа переключателей.
region — Большая область веб-страницы или документа, которую автор счел достаточно важной, чтобы включить в основную информацию страницы или оглавление, например, область страницы содержающая спортивную статистику событий онлайн.
row — Ряд ячеек в grid.
rowgroup — Группы, содержащие один или несколько элементов row в grid.
rowheader — Ячейка содержащая заголовок для row в grid.
scrollbar — Графический объект, который управляет прокруткой содержимого области просмотра, независимо от того, полностью ли содержание отображается в области просмотра.
separator — Разделитель, который разделяет и отличает разделы содержимого или группы пунктов menuitems.
slider — Интерфейс ввода для пользователя, когда пользователь выбирает значение из заданного диапазона.
spinbutton — Форма диапазона, где пользователь может выбрать из числа дискретных решений.
status — Контейнер, содержание которого носит рекомендательный характер для информирования пользователя, но не является достаточно важным. Также см. alert.
tab — Вкладка, представляющая из себя механизм для выбора вкладки необходимой пользователю.
tablist — Список элементов tab, которые являются ссылками на tabpanel элементы.
tabpanel — Контейнер для ресурсов связанных с tab, где каждый tab содержиться в tablist.
textbox — Поле ввода, которое предоставляет ввод в свободной форме текста.
timer — Тип интерактивной области, содержащую числовой счетчик, который указывает на количество затраченного времени от начальной точки, или время, оставшееся до конечной точки.
toolbar — Набор часто используемых функциональных кнопок, представленых в компактной визуальной форме.
tooltip — Контекстное всплывающее окно, которое отображает описание элемента.
tree — Тип списка, который может содержать подуровни вложенных групп, которые могут быть свернуты и расширены.
treegrid — Сетка, чьи строки могут быть свернуты и расширины так же как и в tree.
treeitem — Опция элемента tree. Этот элемент внутри tree, может быть свернут или расширен, если имеет вложенный подуровень.
Здравствуйте!
Для списка категорий раздела какой можно применить?
Семантика в HTML5
Иллюстрации: Кевин Корнелл
Перевод: Влад Мержевич
Я хочу сделать смелый прогноз. После того как вы и я исчезнем, HTML по-прежнему будет вокруг. Не только в миллиардах архивных страницах нашей эры, но, как живой, дышащий организм. Слишком много сил, энергии и инвестиций пошли в разработку инструментов Интернета, протоколов и платформ для того, чтобы от этого так легко отказаться.
Давайте остановимся на нашей ответственности. К сожалению, в истории мы связаны с развитием важного инструмента нашей цивилизации, который будет использоваться для коммуникации на десятилетия вперед. Таким образом, когда мы направляем наш разум, праздно или всерьез, на улучшение HTML, мы должны понимать уже сегодня последствия далеко идущих решений.
HTML5, над которым W3C недавно удвоил свои усилия по формированию следующего поколения HTML, развил значительный импульс. Это огромный проект, охватывающий не только структуру HTML, но и модель парсинга, обработку ошибок, DOM, алгоритмы извлечения ресурсов, медиа-контент, двумерную графику, шаблоны данных, безопасность, страницы загрузки, хранение данных на стороне клиента и многое другое.
Есть также изменения в структуре, синтаксисе и семантике HTML, которые частично описал Лаклан Хант в статье Предварительный обзор HTML 5.
Но в этой статье давайте обратимся исключительно к семантике HTML. Она интересует меня уже много лет и считаю, что семантика принципиально важна для будущего HTML.
Би-би-си недавно объявила, что отказывается от микроформата hCalendar используемого в их списках передач в пользу удобного и доступного шаблона сокращений. Это свидетельствует о том, что мы, вне всякого сомнения, вышли за пределы семантических возможностей HTML, которые были предназначены для этого языка. У нас просто закончились элементы и атрибуты HTML, которые обогащают семантическую разметку документов. Если мы продолжим хитрить с существующими конструкциями HTML, возникнет много проблем, потому что HTML как семантический язык разметки страдает от фундаментального дефекта — его семантика фиксирована и не расширяема.
Это не просто теоретическая проблема. Сотни тысяч разработчиков используют атрибуты class и id для создания расширенной семантической разметки. При этом практически неизменно разработчики используют специальные словари, которые они сами же составляют, а не значения, взятые из существующих схем. В лучшем случае это псевдосемантика.
Расширяемая семантика
Существует реальная проблема, которая должна быть решена. Нам нужны механизмы в HTML, которые чётко и однозначно позволят разработчикам добавлять в разметку более существенную семантику, а не псевдосемантику. Это, пожалуй, одна из важных целей проекта HTML5.
Но придумать такой механизм не так просто, потому что в любом решении имеются ограничения. Есть существенные ограничения, возможно, самым большим из них является обратная совместимость. Решение не должно ломать сотни миллионов используемых сегодня устройств, и которые будут использоваться ещё долгие годы. Любое решение без обратной совместимости не будет широко принято разработчиками из страха потерять читателей. Такие решения быстро вянут на корню.
Решение также должно быть совместимо и с будущими версиями. Не в том смысле, что оно должно работать в будущих браузерах — это ответственность разработчиков браузеров, но оно должно быть расширяемым. Мы не можем ожидать какого-либо единого решения, которое разрабатывается прямо сейчас, чтобы решить все мыслимые и немыслимые будущие семантические потребности. Мы можем разработать решение, которое удовлетворит расширяющиеся потребности по мере их возникновения.
Этот тандем двух ограничений является настоящей огромной проблемой. Но в контексте языка, основные итерации которого повторяются десятилетиями и важность которого в качестве глобальной платформы для коммуникации имеет первостепенное значение, эта задача должна быть решена.
Хотя эти элементы могут быть полезными и, похоже, вызвали некоторый интерес, решают ли они действительно проблему, в частности обратной совместимости и совместимостью с будущими версиями?
Давайте рассмотрим каждое ограничение.
Обратная совместимость
Похоже, отличное начало. Но когда мы пытаемся установить, к примеру, такой стиль для элемента :
. большинство упомянутых браузеров изменило стиль элемента, но IE8 (а также IE6–7) нет.
Итак, мы имеем серьёзную проблему обратной совместимости с 75% используемых в настоящее время браузеров. Учитывая период полураспада Internet Explorer, мы можем предсказать, что большинство пользователей будут использовать IE6 и IE7 даже спустя несколько лет.
Давайте обратимся ко второму ограничению — совместимость с будущими версиями.
Совместимость с будущими версиями
Начнём с постановки вопроса: «Зачем изобретать новые элементы?». Разумным ответ на него будет: «Потому что в HTML не хватает семантического богатства, а добавив эти элементы, мы увеличиваем семантическое богатство HTML — что не плохо, не так ли?».
При добавлении этих элементов мы стремимся, чтобы в HTML было больше семантических возможностей, но только в узкой области. Независимо от того, сколько элементов введено, мы всегда будем думать о добавлении в HTML больше семантики. Добавив столько новых элементов, сколько нам хочется, мы по-прежнему не решим проблему. Нам не нужно добавлять определенные термины в словарь HTML, нам необходимо добавить механизм, который позволит обогащать документ семантикой по мере необходимости. С технической точки зрения мы должны сделать HTML расширяемым. В HTML5 никакого механизма для расширения нет. Именно поэтому HTML5 угробит значительный процент современных браузеров и в реальности не добавляет семантику вообще.
Почему бы не принять существующий словарь, тот же Docbook? Его словарь структуры документа гораздо богаче и он разрабатывался рядом экспертов в течение многих лет. Однако это не является аргументом в пользу Docbook, дело в том, что задача обеспечения механизма семантического богатства в HTML идёт своим путём, уделяя мало внимания передовой практике в отношении работ тридцатилетней давности (исходная работа началась в начале 70-х годов).
Некоторые соображения по поводу решения
Критикуя нынешние усилия, есть ли у меня какие-то практические советы о том, как решить эту проблему? Ну, начну с одного.
Если добавление элементов в HTML находится за рамками темы, по крайней мере, в этой дискуссии, атрибуты это другая логическая область HTML, на которой мы сосредоточимся. В конце концов, в течение почти десятилетия мы использовали атрибуты class и id в качестве механизмов расширения семантики HTML. Множество разработчиков знакомы с этим подходом, и он их устраивает. Проект микроформатов показал, что существующих атрибутов HTML недостаточно для универсального механизма по расширению семантики HTML. Таким образом, если мы хотим использовать атрибуты чтобы помочь решить эту проблему, мы должны включить один или несколько новых атрибутов. Прежде чем перейти к механизму о том, как это работает, проверим это решение на те же требования, что и для новых элементов HTML5. Самое главное, поддерживают ли новые атрибуты HTML обратную совместимость? И если да, обеспечит ли это реальный механизм для семантического расширения HTML?
Давайте внедрим новый атрибут. Я назову его «structure», но конкретное имя не имеет значения. Мы можем использовать его так:
Посмотрим, как наши браузеры справятся с ним. И конечно все браузеры должны изменить его стиль через CSS.
Но как это сделать?
В действительности, почти все браузеры, включая IE7, стилизуют
Расширяемость с помощью атрибутов
Вместо новых элементов, HTML5 должен принять ряд новых атрибутов. Каждый из этих атрибутов будет входить в категорию или тип семантики. Например, как я подробно изложил в другой статье, HTML включает структурную семантику, риторическую семантику, ролевую семантику (взята из XHTML) и другие классы или категории семантики. Эти новые атрибуты могут быть использованы так же, как атрибут class : для подключения к элементу семантики, которая описывает характер элемента, а также для добавления метаданных об элементе.
Это не отличается от атрибута role в XHTML, но вместо того, чтобы один атрибут «отдувался» за все семантические элементы, мы должны определить различные типы семантики элемента и разделить их. Например, атрибут role в XHTML работает следующим образом:
Значения атрибута role это разделенный пробелами список слов из словаря по умолчанию или из определенного словаря.
Почему бы просто не взять атрибут role как есть? Ну, есть другие виды семантики, для которых словарь ролей неприменим. Например:
Здесь показан теоретический тип семантики — «rhetoric», который может быть использован для разметки риторического характера документа. Этот элемент, очевидно, не играет роли иронии в документе. Скорее, содержит элемент иронии.
Вот еще один пример. Очевидно, что в HTML не хватает способа прикрепить версии для машинного чтения к версии для чтения человеком, например, дате. Это лежит в основе проблемы Би-би-си с микроформатом hCalendar, о которой мы говорили ранее. Хотя Первого мая следующего года действительно не несёт смысла, нечто вроде строки Первого мая следующего года появится.
Опять же, будем ли мы использовать определенный термин «equivalent» или какой-либо другой термин для этого семантического атрибута не важно. Главное отметить, что это не так просто, как использование одного атрибута class или role на все случаи. Для правильного расширяемого решения, которое обеспечивает обратную совместимость и достаточную гибкость, решения в этом направлении заслуживают изучения. Я назвал этот раздел «Некоторые соображения по поводу решения», поскольку нужно сделать значительный объем работы, чтобы действительно добиться приемлемого решения. Открытые вопросы включают следующее.
Вместо того чтобы спешить ответить на эти вопросы, я выделю проблемы, которые необходимо решить и начну диалог. Последствия и влияние решений сделанных в HTML5 слишком велики для решений, которые будут сделаны без хорошей осведомлённости о лингвистике, семантике, семиотики и смежных областях. Надеюсь понятно, что просто «создание новых элементов» не является решением для роста семантической мощи HTML. Давайте несколько не будем спешить с этими решениями, в конце концов, изменением климата мы озаботили наших внуков достаточными проблемами. Пусть, по крайней мере, мы оставим им наилучший HTML какой сможем.
Подстраховка web-доступности семантических областей HTML5 через роли WAI-ARIA
Как известно, HTML5 имеет расширенные возможности семантической вёрстки. Он позволяет обернуть отдельные логические блоки страницы в специально предназначенные для них блочные теги, какие как header, main, footer и другие. Ну а улучшение структурной и семантической вёрстки, как правило, автоматически способствует повышению уровня accessibility web-интерфейса для пользователей программ экранного доступа, потому что они добавляют элементы страницы, по которым возможно осуществлять навигацию и быстро перемещаться между блоками контента.
В принципе, дополнительная разметка для обеспечения accessibility реализуется через отдельную технологию WAI-ARIA, однако и стандартные семантические структуры HTML5 современными браузерами и современными программами экранного доступа воспринимаются как соответствующие атрибуты ARIA для вспомогательных технологий. Проще говоря, это означает, что в теории следующие два варианта вёрстки с точки зрения программ чтения экрана аналогичны::
Листинг 1:
Поскольку в рамках всей статьи нас интересует только то, что происходит в контейнере body, то далее договоримся, что в последующих листингах будет приводиться только вёрстка из body, а всё остальное будет подразумеваться как в листинге 1.)
Итак, листинг 1 свёрстан с использованием стандартных семантических возможностей HTML5, а листинг 2 использует старую добрую блочную вёрстку через div, но с добавлением разметки WAI-ARIA. По задумке разработчиков стандартов доступности, браузеров и вспомогательных технологий предполагается, что эти две страницы должны обрабатываться программами экранного доступа одинаково, однако тут мы и сталкиваемся с прозой жизни.
Возьмём две наиболее популярные программы экранного доступа: JAWS (версии 15.0) и NVDA (версии 2014.3), а также два наиболее популярных у их пользователей браузера: Internet Explorer (версии 11) и Firefox (версии 32). После этого протестируем все возможные конфигурации на предмет обработки семантических областей из листинга 1. В итоге, получим следующие результаты:
| Теги | JAWS Internet Explorer | JAWS Firefox | NVDA Internet Explorer | NVDA Firefox |
|---|---|---|---|---|
| aside | Да | Да | Нет | Да |
| footer | Нет | Да | Нет | Да |
| header | Нет | Да | Нет | Да |
| main | Да | Да | Нет | Да |
| nav | Да | Да | Нет | Да |
Оказывается, что всё работает далеко не так, как предполагается теоретически. Причём с понижением версий ПО поддержка некоторых структур может начать неравномерно отваливаться. А главное в официальных руководствах и технических стандартах об этом вряд ли удастся прочитать, и такие проблемы сможет выявить лишь опытный и дотошный QA-инженер accessibility, который есть далеко не в каждом даже очень крупном проекте, пускай там доступность и прописана в ТЗ, например, в случае разработки социально ориентированных или государственных сайтов, а также в проектах, для которых доступность подразумевается как конкурентное преимущество, например, Интернет-банкинги. Про проекты не фокусированные на accessibility и говорить не приходится.
Разумеется, поскольку финальный вариант WAI-ARIA принят совсем недавно, а руководство по его поддержки со стороны User Agent вообще до сих пор не существует в завершённом виде, то в будущем, когда всё утрясётся, можно надеется, что и такие вещи также унифицируются. Однако проекты разрабатываются и сдаются уже здесь и сейчас, да и graceful degradation тоже никто ещё не отменял. Поэтому имеет смысл верстать так, чтобы с одной стороны использовать семантические новинки HTML5, а с другой — не обижать вспомогательные технологии при любых раскладах.
Достигнуть этого можно путём одновременного использования и семантики HTML5, и разметки WAI-ARIA. То есть к этим тегам надо будет добавлять соответствующие роли WAI-ARIA, как бы подстраховывая семантические области HTML5 через Accessible Rich Internet Applications.
Здесь следует сразу предупредить, что атрибуты разметки WAI-ARIA имеют более высокий приоритет, чем стандартные семантические структуры HTML5, поэтому если, например, для тега main прописать атрибут role со значением contentinfo, то программы экранного доступа будут называть его так, как будто это footer. Так что отсутствие WAI-ARIA лучше, чем наличие её некорректного применения. Иными словами: «Не умеешь, не берись», но эта статья как раз и призвана научить этому не сложному приёму вёрстки.
По большому счёту, всё сводится к необходимости выучить правильное соответствие ролей WAI-ARIA и стандартных семантических структур HTML5. В принципе, из листингов 1 и 2 основные соответствия уже ясны:
| Тег HTML5 | Роль WAI-ARIA |
|---|---|
| footer | contentinfo |
| header | banner |
| main | main |
| nav | navigation |
Кстати, что касается роли banner, специально оговоримся, что она предназначена для оборачивания именно всей шапки страницы, а не рекламного баннера. То есть она, действительно, прямой аналог тега header. Как показывает практика, некоторых слово «banner» вводит в заблуждение, и они начинают это значение присваивать именно рекламным баннерам, но это неправильно.
Вышеприведённые соответствия позволят корректно разметить в WAI-ARIA базовые семантические области HTML5. Однако заметно, что там упомянуты далеко не все из них. Дело в том, что во-первых, некоторые семантические структуры HTML5 не имеют прямых аналогов WAI-ARIA, например, это касается тега article, а во-вторых, с некоторыми из них всё не так просто, главным образом, речь, конечно, об aside.
По умолчанию тег aside программами экранного доступа трактуется как аналог роли complementary. В принципе, в большинстве случаев так и должно быть, однако диапазон возможного применения aside достаточно велик, поэтому могут встречаться ситуации, когда роль complementary будет не очень уместна.
Откровенно говоря, здесь мы уже вступаем на достаточно тонкий лёд вкусовщины и субъективного понимания дизайна невизуальных интерфейсов, где дискуссии примерно соответствуют спором о шрифтах или цветовых гаммах в мире визуальных интерфейсов. Тем не менее, всё же приведём один пример, чтобы дать представление об этом аспекте.
Роль complementary описывает для программ экранного доступа блок интерфейса как участок с некой дополнительной информацией, не имеющей прямого отношение к основному содержимому. Однако в нашем примере мы выделяем два таких блока: на уровне всей страницы, в который оборачиваем навигационную панель, а также внутри основного содержимого, куда оборачиваем теги. Очевидно, что по своей сути это сильно различающиеся блоки с дополнительной информацией, поэтому второму мы назначили роль note, которая маркерует блок как участок с неким примечанием.
Использование таких приёмов вёрстки требует уже несколько большего понимания логики невизуальных интерфейсов, поэтому рубить с плеча тут не стоит. Можно только посоветовать всё-таки использовать роль complementary, а более сложные интерфейсные ходы применять только если вы в достаточной степени уверены, что это уместно. Если бы в листинге 3 вместо note была использована complementary, то это было бы лучше, чем наоборот.
К слову, у роли note нет прямого аналога среди семантических тегов HTML5, поэтому полной совместимости нет как в одну, так и в другую сторону. Такие роли и программами экранного доступа обрабатываются несколько иначе, поэтому с ними вообще лучше не связываться, если в проекте нет серьёзных специалистов по accessibility, понимающих все подводные камни.
Кроме того, проблему использования нескольких одинаковых семантических областей HTML5 можно решать и другим способом, а именно добавлением к ним поясняющих меток. Например, если в интерфейсе несколько навигационных панелей, то имеет смысл указать их назначение, чтобы пользователь программы экранного доступа сразу понимал разницу.
То есть атрибут aria-label позволяет задать дополнительную текстовую метку, которая будет пояснять назначение данного блока. Причём важно понимать, что aria-label именно дополняет role, поэтому не надо в её тексте дублировать информацию о семантическом назначении блока, например, совсем не нужно для nav писать, что это «Область навигации по разделам», достаточно просто написать «Разделы». Ну а для тега main вообще нет необходимости прописывать aria-label, так как он в принципе должен быть на странице лишь в единственном экземпляре и его назначение итак понятно. А вот для aside, footer, header или nav поясняющую метку следует добавлять по обстоятельствам. Как правило, это имеет смысл, если на странице несколько таких элементов одного типа, что с теми же footer или header бывает не так часто.
Соблюдение несложных приёмов вёрстки, описанных в этой статье, позволит вам создавать не просто доступные, но одинаково доступные под всеми основными конфигурациями интерфейсы. И главное, всё это абсолютно никак не поломает визуальную вёрстку, потому что атрибуты role и aria-label оказывают влияние лишь на то, как страница представляется программами экранного доступа через речевой или тактильный вывод информации.
Напоследок две ссылки, по которым можно более подробно ознакомиться с семантическими возможностями HTML5 и WAI-ARIA: