If you Google around on whether or not you should use lists as the markup for navigation on websites, you’ll find no debate. Every article suggest that yes you should. The vast majority of tutorials you read will use lists for navigation. The vast majority of templates you see will use lists for navigation. But is this ubiquitous markup pattern absolutely correct? Let’s see.
What you’re likely to see today
<nav>
<ul>
<li><a href="#">Home</a></li>
<li><a href="#">About</a></li>
<li><a href="#">Clients</a></li>
<li><a href="#">Contact Us</a></li>
</ul>
</nav>
Or if pre-HTML5, there would be no <nav>
tag and instead <ul class="nav">
Alternative: Listless Nav
<nav>
<a href="#">Home</a>
<a href="#">About</a>
<a href="#">Clients</a>
<a href="#">Contact Us</a>
</nav>
An Old Battle
2005: Bruce Lawson does actual research with screen readers. The conclusion was that lists are best, but it was being compared against marking up lists in tables, so that makes sense.
2007: I posted about listless navigation and Dustin Brewer strongly disagreed that this should ever be used. Dustin’s article talks about semantics, accessibility, and screen readers, but has no research and doesn’t explain why the listless navigation is un-semantic or would present screen reader problems.
Enter Reinhard Stebner
In January 2011, Reinhard spoke at a Refresh event in Baltimore and apparently made a HUGE impression on the audience. He is completely blind, and talks about markup accessibility.
Reinhard suggests not using lists for navigation, and instead using divs and spans.
Leah Vogely was at the event and writes:
I think everyone in the room scratched their heads when this was said. One of the first things you’re taught about coding is how to structure a navigation and this is normally done with an unordered list. This list structure, however, is not conducive to the screen reader’s logic. The span tag is not recognized by the screen reader, so it is one of the ways you can simplify your content for accessibility.
Divs and spans are the way to go as they’re invisible to screen readers. Stebner was tabbing through the far too many lists on mica.edu and they gave no clue as to where he was on the page and no information other than “List, 10 items. List, 6 items…” With divs and spans, the content is immediately available to the screen readers.
Jim Doran was also there:
Putting a navigation structure, which is just a collection of hyperlinks, in a list is supposed to allow screen readers to pause between each link instead of reading all the links as a sentence. Semantically, this makes sense. We use HTML to apply meaningful mark-up to content – making things lists seems like a good ides. Yet, there’s no easy way to identify a list as a set of links, so a page with 12 sets of links can be very confusing. He demonstrated this with Jaws.
We touched on ARIA as a way to help deal with some of this, and instead of using lists for links, he would like to see more
<div>
and<span>
s used.
Reinhard Stebner made it pretty darn clear. He uses JAWS as a screen reader and navigation in lists makes it harder for him.
VoiceOver
All the research mentioned so far has been for JAWS. In my understanding, JAWS is the most popular screen reader. There is also the native VoiceOver that comes on OS X. In my testing, VoiceOver tabs through the navigation in the exact same way, whether it’s in a list or not. Just as cross-browser testing is important, so to is cross-screen-reader testing.
HTML5
Some of these conversations pre-date the widespread usage of HTML5. HTML5 has the <nav>
tag which I believe puts the semantics argument to rest. If you’re marking up navigation, put it in an <nav>
tag. In lieu of HTML5, or if you simply must use a different wrapping element, you have the ARIA role: <div role="navigation">
.
Update: upon asking around, you should use the ARIA role on the nav tag, even though it’s implied, because some browsers don’t apply it like it they should. So <nav role="navigation">
. Thx Dave!
The Spec
Says:
A nav element doesn’t have to contain a list…
And goes on to show an example of a navigational paragraph.
Inline vs Block
Not using a list for navigation means the links will lay out in a row rather than each on a new row like a default list would be. Personally I find that a convenient blank slate and enjoy not having to remove user-agent stylesheet styles for lists. Should you want links to behave like a list, you could always change the display
property for the links via CSS.
So
What do you think? Pointless pursuit? Worthy discussion?
Personally I’ve been list-free for quite a while now. Until I see some solid research that suggests that’s dumb, I’m sticking to it. As always, the best would be to get more information from real screen reader users like Reinhard.
And if we continue to use lists, why is it always an unordered list? I remember Ryan Singer going off on that one time. Doesn’t it stand to reason that we chose the order of that list very deliberately?
Make sure to check out the wrapup post of what we learned about all this after this post came out.
What about nested navigation?
Curious about this too – lists provide a great heirarchy for sub-links. Is there a recommended way of doing this without lists?
You can nest
<div>
s too… But I’d mostly be curious what a screen reader user has to say about it. Certainly the sub menu NEEDS to be triggered on :focus.You can nest elements in link elements, shouldn’t be any difference. Unless you are talking about something more complicated?
Thinking more about the benefit of the natural hierarchy. Even without css, navigation and it’s sub-menus in a list show up in a useable way, with levels clearly indicated.
Interesting topic. I did switch over to a listless navigation but I haven’t really done a nested navigation with it.
If I use a <div> that means it should go inside the parent <a> tag, right?
I tried doing it on jsfiddle, the nested <div> is not recognized as a child, but as an adjacent element. And you can’t get to the sub nav as it disappears when you leave the parent link. Is there something wrong with this code?
A NAV element is a sectioning element. And you can simply nest NAV inside another NAV thus creating sub-sections (strictly speaking each NAV should have a heading, if not, it gets an implied “empty heading).
@Marc Racho: in your jsfiddle you nested links (A) inside another link, this is NOT allowed.
I wish I could correct my own reply. While one can nest a NAV inside a NAV, it would obviously be better to use a SECTION to create sub-menu’s.
You can’t nest link elements inside link elements though. That would be ambiguous in addition to being invalid.
@Evert – that what I was actually thinking, you can’t nest a link inside another link. But yea, I misunderstood what Chris said about nesting <div>s LOL it should have been like this.
I think nesting DIVs/SPANs might still have us in the same mental model as using UL & LI to do this. Perhaps “Nested” menus using NAV should be more like: http://jsfiddle.net/g4kMG/1/ (I haven’t researched any implications of this though).
I was using UL & LI for navigation menus because I believed Screen Readers paused between reading out each list item. If they pause between the links inside NAV, then that’s OK I guess.
I’m so glad you wrote this up, Chris – I too have wondered why everyone uses lists for navigation, while then taking the time to write styles that removes most if not all of the default list attributes to make them look nothing like lists. Thank you!
And by the way, I agree, It seems “they” should rename ordered/unordered lists to numbered/bulleted lists, because both are inherently ordered by the order in which you code them as you pointed out.
calling them “numbered” or “bulleted” ties them to presentation – not the definition of how they should be treated.
“Unordered” never meant that items would display randomly: just that their display order is arbitrary and that re-ordering them wouldn’t have any negative impact on their meaning.
Yes, but could it not be argued that “numbered” lists could imply more than presentation, just as “ordered” does-meaning they’re numbered for a reason to indicated “order.” Designers using Adobe products such as inDesign would certainly argue so, as the two types of lists we’re talking about, ordered and unordered in HTML markup, are labeled numbered and bulleted and the same goes for most text editors as well. Only in HTML do we seem to call them something different. The same thing happens when I rearrange an ordered list in HTML as I do rearranging a numbered list in a word document. I don’t even understand why we need anything more than just a “list”. Just let me set a style to it to determine whether we’re using bullets or numbers or what have you and let the list behave as such with the first li representing #1, or letter ‘A’, or what have you…if I turn off said style attribute, it could fall back to “bullets” in place of numbers. In either case, I’m ordering the list behind the scenes.
For the record, I agree that in the eyes of the user, seeing a numbered list does portray a different meaning than seeing a merely bulleted list-that being that the order does matter (i.e. gold, silver, bronze). What I'm talking about though, is behind the scenes-in the code, everything is determined by how I, the developer, order each list item, regardless of whether I've used <ol> or <ul>. An ordered list that reads bronze, gold, silver doesn't make more sense to the user than an unordered one that reads gold, silver, bronze. Point being, it still comes back to me, the developer, ordering the code for both ordered and unordered lists properly.
Bullets and numbers are applied with CSS. Sure, ol’s automatically have numbers, and ul’s automatically have bullets, but ul’s can have any number of indicators, and more importantly, ol’s could be a. b. and c. instead of 1. 2. and 3.
Ordered and unordered might be a bit awkward, but they’re always correct, regardless of style.
This may be a noob comment but why can’t something like sass add the list markup within a nav tag in preprocessing?
Sass (and scss and less and stylus) only mess with your css. It doesn’t touch the markup. JQuery would probably be best if you wanted to go that route.
This seems like something that the JAWS browser could handle better. I’m guessing this would be a pretty common problem as it stands today.
I agree with this.. you would have thought that if using lists is the de-facto method.. then they would have been able to handle it. You could add role to the ul and the reader could use that.
Its mad that the one thing JAWS cant handle very well is navigating? Seems like a major oversight?
Exactly what I was thinking the whole time reading this. We have semantic tags for this exact reason. Should they not be assessing their users experiences and finding ways to improve/ fix these nuances? That’s what happens (for the most part) in the world if regular web browsers
I am assuming that something like HTML5 Shiv does a pretty good job on the fallback for IE?
I use lists for the menu. As my site is primarily for 3D I don’t think the blind will mind if there is a list or not, as they can’t see the pictures anyway. However I will probably carry on using lists.
FYI screen readers are also used by partially sighted users, not only blind people. Not all partially sighted users, it depends on many factors, but these ones will see your site and/or listen to it via their screen readers.
An UL is more appropriate than an OL because it is not a sequence of events that NEED to happen in a certain order. http://www.w3.org/TR/html401/struct/lists.html
I have always thought that the spec should be changed to treat the Nav element as a special kind of list. Wouldn’t it make sense to have all of the links in a Nav be NavItems?
I’m personally always use lists for navigation, because it makes me feel that each nav item is a part of it.
But what I really doesn’t like is
nav > ul > li
, to much elements. Why just notnav > li
. Ok, it’s not semantic, butul.nav > li
is less semantic in terms of HTML5 spec, wherenav
is designed for navigation. So what’s the plan?.nav
is just the name of an HTML class, it has no semantics, no meaning except to us webdesigners and webdevelopers who see the source code (not speaking of microdata here, irrelevant to accessibility for now).nav
is an HTML5 element and you can add whatever classes you want to it, they won’t change its semantics.Is it too much elements added to your code? Well in general you add 1 navigation to your page, maybe 2 or 3. More of them is quite unusual, so it’s not a big deal imho as it brings a lot.
If you don’t want to do a
nav > ul > li
, you can donav li
which will pick all the list items within your nav.nav > li
won’t work since you don’t have an li’s as immediate child to navI like this approach. I hate it to clear out the list styles to fit my navigation and also I’ve wondered for a while now while the most of our community sticks to this list navigation thing. So if both me and the people who read pages with a screenreader can benefit from a non listed nav, why should I not change this pattern. I like it a lot thanks Chris and all the peeps which have helped to figure this out.
I personally like the UL inside the NAV. But as with anything, there are multiple ways of creating navigation.
But i do like the NAV with no UL and LI elements inside it. each to there own.
Its become a routine to use the UL as a navigation process.
I agree with you Chris. I abandoned the use of ul as navigation block since the semantic purpose was lost with the introduction of the nav element. An ul inside a nav feels redundant.
How do you code subitens?
It’d make drop down menus pretty dang hard… Lol.
What about using nested NAV instead? then it’s not that hard. nav class=”top-level”, and nav class=”sub-level”.
I just wanted to clarify something about the “unordered” and “ordered” naming. The names come from the idea that items are either ordinal or not. Of course any list is in an order, but in some cases the order doesn’t matter, in other words each items place in the list is arbitrary. In some lists the order does matter, thus it makes sense to use numerals or letters to designate that order. Navigation is in an order that is decided upon by the designer or developer but we don’t usually look at navigation as ordinal. Where as a top ten list is ordinal and where an item appears on the list has a meaning in relation to it’s numbered position.
I prefer using a list as it gives me lots of extra elements for free (which are handles for styling – think rollovers and icons added), renders nicely even in non-CSS environments (like an RSS reader showing a table of contents pointing to anchors in the document) and it adds space between links which makes it easier on touch devices without having to style anything.
Screen readers are damn slow to update and vary immensely between different versions. I guess ARIA can make all this easier, but I gave up a long time ago calling something accessible or not when it works in Jaws.
Accessibility has many facets, blind users is just one group to care about. Say someone with dyslexia or learning disabilities could benefit from a proper list structure especially with nested menus. Of course you can achieve that with CSS on any element, but why not take the ones that work and were meant for the job of listing grouped content?
Again the question is: what is to be gained by changing a common practice? The screen reader experience is a very subjective one as I know other blind users who love navigating with keyboard shortcuts in lists. And the “clean slate” argument is also a matter of taste.
Some of the answers here scare me. ul > li > a is not too many elements, it is a proper HTML structure, nav > li is not as nav is not a list element. You can overdo it with saving keystrokes. same with the SASS answer – it seems there is a weird believe that SASS can do anything. So is it the new PHP? :) Some things need changing, others really only need changing when they are broken, rather than breaking them for the sake of applying a new hot technology or saving code.
This was my first thought too. The <ul> and <li> elements not only organize the links for navigation, but give you many more options for how to present those links.
A screen-reader is always going to have a different experience in accessing a page than a sighted user using a mouse. The challenge of accessibility isn’t to give the same experience to all users, but to assure that all users can get the information they need. If a page is confusing to screen readers because it has several navigation lists, that seems to be more a problem of how the page is designed and organized than a problem with having navigation links in lists.
The idea of list-based markup giving “extra” elements for free is a nonunique benefit. Using divs and spans in a listless setup gives you the same freedom (and even more room to breathe). Further, I’d argue that using a list-based setup simply for the presentation benefits is not inline with standards.
Tangentially, thanks to learning to use a ul > li > a setup for navigation, my brain sometimes reduces everything to “OH! This is a list, too, because it’s a series of similar items!” And I have to stop (and punish) myself from (for) the ol > li > article flotsom and jetsam that would invariable ensue.
Hi Chris, you wrote:
In response
Here here. It’s smacks of something new and hip for the sake of it.
I think on some level should be some type of list with people able to put li tags inside of them and maybe with an href attribute. navigation by default implies that it is in fact a list.
One of reasons why navigation is a list is that there is a decency that webpage should not contain links pointing to itself:
In the example, we are on the home page of a website, so “Home” menu item is not a link (
A
), but it’s still a menu item (LI
).P.S. Markdown in comments here seems to not work (at least as for preview).
Oh, it’s preview that is broken here. Correct code example:
I cannot say the last time I saw a nav where the current page did not remain a link. I have definitely seen that sort of pattern in a breadcrumb, but for navigation?
However, to solve the issue you present in Chris’s markup, just wrap the current page in something else, such as a span. Or if you want to keep the character count short, go with i or b.
Marat, you do not need a list item to place mere unanchored text…
I could just as easily write
Home
Products
Contact
using nothing more than spans…
My point is that assumption that “consequent links are already obvious list” is wrong since some items are not necessarily links. For styling (presentational) purposes we of course could use
SPAN
instead ofA
for inactive items, but from semantics perspective there is nothing semantic inSPAN
, so nonlinked text becomes not an item at all, it’s just semanticless text of unknown purpose. At the contrary, list item is list item always, regardless of whether its contents is a link or not.Sean:
For example, most of websites created by Art. Lebedev Studio (leading web studio in Russia) use this pattern. Tracking that specific link corresponds exactly to current page is sometimes technically problematic (that would be quite trivial in DOM, but, for example, DOM in PHP [in fact most popular server-side language] is very buggy and almost unusable in practice) and may be unreasonable in “assembly-line production” of websites, but the pattern itself is quite sensible and useful (BTW logo on home page of a website should not be link to its home page for the same reason).
Definitely an interesting discussion, so I decided to dig around a little. I think the concerns you mention in the post are mainly due to their being multiple lists of links on a page, causing confusion for SR users.
Mainly, SR users themselves should be the final authority on what is best practice, and so I can see why Reinhard’s statement was taken so seriously (as it should).
Nonetheless, here are some noteworthy quotes and links:
From Roger Johansson, in 2009:
From a University of South Florida page (which also has a video demo of VoiceOver reading a link list):
From Userite, a company that specializes in web accessibility (this quote might be from an old page, there’s no date):
This W3C document recommends grouping links via lists.
This Penn State University accessibility page offers some suggestions for groups of links, but doesn’t state anything about lists.
In WebAIM’s most recent screen reader survey, under Problematic Items, there is no mention of link lists, although other navigation-related items are seen as problematic.
This old discussion on WebAIM discusses link lists, but it’s an old post, so I’m not sure how relevant it is today.
Further from WebAIM, they explain under the heading “Screen readers inform users that a piece of text (or a graphic) is a link”:
And here’s an interesting tidbit from that same page:
Again, it would be great to get further feedback from actual screen reader users. I think it’s significant that the WebAIM survey does not mention link lists as a problematic item, so based on that I would not be so quick to reject the use of the unordered list for links. After all, isn’t what the majority of SR users what’s most important, not just one person?
Anyhow, I’m sure others with more up to date knowledge will chime in here, and I think Christian Heilmann’s comment above is good because, as he suggests, there really is no perfect one-size-fits-all solution.
Lee, he’s right. The proper target of the skip-nav is the page
<h1>
, so that it is read. Chrome doesn’t move focus to it without JavaScript. At least it didn’t as of last month.I feel your pain about posting code. I put a
<code>
, then escape all<
s and the rest is normal.Chuck, I’m still struggling, I’ve just tested a few HTML-only skip-nav links, and can’t find any issue. Are you saying #links are broken in Chrome? How are you testing that focus has moved?
Ah, keyboard focus! Figured it out, it’s still a ‘bug’.
Why is this (the accessibility portion) still an issue? There is already a solution:
https://developer.mozilla.org/en-US/docs/Accessibility/ARIA/ARIA_Techniques/Using_the_link_role
According to the Working Examples,
<nav>
<ul role="navigation">
<li><a href="about.html" role="link">About</a></li>
. . .
</ul>
</nav>
also works with divs (assuming linkage is handled by JavaScript)
<div class="nav" role="navigation">
<span role="link">About</span>
. . .
</div>
So why isn’t this being used? Accessibility shouldn’t be a reason to choose one markup solution over others. It should simply be an additional layer.
Here’s my list:
Why do I still need to add JavaScript in order to make skip-nav work?
Why can’t I use CSS meant for visual browsers (
display: none
) without worrying about how non-visual tools will handle it? After all, there is also ahidden
ARIA state.For that matter, why should CSS even be served to blind users?
These are answered by Christian’s comment: “Screen readers are damn slow to update and vary immensely between different versions”.
Is it so hard to create a non-visual “browser”, instead of trying to piggy-back on a visual one? It would have complete control, such as ignoring “target=_blank” and pop-ups. There must be someone working on Webkit or Gecko who could put something together.
I don’t think you’ve ever needed to use JavaScript in order to make skip-nav work.
role=link is not required on an <a> element as its role is already mapped in the browser. ARIA role are only required on most elements if you a) are trying to change the native semantics or b) trying to polyfill lack of browser support (refer to: Using ARIA in HTML. See my comment below in regards to Christian’s comment about screen readers.
@Lee: There are some very old bugs (can’t look it up now, but I think in Webkit) that result in skip navigation not working for keyboard users (focus issue). Without JS you can’t get a skip nav to work for these users.
Steve, my point is to treat ARIA attributes as we do classes. We can target tags in CSS, but if we target classes, the tags can change (such as when updating to HTML 5). The same would apply here. If the screen readers look for role=link, it doesn’t matter what the tag is. In other words, make ARIA attributes independent of HTML/XML/WhateverML, so all roles would be valid on all tags. It would also help avoid
<a href="javascript:void(0)">
and<a href="#">
, which aren’t actually links.Regarding your comment about browser support, I agree. That’s another argument for a separate browser specifically for accessibility. Let the community that deals with accessibility have its own browser tailored to their needs. That would also give developers definitive validation as to whether a site is compliant.
@glev: I’m doubtful, my skip-nav links have always been HTML-only:
“For that matter, why should CSS even be served to blind users?”
I could be 80% blind and have difficulty reading text and navigating web pages. but visual elements may help me navigate using keyboard/mouse. Therefore it is important to render the CSS.
But I’m not sure if that’s important to that audience. Just trying to think of an example of why CSS is still read.
I, too, have stopped using lists for my navigation purely for the sake of code bloat. Whenever I see an element in my code that contains only one other element, I remove it unless there is a very compelling reason not too. 98% of the time, I can achieve what I need to using just the one element. I was also getting really tired of setting the <a>’s to display: block anyway, just so the clickable area would extend to the edges of the . I still will nest an <ul> for menu systems, but I’ve broken free! It really is quite liberating.
Don’t you think it’s a bit strange how web designers focus so much of their time and energy on the visually impaired?
Don’t get me wrong, it’s important they can access websites – but the amount of effort that goes into accessibility is disproportional to the percentage of internet users who actually use screen readers.
I could not agree more. I have an impaired Uncle, and I do believe it is very important for him to be able to access the internet.
However, I can’t see a completely valid argument for using or not using a list navigation. It all just seem like opinions to me.
In my opinion, HTML and the way we write it ~ isn’t broken. The problem itself is the screen readers. Why are we spending all this time on what we know works and works well, rather than fixing the actual issue. Build something better that allows the visually impaired to access modern day HTML correctly.
I do appreciate the progressive attitudes about building the best we can, for everyone, equality in code if you will. I am just not sold that HTML is the real problem here.
Jeremy Keith recently described the “problem of playing the numbers game” (in a different context): “as a percentage, this demographic is tiny. But this isn’t a number. It’s a person. That person matters.”
Also, it doesn’t have to be “a lot of effort”. If you write clearly, use HTML elements for their intended purpose, present your information clearly, and remember that people have different levels of abilities, your work will be accessible to many more people. And you’ll feel good.
Is is all numbers?
What percentage of users still use IE8? At what percentage do you cease to care about them? Screen readers are not ONLY used by the completely blind. They are also used by people with poor motor skills.
Additionally, isn’t accessibility really all about meta data? The better you can describe your content, the easier it is for your content to be consumed and syndicated across a wider portion of the web.
I second the idea of a navigation item. Perhaps: ni
http://www.youtube.com/watch?feature=player_detailpage&v=QTQfGd3G6dg#t=38s
Haha, too funny !!
We are the knights that say “ni”
You need to be British to get that one ;)
Such a funny movie!
Very interesting article Chris, will definitely be paying more attention to this in the future!
List less NAV sounds good. But how could you handle ‘Drop-down menu’? specially WordPress drop-down menu with two or more levels down.
I didn’t even think about this issue and have used lists for navigation forever since I use CSS. Like Christian Heilmann said, the advantages are that they also display nicely if CSS is off and you get some extra containers (the UL and LI) for styling purposes. And if you combine all that with role=”navigation” there should be really no problem at all. The addressed “code bloat” is a bit ridiculous in this context (there are really worse problems), it’s just a few ULs and LIs – and if you want to style a navigation with just links properly you will need some type of containers at some point.
I agree with @Charles @ CodeConquest.com.
Spend too much time just for screen reader? Web have to be stable, and stop follow each change of useless equipments. Equipments have to follow web evolution.
(sorry for my poor english)
This is an interesting idea Chris. I’m going to give this a shot and see how it works out.
Unrelated and OT:
@Chris – I love the fact that you chose to stop supporting IE7 and IE8, coherent and brave decision, I think that all sites aimed at developer/designer should follow this trend beacause it just makes sense.
While I like the thinking, I have a concern about the sub-menus navigation. Lists seem the perfect way to nest sub-nav. Sure, you can nest another div but it feels a bit wrong.
===
Isn’t the idea of an ordered list that the item order is relevant to each other? i.e. a set of directions where you can’t very well change the order and still expect to reach your destination.
Possibly with the exception of the ‘home’ menu item (which I guess most people would expect to be the first in the list) the order of most navigation items is not relevant.
Take your navigation bar on this site: it does not matter that ‘Snippets’ is before ‘Videos’ in terms of how the navigation works. They could very well be a different order and would still ‘make sense’ in the context of a navigation menu.
An unordered list still has an ‘order’ – in that, as you read through them, there is a first item, a last item, and a bunch in the middle. It’s just that the order of the items is not important in terms of understanding their meaning.
Your navigation menu, for example, could just as easily be this and still ‘make sense’:
Interesting article Chris. The
role="navigation"
tip is very useful indeed.Yes, an ordered list describes a sequence that needs to happen. That is not the case with navigation. You could argue that breadcrumbs might me, though.
I attended this Refresh and Reinhard did say that he felt it was logical to put the breadcrumbs in an ordered list.
Another point he made was not using lists to display non-list content. He was referring to poorly written CMS that use unordered lists to layout everything.
Thanks for swimming against the stream!
Searched after a way to do this with
wp_nav_menu
in WordPress, but naturally you covered this some months ago: Remove LI Elements From Output of wp_nav_menuIf I recall correctly Bobby (ye olde accessibility validator tool) would flag up consecutive hyperlinks as an error if they were only separated by whitespace. If the links are presented without CSS being applied (for some reason) then you can’t visually tell where one ends and the next one begins. Is that two words or two separate links?
So do we care what a page looks like when CSS is not being applied? If you do, then you need something between those links. A list provides decent white space so works fine.
If not using lists then maybe you should place commas between each item and then hide the commas with CSS??!?!
I always liked list for navigation menus, you always can put another ul inside another in order to create sub-menus, exactly how lists were meant to be.
and about screen-readers? role=”navigation” seems like the best solution…
“sorry about my english grammar”
I agree with you Chris, I’ve been doing this way a long time ago.
Regards.
Here’s my reason for continuing to use an unordered list for my navigation links: it’s a way to tell the world (people or machine), through a semantic organizational structure, that these links are part of single navigation system. The order that the links appear doesn’t matter. But the fact that they are organized together in an unordered list says in no uncertain terms that these links are related organizationally.
Using other markup (divs, spans, or even just straight up anchor tags) does not provide such clear meaning. As far as accessibility goes, unordered lists may be more hassle but apparently, judging by the comments, the jury is still out on that and perhaps future accessibility tools will make the argument moot. I guess technically the nav tag would also provide a rational organizational grouping but it’s not as clear-cut as a list (because the nav tag can also contain other content besides navigational links).
Could not a set of links inside of a nav tag convey the same meaning that they are related since they are children of the nav tag without needing to improperly use a list for something that isn’t really a list just to infer relationships?
@MaccG – I see what you’re saying – the nav tag would automatically create the group/association that the list would normally create. But how do you associate specific groups of links together within the nav tag? Since the nav tag can hold more than links (associated text related to navigation) – how do you create a semantic separation of different content within the nav tag?
That’s what I’m getting at – the unordered list provides that distinction.
Regarding when to use proper ARIA roles (such as role=”navigation) , I tend to lean heavily on Steve Faulkner’s Using ARIA in HTML. It’s an excellent resource (especially the Recommendations Table).
From this article, what about using
role="presentation"
on the<ul>
It would remove the semantic from the list?
I agree with many of the comments placing the responsibility on the screen readers to interpret contextually correct and pervasive coding practices in a meaningful way for their audiences. I’m sure this must be much easier said than done since it isn’t already done. I’ve tried surfing the web using a screen reader before and it’s agonizing. But just as it’s the browser’s job to meaningfully interpret the markup for capable people, it’s the screen reader’s job to meaningfully interpret markup for handicapable people.
If nav>ul>li>a is the pervasive, defacto standard… then deal with it screen readers!
The idea of a “defacto standard” is a little nauseating. That’s not a standard, that’s a pattern, or a trend, and telling a niche group of devs to “deal with it” puts a pretty unwieldy burden on them: “ANTICIPATE WHAT THE REST OF THE WEB THINKS IS A GOOD, UNDOCUMENTED PRACTICE THAT MAY OR MAY NOT CHANGE IN A YEAR OR TWO OR VARY SITE BY SITE DEPENDING ON THE DEVELOPER’S PREFERENCES!” I mean, yeah, it’s not an insurmountable task, but still kind of a crap expectation.
And maybe I missed it, but was it established that a screen reader doesn’t actually provide meaningful markup interpretation? I read it as just a cumbersome process for the enduser.
@Vince, point received. I’m definitely pro standards, and this discussion is great. I’m just saying that once the developer complies with the standard, he has theoretically done his job. The rest is up to the browser to interpret that standard in a way that is meaningful and usable for their audience.
Hmm… lets try this again:
This works fine
<ul role=”naviagtion”>
<li><a href=”http://www.google.com>Google</a></li>
</ul>
If you want to get fancy with it, wrap it in a <nav> element.
But what about the entire part of the article where Reinhard suggests that doesn’t “work fine”?
@Chris – but is this Reinhard speaking for every user using a screenreader or is it just him speaking from his experience? One data point does not make the case for all situations. Ultimately I think it’s up to the accessibility software developers to create better software and for us web designers and developers to code to the standards and best practices.
Perhaps the best practice will change to just putting links within a nav element and to create “associations of links” by putting links together within a section element. But as of right now, an unordered list works for me and provides that semantic grouping and organization.
Interesting conversation.
It’s just one data point, to be sure. But let’s get more! It’s literally the only one I’ve ever seen from an actual screen reader user, which gives it more weight to me than an entire thread of non screen reader users.
There have been a couple of surveys by WebAim – this is the latest (sadly, back in 2009):
Screen Reader Survey #2
Even though the data presented is over 3 years old and the number of respondents is small (in comparison to the number of registered disabled internet users), it’s an interesting read. Particularly the section on “Problematic items” which doesn’t even mention navigation items as an issue (argument for convention there?)
Aside from there being the issue of subjectivity as suggested before, we can also expect that one person’s solution is another person’s problem as Chris Heilmann suggested in his scenario of blind and dyslexic users’ experiences.
ARIA roles override native role mappings in the browser. role=navigation on ul is non conforming in HTML5. Allowed role values are directory, listbox, menu, menubar, tablist, toolbar, tree and presentation.
I still see
UL > LI > A
as a logical structure for navigation. After all, it’s still a list of pages. Site maps are commonly structured in this way and often fall in line visually, too (in terms of nesting and indenting, etc) so that seems to fit well.It would be nice if screen readers could distinguish between a navigation list and lists containing other sorts of data, either using the
<nav>
element or ARIA role attribute. In other words, maybe only reading out the fact that it’s a navigation block and then alerting them to any sub-menus (dropdowns). That’s all fairly clearly presented in the markup when using lists.I would like to comment on the misinformation about “screen reader lag” It is often the case that the lag is caused by a failure of browsers to implement the appropriate accessibility support, nothing to do with screen readers. Case in point, a new element was added to HTML recently. In the last week or so it has landed in the nightly builds of Firefox, WebKit and Chrome. It is also supported by JAWS, VoiceOver and NVDA the same day that browser implemented it. Why? Unlike most new elements that get added to HTML its implementation included accessibility (role mapped in browser accessibility API) along with its mainstream implementation such as parsing and styling, so screen readers are instantly able to make sense of it and convey its meaning to users. Note that due to a browser bug in chrome, the element is not currently conveyed with the specific role it should have, but a more generic ‘group’ role.
Perhaps we can rally the webAIM to include a test or question to this issue in their next survey? http://webaim.org/projects/screenreadersurvey4/
blimey. I’d completely forgotten about doing that actual research. It must be the first time I moaned about XHTML2 and going back to HTML, too!
from the article “List, 10 items. List, 6 items…”
this is a simple JAWS control. Don’t want all that information…turn it off. JAWS and most screen reader have lots of verbosity settings. Users can pick and chose what they want to hear. And, one persons opinion does not make a standard, nor does that person speak for an entire group.
Excellent information! Do you use JAWS regularly? Can you share a blog post on how to adjust those settings? Do you have opinions on markup patterns that are better/worse for navigation, or anything else? I hate to make huge decisions on one person’s opinion, but it’s literally the only one I’ve ever heard from someone who actually uses one.
I work at a school for the blind. I am not blind. I was a teacher of the visually impaired for 10 year. I have taught JAWS. I test with JAWS. It is deep software and highly configurable…IF a user chooses to do that.
here are some useful links that will explain some of what can be configured.
http://webaccessibility.gmu.edu/docs/Accessible%20Documents%20Creation/6%20HTML/Tab%205%20–%20A.%20JAWS%20and%20HTML.doc
this is more specific to HTML – though a bit dated still good information to start. The bits that are missing are more related to Landmarks and newer features. JAWS is on about a 12-18 version cycle with quarterly (or more frequent), sub-versions and builds.
Also, many folks with visual impairments (blind and low vision) helped develop the WCAG, ATAG, UAAG, 508, European, Australian, insert country here, standards. They did not get developed in a vacuum.
and
http://www.indiana.edu/~iuadapts/technology/software/jaws/jaws_guide.html (this is more of an intro)
Jim,
Can you provide more information of a few test cases? Such as JAWS w/ minimal optimization (how it reacts) vs. JAWs output with medium / maximum optimization? Your post was the most valuable I’ve read thus far. I too have been curious about this.
Thank you
This is the kind of content I love to read. Thanks for putting this together Chris.
You’re missing the point! The problem with “a page with 12 sets of links” is that it’s a badly designed webpage.
“Too many links or navigation items” on a webpage is one of the biggest problems for screen reader users: http://webaim.org/projects/screenreadersurvey4/#problems . I’d prefer to see an article about that problem.
I don’t agree with your statement. Tell that to someone like Amazon, Overstock, or any large-sized e-commerce company with potentially millions to hundreds of thousands of items in inventory. Does your theory still apply? Navigational elements are an integral part of many sites that still require them. While I agree less is more if done correctly, it doesn’t always apply.
In the bad old days, it was certainly true that Amazon (both .co.uk and .com) websites were used by RNIB as examples of bad practice, but this was more to do with the fact that every link on the page was phrased ‘click here’ and not at all useful to someone that was navigating the site with a screenreader just jumping between links (link: click here, link: click here, link: click here, ad infinitum).
I had a look at Way Back Machine there to try and find an example, but none of the snapshots from before 2007 are working, I’m afraid.
This method of setting up links is still problematic on many modern sites, but I use a hidden span to get around this issue when the artwork dictates its use, eg “Link: More Info (about something), Link: More info (about something else)”.
@David Aimi:
That’s an interesting question. I think my theory does apply. A webpage doesn’t need to have 12 sets of links just because the company has a large inventory. Luke Wroblewski’s “Mobile First” presentation showed that many large companies are moving towards webpages with less content, but more focused content.
I’m not saying that navigation elements are bad. I’m referencing evidence that says webpages with too many links or navigation elements are a problem for people who use screen readers.
@Alan Dalton
I 100% agree with pretty much everything you’ve said. Regardless of the device or location, if your site isn’t minimal, functional, and designed to help the user complete a task, it’s time to rethink the whole site.
Lists are helpful to screen reader users for a couple of reasons…
1. They act as a hook for navigating through page content. All screen readers recognise lists, but only one (that I know of) recognises divs in this way, and none have the ability to navigate by spans.
2. When a screen reader encounters a list it informs the user how many items it contains. This helps create a mental map of the upcoming content, roughly analagous to glancing quickly at the navigation block as a whole.
3. Lists convey navigational hierarchy with absolute clarity. The relationship between nested lists is easily understood by screen readers.
Recent versions of some screen readers support the nav element and/or navigation landmarks. It’s possible to navigate by nav or navigation landmarks, duplicating the first benefit outlined above (if only for some screen reader users).
The only elements in the HTML5/5.1 spec to duplicate the second benefit outlined above are ordered or unordered lists. They’re the only elements (relevant in this case) that are intended to represent groups of items.
Nested nav elements are not supported by any screen reader at present. The individual nav elements would be recognised but only as independent entities. Using the nav element there is no way to duplicate the third benefit outlined above.
@Chuck Barlow
The first example you provided would work better if the navigation role were applied to the nav element. This would better reflect the mapping between the two, and would also avoid ARIA and HTML5 aware screen readers from duplicating the “Navigation region” style announcements.
@Chris G
nav – ul – li is almost certainly the coming standard (it’s some way off pervading just yet), but all screen readers can handle it perfectly well already. Those screen readers that support nav will announce it as such, those that don’t will ignore it as though it were a div, and in every case the list is treated as a list.
In fact I’d recommend this design pattern as the most robust, semantically useful, and well supported option.
A quick straw poll of around 30 screen reader users this afternoon suggests that many find lists useful in this context. Some said a list may not be nescessary if a heading were present before the navigation block, and some said they preferred to use the features of their screen reader to access links but acknowledged that if they were looking for a specific group of links that wouldn’t help.
Just to highlight this useful passage:
This is precisely the problem. Why does HTML have to be a factor? The language should not make a difference. It is a visual medium and could change. Let accessibility be an additional layer to whatever the language is. If ARIA attributes are used to indicate list items, it shouldn’t matter if those items are
<li>
s,<span>
s or<newTagThatDoesNotExistYet>
s.I’m not suggesting that every single tag have an ARIA attribute on it. You could have an attribute that indicates what tags are used for list items. So whether you use
<ul>
and<li>
s or<nav>
and<div>
s, the container element would haverole=navigation nav-items=[tag name]
. Optionally, if omitted, thenav-items
value could be assumed as whatever the first child element is.And where is it written that screen readers have to understand web pages? Why can’t the accessibility community take the open source code and create its own browser? Then it wouldn’t be so dependent on others to implement features.
@Chuck Barlow:
Because it’s what webpages are written in.
No, it’s not.
That’s like retrofitting a ramp on a building that has a step at its entrance: time-consuming, expensive, and sometimes doesn’t get done. Designing something to be accessible from the start is faster, cheaper, and inclusive.
They’d be fairly useless if they didn’t.
Mainstream is better than segregation.
Everybody who uses the web depends on web designers to make webpages that they can use. Good designers can create things that everybody can use. Stop thinking in terms of “them” and “us”.
And? If some new language is introduced, also tag-based, should we have to start over with accessibility? If it were just an additional layer, nothing would have to change. See HTML 4 -> 5 as a real example, but it would apply to a completely new language, as well.
Yes, it is. XML might not be, but HTML very much is. It started with
<font>
,<b>
,<center>
,bgcolor
, etc.. We have CSS for most visual properties, now, but we still have<div>
and<span>
that are otherwise identical except for how they are visually displayed by default. Screen readers don’t even acknowledge<span>
. Similarly,<em>
and<strong>
are simply semantic replacements for<i>
and<b>
. There’s no reason we couldn’t use the same tag in all situations where emphasis is needed, using CSS to make the visual distinction.Except that we have a world of developers who debate the minutiae of how best to implement accessibility. This is something that would take some time, but would (pardon the pun) ramp up relatively quickly. And once established, implementation would be straightforward.
They’d still be extremely useful. Screen readers were around before the Web existed. They work with all other applications on the computer.
Because “mainstream” is where all of the innovation comes from. Having something cohesive, nimble, and made by the same experts that use them is better than the slow-to-implement, inconsistent group of screen readers and browsers currently available.
I’m talking about other browser developers, not web designers/developers.
HTML didn’t start life as a visual language. It started as a structural language. It had i, b and u elements (as well as strong and em), and an align attribute for images to allow text to “float” around them, but that was it – see http://www.w3.org/MarkUp/draft-ietf-iiir-html-01.txt
Other stuff was added, subdequently – and then removed when CSS became mainstream.
My mistake. I shouldn’t have worded it as if they were all there in 1.0, but said “HTML as we know it”. However, the inclusion of those and
<pre>
, along with the fact that there are default renderings in that proposal, give a pretty good indication that visual representation was the forefront consideration. But clearly I don’t know for sure, so I’ll concede that one.@Chuck Barlow
Accessibility is built into HTML, and it’s worked quite well so far. Structuring the content with HTML is the first step in making your content accessible. Also—and this is absolutely crucial—it’s easier for new designers and developers to learn how to use HTML elements properly, than to learn how to apply ARIA to elements. That means that realistically, they’re more likely to actually to use HTML elements to make content accessible, than they are to apply ARIA roles, on real-world projects.
…and every other topic imaginable. That’s no reason to abandon good practices.
That’s guessing. That’s not particularly useful. Using semantically-correct HTML makes information more accessible to people with all sorts of disabilities. Lots of designers and developers already do that. I don’t see any reason to try to change that.
How much of this is the failure of screen readers?
In the case of benefit 2, could it not be achieved by screen readers telling their users how many “a” elements there are in the nav (or role=”navigation”) block?
Benefit 3 could be fixed if screen readers understood nested navs.
Why are we trying to fix the mark-up from literally millions of web authors, practically all of whom will never read this discussion or anything like it, rather than fix the behaviour of the few screen readers in use today?
It’s not just screen readers!!! That’s why. Normal users can also be thrown when links are ambiguously laid out. If you’re not careful, a wrapping link can look like two links, or consecutive links can appear as one.
For example, in wikipedia, where links to other articles are not underlined, what looks like a link to “European Union” might disappointingly be just two links, to “European” and “Union”.
Generally in accessibility you want to add as much semantics as possible so a screen reader user can use quick navigation keys to jump around your site efficiently. If you use a list they can press L for lists. I’d say use the lists for site navigation to give it semantics and let the user know how many items are in the navigation. If you don’t use lists for site nav I would not call it a failure, but if you don’t use lists for a visibly bulleted list of links like in the footer I would call that a failure.
Don’t worry about the screen reader’s verbosity, the user has control over that depending on what screen reader they use. All screen readers work differently and if they hear “List, 6 items” before the link it’s not a big deal at all. You did your job by implementing semantic HTML code. The screen reader software and the user should do their job of controlling the verbosity of how that’s spoken.
Also, disabled users are very different and may be very picky about how they want things coded for them. But they don’t represent all disabled users. Many times you’ll see people making coding decisions based on “what they heard from this one blind guy” or “what they heard from this one accessibility specialist”. Low vision users may be even more picky than blind users. The best choice is to follow standards based coding using the semantics and let the user and their assistive technology software control how those semantics are presented.
In short, verbosity is not your concern, it’s the AT & AT user’s concern.
I’m just one accessibility specialist with an opinion based on testing and research but again not all accessibility specialist would agree with me.
See what happens when you rebel against structural mark-up? The minute we decide not to use lists, we start wondering whether we should use divs, span, paras, sections or whatever else instead. Don’t fix what ain’t broke. :)
To me, as a screen reader user, navigation lists provide:
the safety that there are no other items in the navigation block but the navigation links.
the size of the navigation block, i.e. how big it is (disagree with the other screen reader user here).
Knowing the size of the navigation block allows me to decide whether to continue tabbing through or skip the list altogether (screen readers in particular allow me to skip blocks of structural mark-up on the page).
I hope this won’t sound too blunt, but… The reason a lot of this doesn’t make sense to you guys is because you look at the screen as you test. Try navigating web sites with your eyes closed and you may start appreciating the importance of structural information.
+1 for the tag.
Does anyone have Tim Berners-Lee’s P.O. Box number? I’m gonna write a thoughtful letter.
The nav element is a new element precisely for the purpose of indicating navigation for screenreaders and to allow styling to be handled differently. Unlike <nl> which was proposed for XHTML2, it can’t have <li> as a direct descendent because HTML5 needs to be compatible with old content and old browsers.
that should have been +1 for the <ni> tag.
Personally I like the <nav>element with <a>, it is a simpler method and makes sense when teaching it to intro web design students.
However, as many of you have pointed out, what about nested links. Then there’s WordPress, which uses lists, so themeing you still have to consider lists.
I think, though, it would be nice if the element could work like say description lists, so we could have for example something like this:
<nav>
<nl><a href=”link.htm”>Link 1 </a></nl>
<sl><a href=”linkA.htm”>Link 1 A</a></sl>
<sl><a href=”linkA.htm”>Link 1 B</a></sl>
<nl><a href=”link.htm”>Link 2 </a></nl>
</nav>
In this example we could have a “nav link” <nl>and a “sub-link” <sl>. Of course this would only come about in a prefect world. ;)
or <ni> like others have suggested
I would think that using a list or not would have more to do with the kind of navigation inside than what is the blanket cure all right answer.
If you think about them as normal content inside a tag, would it be the kind of content that you would put inside a ul? or is it just a series of elements.
For simple navigations especialy I feel there is little reason why it should be all wrapped up in an extra element.
Also, there are a lot of different kinds of navigation so I doubt there is one “right way” for all situations.
tl;dr If it is a list then it should be in a list in a nav but if it is just a group of links I see no reason to wrap it in a ul
Reading through the comments specifically, I fail to see how “the scale is tipped toward” using lists, as you mentioned in your tweet.
Here are some testing results from VoiceOver, NVDA, and Windows Eyes
The compelling reasons to use ol or ul are usually:
This is the way it has been tested and implemented on the majority of the web.
This provides subnavigation items with some meaningful hierarchy.
<ul role=”navigation”> provides near-identical markup to a div and span solution.
The compelling reasons to avoid their use are usually:
This removes unwarranted meaning from the page.
This simplifies markup and removes unnecessary elements, especially in breadcrumbs and flat navigations.
This justifies all the classnames I wanted/was-forced to use (and really shrunk the HAML markup).
It seems like there is a preference thing going on, even amount those that use screen readers. As long as your considering screen readers, I don’t think there is “one right answer.”
Without actually being someone that uses a screen reader, it’s hard to judge, just by looking at it, and it’s a dangerous stance to take that everyone using a screen reader (or any group of people) all browse or prefer to browse the internet in a specific way.
I find it strange how so many people are commenting: “What about dropdowns?” …What about em!?
So I love this idea, but how do we get wordpress to do this. WordPress wants to put everything and the blink tag on navigation. Any ideas?
As a waypoint here, I’m trying to keep the major for/against points here: http://codepen.io/chriscoyier/details/ztxvw
I know the HTML5 spec states this restriction, but it fails to indicate where this restriction comes from. Neither the ARIA spec nor the W3C ARIA authoring docs claim this restriction. In fact, role=navigation is considered a global attribute and can thus be placed on anything.
This is only true for “flat” navigation. As I pointed out earlier, when you need sub-menu’s the whole thing becomes more complex. A simple example:
And this is not even the most complex structure. In order to maintain a proper HTML5 sectioning structure it would be best to wrap each menu-item and sub-item in its own section-element. Also, each section must have a heading.
The point I am trying to make is that while using a UL the structure remains flexible no matter how complex the navigation becomes, but when using no UL, the structure becomes increasingly more complex.
role is a global attribute, the only global token for role in HTML is “presentation”. the conformance restrictions in HTML5 are based on the concept of ‘strong native semantics’ and ‘implicit ARIA semantics as defined in the ARIA spec. In the ARIA spec it states:
Just chipping in with my tuppence worth…
Going way back, to around 2005, I worked closely with the RNIB, and specifically with blind test users, when rebuilding the Scottish Qualifications Authority website for accessibility. These test users were accessing the web with both JAWS and Supernova.
All the main navigation on the site was built using unordered lists, and at no point did it cause the users any undue problems with navigation.
In fact, the tags helped ensure that links did not run into each other (this might have been before links were specifically announced as being such in Jaws) and it also degraded nicely for users who did not view the web with stylesheets switched on, as a standard list of links is still nicely separated into unique items, though divs as blocks would do the same, this would not be the case for spans etc.
I think that accessibility of websites should be achievable on all websites with good coding practice. However, there are always the odd occasions where even the chaps at RNIB are left scratching their heads…
We never did find a way to describe a graphic of the Periodic table using alt or longtext alternatives…
What about creating a new element for navigational list which could then be interpeted separately by screen readers and handled differently for styling.
That’s one option but it is still a list within a NAV, just a different type of list from a UL.
I’ve often thought about the reason we use lists as menu-structures for example.
This is very interesting reading.
I wonder if this have any impact on SEO?
What about SEO?
In my last job the SEO department who claim to be one of the best in the UK always said that a navigated list, whether it be the main or footer nav needed to be in li structure so that search engine bots could identify main sitemap structure easily?
What surprises me is way back when, people used to separate links with a | character or whatever as per accessibility advice: http://joeclark.org/book/sashay/serialization/Chapter07.html#h1-2935.
Then the advice to use lists for navigation, was also based on accessibility: http://www.brucelawson.co.uk/2005/navigation-lists/
Now we have a nav element, we still use lists: http://www.w3.org/WAI/GL/wiki/Using_HTML5_nav_element
So the whole notion of not using lists any more, is most peculiar.
Let me give you an example how “lists of links” sounded like before they became properly structured with unordered lists widely. To separate them visually, they were either graphics, with 80% of alt text missing because the particular designer didn’t care, or they were text links either wrapped in brackets [], or separated by things like vertical bars |. So a “list of links” might have sounded like this, baring in mind that these are so special characters that screen readers would only suppress them in the tightest verbosity model:
“left bracket Home right bracket link” “left bracket Products right bracket link”
or, especially when reading continuously:
“Home link vertical bar Products link vertical bar Support link …”
With the spreading of proper structural markup for these, the situation for those who have to listen to their computer jabbering away all day, especially for textual links, improved IMMENSELY!!! All these extra characters disappeared because they were no longer needed for the visual separation of two links from one another.
Now, if suddenly going back to spans and divs, even when wrapped in a nav element, structural markup is mostly lost again. Spans are nothing more than text insertions within other text, and divs are weak sectioning elements. They are often nested so deeply that communicating levels of indentation is totally ridiculous, so there would be no reliable way to clearly communicate what is intended. Yes, that’s what it comes down to: INTENTIONS HAVE TO BE CLEAR AND UNAMBIGUOUS! List markup is the most reliable to do that in an unambiguous way. This is important not only for screen readers, but also, as pointed out, to get styling, indentation that might be important for various screen sizes to be taken into account and interpreted by the browser correctly, etc., etc.
In my opinion, the idea to go back to styling groups of links with divs and spans is almost as bad as suggesting to do it in layout tables!
Reinhard Stebner certainly doesn’t speak for me when he says that lists of links should no longer be. And I think he just picked one particular site with horrifying usability and generalized from it, and we definitely shouldn’t do the same.
Well said. And, yes, a lot of problems would be solved with better code and better UA’s.
Feeling the nostalgia and going back to past too, there is a reason to a homepage be called a index.
This is based in a book index. And a book index is a list.
Some time after, they put that same index fixed at top or sidebar of entire site, so we don’t need go back to index.
They called this a menu, just like a restaurant menu, that is a list too.
This is logical: if a index is a list, a menu is a list.
And more: a menu is not just a “list of links” a menu is a index, a list of site chapters or pages or sections or areas…
This need to be semantic even if you ignore the links.
“company | buy | contact” is like “company, buy, contact”. This have some logic because I’m listing things like in a sentence.
But “company buy contact” is just a illogical words arrangement. This is not a phrase, is not a list and is not a index. Or you can understand it like “a company that is buying contacts”… weird.
This is a menu, a index and a list:
– company
– buy
– contact
Before someone asks, tabs are based on books too. Use the tabs and go to another chapter, so we don’t need to back to index.
Tabs uses the same index. Them, are lists too.
What a hot topic!
To me, the nav is a list of other pages on the site. Therefore, I mark it up with a list. A more interesting discussion is whether or not the navigation is an ordered list or not. UX would say it absolutely must be in that order, so I should probably be using ol; one could easily make an argument for the contrary.
If a screen reader is having a problem with navigation lists (which seem to be the norm), that’s a poor choice on the software side of things, not on the semantics of our markup.
I don’t think it’s about whether the user interface design stipulates an order, if you’re working from screen designs, they’re going to be in some order, accidental or otherwise.
A scenario I would imagine warrants an OL for navigation instead of a UL would be when the navigation is meant to be a set of sequential steps, executed in that order, like the checkout process of a shopping cart. They like to show all steps, the current step is highlighted, the previous steps are navigable, and the next steps are only shown for information.
But if you just had some typical footer links and the screen designs / customer said they absolutely must be displayed in a specific order (not uncommon), that’s still not a reason to use an OL. It’s whether the order is considered important to the user, not the author.
@Lee: I can get on board with the disagreement for OL in main navigation. If the order were changed, the list items wouldn’t change meaning (so long as nested stays nested of course).
This is an interesting topic. I believe that if you disable all your styles, the page should be rendered in a logical way. This would be a reason to keep navigation links in a list, in my humble opinion. An ordered list.
I agree, Rob. This website uses Andy Clarke’s universal style sheet for IE6 and IE7, and the groups of links that are marked up as lists are easier to use — visually — in those browsers.
3 people who use screen readers — Léonie Watson, Victor Tsaran, and Marco Zehe — have said here that marking up navigation links as lists is useful.
What more do we need?
Mark up navigation links as lists.
Four, counting Aaron below, plus the referenced straw poll of 30 that preferred lists. But also one that doesn’t and speaks out against them. I do feel like all the factors lean toward lists though. I’ll do a wrap up soon.
As a blind Jaws user, I personally prefer that navigation items are wrapped in lists. As has been mentioned previously in this discussion, it allows the author to present hierarchical information, as well as gives me some quick information about how many items there are, gives me another quick way to skip from item to item, and makes things feel a bit more organized. However, that being said, when I visit a site, whether or not their navigation is in a list isn’t likely to have a meaningful impact on my experience, nor is it likely to make much difference as to whether or not that particular site is accessible.
Of course with ARIA, this is less of an issue, as has been noted, but having the navigation links in a list does give a bit more semantic information, which is always nice.
If you think about it a list of links is still a list, whether or not you realize it’s a list. The appearance of NAV on the scene doesn’t change that. We need to collectively wrap our minds around this until we fully grasp the nascent truth just sitting here. I’m not saying that means you need to use the UL element if you don’t want to. I’m saying we shouldn’t think that NAV being here now somehow means a list of links is no longer a list.
Besides NAV only takes the place of <div id=”nav”>, not the list of links that was very likely within the <div id=”nav”></div> element. But perhaps browsers could make NAV act like the beginning of a “navigation list.” Or perhaps they could create an NL element for . . . “navigation list.” And perhaps that NL element could go within NAV, kind of like how H1′s and H2′s go within an HGROUP which goes within a HEADER. Or we could continue to use a UL within a NAV. Just don’t think that a list of links is no longer a list.
I think it is right that navigation is marked up as a list, but I have seen other things marked up as lists that I feel definitely should not be. The most astonishing was when I saw a form had been marked up as a list of form fields. The list items need to be more strongly related than just belonging to the same form. Perhaps if there’s a list to be captured, but this wasn’t the case.
Yes, people get it wrong sometimes. All the more reason to get it right when we can.
@Christian, I’ve thought the same with a “nl” element. The Navigation List element could have simply been style free unlike ol and ul but kept the indention but do we really need another list element. Nesting un-styled ul’s gives you a visual queue of nesting (● > ○ > ■) which goes hand in hand when working with tiered navigations. I’m betting when someone thought up of the nav element their intentions wasn’t to trivialize navigations in just using nav > a + a, that kind of loses semantics in a way then again I suppose that can be subjective.
I know they talk about non-listed uses of nav in the spec but in their examples they show using ul’s as well, and when I think more about it, nav is more or less like section, article or aside, describing the content inside, not a shorthand nav solution. If there is no hierarchy in your navigation then ul works perfect but in cases where it might require importance or sequence, ol could make a nice argument. For me it makes sense to stick to the traditional method of creating navigations. Far as styling goes I’ve created a nice little utility _tools.scss file that I can easily work in a mixin that removes some of the browser styles when using normalize if I absolutely have too.
@Lee: “The most astonishing was when I saw a form had been marked up as a list of form fields.”
What would your choice be?
Semantically, a set of form fields is more a list (UL and in some cases OL) than it is a paragraph…or even a div…or a span. One could make an argument for a definition lists as well. I think it is the semantically correct choice to markup a form with a list.
Hey Merne. My astonishment was purely a gut reaction, I don’t know if I can articulate why, but I’ll give it a go:
Semantically, a form does not typically contain a list of fields. To you, maybe, but not your user. That would be like saying a paragraph is a list of sentences, or a sentence is a list of words. They are implicitly, but not explicitly, it would add no value to refer to them as such.
There’s no need to do anything in HTML just because you have a sequence, it handles sequences just fine already.
Whilst it may be convenient for you to structure or process your documents using lists from an implementation perspective, serving them as lists is of no benefit to your users. This is what semantic elements are for (your users).
I’ll try to expand the form != list of fields a little more.
A list (one that is meaningful to the user) is not just a set of related items but usually items of the same type. Forms typically don’t just contain a straight sequence of fields, they have headings, labels, fields, paragraphs of explanatory text, help icons, form error messages, field error messages, cross-field error messages, buttons, maybe a list of steps, a progress meter, horizontal rules (who knows?), fieldsets and maybe even more.
If you think some of these things ought to be outside of the form element, imagine if the form element has a background, with a lovely border, or even if the form was a paper one, semantically, they belong to the form, yes?
So, if a paragraph was to go between two form fields in a form, would the paragraph also be part of the list, or would it mean you need to end one list and start another? I just don’t think it makes sense to use a list at all.
So, if not lists, what is my choice? These days usually nothing, no div, span, paragraph, definition or anything, since labels should be above the fields, I find most layouts achievable without any additional markup. HTML4.1 Strict does not allow the input element as a direct child of the form element, which was annoying, but HTML5 does.
“A more interesting discussion is whether or not the navigation is an ordered list or not. UX would say it absolutely must be in that order, so I should probably be using ol; one could easily make an argument for the contrary.”
Merne, yes, the solution here is to make it an ordered list if the order really does matter in that particular case. If the order doesn’t matter then stick with UL. I’ve used both.
Correct. Absolutely correct. If you want your navigation in a paragraph then put/keep it in a paragraph (which would then itself be within the NAV element). But if it’s a list then keep it in a list (which would also then itself still be within the NAV element). You don’t say, “Well, now that we have the NAV element I’m going to remove my paragraph of links from the P element they used to be in.”
As a blind screen reader user, I, too, vote for the use of lists, for all of the good reasons others have stated. As a side note, without making a huge deal of it, when I teach about Web accessibility, I try to make my credentials very clear i.e. over ten years of working on and promoting Web standards. And if I do give a personal opinion, I try to be very clear about that. I think there are ways to ask people about the basis for their claims that elicit valuable discussion and don’t come across as an attack.
It’s very refreshing to hear from people whom this directly affects.
I’ve been having this debate for about a year now. Arguably, I haven’t been working in web for too long and wasn’t classically trained in web or coding, but I’m also no dummy and spent most of my time in college solving difficult problems. I’ve done some research and the only arguments for lists as navs I’ve found fall into a few categories:
semantic web: the problem is, no one seems to be able to explain why “ul li a” is semantic and “div span a” is not. It seems smarter to me to leverage the html objects natural states to get us close to what we want before we even touch the css.
screen readers: Apparently these lists aren’t as useful for them as some have thought.
that’s just how it’s done: dogma. I hate dogma, and if I’m performing extra steps to get the same results I could be getting in fewer steps I want to know why. Again, no good explanations.
At work I use lists because I’m working with others and it’s important to have a consensus, but at home I will never use lists for navs, unless I want a nav that looks like a bulleted list it seems silly to me.
The other crazy thing I’ve proposed that people seem to not like so much is to never ever ever use html objects as jquery or CSS selectors. This seems like an obvious way to make css and html act more modular to me. Keeping html objects out of selectors allows you to change the html for any reason (go from span to div because I want some objects to stack, for example, without needing to change all of my jquery and css selectors would be awesome.)
Then again, as I think I said above, I’m fairly new. So until I have the time and data to actually test these ideas of mine, I’ll stick to convention for work.
Answer: it’s because DIV and SPAN do not carry any semantic meaning in and of themselves and without extra data applied, be it in the form of classes or ID’s, roles or whatever. The first means “generic block level item,” while the second means, “generic inline item.” But UL and LI each carry a lot of semantic meaning. The first means “unordered list,” while the second means, “list item.”
If you have a list of links then you have a list and it then becomes proper (although perhaps not mandatory) to characterize them in HTML as a list.
“DIV SPAN A” is more steps than “UL LI A.”
And to the people that are concerned that sometimes when making navigation lists you have to undo default styling, well with DIVs and SPANs you’re going to have to add styling. There’s quick ways to style lists without code bloat if you know what you’re doing. And the bigger concern is characterizing your HTML elements properly and then styling them.
6 people who use screen readers have said here that marking up navigation links as lists is useful.
So do I.
Read the comments here from people who use screen readers. Those are good explanations.
Christian:
Ok got it, so you’re assuming that thinking of navigations as lists is somehow helpful. I still think it’s silly to think of a nav as a list unless I want my nav to be a bulleted list. People in webs have adopted this convention but it seems like an arbitrary adoption to me. If it wasn’t arbitrary in the 90’s it sure is today.
I’m sorry, would you mind qualifying this statement? I count 3 elements each, that means it takes the same number of steps to construct each.
Sorry, you have to do this all the time, not sometimes. All the time. Every single time you use list items as your navigation you need to use CSS to remove those list styles and in many cases force them to display inline.
I don’t understand this statement. We’re not talking about style here, we’re talking about structure. Lists have style that you have to remove every time (which you could add in a reset file). Thing is, most of the nav bars I see today are horizontal. If you use a reset to remove the list styling then what happens if that reset doesn’t load for some reason? Your horizontal list is now busting out of your styled container and has those ugly black dots. DIV SPAN A side steps the whole issue of needing a reset to un-style the naturally styled lists.
To put it another way… if I want a nav to display like this:
Home News Contact
I can leverage the natural structural behavior of HTML objects to get there right away without any css… example (sorry about the creative html representation haha):
and I’m done! If I want to go the list route I go through the above step, and need to also handle display: inline and list-style-type-none. So to break it down, initializing a non-list navigation takes 1 step and is less likely to break your page formatting if something goes wrong, whereas creating list navigation takes 2. Last I checked, 2 < 1
IF the navigation is a list, but not if it’s not.
The problem there is thinking something is only a list if it’s bulleted.
All the above being said, I’ve also read a few of the screen reader comments and they make sense. This makes the most sense to me though:
Couldn’t this also be done with a plugin? This seems like it would be an interesting problem to try and solve. I wrote a bookmarlet that essentially allows remote clicking in the browser and could also be used as a plugin. It was a challenging exercise to build something that works the same on any webpage despite the structure of the HTML. When I get better at this webs stuff perhaps it would be fun to attempt to build a screen reader that intelligently parses webpages regardless of the markup. That would be some next level shit though, and I’m definitely not there. (yet)
Either way though, the screen reader argument seems to be the only viable one I’ve seen so far. I’m sorry, but the others simply don’t hold water for the reasons I just mentioned above.
There’s always a risk of styles not loading. That’s not a problem unique to lists.
ok, thanks christian for showing me that I was right about lists being more work for no good reason. I’m going to stick to no lists in my personal projects from now on, and may even be able to convince my coworkers of how silly lists are.
What you seemed to misunderstand about the reset not loading is that a horizontal nav with the list markup could potentially be completely unusable in that case, whereas the other option would still be useable with no or fewer styles.
I don’t have a personal stake in what you do.
You can feel free to characterize something that is a list as not being a list if you prefer. I’m not going to stop you. “A list is a series of items which is written or printed.” It doesn’t have to be “vertical” and “bulleted” to be a list. Also see here.
I know what you’re getting at. And if people want to they can code everything as though “reset” styles only might fail. Lately I have been using the approach of putting reset/normalize styles at the top of my own style sheet and then tweaking the values in the reset/normalize area if that helps things. And quite often it does. And then if my whole style sheet doesn’t load and only user agent style sheets are then being applied then if my HTML was correctly marked up then the site will still display in a logical manner.
In saying this I’m not dictating how one should characterize their content, just reminding that we have a tail wagging the dog scenario when “how it looks in the browser” determines how we mark up our content.
As a screen reader user and as someone who consults on this topic frequently–including testing, I’m happy to see this passionate discussion of navigation.
I will concur with the other screen reader users who have commented here about the advantages of using lists for navigation. I will also point out this useful resource for ARIA markup for nav/menu over at Stack overflow.
http://stackoverflow.com/questions/12279113/recommended-wai-aria-implementation-for-navigation-bar-menu
I also want to respond to the suggestion that the disability community should create its own browser so that it can get the best implementation. As others have already pointed out, this is neither desirable nor ideal. In fact, it’s the opposite. Most of the browser vendors have put in significant work in including accessibility. Screen reader developers have done work to support these browsers. It is assumed that creating a “special” browser would automatically relieve designers and developers from the responsibility of coding to spec and to best practices. This, of course, is far from true.
As Victor pointed out, it is sometimes difficult to understand what users with disabilities go through when browsing the net. Sometimes, the most subtle thing could make a huge different in the quality of browsing a particular site. I encourage every developer to download and use the free and the most up-to-date screen reader from http://www.nvda-project.net. When you test your site, try to turn your screen off or don’t look at your device. Voiceover can be used on your iOS devices by going to Settings/general/accessibility/Voiceover. Learn how interaction actually occurs. Think of it this way: do you test and see how your navigation or how a certain feature looks? Then, why not test how your site will appear to disabled users?
I assume you’re referring to my comment, since I can’t find any other mention of this.
First of all, I never said it would “relieve designers and developers from the responsibility of coding to spec and to best practices”. That should always be done.
The advantages I was thinking of would benefit everyone. There would be a single, platform-agnostic point of testing for accessibility (who has the time and resources to test all screen readers?). Native widgets (e.g. calendar) could be created that are known to be accessible, and skip navs could be properly dealt with (Webkit being the troublemaker here), among other things.
This suggestion is partially based on these results, which are pretty bad (only 2 got “green” scores): http://www.html5accessibility.com
And if the browser were based on Webkit, some of those contributions could go to the other Webkit browsers, as well.
By the way, the link you provided appears to be wrong. It should be http://www.nvda-project.org, not .net.
One important piece I left out, although it was mentioned in my original comment, is that the browser would handle the text-to-speech piece, also. I don’t think that was clear. That’s where the single point of testing accessibility comes in.
When I first read this my blood was boiling as I thought here we go, HTML being taken away by coders trying to shave a few keystrokes of their work by eliminating something that has worked well for many years. After reading the comments I am glad that cooler heads have prevailed and that we have heard from people who actually use web sites by hearing them. From what I read above it appears that lists appear to be perfectly fine way for most non-sighted users to access a list of navigational items.
Do you see how I used the words “list of navigational items”. I was not in the web field back in the early to mid nineties when these original tags where being developed, but I believe that HTML was developed for researchers to share research reports with other researches in an open standard document format that could be read by anyone on any operating system. Often in research reports I believe you include an “index” page or table of contents which contains a list displaying the main sections of the document and what page they are on. A perfect use for a list. I believe a web page navigation to be akin to a table of contents, so I believe semantically, putting navigation items in lists makes complete sense semantically. Just because a “ul” , “li” takes a couple of extra bytes of computer code is not a reason to get rid of it.
I always like to write my HTML in a way that will make sense and look logical on a page without any CSS applied, and putting navigation in a list does just this. It puts the navigation items in a nice neat list and if you have sub navigation items those are nicely indented to show a hierarchical relationship to other navigational items.
If it ain’t broke don’t fix it. Of course this should not stop innovation and we should always be open to finding better and more efficient ways of doing things, but changing things just for the sake of changing them or just to save a few keystrokes is not the way to go.
My two cents…
“Hits the big invisible LIKE button”
I totally agree. The basic question here is “are navigation links a list?” And the answer is definitely YES.
Is a table of contents a list? Is a site map a list? Whether you call “navigation,” “menu,” or something else, it’s a list of links to pages on your site. Why would that be any different?
Even the definition of menu is “a list of options …” (http://www.thefreedictionary.com/menu)
@Chuck The trouble is that, just like all other users, disabled people have their own preferences. Can you expect every single browser feature from all the browsers out there to be combined into a separate, “special” browser? IBM Home Page Reader was an experiment in just what you suggest. Because of the differences and people’s needs and the rapid nature of the changes occurring in browser technologies as well as standards, it could not be sustained–even when a major corporation like IBM was behind it. Where would the money for such an effort come from? Then, following the logic chain, why not have a special operating system for disabled people? By the same logic, why not have a separate browser just for geeks because geeks consume content in a different way? Their needs are different.
If we attempt to have text to speech imbedded in browsers, each will have its own implementation, not solving the fundamental issue. The discussion we are having is about content and how it’s structured. The best we can do as users of these assistive technologies is convince you that, so long as you design and develop your sites and your content in a certain way–in a way that benefits all, we will be able to consume it with our assistive technologies.
Hi Chris!
Have you seen this article? http://www.netmagazine.com/features/truth-about-structuring-html5-page
It is also about the (probably?) wrong usage of elements to improve the behavior of screen readers. I would be very interested about your opinion of this article.
Back to you article:
“Update: upon asking around, you should use the ARIA roll on the nav tag, even though it’s implied, because some browsers don’t apply it like it they should.”
I never heard that before. Very interesting – and very… sad! That clearly is a problem of browsers/screen readers not us web developers. :( We shouldn’t have to do this.
@Pipo:
We live in an amazing time. The web allows people with disabilities to communicate, work, shop, and socialise, just like everybody else. We have a free platform that allows blind people to read news from all around the world, as soon as it happens — that would have been unthinkable in the 1950s! Even if you lost your vision tomorrow, you would be able to do the same job, and use the same social networks, as you do today; you wouldn’t need to feel excluded. Seriously, this stuff blows my mind. Never before has a technology allowed so many people to participate in society, instead of being excluded.
And you’re complaining about typing 17 extra characters in a webpage:
The important thing is that you can.
Just a warning about that article (while I agree with a most of it). There are some pretty elementary thoughts going on there, take it with a grain of salt. Example: “Styling headings HTML5 style is kind of insane” section is under the presumption that headings need to be classless and styled individually (which perpetuates the problem outlined [pun intended] in the headings section about doc outline).
@Alan Dalton:
Sorry, I think you misunderstood me or I did not express myself well, but I think WAI-ARIA, modern HTML5 and the existence of screen readers is absolutely awesome! Modern technology is great! And I don’t want to complain about typing 17 extra characters. I want to complain about that everyone I know (me included) thought that using “nav” as an element would always include “role=”navigation”” as an attribute by default. But this seems to be wrong. I complain about that it took two or three years since the first time I save “nav” that someone explained me that I should add a WAI-ARIA role to this element, because using “nav” isn’t enough. And I read a lot of blogs and tutorials, but I’ve never heard that before.
I want to do the right thing and I want everybody else to do the right thing, but how should I and everybody else do this, if it seems that all contributors/evangelists of HTML5 can’t explain the right behavior and usage of some HTML5 elements to me “plain” web developer” :(
Is this my fault, too? Sure! But I’ve seen this “wrong” usage by very, very smart people, too. And that is kind of sad :(
@Pipo:
I misunderstood you. Sorry!
I see what you mean. I usually use attribute selectors based on landmark roles — [role=”banner”]{}, [role=”navigation”]{}, [role=”main”]{}, [role=”contentinfo”]{} — for laying out webpages. I’ve never had to worry about needing to add roles.
That’s a good question. I learned from Jeremy Keith’s Landmark roles article.
@Pipo- there are resources out there. A good place to start is MDN – ARIA. This document: Using ARIA in HTML provides guidance for every HTML element and whether or not an element needs addition of ARIA to make up for lack of implementation in browsers. HTML5Accessibility.com provides an overview of current accessibility implementation support in popular browsers. Here is a Rough Guide to browsers, operating systems and screen reader support.
@Steve: Your MDN – ARIA link led met to another link and it turns out that the W3C itself has a recommendation table (2.10.) on how to use the new HTML5 elements. Now everything seems to be so obvious!
I even went to html5please.com which I visited hundred times before and what do you think? They say that only some browsers implement the correct accessibility APIs and that you can use a polyfill to solve this problem. Why didn’t I see that before?^^°
@Pipo, glad you found what you were looking for. note: I am the editor of the spec containing the recommendations table :-)
From http://www.yourdictionary.com/list:
This doesn’t say anything about horizontal or vertical or whether or not each item has to have a bullet (or some other such visual indicator) next to it. We need to think about characterizing our content properly before applying styles to it. Sometimes we may even need to momentarily remove from our minds the styling that user agent style sheets apply to our content. In other words, when just looking at our HTML is our HTML correct? In saying this I’m not dictating how one should characterize their content, just reminding that we have a tail wagging the dog when “how it looks in the browser” determines how we mark up our content.
using nested navigation is “right” i do something like:
question is: do i apply the
role="navigation"
to the second nav or leave it as is?i think it needs testing.
and other alternatives as well, this was the first one i could think of.
How can you nest navigation like that Marco? You can’t put any links inside links, supposing for a moment that wasn’t invalid HTML, you’d be clicking on two links simultaneously.
Reading the specification, nesting a nav element doesn’t appear to have any meaning. It’s a sectioning-element, you just wrap it around your site or page navigation, whatever that is.
The nav element is a landmark so the author can say “this is where the navigation is” to the user. I don’t think it is meant to be used for nesting.
In W3C specification is clear when he says that yes we can, terms marking the nav element without the use of lists, but in his own example in http://www.w3.org/html/wg/drafts/html/master/sections.html#the-nav-element, he puts a code where the nav elements in paragraphs which are used, but where the links are not adjacent, which certainly would cause problems to users of screen readers. In the example above, Chris create adjacent links, which in accessibility, since WCAG 1.0 this is not recommended in item 10.5 – priority 3.
Interesting topic. From the definition of
nav
element, I think it’s suppose to use without lists.nav
can be used not only for main navigation, but also for other types of navigation links like previous/next links, where list is rarely used. So, if we stick with list fornav
, we have to change other types of navigation links to list, too and I think that’s not quite convenient.I prefer using listless for navigation. But as the 1st question by Chris, we need a good way to implement some things like sub menus, dropdown, etc.
I feel that nav is describing the area of a page but not really giving it “structure” so to speak. Before html5, I think the common thing was to use divs everywhere with a proper class/ID that describes the element. And I think the same rules should be applied post HTML5. Sure you have a nav, but what is it? It’s (commonly) just a list of pages on your website. I feel like if we only use nav and don’t use any other structure, when do we draw the line with divs? Are articles and asides enough to stand on their own as is?
Perhaps I’m not thinking about it the right way but that’s my two cents.
LISTS are the way to go, screen readers can suck on the big one
When I was making a WordPress theme from my blog, trying to get rid of list navigation drove me mad! I think this website is where I found the tutorial on how to get rid of the list elements.
If we are talking about screen readers, so why nobody says about tag?
“dfn” tag
According to the Checkpoints for Web Content Accessibility Guidelines 1.0, Priority 3 Checkpoint 10.5 states:
http://www.w3.org/TR/WCAG10/wai-pageauth.html#tech-divide-links
As such, the proposed listless nav (in it’s current state) does not comply.
Personally, I’m still using lists for navigations, but am intrigued to find a more appropriate way to markup navigations.
Stacey. ‘Until user agents render adjacent links distinctly’ is key. When links are in a list, they are rendered distinctly, even by a screen reader.
WCAG 2.0 is the recommendation now. It uses UL in its example technique of grouping links: http://www.w3.org/TR/2012/NOTE-WCAG20-TECHS-20120103/H48.html#H48-ex5
That’s exactly my point, Lee. :)
Ah, so it is!
What do we think about something like this for drop down navs: http://codepen.io/bkbillma/pen/mKkEv
@Alohci
“How much of this is the failure of screen readers?”
None. In the spec the nav element isn’t defined as the parent of a collection. A screen reader could report the number of links within a nav element, but that wouldn’t be standards compliant – and that’s the goal we’re trying to move all UAs towards.
Thanks Léonie.
Surely if the thing that is stopping AT users getting a better experience is the spec, then the spec needs changing. The nav element’s semantics certainly seem consistent with being treated as predominantly a group of links, just not only a group of links. What difficulties would be caused by changing the standard such that the accessibility tool chain could be enhanced to support this?
How about html5 outline?
<nav>
<h3 class=”screen-reader-only”>Menu</h3>
<ul>
…..
</ul>
</nav>
added note to nav element in HTML 5.1 about use of list markup:
Feedback welcome, ways to do so listed.
Excuse this if completely stoopid but could flexbox offer some ordering capability to this method of menuing? I’m new to all of this (not a designer, just trying to design my first site) so maybe I’m adding Buicks to my basket of oranges, but if you need the ordering/reordering capabilities that using lists for nav gives you, couldn’t the ordering of divs & other elements that flexbox allows do the same thing?
In any case, an interesting post and idea. I’m going to give it a try on my site since I’m trying to do something different with my menu than I’ve seen on most sites.
Will do some listless nav today. I like horizontal lists and some time ago thought about why don’t use a banch of links for horizontal navigation. So for personal small projects it’s good but if talking about smth bigger need to find out if it is good for seo, screenreaders, etc.
btw @brad very nice navigation
This post has comments from 6 people who use screen readers, all saying that marking up navigation links as lists is useful. I think you have your answer!
See: https://css-tricks.com/wrapup-of-navigation-in-lists/
Spec also say: “In cases where the content of a nav element represents a list of items, use list markup to aid understanding and navigation., which makes sense.
However, Reinhard Stebner is right, too. This is a interesting point to discuss and deserves a lot of study.
http://codepen.io/corysimmons/pen/hbndI
I have an idea. Download a screen reader, learn some of the controls, try it for yourself. w/o lists is infinitely smoother than having to listen to “list item 1, list item 2, …, list item 10”.
Here’s a better idea: read the comments here from people who actually use screen readers, as opposed to trying them. They all say that marking up navigation links as lists is useful.
It’s really a cool and helpful piece of info. I am glad that you shared this useful info with us. Please stay us informed like this. Thank you for sharing.
Chris, a group of links in spans gets read out by JAWs as a string with no pauses. It’s definitely not a good idea. This applies to navigation, filters, pagination links, and any other groups of links. Spans should never be used for structural tagging anyway. A span boundary doesn’t mean anything.
Current JAWS recognizes NAV element and will announce navigation region. So, definitely put navigation inside a NAV. Inside the NAV, I’d put the links into DIVs so they are block elements. JAWS pauses after block elements.
WCAG recommends adding title attributes to A tags. I recommend really spelling it out e.g., “Go to home page” or “Navigation, Home”. Do use commas, as commas are read as a short pause. Very useful. I really try to close my eyes and think how it will sound.
Putting A tags into an UL has advantages. It’s less about semantics but some.
Advantages: (1) semantics: at the UL JAWS pauses and announces that I’ve entered a list, it tells me at least that the next items go together; NAV is better but a list of links is not necessarily a navigation, (2) JAWS understands li tags as separate items and stops after reading each item, (3) more semantics: hierarchy is clear if one list is nested inside another (subnav) – JAWS announces nesting. For nested navigation/links, I would lean towards nested lists. (4) Not sure how people use this exactly, but JAWS does have a shortcut key that detects any lists on the page. Lists are more discoverable.
For a different technique: I’ve experimented with tables in accessibility scenarios. They can be very useful. In this case, you could put links in a table with column headers “Navigation”, hide the header row, and style section to not look like a table. JAWS would announce “Table, Go to page”. When you continue, it would read the header and first cell value, so it would say “Go to page, One”.
If we place a div tag inside an “a” tag, Should it be according to Accessibility guidelines ?
Comment from Mark Harter:
I was intrigued by what you wrote and the fact you mentioned a speech by a blind user who doesn’t like list items for navigation.
Well, as a blind user, and a programmer myself, I beg to differ from what Reinhold said. I also use J.A.W.S., and it is the best screen reader available, but First of all, every blind user uses a screen reader a bit differently to navigate a website. For example, when I’m viewing a website, I use J.A.W.S. hot keys, and I like to look for header tags by pressing the “H” on my keyboard, that will move the focus of the screen reader to that point in the site. So if a website is formatted properly, the site ame will be an h1, site section will be h2, etc, etc… but I also like to skip around using ehe “E” key, which will find form fields for search as well. If I press “V”, it will take me to a visited link on the site should I have already been there, “T” for tables, “L” for lists, etc.
But getting back to a website navigation using lists, I believe this is the smart move, and it should be the first list items of a website. I like to span them across a website logo, or beneath it, or after the h1 tag if the site has a left column navigation.
But yes, if a site has too many list items, it can get confusing, but if these lists are properly tagged, there shouldn’t be an issue.
One thing I’ve discovered/learned over the past 10 years since losing my eyesight and using J.A.W.S., the more screen reader friendly a website is, the better indexed it is by a search engine such as google, bing, etc.