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, может быть свернут или расширен, если имеет вложенный подуровень.
Здравствуйте!
Для списка категорий раздела какой можно применить?
Продвинутая семантика и доступность
Семантика и доступность — это естественные части HTML по замыслу, однако они не используется в полной мере, если не применяются правильно. Знание, как писать семантический и доступный код правильно начинается с понимания того, как семантика и доступность работают и как пользователи и машины их интерпретируют. Писать семантический и доступный код невероятно сложно и это может занять много времени. Однако в долгосрочной перспективе преимущества побеждают.
Одна из наиболее важных частей, о которой следует помнить при написании семантического и доступного кода — это сделать всё возможное, чтобы использовать стандартный язык разметки. Приложите усилия, чтобы по возможности писать чистый код и гордитесь своей работой. Вообще говоря, не используйте бессмысленный элемент там, где другой элемент может придать более семантический смысл, к примеру, использование
подходит лучше. Используйте семантические элементы и атрибуты, а также микроданные и WAI-ARIA, чтобы расширить значение вашего кода.
Кроме того, будьте адвокатом семантики и доступности. Расскажите, почему вы написали определённый код и дайте обоснование, почему некоторые модули содержимого размечены таким образом. Обозначьте цели и задачи в вашем коде и объясните, как эти цели и задачи выполняются. Практика написания семантического и доступного кода растёт, однако внедрение в целом ещё не завершено. Будьте адвокатом для кода, который вы пишете.
Мотивация для семантики
Иногда можно спросить, реально ли семантика изменит ситуацию. Вы можете услышать, что она замедляет разработку, плохо поддерживается или даже что она своевольна. Хотя это иногда и так, вам по-прежнему необходимо сохранить целостность и продолжить писать по возможности лучший код, потому что семантика вкладывает больший смысл в написании кода.
Важным фактом является то, что семантика в значительной степени полезна всем. Для начинающих семантика наделяет содержимое однозначным смыслом. Семантика придаёт содержимому устойчивую структуру и значение, а также в угоду доступности предоставляет более качественный пользовательский интерфейс и дополнительную информацию для вспомогательных технологий. Поиск и глобализация в большей степени связаны с семантикой, что позволяет проще обслуживать контент на международном уровне и делает его более дружественным поисковой системе. Если это недостаточно, семантика также способствует совместимости операционных систем, что позволяет обмениваться и пользоваться информацией на различных платформах и устройствах.
Можно с уверенностью сказать, что семантика важна и она здесь надолго. Если кратко подытожить, семантика обеспечивает:
Структурная семантика
Скрытие содержимого
Представьте себе, что слепой пользователь пытается заполнить форму, и первая часть содержимого, ещё до заполнения формы — это сообщение об успешном выполнении. Это плохой пользовательский опыт и он может быть легко исправлен с помощью надлежащей семантики.
Текстовая семантика
Большая часть содержимого в Интернете живет в тексте и мы в первую очередь пролистываем Интернет в поисках этого содержимого. Использование правильной семантической разметки для текста помогает пользователям проще находить то, что им нужно.
Жирный текст
Есть несколько способов, как сделать текст жирным, в том числе несколько элементов и стилевое свойство font-weight. Два основных элементов, используемых в данном случае, включают в себя и . Хотя эти два элемента имеют одинаковое представление, у них совершенно разные семантические значения.
Элемент описывает текст, который имеет важное значение. С другой стороны, элемент определяет текст, который должен быть стилистически выделен без важности. Вообще говоря, элемент следует использовать исключительно в качестве щипцов для завивки, чтобы изменить представление элемента, тогда как элемент должен быть использован для идентификации существенно важного текста.
Демонстрация жирного текста
Курсивный текст
Курсивный текст работает в той же области, что и жирный текст, где мы можем использовать несколько элементов или стилевое свойство font-style для достижения желаемого представления. Для курсивного текста наиболее часто используются два элемента — и . Опять же, у них одинаковое представление, но совершенно разные семантические значения.
Элемент акцентирует сильное выделение на тексте, а элемент определяет текст, который будет выражен альтернативным голосом или тоном. Использование элемента действительно ведёт к выделению текста с добавлением важности. С другой стороны, элемент в основном используется в диалоге или прозе, выделяя текст без какого-либо добавления акцента или важности.
Демонстрация курсивного текста
Использование для иконок
В последнее время наблюдается небольшое движение фронтенд-разработчиков к использованию элемента для включения иконок на странице, в частности, как это видно в Bootstrap. Элемент используется в качестве хука, а затем его класс определяет, какую иконку фонового изображения применить к элементу. В зависимости от того, насколько близко вы хотите следовать за семантикой, это может быть приемлемой практикой или нет.
Подчёркивание текста
В продолжении шаблона, в котором у нескольких элементов одинаковое представление, подчёркнутый текст ничем от них не отличается. Есть разные элементы, которые мы можем использовать, а также стилевое свойство text-decoration. В нашем случае два основных элемента, применяемых для подчёркивание текста — это
RoleAttribute
Contents
A Role Attribute for HTML5
Introduction
Use cases for a role attribute for HTML5, include:
Proposal for a «role» attribute for HTML5
Role Attribute Original Limited Proposal
Recently, the «curly brackets» hack of identifying a graphical image by its use or type by inserting a generic identifier / descriptor in curly braces as the @alt value for an IMG, has been added to the HTML5 working draft.
Not only is the «curly bracket» technique insufficient, it constitutes both an abuse of the alt attribute and does not satisfy the WCAG requirement that alt text contains a textual equivalent of the image.
Therefore, i would like PF to FORMALLY propose to the HTML WG that:
Additional Considerations
Comments on the Original role for HTML5 Proposal
Rob Burns (HTML WG member)
Thanks for initiating this issue. It’s high priority in my view.
I think role is exactly the appropriate place for this data. As more and more photographs are taken with digital cameras it is very easy to tag them as role=’photo’ from the internal metadata of the image format. The only exceptions that would require manual role metadata assignment would be scanned photographs or photographs that are photographs taken with a digital camera but taken of a physical print format of another role. For example, someone might take a photograph of a diagram, a bar chart, or geographic map. To me these are the types of role an image might serve as (whether from a photograph or generated wholly from software). So some suggestions:
A reference list of role keywords
XHTML role attribute module
Mac OS X AXRoles (accessibility api)
less relevant to HTML:
TV Raman (Google, etc.)
Only change I’d recommend in what you describe for @role:
Role Attribute Genericized Proposal
Synchronization With the XHTML Role Vocabulary
XHTML Metainformation Vocabulary
The XHTML Metainformation Module defined as part of XHTML+RDFa specifies the following vocabulary items for use in the rel and rev attributes.
Items from the XHTML Role Module
The following values are defined for use in the role attribute as specified in the XHTML Role Attribute Module:
ARIA 1.0 Pre-Defined Roles
Possible non-text media relevant role keywords
Each role keyword might correspond to different specific advice for alt text for a resource, allowing authors a simplified two-step process to providing text equivalents For example, some role keywords might require no alt text or text equivalent whatsoever. While on the other hand, something like role=’portrait’ might specify a list of the names of the individuals in the portrait from left to right (for ltr text): e.g., alt=’Mona Lisa»).
Relation to alt text replacement
The following table shows the relation of the alt text to the role keyword. Authors must include at least one of the following keywords on the element for each embedded resource. In some cases a null value for the alt text can be automatically inferred by UAs from the author designated role and conformance checkers can alert authors when the role and alt attributes are inconsistently specified. Conformance checkers can also provide focussed guidance to authors based on the role attribute keywords. The role attribute must always be specified, while the alt attribute might sometimes be null (note the various required, recommended and optional categories for alt text are only suggested as one possible approach the role attribute makes possible; these could all be required for strictness).
Семантика в 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 какой сможем.