The Power of Silence, Part 2

With only a few days remaining until Election Day in the United States, things are likely to get really loud, as if they weren't already loud enough. If you're like me, occasionally you need to turn down the volume and embrace the silence. I'm hesitant to talk or write about silence since these very words interrupt it. And I'm hesitant to read about it for the same reason. That said, I do find inspiration from others who share an appreciation for it. For example:

In One Square Inch of Silence, Gordon Hempton says "When we listen to silence, we hear not absence, but presence." I believe this wholeheartedly. When we pause all the noise that we humans are constantly making, we discover a rich spectrum of natural sounds. They were there all along, but we couldn't hear them. And when we finally hear them, it's wonderful to stop and listen.

Hempton has traveled the world seeking silent places, and has identified a particular special silent spot in the Hoh Rainforest in Olympic National Park that he's declared his "one square inch of silence." If we can preserve the silence of that tiny spot, the effect will expand outward far beyond its center. And in this era of constant human noise, there's a compelling need to preserve the few remaining silent places. On Earth Day 2005, Hempton placed a small red stone on a mossy log to mark his spot. In late September 2020, having grown increasingly weary of society's crescendo, I shouldered my backpack and hiked solo into the Hoh Rainforest on a pilgrimage to find that one square inch.

It isn't hard to find. Hempton's website includes Directions to One Square Inch (in PDF), although the published coordinates seem to be a little off. I found it at N 47.86576°, W 123.87009° (link opens in Google Maps). There is not just one red stone, but several, evidence of others who have been on this same pilgrimage. The spot is surrounded by trees — Sitka Spruce, Western Red Cedar, Douglas Fir, Western Hemlock — in various stages of life and death. The landscape is blanketed in thick moss and ferns. I sit for a while, and listen. It is very still, but not silent. The Hoh River hums softly in the distance. Flies buzz by, and tiny birds flit in the surrounding trees. A distant crow calls. An elk bugles.

A pile of small red stones on a mossy log

I take a decibel reading with my iPhone: 29 decibels average over five minutes, among my quietest readings in over three years of collecting data, though not the quietest (see below for my table of decibel readings for comparison).

I turn my attention to the Hoh River. Over the next few days I travel most of its length, from its origins at the Hoh Glacier on Mount Olympus to its terminus at the Pacific Ocean. I camp along the river bank, where historically the Hoh Tribe lived, fished, and foraged. For several days, I'm immersed in silence, which grows increasingly powerful. I take some additional decibel readings along the way, and capture a few moments from my journey on video.

I've taken some time over the last couple of weeks to fine-tune the video. All footage was captured on my iPhone, and the audio required some EQ finesse in order to filter out wind noise. I mixed the video in iMovie, and exported the audio track to Logic Pro where I adjusted volumes and EQ, then imported it back into iMovie. I also created an audio described version for people who are unable to see the video, taking care in the described version to find the right balance between being informative and respecting the silence. You can toggle between the described and non-described versions via the Description button on the media player. The media player is Able Player (it's free, open source, and the most accessible media player on the planet).

I recommend watching the video with a good pair of headphones, and the audio cranked. Silence is best appreciated when it's loud.

Continue reading

The Power of Silence, Part 1

The 2020-21 NFL season kicked off this week. I write this having just watched the Seattle Seahawks beat the Atlanta Falcons in an empty stadium. The TV broadcast included fake crowd noises that were somewhat effective for manufacturing a sense of excitement, but a little off in their cadence and authenticity.

The kickoff event of the season was earlier this week on Thursday night, when the Kansas City Chiefs played the Houston Texans in Arrowhead Stadium in KC. No fake audience track was needed for that game. Kansas City is one of only six teams in the NFL that is allowing a limited number of fans to attend their games, at least at the start of the season (the others are Cleveland, Dallas, Indianapolis, Jacksonville, and Miami).

At Kansas City, there were reportedly 17,000 people at the game, which is 22% of their 76,000-fan capacity. Despite the relatively small crowd size, they sounded incredibly loud on the TV broadcast, seemingly as loud as a fully packed stadium, and loud enough to disrupt the Texans’ offense on a few occasions. This led me to wonder: How many fans are necessary for attaining nearly maximum volume, after which adding no amount of additional fans has a significant effect?

Continue reading

Pulling the Plug on

The idea for Peakware was spawned in 1994 on the summit of Mount Elbert, the highest mountain in Colorado and the second highest in the lower 48 states. This was was my first fourteener (mountains higher than 14,000 feet), and I was hooked. I loved the physical challenge of hiking more than 10 miles and climbing nearly 4,500 vertical feet in increasingly thin air. And the view from the summit was truly awesome. The entire Western United States seemed to be spread out before and below me in all directions.

I stood on the summit, taking in the views and wondering which mountains I would climb next. On this particular trip, I knew that I'd be climbing Mount Massive (Colorado's second highest) tomorrow, and La Plata Peak (fifth highest) the day after that. But then what? How much higher could I climb with the skills I had? And what were my best options for climbing in say, Mexico? And where could I climb in Winter when most of North America's high peaks were snowed in and no longer accessible?

In Summer 1994, these were difficult questions to answer. Hundreds of guidebooks had been published covering mountain ranges all over the world, but there was no single reference tool that consolidated all their information and made it easy to search. I had the need for a tool like this, and then and there, on the summit of Mount Elbert, I decided to create this tool.

I returned to my home in Lawrence, Kansas and immediately created a database to house the information I planned to collect. Not long after, I returned to Colorado and spent two weeks in Golden at the American Alpine Club Library, collecting and entering data about the world's highest peaks. I arrived when they opened each morning, and stayed until they closed each evening. Each evening, I would grab my daypack and go for an evening hike in the surrounding mountains. After collecting the core data, I mailed letters to national parks and tourism bureaus all over the world seeking royalty-free mountain photos, and my requests were met with an overwhelming response. In early 1997, Peakware World Mountain CD was released. It included profiles of the world's most famous mountains, with maps and photos, and most importantly - a search interface that enabled users to search for peaks that met their climbing or hiking preferences. I ran ads in Backpacker and Summit magazines. And I sold a few copies.

Cover, Peakware World CD; includes instructions for installing in Windows 3.1 and Windows 95

But I had a bigger vision. Spending two weeks in the AAC Library did not make me an expert. The experts were the people around the world who lived near these mountains, or the people who had already climbed them. I needed to tap into that collective community expertise. These were the early days of the World Wide Web, and I had already been building HTML web pages and contributing to conversations that were happening within the World Wide Consortium related to web accessibility. I knew what I had to do. I needed to publish Peakware to the Web, make it freely available to everyone, and invite users to contribute their knowledge and experience. launched in June 1998. Its primary function, just like on the CD, was search. And this was three months before Larry Page and Sergey Brin launched Google on Stanford University's web servers ( Another key feature of Peakware was the ability for users to contribute content: They could add new peaks, edit data for existing peaks, submit trip reports, and upload photographs. And this was 2.5 years before Wikipedia. I earned revenue through commissions on the sale of guidebooks, initially as an affiliate of Adventurous Traveler Bookstore, and later as an affiliate of a new online bookstore called I also earned revenue by selling ad space directly to outdoor recreation companies, but this required too much time for too little return. By then Google had moved beyond search into other areas, including advertising, so I signed on early to using Google Ads for most — and eventually all — of Peakware's advertising.

Once word got out, the community of active users grew rapidly, and by 1999 there were hundreds of users, and new content was being added daily. I spent hours each day reviewing user-submitted content, fixing bugs, adding new features, and communicating by email with users. There were dedicated users throughout North America, Canada, Australia, New Zealand, and the UK, plus other users from around the world. I had particularly memorable exchanges with many users in Europe, a member of the Maasai people in Kenya about mountains in his region, and a scientist stationed in Antarctica about the high peaks there. I loved being part of this global community of people who shared a love for mountains.

But I also had a full time job, was attending graduate school at the University of Kansas, and was a new first-time father. I was so sleep deprived I could take a 5-minute power nap and have vivid dreams before my alarm dragged me back to the waking world. In December 1999, overcommitted and utterly exhausted, I exchanged emails with Marshall Hall, President of Interactive Outdoors Inc. They were a small company of avid outdoor enthusiasts in Aspen, Colorado, who — like me — had been collecting big data about outdoor recreation for their flagship website, They were impressed by the dedication of the Peakware user community, and were interested in acquiring my website. The timing was perfect, we negotiated a deal, and I bid farewell to the site I had created.

For the next 20 years, Interactive Outdoors continued to own and control We stayed in touch, and they hired me as an independent contractor to do most of the design and development work. Peakware continued to be a leading online resource for information about the world's mountains. Over the years, 10,000 users contributed content, including over 4,000 peaks, 8,000 photos, and 16,000 trip reports. Peakware became such a reputable source for mountain data that a "Peakware ID" field was added to mountain records in Wikidata, the data engine that drives Wikipedia.

But Peakware wasn't alone. Another site,, had been around about as long as Peakware had, and in fact shared a similar history to Peakware's. Both of these sites faced stiff competition from SummitPost throughout the 2000s, then from Peakery in the 2010s. Climbers were also turning to local and regional sites such as the ones I'm most familiar with in the Pacific Northwest: Cascade Climbers, The Mountaineers, and Washington Trails Association. And more recently, users have turned to dedicated mountaineering and climbing groups on Facebook and other social networking platforms.

Maintaining a popular website and keeping it relevant amid such competition is no small task. Traffic gradually decreased over the years, and advertising revenue decreased in proportion. In January 2019, Interactive Outdoors dissolved and Marshall returned Peakware to me. I kept it afloat for over a year, fixing bugs and adding features. Most notably, I did a massive data sync with Wikidata, bringing Peakware's database to 16,893 peaks, which I believe to be nearly every mountain in the world.

However, the bulk of my time in later years was consumed in seemingly endless battles with spammers. And with Google.

Continue reading

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