As UX designers, we know that user testing plays an integral role in ensuring that a website makes sense. But how does that process change when the user can’t see the site you’re testing — or see at all? A recent trip to the Perkins School for the Blind in Watertown shed light on the unique user experience challenges that exist when a user must rely on assistive technology to navigate a web page. If you care about good UX, there’s no excuse to skip this kind of testing for your website or application.
Let’s say you’re a business owner. In order to keep your business afloat, you’d like to maximize your audience—you don’t want to exclude anyone without damn good reason. Imagine a restaurateur refusing service to customers who were born on a weekend or a ticket box office cutting off sales before the show sells out. This may seem like Business 101, but in the Wild West of the World Wide Web, it’s all too easy to deliver a subpar (or worse, unusable) experience to people who want to engage with you.
According to research estimates from the Arlene R. Gordon Institute, nearly 40 million people worldwide are blind, while more than 285 million experience significant visual impairment. That can amount to a sizable portion of any website’s audience, but many sites simply aren’t easy to use by the blind and vision impaired. Much of this can be attributed to a lack of awareness; according to a January 2014 WebAIM survey, nearly 40% of respondents listed a lack of awareness of web accessibility as the primary driver behind developers not creating accessible experiences. Other factors included a general lack of accessibility knowledge, budgetary concerns, and a fear that making a site accessible would hinder the overall look and feel of a site.
One of the easiest ways to become more “aware” of web accessibility is to test on actual sight-impaired users. While it may require slightly more time and resources than a typical user test, the results can be stunning—even a bit uncomfortable. Recently, Fresh Tilled Soil worked with Perkins to see how our client’s current site would hold up against the screen reading and magnification technology typically utilized by those at the school. It wasn’t pretty.
Testing at Perkins
One of our testing subjects, Joann Becker, is a technical support specialist at Perkins. She is blind in both eyes and tested the site using the screen reader Job Access With Speech (commonly referred to as JAWS), the most widely used product on desktops and laptops. Screen readers like JAWS can be used for both web surfing and basic desktop navigation. They work by reading aloud the words on the page (sometimes with lightning-fast diction, depending on the user’s preference) and, in the case of a website, rely on the underlying HTML to help explain the page’s content and hierarchy. This is where proper labeling (via more descriptive “alt” attributes for images, semantic document structure, and ARIA landmarks, to name a few methods) becomes paramount. If, for example, a heading isn’t labeled in the code, it often won’t be read the to user, severely hindering the experience right from the start.
As someone who occasionally struggles to remember to include something as simple as alt attributes in my code, watching Joann attempt to deal with the site’s various accessibility shortcomings firsthand left a major impression. Even though it wasn’t my site she was using, this was a real person having real issues. To our client’s credit, they cringed too when they saw the footage.
The tasks asked of Joann didn’t differ much from our normal user testing script. For certain tasks where the relevant pages were well formed and accessible, she took no longer to accomplish the task than did our sighted users. However, on several tasks she found herself frozen out completely due to poor web accessibility practices in the underlying code. For instance, she had difficulty advancing past the first question because the screen reader “wasn’t talking to her.”
Because many links were not labeled (relying entirely on iconography to convey the meaning to sighted users), Joann also found herself repeatedly diverted to a top navigation bar, far away from the content she was trying to access. JAWS utilizes “quick keys” to let users swiftly cycle through landmarks such as “banner,” “main,” or “navigation,” or a list of links on a page. However, when she tabbed through a certain page, JAWS helpfully read out “unlabeled button five” and “unlabeled button two.” When she couldn’t navigate out of a language selection box that inadvertently translated the page into Estonian, we decided to move on.
While this was only a single instance, the test represented a microcosm of the current state of accessibility on the web. Despite enormous cosmetic gains due to new WebKit additions, parallax scrolling, CSS3 animations and the like, many websites still lag behind on the accessibility front. However, the clean HTML and dedication to semantics that have made progressive enhancement an important and enduring best practice can provide an enjoyable experience for all users regardless of their devices, browsers, or capabilities.
- Utilizing headers correctly: <h1> for main content or page title, <h2> for major section headers, <h3> for subheadings
- Using the <label> element on forms
- Making all content accessible via keyboard
- Creating significant contrast between text and background for users with partial blindness who use screen magnification software like MAGic
- Descriptive “alt” attributes for all media and adding empty alt attributes for pictures that screen readers should ignore
- Adding a “Skip to main content” link at the beginning of each page to avoid superfluous navigation
- Utilizing landmark roles to complement HTML5 elements that may not yet be supported by assistive technology, such as “complementary” for an aside or “navigation” for a nav
These additions are painless to implement and should become commonplace as awareness increases, resulting in a more accessible web experience for all.
*Source: Don’t Make Me Think by Steve Krug