Orienting web visitors using landmarks

· Accessibility, Design · Patrick Smith

When you visit a new city, one thing you expect to see are landmarks. Statues, botanical gardens, theaters, skyscrapers, markets. These landmarks help us navigate around unfamiliar areas by being reference points we can see on the horizon or on a map.

As makers of the web, we can also provide landmarks to people. These aren’t arbitrary — there are eight landmarks that are part of the HTML standard:

  • Navigation
  • Main
  • Banner
  • Search
  • Form
  • Contentinfo
  • Region
  • Complementary

Some of these seem obvious, but some are odd — what on earth does “contentinfo” mean? Let’s walk through what they are, why they are important to provide, and finally how we can really easily use them.

Navigation

This is pretty easy to guess, as nearly all websites have a primary navigation. It’s often presented as a row of links at the top of the page, or under a hamburger menu.

Stripe’s navigation bar at the top of its homepage

Stripe’s navigation provides links to the primary pages people want to visit. It’s clear, and follows common practices of showing only a handful of links, and placing the link to sign in up on the far right.

Most visual users would identify this as the primary navigation of the site, and so you should denote it as such in your HTML markup. Here’s what you might write for Stripe’s navigation:

<nav>
  <ul>
    <li><a href="/"> Stripe </a></li>
    <li><a href="/products"> Products </a></li>
    <li><a href="/developers"> Developers </a></li>
    <li><a href="/about"> Company </a></li>
    <li><a href="/pricing"> Pricing </a></li>
    <li><a href="/support"> Support </a></li>
    <li><a href="/login"> Sign in </a></li>
  </ul>
</nav>

Here we use HTML 5’s <nav> element, which automatically has the navigation landmark.

If there’s only one navigation landmark on a page, then people using screen readers can jump straight to it and the links inside. They can visit Stripe’s Support page in a few seconds. It’s like a city subway that connects key landmarks, allowing fast travel between them.

What if you have multiple navigations? Let’s look at GitHub for an example.

A repository on GitHub with two navigations, one for the whole site, and one specific to my repository.

Here we have a black bar offering links to the main parts of the GitHub experience: my pull requests, my issues, the marketplace, notifications, etc.

But I am on the page for a particular repository, and it also has its own navigation: Code, Issues, Pull requests, Actions, etc.

So how do we offer both? And how do users using screen readers know the difference? By attaching labels to each navigation: the top navigation has the label Global, and the repository specific navigation has the label Repository. It’s like a city having multiple sports stadiums: here in Melbourne we have the MCG (used for football and cricket) and the Rod Laver Arena (used for tennis and music). They clearly have different names to identify them by that means people can find them easily and won’t mix them up.

We can add the labels in our HTML like so:

<header>
  <a href="/">GitHub</a>
  <nav aria-label="Global">
    <ul>
      <li><a href="/pulls"> Pull requests </a></li>
      <li><a href="/issues"> Issues </a></li>
      <li><a href="/marketplace"> Marketplace </a></li>
      <li><a href="/explore"> Explore </a></li>
    </ul>
  </nav>
</header>

<main>
  <h1>RoyalIcing / dovetail</h1>
  <nav aria-label="Repository">
    <ul>
      <li><a href="/RoyalIcing/dovetail" aria-current="page"> Code </a></li>
      <li><a href="/RoyalIcing/dovetail/issues"> Issues </a></li>
      <li><a href="/RoyalIcing/dovetail/pulls"> Pull requests </a></li>
      <li><a href="/RoyalIcing/dovetail/actions"> Actions </a></li>
      <li><a href="/RoyalIcing/dovetail/projects"> Projects </a></li>
      <li><a href="/RoyalIcing/dovetail/wiki"> Wiki </a></li>
      <li><a href="/RoyalIcing/dovetail/network/alerts"> Security </a></li>
      <li><a href="/RoyalIcing/dovetail/pulse"> Insights </a></li>
      <li><a href="/RoyalIcing/dovetail/settings"> Settings </a></li>
    </ul>
  </nav>
</main>

Now people using screen readers or similar browser tools can see that there are two navigation to pick from, one named Global and one Repository.

Note also we have an aria-current="page" attribute on the link that represents the page the user is on. This is equivalent to a 🔴 You Are Here mark on a public map.

Main

When watching a show on Netflix, you’ll often be presented with a Skip intro button. This fasts forwards past the intro content that is often the same every time to the part you want to watch: the new episode.

Imagine if that Skip intro button didn’t exist: what would you do? You could watch the minute-long intro every time. Or you could attempt to fast-forward to the spot where the show actually starts. One is tedious and the other is error-prone. It would be a poor user experience.

On the web, our users might find themselves in the same situation. If they use a screen reader, they’ll probably hear all the items in our navigation and header. And then eventually they’ll reach the headline or the part that’s new — the part they are interested in — just like a TV episode. They could fast-forward, but that also would be error-prone. It would be great if we could allow them to skip past the repetitive stuff to the part they are actually interested in.

Enter <main>. Use this to wrap the part of the page where your ‘episode’ actually starts. People using screen readers can then skip past the tedious navigation and other preambles.

Let’s look at that GitHub example again:

<!-- Logo and navigation that’s on every page -->
<header>
  <a href="/">GitHub</a>
  <nav aria-label="Global">
    <ul>
      <li><a href="/pulls"> Pull requests </a></li>
      <li><a href="/issues"> Issues </a></li>
      <li><a href="/marketplace"> Marketplace </a></li>
      <li><a href="/explore"> Explore </a></li>
    </ul>
  </nav>
</header>

<!-- People can skip to here easily -->
<main>
  <h1>RoyalIcing / dovetail</h1>
  <nav aria-label="Repository">
    <ul>
      <li><a href="/RoyalIcing/dovetail" aria-current="page"> Code </a></li>
      <li><a href="/RoyalIcing/dovetail/issues"> Issues </a></li>
      <li><a href="/RoyalIcing/dovetail/pulls"> Pull requests </a></li>
      <li><a href="/RoyalIcing/dovetail/actions"> Actions </a></li>
      <li><a href="/RoyalIcing/dovetail/projects"> Projects </a></li>
      <li><a href="/RoyalIcing/dovetail/wiki"> Wiki </a></li>
      <li><a href="/RoyalIcing/dovetail/network/alerts"> Security </a></li>
      <li><a href="/RoyalIcing/dovetail/pulse"> Insights </a></li>
      <li><a href="/RoyalIcing/dovetail/settings"> Settings </a></li>
    </ul>
  </nav>
</main>

By using <main> we have allowed users to skip the intro.

Banner

We’ve already talked about the top strip on most websites, and these also have a role. Banners hold the primary navigation and also: logo, search field, notifications, profile, or other site-wide shortcuts. The banner often acts as the consistent branding across all pages.

The banner on GitHub when I’m signed in

Here’s GitHub’s banner when I’m signed in. The part I’ve highlighted with the yellow outline is the navigation (using <nav>). The entire element uses <header>, which automatically gains the role of banner if it meets the following (via MDN):

Assistive technologies can identify the main header element of a page as the banner if is a descendant of the body element, and not nested within an article, aside, main, nav or section subsection.

So the following <header> has the role of banner:

<body>
  <header> <!-- This gains the banner role -->
    …
  </header>

  <main>
    <h1>Heading</h1>
    …
  </main>
</body>

While this one doesn’t:

<body>
  <main>
    <header> <!-- This does not gain the banner role -->
      <h1>Heading</h1>
    </header>
    …
  </main>
</body>

And you can use multiple <header> elements for things other than banners, if you nest them inside “article, aside, main, nav or section” as MDN mentions.

Because of this, I might recommend that you add the banner role explicitly, as it will make it easier to identify and also target with CSS (e.g. header[role=banner] selector).

<body>
  <header role="banner"> <!-- Add the role explicitly -->
    …
  </header>

  <main>
    <header> <!-- Because this is nested inside <main>, it won’t gain the banner role -->
      <h1>Heading</h1>
    </header>
    …
  </main>
</body>

Banner’s don’t necessarily have to be a horizontal strip. Twitter has a vertical banner:

My Twitter profile, with a vertical banner & navigation on the left side

The banner here is the entire left hand column containing Home, Explore, etc. It’s also implemented with a <header role="banner">. The HTML 5 elements are named more for their concept that their visual intention.

More to come…

Jeremy Keith on Architects, gardeners, and design systems

· Design, Teams, Workflow · Patrick Smith

Jeremy Keith:

It’s rare to find job titles like software gardener, or information librarian (even though they would be just as valid as other terms we’ve made up like software engineer or information architect). Outside of the context of open source projects, we don’t talk much about maintenance. We’re much more likely to talk about making.

Anyone who’s spent any time working on design systems can tell you there’s no shortage of enthusiasm for architecture and making—“let’s build a library of components!”

There’s less enthusiasm for gardening, care, communication and maintenance. But that’s where the really important work happens.

Mazda removes touchscreens from its cars

· Design, Product · Patrick Smith

“Doing our research, when a driver would reach towards a touch-screen interface in any vehicle, they would unintentionally apply torque to the steering wheel, and the vehicle would drift out of its lane position,” said Matthew Valbuena, Mazda North America’s lead engineer for HMI and infotainment.

“And of course with a touchscreen you have to be looking at the screen while you’re touching…so for that reason we were comfortable removing the touch-screen functionality,” he added.

The head-up display that top trims of the Mazda 3 get is now projected onto the windshield. The amount of time it takes the eyes to focus on the head-up display is greatly reduced because it’s now focused on a point 7.5 feet ahead of the driver.

I think this shows that just because a technology seems better (touchscreens are in all our phones!) or is newer (everything analogue should become more digital over time!) does not mean it will be a better user experience.

Read the article here