The Implied Web

by Halvor William Sanden published on

People don’t need call-to-action buttons. Interface elements made to get attention and herd people towards clicks increase cognitive effort because they obscure themselves and reduce interfaces to clickable surfaces.

The implied web is based on the idea that people read interfaces through the glasses of their needs combined with previous web platform experiences. Driven by tasks, they are open to clues about solutions and need clear communication to comprehend and actively move through the interface. In short, people must recognise elements so they can act accordingly.

To better understand how to work with the implied web, we will look at signifier mishmash, intent through HTML and the dynamics of roles.

The impossible element

Interface elements tasked with explicitly communicating clickability make things more complicated because clicking is neither a defining nor a driving factor in the interface; it’s just the mundane way things work.

We make such click-focused elements by taking visual affordance indicators from elements we perceive as communicating clickability, usually the link and the button, and we mash them together. Affordance indicators are aspects of an element that communicate what kind of element they are. They can also indicate state and even hint at actions available to the user in the capacity of what they are. When we make a combined clickable style, maybe as part of a design system, we tend to reapply it to any relevant element. At the same time, we end up removing those elements’ native affordances.

The problem is that there are no affordance indicators or signifiers unique to the click, and HTML has no click element. In other words, it’s impossible to communicate clickability as a standalone concept, and with good reason, telling people to click is a sign of inferior communication.

Action isn’t functionality

What signifies clickability for a link is not the same as for a button or a select. Signifiers belong primarily to elements; they are clues to the functionality of the element, not the action the user can take. The link’s functionality, for instance, is to point to somewhere, not to be clicked. If we apply its underline and pointer cursor to other elements, we communicate that those are also links or share some functionality instead of being the “click here” we wanted to convey.

Elements that don’t share default affordances, conventions and functions end up being too similar. It becomes difficult, if not impossible, to tell them apart.

Countering attention

When we approach elements as communicators of action, we also start adding weight to them based on how much attention we think they should get. Elements we want people to click, or think they would like to click, are made to draw attention to themselves. This comes at the cost of the surrounding elements. It can disrupt the order and make it harder to follow the flow of the interface.

As a countermeasure, we attempt to create a scale of clickability and a system of attention instead of an information hierarchy. We invent our own flavour of interface disconnected from HTML, web platform conventions and actual content or data. We end up with elements that don’t come across as anything in particular; we have effectively diverged communication into visuals and code.

No click here

We cannot work with the action and attention approaches in code. We must work with the meaning and state of elements and roles.

Even though there are ways to steal focus with code, there isn’t a “click me!” HTML element, and no attribute can create an attention hierarchy. What people can do is cycle through element types in various means of interaction, like keyboard navigation or screen readers. Still, attention can only be in one place at a time.

Also, action isn’t one thing. A click is not a click because an element is not an element; they have different functionality. For instance, a link can be alt-clicked, a label click activates its input, and a text input activates itself and enables the actual input functionality.

Meaning through HTML

Programming web interfaces is communication work. It’s not the code’s job to give life to a visual; it’s the visual’s job to reflect the meaning already there.

While HTML doesn’t have a visual side, we can safely talk about an element’s base visual properties as defined by conventions that make them reasonably similar across browsers’ default CSS. They may have different styles, but most of the same affordance indicators are present, such as borders, underlines, hover changes and colours. We shouldn’t disregard an element’s conventions or break them without consideration because there is a direct link between the intentional use of the HTML element and its visuals.

Much of HTML’s meaning comes through roles, and disregarding them means working without the meaning that the web platform provides. In other words, we should work from the HTML elements, their conventions and default styles to bring the affordance indicators into the process. Then, we can consciously override them when necessary.

When the reason behind an HTML element lies in the users’ needs, and not a sketch, we go from writing valid code to writing correct code.

Roles

Central to picking the correct HTML element is its role; that’s where a lot of meaning comes from.

Many HTML elements have implicit roles, and we don’t have to do anything but use the elements. Some roles can also change depending on non-ARIA attributes and ancestor element types. The mapping is done through HTML Accessibility API Mappings (HTML-AAM). A role can be relevant for any means of consumption or interaction, even though the wide range of assistive tech perhaps comes to mind first.

Elements that have no implicit role are generic. That doesn’t mean we can use the elements anywhere; all HTML has designated usage areas. But some don’t need a role, and others cannot have one because the usage wouldn’t work well with things like assistive tech. For instance, div, span and i all have the generic role but different use cases and default visual properties. It would also be fairly annoying to have every div and span announced.

We cannot set the generic role, but we can set the role to presentation or none. In contrast to generic, the two are not exposed in accessibility APIs or accessibility trees.

We can also use the role attribute to communicate meaning HTML doesn’t have by default, though the role would no longer be implicit. Reasons to do this can be because the element is versatile, and it would be impractical to have a default role, or because we need to give an element a role different from its default. We should not explicitly set the same role already implied by the element.

Examples of implicit and indirect roles

The following examples are a few selected elements that demonstrate roles and how some can be affected by surrounding or related code.

  1. header has the role of banner, and footer has the role of contentinfo. When we place them inside article, aside, main, nav or section, or elements that have set the role to article, complementary, main, navigation or region, their role becomes generic.
<!-- header and footer with banner and contentinfo roles -->
<body>
  <header></header>
  <main></main>
  <footer></footer>
</body>

<!-- header and footer with the generic role -->
<article>
  <header></header>
  <footer></footer>
</article>
  1. section has a generic role. When we give it an accessible name, typically using the aria-label attribute, it gets the role of region. Beware that over-use of named sections can cause clutter, but there can be other reasons to write code with these elements than exposing their roles.
<!-- section with the generic role -->
<section></section>

<!-- section with the region role -->
<section aria-label="changelog"></section>
  1. img with an empty alt attribute has the role of presentation. img with text inside the alt attribute has the role of img. img without the alt attribute should be avoided, it has the role of img but it will not have an accessible name.
<!-- img with the presentation role -->
<img alt="" src="/" />

<!-- img with the img role -->
<img alt="horse with beard" src="/" />

<!-- img with the img role but without an accessible name – avoid! -->
<img src="/" />
  1. 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></select>

<!-- select with the listbox role -->
<select multiple></select>
<select size="3"></select>
<select multiple size="2"></select>
  1. strong and 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 i and 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 strong and 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.

  1. small, u, i, b, q, 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.

  2. 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.

  3. 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.

  4. 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.

  5. Setting aria-label or aria-labelledby is not allowed on several elements such as a without the href attribute, div, p, abbr, address, body, caption and 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 -->
<div aria-label="news"></div>
<a aria-label="crows">Crows</a>

<!-- allowed -->
<div role="article" aria-label="news"></div>
<a href="crows.png" aria-label="crows">Crow picture</a>

Implied platform

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.

Sources and resources

The HTML spec
ARIA in HTML W3C recommendation
Screen Readers support for text level HTML semantics by Steve Faulkner

About Halvor William Sanden

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.

Website: 8yd.no
hwsanden on Mastodon: Mastodon