In 2020, COVID-19 upended society in countless ways, including the cancelling of the annual NCAA Men's Basketball Tournament. This meant cancelling my annual Accessible Tournament Bracket and pool, which is something I always look forward to.
Fast forward to May. I'm giving a presentation at the HighEdWeb Accessibility Summit on Accessible Navigation Menus, based in part on lessons learned as I've explored this issue over the years, as documented in my previous blog post. Long story short: There's a lot of confusion and debate over how best to code a website navigation menu.
In preparation for my presentation, I found myself wondering what the current state is among higher education institutions. Jared Smith provided me with some data from the WebAIM One Million:
- There are 5903 home pages in their sample with .edu domains
- 4656 had at least one <nav> (79%)
- 859 had at least one ARIA menu (14.5%)
- There are 7,277 ARIA menus in all (an average of 8.5 per page on the pages that have them)
- 2,620 of ARIA menus (36%) were broken (i.e., did not have the required components)
The relatively high use of <nav> is promising. But the high use of ARIA menus (several per page) suggests they aren't being used properly, and the fact that so many are broken is especially disconcerting, but not surprising.
This data just left me hungry for a deeper understanding of what's actually happening out there on higher education home pages. Combined with my lingering sadness over missing March Madness, I decided on a whim last night to stage my own NCAA Tournament, and advance teams in the bracket based on accessibility of their website navigation menus. I devoted many long hours to this endeavor. It's a weekend, so I stayed up until midnight last night staging the play-in games and first two rounds, then woke up early this morning eager to get on with the Sweet Sixteen, Elite Eight, Final Four, and National Championship!
I started with Joe Lombardi's Final Bracket on March 12, in which he predicted who the 68 tournament teams would be, and who would be playing who. Of course, we'll never know if Joe's predictions were accurate, but he tends to be pretty close, and this is all we have.
For each tournament game, I compared schools' web navigation menus, answering questions like:
- Is the menu wrapped in an HTML <nav> element, or another element with role="navigation"?
- If yes, does it have an aria-label so screen reader users can easily distinguish it from other navigation regions on the page?
- Does it have good visible indication of focus, so keyboard users can tell where they are?
- If it has submenus, can they be triggered and accessed by keyboard?
- If the submenus are keyboard-accessible, can they be used efficiently (e.g., with support for enter, space, arrow keys, and/or escape) or are users restricting to simply tabbing... and tabbing... and tabbing through all the options?
- If it has submenus, are they tagged with ARIA attributes such as aria-expanded, aria-haspopup, or role="menu" so screen reader users have enough information about the interface to understand and interact with it?
Regarding role="menu", in my previous blog post I had been persuaded that navigation menus aren't really "menus", and therefore shouldn't use role="menu". I'm less convinced of that now. Nearly all of the menus I examined were identified as "menu" either in an explicit aria-label attribute, a hidden heading, or in classes and ids. Also, I've been doing some historical research for my HighEdWeb presentation, and in Suckerfish Dropdowns, a hugely influential article in A List Apart back in 2003, Dan Webb and Patrick Griffiths describe "the best method for defining a navigation menu". So yeah, maybe menus really are menus.
In any case, after examining 68 navigation menus, many of which have little or no accessibility at all, I was happy to accept any effort to make a menu accessible.
What I learned overall from my not-so-random sample of 68 basketball schools is this:
- 21 (30.9%) have flat menus (no dropdowns)
- 19 (27.9%) have mega menus (submenus with content and structure beyond simple lists of links)
- 3 (4.4%) have a mobile-first menu design for their desktop site (a collapsed menu, toggled with a menu button)
- 46 (67.65%) include a visible focus indicator in their menu design (rather than rely on browsers' default)
- 53 (77.9%) wrap their menus in a <nav> element (or other element with role="navigation")
- Of these, 23 (43.4%) include an aria-label attribute.
Of 44 sites that have dropdown menus:
- 24 (54.6%) have dropdown menus that are accessible by keyboard (at all)
- 11 (25.0%) have Superfish-style menus (dropdown menu appears on focus; tab is the only supported keystroke)
- 18 (40.91%) have submenus that are triggered by pressing Enter.
- 8 (18.8%) have submenus that are triggered by pressing the spacebar.
- 11 (25.0%) have submenus that can be closed with the Escape key.
- 9 (20.5%) support navigating through submenus with arrow keys.
- 2 (4.6%) support jumping to a submenu item by pressing the first letter of that item.
- 14 (31.82%) have aria-expanded on the triggering element.
- 12 (27.27%) have aria-haspopup="true" on the triggering element.
- 4 (9.09%) use aria-controls to explicitly associate the triggering element with the submenu.
- 5 (11.36%) use role="menubar" or role="menu".
- Of these, all but one use role="menuitem" on the items in the menu.
That's a lot of variety among navigation menus, and variety is not a good thing in this context. Users suffer, as every website they visit implements navigation menus differently. The one stat among all of these that gives me hope is the apparent trend toward flat menus. A colleague of mine at the University of Washington manages several websites and closely monitors analytics on them all. He tells me that users don't even use dropdown menus anymore. The vast majority of the navigation on his sites happens via search. So why waste time building an overly complex interface that few people are going to use?
That said, I'm not opposed to dropdown navigation menus, particularly if done well. And the NCAA tournament pool has provided some very interesting examples.
If you just want to know who wins the tournament, the full bracket is available on my Accessible NCAA Tournament Bracket website. But skipping ahead to see who won isn't nearly as fun as enjoying the game, so I encourage you to stick around for my play-by-play commentary. I'll spare you the details of the first two rounds, and start with the Sweet Sixteen...Continue reading