Since I started out using HTML, CSS, etc., one consistent thing I have always noticed is that navigation bars nearly always seemed to be presented as lists, in some variant of:
HTML:
<ul>
<li><a href="link1.html">link 1</a></li>
<li><a href="link2.html">link 2</a></li>
<li><a href="link3.html">link 3</a></li>
<li><a href="link4.html">link 4</a></li>
</ul>
Also with <li>
inside the <a>
CSS:
ul {
list-style-type: none;
}
li {
display: inline-block;
}
And now with HTML5 are basically the same, but shoved in a <nav>
tag or anything saying 'This is some navigation stuff' to the browser/screen reader.
My question is do they need to be in list with modern HTML5 semantics and ARIA accessibility roles, and what benefits are there still? Sure its a list of links but is there any other practical reason?
Reasons I have found:
Semantics, screen readers, and accessibility: Opinions vary, particularity on how it makes it better (or worse …) for screen readers. But shouldn't the use of HTML5's <nav>
and/or related ARIA roles around the links do this? Does it also need to be shown specifically as a list of links (unordered or otherwise) as well?
Aesthetics: In vertical lists with the default bullet points, or without CSS, yes. But otherwise alternative markups (e.g. <a>
in <nav>
) instead of <li>
in <ul>
will be as easy or easier to style as desired.
Existing Use: It is used a lot in existing websites (e.g. StackExchange sites, MDN, many many more …).
W3C <nav>
spec: Says the links don't have to be in a list, but it can be. But it also specify the content of <nav>
as 'a section of links', does it also need to be a 'list of links'?
Backwards compatibility: It is often used so should be widely supported, and HTML5 and ARIA may not be available to old browsers/screen readers.
Various referred to posts:
<nav>
)
<div>
's & <span>
s should be used (from before HTML5). Is worse as otherwise it trys to read out all the navigation lists instead of the pages actual content.
I probably will continue to use lists as that seems to be the current status quo and hopefully will be backward (and forwards?) compatible, and I will try more research myself with my own code using modern screen readers*. But is there a reason to use lists in navigation more up-to-date with HTML5 semantics?
Also, what screen readers should I try other than JAWS?
Many navigation menus contain more than one level (often used for drop-down menus), i.e., a hierarchy:
- Home
- Products
- Physical products
- Digital products
- Contact
Without using a ul
(with a nested ul
), you couldn’t represent this hierarchy in the markup (unless the navigation is complex/long, in which case you could use sub-sections with heading elements).
Your navigation (currently) doesn’t have more than one level? That doesn’t suddenly change its semantics, it’s still the same information structure, just with only one level instead of two or more.
By using a ul
, user agents (like screen readers) have the chance to offer features that exploit that structure. For example, screen readers could announce how many items the list has, and offer additional ways to navigate that list (e.g., jump to first/last item).
If only div
were used, it could easily happen that users "tab out" of the navigation without noticing that the navigation already ended. By using a ul
, it’s very clear where the beginning and where the end is, and that’s especially important for navigation menus, because a navigation entry often only make sense in comparison to all the others (finding the right link for your goal is often only possible by checking all available navigation links and ruling them out).
nav
.The nav
element just conveys that this section contains navigation links. Without nav
(i.e., pre-HTML5), user agents only knew that there is a list. With nav
, user agents know that there is a list + that it’s used for navigation.
Furthermore, nav
should of course not always contain a ul
, as not all navigations are a list of links. See this nav
example in the HTML5 spec:
A
nav
element doesn't have to contain a list, it can contain other kinds of content as well. In this navigation block, links are provided in prose:<nav> <h1>Navigation</h1> <p>You are on my home page. To the north lies <a href="/blog">my blog</a>, from whence the sounds of battle can be heard. To the east you can see a large mountain, upon which many <a href="/school">school papers</a> are littered. Far up thus mountain you can spy a little figure who appears to be me, desperately scribbling a <a href="/school/thesis">thesis</a>.</p> <p>To the west are several exits. One fun-looking exit is labeled <a href="http://games.example.com/">"games"</a>. Another more boring-looking exit is labeled <a href="http://isp.example.net/">ISP™</a>.</p> <p>To the south lies a dark and dank <a href="/about">contacts page</a>. Cobwebs cover its disused entrance, and at one point you see a rat run quickly out of the page.</p> </nav>
The question of why navigation bars are implemented as html lists (ul
) is less important than how you would implement them if you weren't using lists.
HTML menus are like food menus, they are unordered lists by essence. Something you can navigate through and choose the element you want. People do not make the choice to present a menu as a list, it's a fact : a menu is a list. So why you would use another element than ul
and li
?
The fact that the default CSS definition of some browsers implementation presents it with a bullet is something relative to the presentation but does not change the meaning of the tag by itself.
For instance, here is the definition of a div
according to the W3C:
The div element is a generic container for flow content that by itself does not represent anything.
Now, the definition of a table
:
The table element represents a table; that is, data with more than one dimension.
And this is the definition of a ul
:
The ul element represents an unordered list of items; that is, a list in which changing the order of the items would not change the meaning of list.
Among the 3 definitions, the more suitable tag is the ul
.
Moreover, it offers navigation mechanisms for screenreaders like announcing hierarchy, going to next/previous elements, ...
Concerning screenreaders, you can try also NVDA, Chromevox and Voiceover.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With