March Madness 2020 (in May, with Web Accessibility instead of Hoops)

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...

Screen shot of St. Mary's home page, featuring full screen basketball video and a dropdown menu
Continue reading

Dropdown Menus 2020: Menus are not menus

In the comments on my previous blog post, Adrian Roselli called me out for my claim that the "menu" design pattern in the W3C's WAI-ARIA Authoring Practices is the right way to code a navigation menu. This is an issue that has plagued me for at least a decade, maybe more. My first blog post on the topic, Accessible Dropdown Menus, was published in March 2012. I followed that up in December 2013 with Accessible Dropdown Menus Revisited, still searching for the holy grail in accessible web navigation menus, but liking what I found in Adobe's Accessible Mega Menu.

Based on these two old blog posts, I've had many people contacting me over the years asking for advice about accessible navigation menus. In recent years, I've always referred them to the WAI-ARIA Authoring Practices. On GitHub, this resource refers to itself as WAI-ARIA: Authoring Practices Guide and is commonly referred to by the acronym APG, so I'll use that here for brevity. The APG contains dozens of design patterns for common web widgets, including a recommended keyboard model and ARIA markup for each. I've always believed that in order to attain a consistent user experience for common widgets across the entire World Wide Web, we need a central source of standard, recommended design patterns; and from my perspective, APG was that source. I have encouraged developers to keep the APG handy, and when they're about to create a widget, check to see if there's a recommended design pattern, and use that. Developers have followed this advice, and when they've wondered how to create a navigation menu (for example), they've gone to the APG, looked for a "menu" design pattern, found exactly what they needed, and simply followed the recipe. However, there's confusion around menus specifically, which has led me to question how zealously I should recommend the APG.

The source of my confusion is that there are actually several design patterns for navigation menus. I'll summarize the three I know about (or four, depending on how you count them):

Continue reading

Squarespace, Wix, & Weebly: Accessibility Review

While watching the Kansas City Chiefs win Super Bowl LIV last night, one of the most effective commercials for me was the one from Squarespace, featuring Winona Ryder sitting roadside in the snow with her laptop. A local law enforcement officer shows up and they have an exchange that's reminiscent of Fargo. The commercial isn't hilarious or outrageous like some of the other commercials, but it's kind of cute, and it sparked my interest. It's actually the only Super Bowl commercial that inspired me to take action: I reached for my phone and went straight to the website Winona had created using Squarespace, WelcomeToWinona.com.

In case you missed the ad, here it is, hosted on YouTube but played within the Able Player WordPress plugin.

Since I visited Winona's site, I now am seeing ads everywhere for Squarespace, as well as for Wix and Weebly. Clearly The Universe thinks I want a website. I don't, but I am curious to know whether these easy-to-use website authoring tools are capable of creating accessible websites. So I created an account on each service, and got started creating some simple websites. Here's what I found...

Continue reading

Audio Description using the Web Speech API

When HTML5 was published, it introduced the <video> and <audio> elements, as well as the <track> element. The latter provides a standard means of synchronizing text with media for a variety of purposes. The HTML5 spec specifically defines five kinds of track: captions, subtitles, chapters, metadata, and descriptions. The latter is particularly interesting, and is the topic of this post.

Description, historically known as "audio description" or various other terms, is a supplemental narration track designed for people who are unable to see the video. It describes content that is presented visually, and is needed if that content is not otherwise accessible via the program audio. Historically we've outsourced description to professionals, but with prices starting at $15 per video minute, we've never gotten the kind of participation we need if video everywhere is going to be fully accessible.

With HTML5, description can now be written in any text editor. All five finds of tracks, including description, are written in the same file format: WebVTT, which is essentially a time-stamped text file. Imagine that you have a video that beings with a short interview with someone notable, say the president of your university. The president's name and affiliation appears visually in an on-screen graphic but they're never specifically identified in the program audio, so a non-visual person has no idea who's speaking and whether to take them seriously. This is a really simple use case, but common among videos I see in higher education: The video can easily be made accessible by creating a WebVTT file that includes the speaker's name and affiliation, with start and end times indicating when this text should be spoken. There's a bit of thought that must go into timing, as you want to avoid colliding with other important audio, but otherwise it's a really simple task. The result would be a file that looks something like this:

WEBVTT

00:00:05.000 --> 00:00:08.000
Ana Mari Cauce, President,
University of Washington

Save that as a VTT file. Done. Thirty seconds and your video has description.

With text-based description, it's easy to edit the content or the timing (not true if the description narration is mixed into the video). Plus computers can read it themselves; we don't need to hire professional voice actors to do that. This makes description affordable, easy to do for most of the videos we're using in academia, and increases the likelihood that video owners will actually do it.

But how can text-based description be delivered to users?

Continue reading

Accessibility of College Radio Stations

This post comes live from the National Student Electronic Media Convention, the annual fall convention of College Broadcasters, Inc (CBI). It's in Seattle this year, and I was invited to present on web/media accessibility along with folks from WKNC, North Carolina State University's student-run radio station. This is a very cool coincidence, since my co-presenters weren't even aware that I was once employed by NC State, and was a regular listener to WKNC in those days.

In fact, I'm a huge fan and supporter of college radio! Two of the six stations on my car radio dial are KEXP (UW) and KUGS (WWU), and before moving to Washington I was a regular listener of WKNC (as I mentioned) and before that, KJHK, "The Sound Alternative" in Lawrence, Kansas. Also, as an independent musician, the only radio stations that have ever given my music air time are college stations.

To prepare for my presentation, I thought I would do a quick informal assessment of the state of accessibility on college radio station websites. Hence, this blog post.

Continue reading