A long long while back, when I decided to start writing the chapters for the Semantic HTML unit in my HTML course, I was heading into new territory. Sure I had heard about <aside>s, <section>s, <nav>s, and <main>s, but never did I ever get to appreciate them so closely.
You know, learning is one thing. When you're learning, you're only concerned with yourself, i.e. what works for you. But when you get into teaching something, it's another completely different thing. When you're teaching, you need to research, get really deep into what you're learning, or otherwise you risk becoming a mere expresser, not a teacher.
Now, for the purposes of this article, I am concerned with the <nav> element in HTML. I always used to think that <nav> is only meant for making HTML code look presentable. I mean, who likes a surge of <div>s anyway? Beyond this, I gave no importance to the <nav> element. Period.
But little did I know that there were much deeper and paramount reasons for using <nav>. It wasn't just about better code, but also about the extremely neglected notion of building accessible websites, usable by everyone.
In the following discussion, I aim to talk about a couple of reasons for using <nav>, and to convince you to throw away your <div>s out of the window if you're using them to create navigation sections.
But how to throw away a <div> out of the window? Anyways...
What is the <nav> element?
The <nav> element belongs to the class of semantic elements in HTML that clearly describe the purpose, the meaning, of the underlying content they contain.
Actually, pretty much all of HTML falls under the category of semantic elements. For example, the familiar <h1> and <p> elements are also semantic elements, but we don't usually see them in this light perhaps because the word 'semantic' was popularized by HTML5, and all the new elements introduced by this specification came to be known as 'semantic elements.'
It's mainly the monotonous, generic <div> and <span> elements that are not semantic in nature. On their own, they don't convey that they represent on a webpage.
Coming back to the <nav> element, we can more specifically refer to it as a semantic sectioning element. That is, <nav> is a semantic element that serves to represent some kind of a section in an HTML document.
So what kind of a section? A navigation section.
<nav> element represents a navigation section in an HTML document.A navigation section is basically composed of a bunch of hyperlinks to aid us in navigating across the website (as a whole) or in navigating across the current webpage.
The beauty of using <nav> lies in the fact that it implicitly creates a navigation landmark on a webpage which is then used for accessibility purposes.
And this takes me to my second point: What is a landmark?
What is a landmark?
In HTML speak, a landmark is an important, distinctive region of a webpage. Or should I say, an extremely important region.
For example, the header of a webpage is a landmark. So is the footer. Navigation sections, as I just stated, are also landmarks. The main content (represented by the <main> element) is a landmark too.
The WAI ARIA that looks after the specification of landmarks in HTML actually defines them in a beautiful way:
Landmarks provide a powerful way to identify the organization and structure of a web page.
So what's the use of landmarks? Why should anyone care after all?
Again, the WAI ARIA continues as follows:
The use of landmarks roles support keyboard navigation to the structure of a web page for screen reader users, and can be used as targets for author supplied "skip links" and browser extensions for enhanced keyboard navigation.
The most important point to note here is of keyboard navigation for screen reader users. That's what landmarks are, at the core, intended to do.
People without disabilities perceive a webpage differently than those with them. They'd be able to quickly see what's visually laid out on the webpage and, thus, not really need to have a classification of landmarks (i.e. what's a header, what's a footer, and so on).
However, people with disabilities, using different kinds of assistive technologies for using their computers, won't be able to make all this judgement about a webpage. These users rather rely on programmatic hints on what part of a webpage is what.
And in this regard, landmarks help us website developers in giving these programmatic hints for such users.
With this knowledge out of the way, let's get back to the <nav> element and see the reasons for using it (over the monotonous <div>).
So why use <nav>s?
Better for accessibility
As stated earlier, the <nav> element represents a navigation landmark on a webpage. This helps us clearly announce to screen readers that a particular section on a webpage is meant for navigation purposes.
Screen reader software, such as NVDA and JAWS, allow users to quickly move between different landmarks on a webpage using keyboard shortcuts.
Thus, having a navigation section laid out as a <nav> element means that it'll be possible for screen reader users to conveniently navigate to it, and then navigate across the website or the current page, depending on what kind of a navigation section it is.
And this in turn means that <nav> improves the accessibility of a webpage.
Clearly, we can't get this benefit when using a <div> (at least on its own). Having a <div> represent a navigation section means that it's only so for users who can perceive visually; users with visual disabilities won't be able to know this.
role="navigation" on a <div> to accomplish the same thing, that is, create a navigation landmark. However, with the mass support of <nav>, there's really no need to be using a <div> at all.And because fluid navigation is a vital part to any website, which almost all visitors use at one point or the other, it becomes even more crucial to have <nav> represent navigation sections.
Better for code readability
If you've ever gotten the chance to move your eye through an intensely nested HTML code file, flooding with <div> containers everywhere, you'll agree to the fact that it's no easy feat to read it.
Most importantly, there's probably nothing to break what I call the '<div> chain', that is, an endless chain of <div> elements.
Using a <nav> instead of a <div> for representing a navigation section helps break this tedious chain of <div>s.
Without a doubt, it's easy enough for us to spot a <nav> within an outright winning majority of <div>s, and to quickly make the connection between the starting (<nav>) and ending (</nav>) tags in the code.
In essence, I like to think of this to be parallel to the reason why we comment code, or put a block of code on a newline at an increased level of indentation, or use _ separators when writing out huge numbers in code (for e.g. in JavaScript, PHP, Python) — to make code readable.
Wrapping up...
And this wraps up this not-so-long discussion on the significance of <nav> in HTML.
What I've come to appreciate very strongly — like very very strongly — over the months of creating the HTML course is that just because a website looks fine for you and me doesn't mean that it's fine for everyone.
It's not at all a trivial task to create a website that is accessible for everyone but by no means is it impossible. As web developers — and programmers, in general — who are always taught to think about efficiency, performance, scalability, it's time that we also embrace accessibility.
It might take us some time to make existing websites accessible or to create ones from the very beginning, but it's better late than never.
So probably as a first step in this marathon, go on and throw away the <div> out of the window if you're using it for denoting a navigation section in your website. Use <nav> instead.
To test your understanding of the <nav> element, you can take the Semantic HTML — Navigation Quiz.
And while I am at it, the subtle details of the <nav> element also remind me of the fact that frontend development is by no means easier than backend development. The conundrums underlying HTML and the subtle nuances of HTML elements are so intricate and complex that it's impossible for even an expert developer to fully grasp them.
In this respect, here's a shoutout to all the frontend developers (including myself) 🙌.