The recent post about marking up navigation in lists (or not) generated nearly 200 comments of mostly-great discussion on this topic. I thought it would be of benefit to wrap up the important points.
“Against” navigation in lists
- At least one screen reader user prefers navigation without lists, which was the origin of the original article.
- Simpler markup.
nav > a
is easier/less thannav > ul > li > a
. - Divs and spans can be just as good, especially with ARIA roles
“For” navigation in lists
- Announcing the number of items in the list can be helpful
- Benefit to structure in non-CSS browsers (Lynx screenshot)
- Long standing pattern that hasn’t proven widely to be a big problem
- Lists are a “hook” for screen readers, (e.g. press L for lists) and display hierarchy well
- Safety: nothing can be in lists but list items, not so for nav
Draw
- The extra markup can be helpful for styling. I’m calling this a draw because it’s true but reaching. I could wrap every div on a page in another div and that might be helpful someday for styling.
- You can’t use
role=navigation
on a<ul>
anyway (“Allowed role values are directory, listbox, menu, menubar, tablist, toolbar, tree and presentation.”). I’m calling this a draw since in either case you should wrap navigation in a<nav role="navigation">
. - The “verbosity” of screen readers is a choice. Lists are more verbose, but that can be adjusted.
- VoiceOver treats exactly the same
- The spec doesn’t care either way.
Relevant
- Accessiblity is more than screen readers
A “Winner”?
Personally, I think marking up navigation as lists seems to be the best choice. You can look at the facts and decide for yourself though.
“Leave Accessibility to the Experts”
Dennis Lembree thinks I shouldn’t talk about this stuff, as a non-expert. I feel like the gist was that I made up my mind that lists are bad in the original post and my rabble-rousing will hurt the internet. I don’t see it that way. I saw it as I have a new set of facts that are questioning an old best practice and I’m going to start a discussion on it. Closing down discussions before they start hurts the internet worse, I think. That said, I encourage all constructive criticism of this blog, what I write, and myself at any time.
Thanks for the summary Chris! I never made my way through those comments =)
Questioning what we do and why we do it is great for learning,
If it wasn’t for trying something different, we would still be hiding text by offsetting it <—– 9999px over there.
And reading some of the comments, made me question some markup tags, such as the UL vs OL tags, which could possibly be just get placed into a list tag, and either through css, or as an attribute to specify whether is should be numbered, lettered or styled such as bullets or squares.
Ya, who would do that!?
So I’m assuming you mean this method: http://www.zeldman.com/2012/03/01/replacing-the-9999px-hack-new-image-replacement/ – unfortunately I’m sticking with -99999px, as when you hit Ctrl+F and type the text which has been hidden with the text-indent:100%; method, the text becomes visible.
See this fiddle: http://jsfiddle.net/4d5H6/ , press CTRL+F and type “Hello”, hit enter a couple of times in webkit.
There is certainly no shortage of opinions on the topic. But as you know, opinions are like @#%^&*$, everybody’s got one. I made it though about 5% of the responses. Would love to see some ul-less solutions for dropdown menus in action rather than in theory. Thanks again for the topic.
For dropdown menus you have menu type=”toolbar”.
It’s not semantically a “navigation” but if you can wrap your toolbar with nav.
The difference between ul and menu markup is minor – both may only conatin li elements, and are basically the same things (at least at the moment).
But the menu type=”toolbar” markup has better semantics – it is treated as “interactive content”, while ul elements were intended to display data (without interaction).
See what you think of this one. I am a couple o days behind as I have just read both of the posts on the topic and did this pen after reading the first.
http://codepen.io/bkbillma/pen/mKkEv
Thanks for the summary Chris – great to see the results of a constructive discussion.
Interesting to see that the debate seemed to change your mind on which was the better solution – stuff like this helps move our industry forward in terms of finding the best way to do things as a group.
If we didn’t discuss, we couldn’t learn from each other, and this particular discussion raised a lot of points beyond just how it related to accessibility I think.
Great roundup Chris. For what it is worth, I really enjoyed this particular discussion and seeing other peoples views and perspectives on the matter.
You become an expert by learning, and you learn by discussing ideas with others. Avoiding the discussion gets us nowhere.
First off I think it was good that you started this conversation, and we should all be open to at least discussing new ways to mark-up our content but perhaps people such as yourself (Chris) who have a strong influence over many web developers due to their strong presence on the web and their many hours spent sharing their knowledge with the greater public should be a bit careful with spreading techniques that may not be the best techniques to use for web designers/developers.
This is an added burden on you I realize, but I think one of the things that comes along with being a big player in the web design community…Your position of influence is well deserved due to your 5 + years of blog posts and sharing your insight into web development…and for this you should be applauded….I just think one should be careful with what they publish when one is in such a position.
Regardless…please keep sharing your knowledge….as I look forward to reading it whether or not I agree with it or not…
My above comments have not sat well with me…just keeping putting your mind to blog posts…and us readers will let you know one way or another our opinions…open discussion and openness to all ideas and willingness to discuss possible new techniques is a good thing…
Just keep posting…and us readers will provide the feedback…
This is a great blog and I can not count how many times I have used it both for work and for just plain reading enjoyment…
We don’t need to defer to experts, but we should defer to expertise. Jim Allan’s comment put it best:
Thanks for the roundup Chris! Must be tough going through those 200 comments… Nonetheless, I too think that marking up navigation as lists seems to be the best choice.
Chris, this is the very reason I stopped following many ‘experts’, because they stopped allowing comments outright, they close them after a few days, or they require twitter or disqus etc to comment (both are blocked where I work), or for some other obstacle.
I need to know whether an article’s contents are sound, what other people think of it, and if it’s an old article, whether the content is still relevant. The comments are where it’s at. I don’t take any expert’s output as valid unless it stands up to scrutiny from the audience, from another recognised expert or otherwise. Often it is irrelevant whether the person that started the discussion is an expert in the subject or not.
Leaving anything ‘to the experts’ is prone to leaving it completely, it might as well be completely hidden, and ignored by the masses.
I think having quite a large readership justifies the occasional diversification, it’s not as if it’s entirely unrelated (it’s not at all). For me, all your articles are interesting because I like following your progression as a fellow web developer, and they’re easy to understand. If you only wrote about the CSS parts, I think that would be an incomplete account of what you do, and what you’re about.
Exactly. I always wondered why people were so anxious to close comments on their articles (e.g., “Commenting on this entry is automatically closed after two weeks.”). It seems to me to make the Internet more worthless and disposable. It’s like you’re saying your content has no particular value anymore.
Great article Chris. I think the best tactic would be whatever works for that current project at the time.
Great insight into the topic Chris. Even though I still think using ul’s is the way to go, I still I appreciate the discussion that was formed around your blog post.
As for Dennis, he went on to post a lengthy comment that ended with “please don’t crucify me for my thoughts”, which seemed a little hypocritical judging by his blog post.
A friend of mine had spoken with me about these some weeks ago, I tried dropping lists within a nav item but for me it just didn’t sit well in terms of structure, although I believe that to be more of a personal preference. I did end up using nav > span > a for the navigation on one project, which served its purpose well.
Lists are the best way.
There’s a reason why almost everyone uses it for navigation.
Chris, you’re about as much of an expert on the web as anybody. I’m not convinced that lists are either right or wrong, but I do know that you’re more qualified to write about anything that has to do with the web than most.
Thanks for all you do!
I have a collection of fortune cookies. One of them reads:
I try, as often as I can afford, when there is more than one way to do something, to give myself to research, contemplation, and discussion, until I’m convinced which way is best, among the choices I am already aware of, even if it is only best by some small measure.
During this process, I consider everything a decision factor, even subjective evidence, like opinion, feelings, intuition, etc. However, I try to give each factor no more and no less weight than it deserves.
The thought trail leading to the conclusion is just as valuable, perhaps more, than the conclusion, for the thought trail validates and supports the conclusion. Too often it seems the thought trail is non-existant, lost, or full of gaps. I consider it a triumph when a thought trail finds its conclusion, and to see a conclusion fully supported by a complete and correct thought trail.
So let’s continue onward, in the “perfection of the minor details”, in our understanding, our knowledge, our craft, and not let “experts” stand in our way.
Chris, I fully support you stance. I think that people using the tools that create the web (HTML/CSS/JS/whatever) are the ones that have to start the debates that challenge the “status quo”, and that they should be public and open to experts and “non-experts” alike. No ivory towers please.
Your article sparked a lot of reactions (including Dennis’ post) that have helped a lot of humble practitioners (myself included) to understand the accessibility issues behind some of our common practices. I think the internet has worked this time!
Hey. I’ve slept on this. The very notion that an expert on CSS has no business writing about accessibility is sheer distasteful, disgusting nonsense.
As I have to remind members of my development team every once in a while. CSS is not magic. You can’t throw any rubbish into your HTML and expect the reusable corporate CSS to render it properly. The HTML structure must be prescribed, and followed.
So given that it makes sense to expend quite a lot of forethought to your HTML before you can even start writing your CSS, giving due consideration to accessibility would be the responsible thing to do.
You’re not an expert?! Ok. Lists all the way for me.
Chris,
I’m going to agree with your articles, and disagree with Dennis’ perspective on leaving accessibility to the “experts”. There is nothing wrong with challenging a current process or series of process and getting the community involved. Every process can always be improved upon.
Dennis makes valid points that the ul topic has been relentlessly debated, but the difference here was that you were not preaching to be the expert on the topic, and instead created a forum for other people to discuss how they feel about it. That’s not you with a pointed finger telling everyone to do it your way, its you saying “challenge” this topic. True experts welcome challenge and adversity. Although this might be a bit of an extreme comparison how do you think medicine and medical practice improves? We have a basic formula for success, and then we improve upon it.
There’s a quote I live by that I’ve coined, and its that “I’m not an expert, I’ve just done everything there is to do wrong” In my eyes an expert is only an expert when they’ve challenged as many things as possible.
This part 2 article even showed that you conceded that lists were actually the better choice. So not only did you engage the forum with one particular belief/understanding, but you adjusted your own understanding of the topic.
I enjoyed the articles. Continue to challenge the community and work we face every day as developers/front-end developers. I look forward to it.
Hi! Long ago, and about 9 or 10 years old when I entered the world of accessibility I had not scored menus with lists, put the links one after the other and this really could generate a fatal error as accessibility screen readers read only the first link and the rest, so that did not happen this had to separate consecutive links with a printable character, the fact remains that include additional characters, introducing noise into the website, so the best way to solve this problem was to use lists. Anyway just to dial a paragraph, a heading, etc. .. Should we make a list in the case of a collection of interrelated elements?
I feel my English…
So can we expect another wrap up post wrapping up the things discussed in the comments here?
First he’s like:”Until I see some solid research that suggests that’s dumb, I’m sticking to it.”
Then he’s all:”Personally, I think marking up navigation as lists seems to be the best choice.”
…
…and I’m like: “Whatever!”.
Thanks for the wrap up Chris and sparking the accessibility discussion on a mainstream web dev blog!
Last post really got the thinking. I thought the less writing would be of great value, but I think the navigation is lists is just a bit better, just for the styling. I think you can do more with the li and a together than just styling a hyperlink.
Also it’s a sh*tload of coding to use this way of navigations in Joomla!, or any generated nav with a CMS.
I’m sticking with the ol’ fashion way. ul > li > a.
Thanks for the great topic!
Thanks Chris for your previous post that almost convinced me. It seemed weird to me that lists is the de facto standard for navigation but without real need or benefit. I’m glad your conclusion is that it’s ok to use it anyway ;-)
Thanks for this wrap up. It’s very helpful and much appreciated.
Well said Chris! Thanks for the excellent wrap-up!
Great round up Chirs ….Thanks!!!
I agree with your outcome Chris, purely for semantics. Any item that can be defined as a list (eg a list of links) should be marked up as such in my opinion. I accept it’s more code to mark up navigation this way but if you were to switch of stylesheets to view the HTML in it’s purest form, a list of links reads more like a document’s table of contents. A list makes more sense.
agreed with your stances:-)
This is quite a minuscule issue you are on about.
I know right?! Why are we discussing a markup pattern to nearly every single website on the entire internet when BEYONCE’S DRESS MIGHT HAVE HAD IGUANA ON IT.
The most important “For” point was not included in the original post even though many comments on the original article referred to it, that being that a list of links is still a list regardless of the presence or absence of the NAV element. A list is a list. The NAV element is characterizing the overall block that it is inhabiting in the DOM. It gives a hint about what will be inside but that doesn’t mean that what is inside can now have no structure. As I said before, there might still be any number of ways to handle content and links inside a NAV; just don’t think that a list has suddenly become not a list just because HTML5 gave us the NAV.
Very refreshing attitude. It’s principles being discussed here, not persons, and there was nothing wrong with the discussion.
If it’s a simple site I use a classic list in a . If the site is complex and requires some browsing, I essentially categorise the lists into divs with links turned drop downs. This makes the design minimalized, but more importantly, a blind user or screen reader won’t have to shift through the entire nav bar on every page load.
In a nav, I meant.
I think it’s easier to use a list. Then than means for sites with CMS editors, then you can easily create a bulleted list for the navigation.
For years, banks and financial institutes have told us the leave banking and financial questions to them. Look where this has recently led us. Same for the food industry. Mosanto anyone? Yeah, leaving things to “experts” has really proved very good for us in the past…
I am part of that accessibility community and I personally think it’s great that accessibility questions are beginning to be talked about and debated outside the usual circle of so-called “accessibility experts”. This blog is one of those nice places that gets a lot of positive attention from web developers, so having accessibility questions covered here is a good thing for digital inclusion in general. The more web devs are exposed to those questions, the more likely they are to integrate some of them in their work.
Of course, they may not always get stuff right at the beginning, but with a little guidance, we can hope they adjust with time, just like for any other aspect of web development.
Like for anything else, there could be wrong assumptions being made from time to time, and I think the question that were brought here about lists and navigation were an example of that that unfortunately got out of hand. But I think even the top experts aren’t impervious to making mistakes.
I don’t man to make excuses for anyone, because it’s not my role to do so, but a lot of the people from the accessibility community – myself included – are very passionate about the subject because it appeals to human nature and exclusion. Sometimes, that stirs up emotions that will provoke reactions that are bigger than intended.
I feel like it’s all part of a positive learning curve for everyone: acquiring new skill sets for some, and learning to let go for others.
So, despite what was written in the blog post on letting accessibility to experts, I encourage you to keep looking at the accessibility angle as something worth considering. First, thinking about it will make everyone here a little more concerned about the topic and second, it forces everyone to think outside the box for a change.
After all, we all want the same thing, and that’s creating web browsing experiences that work a much as possible to the widest audiences and the largest number of platforms possible. So please keep exploring new leads and keep accessibility in the picture. You are doing a great job. And as you might have guessed by now, some accessibility folks will also be watching! ;p
Hopefully, together, we can all start contributing in a positive and constructive way, for the better good of this web we all care so deeply about.
Chris, thank you for being willing to learn that one person rarely (ever?) speaks for all. As I wrote in the comments for the first article, I encourage everyone to make sure they have at least a bit of a sense of the qualifications of a presenter. We’d do that whether or not the person had a disability, wouldn’t we?
I’d also like to encourage people who are interested in following and learning more about accessibility to regularly read the WebAxe blog at http://www.webaxe.org. Dennis has contributed much to making the Web a better place, as I am sure you’ll agree if you read more.
While the discussion has been interesting, current navigation markup techniques are neither out-dated nor broken. I view the issue as a simple one, if what you are defining is a list of items, then mark it up as a list. To claim a traditional navigation schema isn’t a list of items in an effort to alleviate a few extra seconds of adding additional markup harkens back to the days of table-based layout and omitting closing tags. However, if a site’s navigation is clearly not a list, then use the HTML5 NAV tag with the proper semantic markup. The biggest flaw I see with not using a list is when a navigation consists of dozens of items and is coupled with failing to provide a skip to content link for screen readers. My college’s website is a prime example (tccd.edu; check it out in Lynx), and illustrates how ridiculous it is to abandon proper structure.
Exactly.
Accessibility is indeed more than just screen readers. What I don’t see in the summary yet is that links are inline elements by default, whereas you need a block-level separation for each new navigation item, so just going with an a-tag is not sufficient.
Also, I could be wrong about this but I always figured ARIA roles came secondary to good html. A solution for when standard HTML structure/semantics just didn’t cut it.
This is slightly tangential and slightly germane to the discussion but one of the points we are ignoring here is that ideally web pages should be created in HTML first with content being surrounded by proper and logical tags (“Is this a list? Then let’s mark it up as a list. Is this a paragraph? Then let’s mark it up as a paragraph. Is this a header? Then let’s mark it up as a header.”) These considerations are supposed to come before “what it looks like in the browser” is considered. This is what CSS Naked Day is all about. After you’ve correctly marked up your content then it’s time to apply styling. We could even say to mark up your content then check it in a browser with only UA style sheets applied and then apply your own styling. If you ditch UL > LI in your navigation now because you think your list of links is no longer a list does your page at least appear logically to you when viewed in a browser before you apply your own styling?
I’m somehow not compelled by a self-proclaimed expert telling the rest of us to basically shut up, as if concerned we’ll come to a different conclusion than the one he’s already decided upon. Truth is, experts are all around us. Real innovation can come from a variety of outlooks blended together into a discussion among peers, rather than a single self-certain perspective.
After reading the submitted pros and cons, I’m struck by how little it really matters. I find that freeing. Everyone should try it both ways just to see how it works for their semantic outlook.
In the case of an ordered Table of Contents type nav (like a wikipedia entries jump links to major heading,) I would tend to use an ordered list for a quick numbered visual queue of subsections. But everything else is fair game for experimentation in my mind.
Despite what Dennis and others claim, a “list” is very light on semantic meaning, bordering on meaninglessness in this case. “Nav” on the other hand is very meaningful. But a “list” of items grouped together – for what purpose? Navigation.
A list of items you need to complete this project? Clearly listy.
A list of items you may click on to navigate this site? Not so much. It’s just not what we think of as a list. – It’s not a to-do list, not a wish list, not a David Letterman Top 10 list. it’s just a bunch of navigation items grouped together, you may choose to view this as a list or not.
Thanks for giving us the opportunity to re-evaluate this.
List or no-list is equally valid, and I won’t criticize a fellow web dev for his/her choice. But allowing the discussion is important. Thank you, Matth
Christian’s point above is a very compelling reason why one should consider a navigation list a list. Yet I can’t help but notice that the reason is based entirely on how it will appear visually in a browser, albeit without css applied, as on naked day.
Is this how we define semantics? No, it is not. Though YMMV.
“Yet I can’t help but notice that the reason is based entirely on how it will appear visually in a browser, albeit without css applied, as on naked day.”
Not quite what I said. My point was that the first consideration should be marking up your content properly before considering how it looks in a browser. Chris Coyier’s original entry suggested, “Maybe we can switch the common usage of
DIV#nav > UL > LI >A
toNAV > A
,” butNAV
is only meant to take the place ofDIV#nav
not ofDIV#nav > UL > LI
.So if something was a list of links before then it is probably still a list now, or more than probably. If we were going to switch to
NAV > A
now (and the tide doesn’t seem to be going that way) then why wouldn’t we have by the exact same reasoning used onlyDIV#nav > A
before? My many posts here point out that a group of links can be something other than a list, but that a list of links is still a list. That was the primary point (emphasis on “primary”).The secondary point (emphasis on “secondary”) was that after YOU have marked up your content and then YOU view it in a browser before applying your own styles does it appear logical to YOU? I was never implying that people mark up all their links in list elements so that I could come over and see a pretty, indented, bulleted list of links on their machine, or even on my own machine on CSS Naked Day.
Hopefully this clarification helps.
I’m not writing this to simply be cotroversial, but – Why should links in navigation be thought of as a “list” rather than a group or collection. What if theres only two items, does that constitute a list? I totally get the purpose of this but it seems we are discussing semantics anyway, both of code and meaning.
We went with lists as it was deemed semantic AND screen readers could deal with it. I will point out that at the time the extra elements did cause some browser issues and nav as lists were more difficult, however we all learned to deal with it and browsers got better.
The semantics of this discussion are not really worth anything unless those nuances of your chosen method or preference can be interpreted by various devices either now or in the future (the past is history).
Although much of what is discussed if acceptable in practice, it seems to me the newer tags describe what the links in the containerer are, better than whether they are a list or not. Only time will tell if devices learn to use those tags to understand the links inside them.
Yes, it definitely is about semantics. Yes, two items constitutes a list… assuming it’s a list to begin with. If it’s a list it doesn’t matter how many items there are.
Shopping List:
Milk
Eggs
No, links in navigation do not have to be thought of as a list. The issue is not if that’s the way they have to be thought of. The issue is: if YOUR links in YOUR navigation is a list of links then it’s a list. If it’s something else then it’s something else. Still, if you see them rather as a group or a collection do you have
GROUP
orCOLLECTION
tags to wrap around those items?And remember that
NAV
is only meant to take the place ofDIV#nav
not ofDIV#nav > UL > LI
.Keep up the good work Chris.
Either method is okay and it is good that you engaged with the community on this.
I am getting a little annoyed at people considering themselves experts on UI, UX and Semantics telling you how you should markup your page as if there “is only one way” of doing this.
Best practice is does not always dictate how the page should be marked up. en devour to have some creative freedom with your markup and designs, who knows one day your approach may become a best practice. Otherwise everything is going to start looking the same.
Especially now with the introduction of HTML 5, a lot of what is considered best practice with markup just does not hold up.
Putting loose
A
elements into aNAV
element is something you can do, but it’s a lot like putting loose eggs into an egg carton that doesn’t have individual cups for each eggs. Yes, it contains them. Does it contain them well? No.I’m no expert on accessibility, but from the results listed context reigns supreme yet again. I can see If a wide array of navigations are present main navigation could be a list, where-as sub-navigation forgoes the listing, or even vice versa if you want to be able to navigate to sub-lists/nav’s quickly using the “L” key.
For smaller websites I don’t see it being a big issue regardless of which method you use. It really depends on the application and the context, as with most things.
I feel more emphasis should be put on sitemaps, accesskey, and tab-index implementation then the navigation markup itself.