Nick Hall · 4 Min Read
As a Web Developer, I make zero assumptions about how people are using the internet. There are numerous variables to consider: device, screen size, connection speed, operating system, input method, cognitive abilities, writing direction, etc. The number of considerations only compound as you examine user preferences. Making assumptions about how people will use the site could result in an unusable website.
For example: Jenny is blind and uses a desktop PC running Windows 10. She has a very fast connection speed but will never see a single image. She uses a keyboard as her input method but her browser will report as a touch device because her monitor has a touch screen. She uses JAWS as a screen reader as well as the browser's built-in "Navigation Quick Keys" to jump around the page by heading.
And that's just one user! Thinking about scenarios like this have helped Fastspot land on a pretty bulletproof navigation markup.
Next, we need to add labels. We give the
h2 an id attribute so both the
ul element can target the heading text with
aria-labeledby. Generally, we visually remove the title from the page with a CSS technique that uses a modified WebAIM approach. First, we use a
nav element to identify the group of links. Then, we use a heading to set a title for the navigation (we're using an
h2 since we reserved the
h1 for page titles). Finally, an unordered list is used to mark up the individual links*.
Seems pretty redundant doesn't it? If you read it top to bottom you see the phrase "Site Navigation" referenced three separate times all inside a navigation element. Navigation overload! However, we don't expect anyone will be bombarded. Let's walk through it.
For visual users, we've styled the elements to look like a piece of navigation UI. They can read the link titles and the cursor will change (along with styling) when they hover over the links. If they are tabbing through the page with a keyboard, the links will receive the browser focus ring and additional style changes.
For users utilizing a screen reader, it will depend on how they will arrive on our navigation. If they are jumping around the page by ARIA landmarks, they will stop on the
nav element and the screen reader will announce the associated label. If they are navigating by heading, they will stop on the visually hidden
h2. If they are navigating by list, they will stop on the
ul and the screen reader will announce the associated label.
Regardless of how users choose to navigate the page, we need to provide them with context. Without making any assumptions about the user, we have created accommodations for Jenny (or any other user!) to navigate and interact with the page information with ease.
* Marking navigations in unordered lists used to be the unquestioned standard. Since the adoption of the
nav element there has been some debate whether it's best practice to continue this tradition. We've read the critiques and Fastspot still feels it's best to use an unordered list as long as you provide context as we have here. What further solidifies the decision to use unordered lists are the default touch device behaviors. There is still a bit of magic (both on iOS and Android devices) where navigations with hidden drop-downs will treat the first tap as a hover and show the nested menu when it is marked up as a list.