I work in a variety of places. I share an office with Doug at the Seattle campus of the University of Washington. I share an office with David, Carly, Stephanie, and Nigel at Western Washington University in Bellingham, with Max a short shout away. I share an office with anyone else who happens to be working at Woods Coffee on any particular day. But sometimes I just want to be alone, working in a quiet place where I can focus on the tasks at hand without distraction. Hands down, the best place to do the latter is my home office. All this week, I've had no choice but to work every day in my home office as outside my front door, I've been knee-deep in snow.
After a week of being snowed in, I'm still loving it, partly because I'm a huge fan of snow; but also because I recently upgraded my home office so it's extremely comfortable and helps me to achieve maximum work efficiency. Some of my equipment travels with me from office to office, but a few things remain at home. So when I arrive back home in my safe, warm den I can plug in my computers and continue to be productive.
Because I'm here, and because I love it, I thought I would share a bit about my setup. First, I'll describe some of the problems I was experiencing before upgrading.
This is another one of those end-of-year blog posts. As I reflect back on 2018 though, it certainly has been an extraordinary year.
I wrote this a few days ago and have been hesitant to post it. If anyone who reads this is interested in traveling to Nepal, I don't want to discourage that. Nepal is one of the poorest countries in Asia, and is populated by fascinating, diverse, kind, and beautiful people, many of whom desperately depend on tourism for their livelihood. If you're interested, I encourage you to go! However, I feel like I have an obligation to tell my story. Perhaps it will help would-be travelers to go with more realistic expectations than I had, and to be more fully prepared than I was for the challenges they may face.
The Truth About Nepal
On September 4, the New York Times published an exposé titled Near Everest’s Slopes, a Helicopter Rescue Fraud Preys on Trekkers. The article described rampant fraud in Nepal involving trekking guides, helicopter rescue services, and hospitals. I'm not surprised by this news, as I experienced hints of it myself while traveling in Nepal this year. However, my experience differed from those of others whose stories were featured in the article.
I was there in April, hiking among the world's tallest mountains. I was traveling solo on a 19-day adventure with Himalayan Glacier. Ultimately the goal was to climb Imja Tse (Island Peak), a glacier climb to 20,305 feet and a full-on view of the massive southern wall of Lhotse. When I arrived at Himalayan Glacier's office in Kathmandu, I was introduced to Bob and Beth, two other Americans who were also traveling solo with the same guide service, and with itineraries similar to mine. We each had our own guide and porter, and would travel separately, though we would frequently encounter each other on the trail. Ultimately Bob and I were to meet up at Island Peak base camp and climb Island Peak together.
Although you might think otherwise as you read the rest of this blog post, my experience in Nepal was largely positive. Step by step I absorbed the amazing beauty of the Khumbu Valley, surrounded by towering white peaks — Kusum Khangkaru, Kongde, Thamserku, Kangtega, Ama Dablam, Nuptse. We strolled through quaint mountain villages where children ran up to greet my ever-smiling Sherpa guide with a hardy hug. Sherpas in general were — as expected — always laughing and smiling and seemed to be enjoying their lives, despite having very little material wealth.
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.
In 2017, I and a small group of colleagues collaborated on a series of accessibility workshops that we delivered as pre-conference sessions at three national conferences, AHEAD, EDUCAUSE, and Accessing Higher Ground. If you were a participant in any of these workshops, you're about to receive a follow-up survey. This blog post documents my quest for an online tool for conducting the survey. My #1 criterion for choosing a tool is whether the tool generates accessible output. My #2 criterion is whether the tool is accessible to survey authors with disabilities, but I didn't specifically evaluate that for this blog post.
To keep things simple, I tested only one question type: Multiple choice with radio buttons.
The first question on my survey is this: "Where did you attend our accessibility workshop?" There are three possible answers: Accessing Higher Ground, AHEAD, and EDUCAUSE. Users are required to select one of the answers.
For this to be fully accessible to screen reader users, the following information should be communicated via their screen reader:
That the field is required
The current state of each radio button ("checked" or "not checked")
The number of options, and the user's position within those options (e.g., "2 of 3")
If I were to hand-code the survey from scratch using standard HTML markup, my code would look something like this:
Here again are the five requirements for full accessibility, with a brief explanation of how each is attained using the above markup.
1. Each answer
The label associated with each radio button (e.g., "Accessing Higher Ground") has a <label> element with a for attribute, the value of which matches the id of the radio button <input> element. This explicitly associates the label with its matching radio button. Screen readers announce the matching label when a radio button has focus, and mouse users and touch screen users can click or tap anywhere on the label to select that button (more convenient since it's a larger target than the button alone).
2. The question
Web developers often make the answers accessible, but often overlook the question. And users should never answer "Yes" if they don't know what they're agreeing to! The standard method for making the question accessible is to wrap the question in a <legend> element, then wrap that plus the group of radio buttons inside a <fieldset>. With this markup, screen readers announce both legend and label when a radio button receives focus. They differ in their implementation of this. Some screen readers announce both the legend and label for each button as the user navigates between the buttons; other screen readers announce the legend only once (when the first button in the group receives focus). They assume that's enough, and on subsequent buttons they just announce that button's label.
3. That the field is required
The required attribute was introduced in HTML5. The proper technique for using it with radio buttons is described in the HTML 5.2 spec, Example 22.
To paraphrase: It's only required on one of the radio buttons in the group, but authors are encouraged to add it to all radio buttons in the group to avoid confusion.
4. The current state
If the radio button is correctly coded as a radio button, all screen readers automatically announce whether the current radio button is "checked" or "not checked".
5. Position within the Total
If the group of radio buttons is coded correctly, all screen readers will announce something like "2 of 3". One exceptions is JAWS in Internet Explorer 11, but this is probably an IE issue, as JAWS does announce this information in Firefox (tested using JAWS 2018).
How Screen Readers Render Standard HTML
Putting all the pieces together, screen readers typically announce the following information when the first radio button in a group receives focus:
What this is, i.e., "Radio button"
The label for the button
The question (e.g., legend)
The current state ("checked" or "not checked")
Position within the total (e.g., "1 of 3")
Screen readers vary on the sequence of these items. Also, as noted above, screen readers vary on whether they continue to announce the legend for each button as the user navigates through their choices.
I created a simple survey with one required question using the following tools:
Then I tested the output with keyboard alone, NVDA 2017.4 in Firefox 57, JAWS 2018 in Firefox 57 and Internet Explorer 11, VoiceOver in Safari on MacOS Sierra, and VoiceOver in Safari on iOS 11 (using an iPhone X).
The following sections show the code generated by each of the survey tools, edited to just show the relevant markup for accessibility. All tools add a lot of extra <div> and <span> elements plus class attributes to help with styling, but these have little or no impact on accessibility and have been removed here for readability. Also, each of the tools auto-generates name and id attributes - I've edited all those so they match my original example.
Do you have control or influence over the design of one or more web pages? If so, then I encourage you to add this New Years resolution to your list: Underline your links!
Since the dawning of the Web, browsers have underlined links so users could distinguish link text from surrounding text. In fact, all major browsers still do this by default. Ever wonder why? Answer: Because it continues to be an effective way to communicate "this is a link".
Unfortunately there's been a growing trend over the last few years among web designers to remove underlines from links, relying on color alone to distinguish link text from surrounding text.