Terrill Thompson | Web accessibility, music, art, life

Time 2020-10-02 15:07:20

Web Name: Terrill Thompson | Web accessibility, music, art, life

WebSite: http://terrillthompson.com

ID:67691

Keywords:

Web,Thompson,Terrill,

Description:

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 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.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.Peakware.com 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 (google.stanford.edu). 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 Amazon.com. 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, Wildernet.com. 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 Peakware.com. 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, Peakbagger.com, 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 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. 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... 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 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 Subscribe via RSSAbout Terrill Terrill Thompson is technology accessibility specialist with the University of Washington, web developer, musician, writer, outdoor adventurer, and seeker of truth.@terrillthompson Recent Posts The Power of Silence, Part 1

TAGS:Web Thompson Terrill 

<<< Thank you for your visit >>>

Hot Websites