The magic of semantic HTML: the nav
is in, and the div
is out!
A semantic navbar makes the web a friendlier place.
This is the second part in a series of posts that document an accessibility project I have recently started.
The project is created by Ad Hoc. For an overview of the requirements and access to the starter files, visit the Accessibility Engineer Assignment on Ad Hoc’s official website.
These were the guidelines I was expected to adhere to:
✅ Goal: Achieve 100 in a Google Lighthouse accessibility scan.
✅ Scope: Modern browsers only, with no need for legacy support, UI or JS libraries, frameworks, or mixin libraries.
✅ Specifications: The form doesn’t need to submit; no animations or task runners are required.
To help you follow along this post series, please visit my completed version of the Accessibility Engineer project and the GitHub repo.
HTML Choices: Laying the Foundation
In this post, the spotlight is on the nav
element.
Part 2: Constructing an Accessible Navbar
The navbar for the page has a very simple structure: a skip-to-content link, the Ad Hoc logo, and links to the About and Contact pages.
<nav>
<a class="skip-to-content" href="#main">Skip to content</a>
<a href="…" aria-label="Visit …">Ad Hoc</a>
<ul>
<li><a href="…" aria-label="Visit …">About</a></li>
<li><a href="…" aria-label="Visit …">Contact</a></li>
</ul>
</nav>
Let's find out why we call the nav
a semantic HTML tag!
An Accessible Navbar: The nav
Element
I wrapped the navigation links in a nav
element because it is a semantic HTML tag. Semantic means that it can convey information to screen readers. Since screen readers are designed to recognize these HTML elements by their tag names and provide appropriate context to the user based on them, it is crucial to always use semantic HTML5 elements like main
, nav
, and aside
, to name just a few.
✅ A11y Importance: When a screen reader encounters the nav
tag, it announces to the user that this section of the page is for navigation. By using nav
I provide context to assistive technologies and offer a more organized and accessible structure.
Non-semantic elements like div
and span
don't convey any information about their content, and that's why always opt for semantic alternatives when available!
An Accessible Navbar: The List Structure
It is ALWAYS a good idea to use ul
and li
elements to organize the links inside the navbar!
<ul>
<li><a href="…" aria-label="Visit …">About</a></li>
<li><a href="…" aria-label="Visit …">Contact</a></li>
</ul>
✅ A11y Importance: By using ul
and li
elements I emphasized that these links are part of a list of equally important items, making it easier for screen reader users to understand the layout and navigate through the items.
For example, given the code above, the NVDA screen reader will announce: "List with two items," and then proceeds to read the info about the first link.
An Accessible Navbar: Aria-label Attributes
Aria-label attributes are used to provide clear labels to assistive technologies, allowing screen reader users to understand the purpose of the link.
<li><a href="…" aria-label="Visit …">About</a></li>
✅ A11y Importance: Without these attributes, screen readers will default to using the text within the link to convey information, and this text may not always provide a clear or accurate description of the link’s purpose or destination.
What if adding an aria-label
to a link is not a choice? For example, on this blogging platform I cannot add the label to the links I embed in my posts. The solution? Name the links in a very explicit way. Do not use "click here to find out more" and be specific about what site or resource that link will open.
Two examples from the Resources section of this post: Microsoft Accessibility Resources and Jon Kuperman's Website Accessibility course on Frontend Masters. When focusing on either link, the user will know to what site they will be redirected if they click on it.
An Accessible Navbar: Skip to Main Content Link
Although the guidelines for this project do not mandate a "skip-to-content" link, it is a common feature added to many websites.
<a class="skip-to-content" href="#main">Skip to content</a>
✅ A11y Importance: It allows keyboard and screen reader users to skip the navigation and start interacting with the main content immediately. Imagine visiting a website with multiple pages and having to traverse the navigation links on every page! If you are a mouse user, you can simply ignore it. A screen reader user needs the skip link for the same reason.
The skip link is the first link that a user will tab to. It is initially hidden from view with CSS, but becomes visible when in focus.
Here is the CSS code that I employed:
// positioned outside the normal flow of the navbar
.skip-to-content {
position: absolute;
left: 10rem;
z-index: 9999;
. . .
transform: translateY(-200%);
transition: transform 250ms ease-in;
}
// visible when the user presses the tab key
.skip-to-content:focus {
transform: translateY(0%);
}
Please note that there are also other methods for the implementation of a skip link. The main idea is to hide the link from view until the user presses the tab key for the first time on a page.
Coming Up
Stay tuned for upcoming posts that will delve further into the header and main components. Later I will move on to CSS and JavaScript and their role in making the page accessible.
Resources
Microsoft Accessibility Resources
Microsoft has a strong commitment to accessibility and has been actively working on making its products and services more accessible. Their site is a treasure trove of resources and training materials to get you started.
Google's Learn Accessibility Website
This is a great place to go from zero to hero in accessibility! Go through each topic to find code samples and links to articles and additional resources. The tone is uncomplicated yet technical, and very conducive to learning.
Jon Kuperman's Website Accessibility course on Frontend Masters
This course is not available for free. However, those with a Frontend Masters account, or those willing to sign up, even for a month, will find it incredibly valuable. Jon delves deep into code specifics while also offering a bird's eye view of accessibility requirements.
W3C Before and After Demonstration of an Inaccessible Website
This demonstration contrasts an inaccessible website with a retrofitted, accessible version of the same site. Each page features activated inline annotations, identifying and highlighting significant accessibility barriers or the corresponding repairs made.
Post originally published on September 9, 2023 on corinamurg.dev
Credit: Photo by Robert Ruggiero on Unsplash
Top comments (0)