select has the role of combobox, but if we give it the multiple attribute or a size attribute greater than one, the role changes to listbox
<!-- select with the combobox role -->
<!-- select with the listbox role -->
<select multiple size="2"></select>
em have the roles of strong and emphasis. Strong is for important, serious or urgent, while emphasis is for just that. Both are misused to a level where their code semantics are no longer useful to screen readers and they are practically just a way to achieve bold and italic like the
b elements. There can be other software that differentiates between them, so they are still relevant. Markdown and WYSIWYG editors are commonly not in that group and output only
em by default, further contributing to the misuse. And we can’t really blame WYSIWYG editors, seeing as they are more WYSIWYGIYCS – what you see is what you get if you can see. The biggest contributor to misuse is probably the microscopic typographic difference. Leaving bold and strong for another article, we typically set things like titles in italic, while emphasis is used potentially to affect the meaning of an entire sentence.
<!-- The author implies that something other than the movie is a better Elvis resource. -->
<i>Elvis</i> is the best <em>movie</em> about Elvis.
<!-- The author implies that other Elvis movies have other leading qualities, such as length or truth. -->
<i>Elvis</i> is the <em>best</em> movie about Elvis.
pre are some of the elements with generic role, just like
span. We should still use them as intended and not interchangeably, as they mostly have different default styling and layout behaviours.
menu has the role of list. It does not have the role of menu or toolbar. It’s identical to
ul; there is no inherent reason to use
menu except if we want to separate the two in code. If we want to indicate navigation, chances are we already have a
nav element with an aria-label. Additionally, the
menu element can only have list items inside while
nav element can hold complete lists and other elements like headings. The possible mixup with WAI-ARIA’s menu role is reason enough not to use the
menu element. The menu role is less about navigation and more about choices and actions like we find in toolbars.
Many specific input types, such as color, date, file and password have no implicit ARIA role. Inputs should have labels and attributes indicating the type and don’t need an additional role to convey meaning.
label has no role and cannot be given an aria-label attribute since it is already a label for another element and cannot be anything else.
Setting aria-label or aria-labelledby is not allowed on several elements such as
a without the href attribute,
code. Elements that cannot have aria-label or aria-labelledby can be given those if they change role, granted that they can change role. Even though the language might not allow something, it doesn’t mean browsers ignore it. Still, using labels on the mentioned elements could be a sign that another more specific element should be used instead or that something like a heading is missing.
<!-- not allowed -->
<!-- allowed -->
<div role="article" aria-label="news"></div>
<a href="crows.png" aria-label="crows">Crow picture</a>
While a button might be the desired destination of a page, clicking it doesn’t complete anyone’s task as long as the rest of the form is blank. People’s tasks lie at the single input asking for an email address, the form with a well of input types or a table heavy with data; that’s what we must communicate, the path and the information enabling people to walk it, not only the destination.
The implied web is not about avoiding being explicit; it’s about leaning on the platform to tell browsers how it should work for people. Conventions and external consistency enable them to move across different services and domains more easily, and how we make our services should regard that.
Knowing about roles means knowing a central communication capability of the web. We can use it to help people read and comprehend the interface. We can use it to avoid rehashed elements, and we can use it to work with code, visuals and function simultaneously. It’s the direction in which the web moves, again.
The HTML spec
ARIA in HTML W3C recommendation
Screen Readers support for text level HTML semantics by Steve Faulkner
Halvor has been programming the web since the turn of the millennium. With university degrees in communication and design, he cares deeply about how interfaces communicate with people. In addition to being an avid writer, he works actively to create a unified field of expertise for the web. He is also the head of a department of developers and designers in Posten Bring.
hwsanden on Mastodon: Mastodon