Designing for Accessibility: Conclusion

This is part 8 of a series that begins here: Designing for Accessibility.

Over the last seven posts, I presented a number of techniques that designers can use to ensure that the broadest audience can read and interact with their content, without needing to offer a separate experience to visitors with disabilities:

1. Designing for Accessibility
2. Designing for Keyboard Accessibility: Location, Location, Location
3. Designing for Keyboard Accessibility: Getting Around the Page
4. Designing for Keyboard Accessibility: Interacting with Page Elements
5. Designing for Visual Impairments
6. Designing for Hearing Impairments
7. Designing for Interactions Without JavaScript

Most of these techniques provide benefits to all users, and if called out early enough in the design phase, don’t require a lot of additional work by developers to implement. Several techniques also make content easier for search engines to index and can improve your site’s rankings in search results, which makes designing for accessibility good for search engine optimization.

A recent report on disabilities by the World Health Organization and the World Bank estimates that 1 in 7 people has some form of disability, with one-fifth of those encountering significant difficulties in daily life. The odds are high that some visitors to your web site don’t see it or interact with it in the same way you do. By designing with these users in mind, you can ensure that all visitors to your site have a great experience.

Designing for Interactions Without JavaScript

This is part 7 of a series that begins here: Designing for Accessibility.

In the previous article in this series, I talked about designing for visitors who are deaf or hearing impaired. This article will talk about how your site should behave when visitors have disabled JavaScript in their browsers.

With many modern web applications relying on JavaScript to emulate desktop applications, it’s not hard to see why some companies look at accessibility as expensive — they’re looking at Section 508 1194.22(l), which states:

When pages utilize scripting languages to display content, or to create interface elements, the information provided by the script shall be identified with functional text that can be read by assistive technology.

Many developers can’t imagine how they would provide the kind of functionality required by complex web applications without JavaScript. Companies think they have to provide an expensive separate experience that doesn’t involve JavaScript.

Earlier this year I heard accessibility expert Derek Featherstone speak, and he pointed this out: if the experience doesn’t work at all without JavaScript for users without disabilities, there’s not much to be gained by providing an alternative JavaScript-free experience for users with disabilities. Section 508 is now over 10 years old, and hasn’t kept up with the changes that have occurred since it was written.

That said, there are people (with and without disabilities) who disable JavaScript in their browsers, and there are browsers and devices (including very popular touch devices) with varying levels of support, and search engines generally don’t play well with client-side scripting. So unless you’re building a very complex web application, basic functionality should always work: visitors should be able to view your content and navigate through your pages and submit your forms.

There are several schools of thought around this, including progressive enhancement and unobtrusive JavaScript, in which the basic interactions are defined first, and JavaScript layered on afterwards to provide an enhanced experience to browsers that support it. However you want to approach it, there are a few things that you as a designer can call out in your design deliverables to encourage developers to do the right thing:

• Call out semantic structures such as links and buttons. (I can’t count the number of times I’ve seen developers use some other tag with an “onclick” event on it instead of a link.)
• Links should go to real pages, or to an anchor on a page (you can suppress it with JavaScript, but don’t prevent it without).
• Don’t disable the submit button for forms pending client-side validation of some field in the form.
• Even if you’re doing client-side validation, do server-side validation anyway.

There is also a lot to be said for designing for the simplest experience first and building on that — you may find that you don’t actually need the fancy stuff.

Up next, the conclusion of this series!

Designing for Hearing Impairments

This is part 6 of a series that begins here: Designing for Accessibility.

In the previous article in this series I talked about design considerations for visitors with visual impairments. This article will talk about designing for visitors who are deaf or have hearing impairments. Even if your site has no audio content, there are still design considerations for deaf and hearing impaired visitors.

Keep content clear and simple

For some deaf and hearing impaired people, sign language is their first language and English (or whatever language your pages are in) is their second. Sign languages have different sentence structure and syntax than spoken languages — they are not simply translations. Keeping your content as easy to read as possible will make it more accessible to these visitors, as well as other English-as-a-second-language (ESL) visitors, those with learning disabilities and cognitive impairments, and those with lower literacy levels.

• Structure content with headings to break up text and make it easier to scan.
• Avoid long, dense blocks of text.
• Use clear and simple language, and avoid jargon or slang.
• Augment complex text with pictures or illustrations that accurately convey content.

Provide audio and visual cues for important notifications

If you provide audio notifications for important changes in state, also provide a prominent visual notification for users who can’t hear the audio or who have the sound turned off.

Provide captions or transcriptions for multimedia content

This one is relatively self-explanatory, but the benefits are broad. Deaf and hearing impaired visitors will be able to understand the content, as will hearing visitors who might be reading your site from a place where they can’t play audio content. ESL visitors will be able to understand the content more easily, and non-English speaking visitors can have Google or other services translate it. The text version can also be indexed by search engines, making the content easier to find.

From a design standpoint, the design should take into account:

• how visitors will turn captions on or off
• how visitors will access the transcription, if it’s provided on a separate page

(If you’re providing content on YouTube, Google provides English-language speech recognition on videos. The transcriptions for automatic captioning generally aren’t great, but if you provide a transcript file the automatic timing feature can be helpful, and there are other tools available to help caption YouTube content from transcript files if the automatic timing doesn’t work for you. The Web Accessibility Center at Ohio State University has a great article on captioning for YouTube. If you are not using YouTube, video editing software like Camtasia and Adobe Premiere offer captioning.)

Up next in this series, one final question to consider: what is the experience when JavaScript is turned off?

Designing for Visual Impairments

This is part 5 of a series that begins here: Designing for Accessibility.

In the previous article in this series I talked about design considerations for keyboard interaction, which was the last of three articles on designing for keyboard access. The good news is that the guidelines for keyboard accessibility also benefit users who require screen reader software to access content on your web pages. In the following article, I’ll talk about additional considerations for screen reader users and other users with visual impairments.

Many people equate web accessibility with screen reader use, but there are many other types of visual impairments to consider in your design. Macular degeneration, glaucoma, cataracts and other disorders can cause blurring, loss of areas of vision, decreased contrast sensitivity, a loss of visual acuity, or gradual loss of vision. Color blindness can occur congenitally or due to trauma; and decreased color sensitivity (such as the ability to tell the difference between navy blue and brown) and contrast sensitivity simply occur naturally as people age.

What this means is that many people — more people than you probably think — don’t see your page the same way you see it. They may:

• use screen reading software such as Jaws, NVDA or VoiceOver to read the content on the screen
• use a screen magnifier (such as ZoomText or the built-in Mac OS X screen magnification software) to greatly magnify the section of the page they are reading
• use a custom style sheet to change layout or colors so it’s easier for them to read or understand content — or turn off styles altogether
• increase the base size of fonts on their computer or in their web browser
• temporarily zoom in or out using the browser zoom — if you’ve used ever your phone or a tablet device to view a web page, you’ve probably done this yourself at some point
• wear corrective lenses to help them focus
• do some combination of the above (including using a screen magnifier and a screen reader together)
• do nothing at all

Let’s look at some of the ways you can make your content available to all of these visitors.

Continue reading: Designing for Visual Impairments

Designing for Keyboard Accessibility: Interacting with Page Elements

This is part 4 of a series that begins here: Designing for Accessibility.

In the previous article in this series I talked about what keyboard users need to get around your site, and how you can design your pages to meet their needs by calling out landmark roles, semantic headings and logical content order. This article explains how to ensure that keyboard users can access interactive content on your pages.

Even the simplest web sites these days often require users to interact with the page in some way, such as entering information in a form, or hovering over or clicking an element to see more information. More complex web applications include drag and drop, scrolling using the mouse wheel, double-clicking or right-clicking — almost anything you can do with a desktop application. These are the kinds of sites that interaction designers love to work on. But they often present challenges to users with disabilities.

There is one simple goal for designing interactions: every interaction on the page — navigating, editing, posting, filtering, arranging, sorting, creating, deleting, etc. — must be available from the keyboard.

Continue reading: Designing for Keyboard Accessibility: Interacting with Page Elements

Designing for Keyboard Accessibility: Getting Around the Page

This is part 3 of a series that begins here: Designing for Accessibility.

In the previous article in this series, I talked about the importance of keyboard accessibility, what keyboard-only users need from an accessible web page, and covered how to ensure that keyboard — and other — users can determine where they are on the page . This article explores how to design for efficient, logical keyboard navigation around the page.

Most of us can visually scan a page to find content we want to interact with, then move our mouse cursor over it to activate or focus on it. For those who rely on a keyboard to navigate, it’s not always that simple.

Continue reading: Designing for Keyboard Accessibility: Getting Around the Page

Designing for Keyboard Accessibility: Location, Location, Location

This is part 2 of a series that begins here: Designing for Accessibility

In the previous article in this series, I talked about how designing for universal access up front can improve usability for all users and make it easier to develop software, and I introduced five questions for designers to ask when designing a page. The next few articles explore the first question: how does someone who is not using a pointer device interact with this page?

Why keyboard accessibility is important

The W3C WCAG 2.0 guidelines recommend that all functionality on a page be accessible [operable] from the keyboard.  Keyboard accessibility is one of the most important building blocks for universal access, as it impacts the broadest audience.

There are several reasons why a user might interact with a page using a keyboard:

• The user may have a vision impairment that prevents them from seeing a pointer on the screen.
• The user may lack the motor control required to use a pointer device.
• The user may be in an environment that isn’t conducive to using a pointer device.
• It’s often more efficient to use a keyboard than it is to use a mouse.

Interactions made available via keyboard are also available to most assistive technologies such as screen readers, alternative keyboards and voice recognition software. Users without disabilities can also benefit — such as a seniors who has difficulty maneuvering a mouse, or someone with a repetitive stress injury.

What keyboard users need

Keyboard users need to be able to:

• identify where they are on the page
• navigate efficiently around the page (and around the site)
• interact with interactive components

Provide visual feedback of the location of current focus

It’s a lot easier to find your way around a page if you can see where you are. Most browsers provide some default visual indication that an element has received focus, such as a black dotted line or a blue drop shadow. (If you’re curious about your browser’s default styles, here’s a focus test page. Tab through to see what happens.)

If web pages always used default styles, figuring out where you are wouldn’t be much of a problem. Of course, the web hasn’t looked like that since the early 1990s. Now, outlines can be lost against the background color or suppressed completely as part of the visual design. Additionally, browsers are inconsistent in how they apply styles.

Take, for example, Google, which sets outline to 0 on its search buttons. This image shows how the Google Search button is displayed when it has focus on three different browsers: Safari, Internet Explorer 8, and Firefox.

This is a simple case, and users might be able to guess where they are based on the proximity of the buttons to where they just tabbed from, but only Firefox users know for sure.

Help keyboard users identify where they are on the page by:

• applying distinct visual styles to form controls, links and other elements when they have focus
• indicating in your design deliverables that styles applied when the user hovers over an element must also be applied when the element receives keyboard focus

Don’t rely solely on changing the cursor style, as keyboard users and those accessing the page from mobile devices won’t see it.

Now that we’ve covered how keyboard users can see where they are, the next article will talk about how to get around.

Designing for Accessibility

As interaction designers on the web, we spend a lot of time looking at web sites, analyzing patterns for interaction and trends in visual design, and trying to figure out whether something is discoverable or intuitive or usable. But we take a lot for granted: that users are using a mouse or similar pointer device; that they see the content on the page and how it’s visually communicated; that they can hear audible cues; that they have images and JavaScript enabled. When we begin wireframing and prototyping and testing, we generally do so with those assumptions in mind.

The experience for users with impaired abilities is often an afterthought, in design and in development. The consequence is that accessibility is seen by development organizations as something expensive – because it is, when you have to go back and design an alternative experience, and refactor and test the code for a major feature or even a small site. But universal accessibility is possible with no technical debt for not a lot of extra effort, if attention is paid to alternative experiences up front.

This post is the first in a series about designing and developing for the web while keeping accessibility for all users in mind. Because I hope that you’ll be thinking about design before beginning development – and because it seems that there are far more resources available for accessible web development than for accessible design – I’ll start there.

Universal Design

The term “universal design” is attributed to Ron Mace, the founder and former program director for The Center of Universal Design at North Carolina State University.

Universal design is the design of products and environments to be usable by all people, to the greatest extent possible, without the need for adaptation for specialized design.

Though Mace, who died in 1998, focused on architecture and product design, his philosophy is just as applicable to software and the web. Many of the principles of universal design map to widely held usability heuristics for user interface design. Where universal design goes further, though, is its emphasis on providing an identical experience to all users to the extent that it’s possible, and only providing equivalent experience where absolutely necessary.

There are advantages to this across the board from a software development perspective. A single, universal experience means less code to write, test, maintain and document, and reduces the likelihood that future changes will get out of sync. Even if you must provide a separate, equivalent experience for some users, understanding that and designing the experience up front enables the development team to accommodate it early on.

The more you know about how different disabilities affect a user’s experience, the easier it is to incorporate that into your design. In many cases, the difference between a universally accessible design and one that isn’t, is a small detail that could have been called out in a design deliverable.

Questions for Designers

There are several questions every designer should ask themselves when designing a universally accessible experience:

1. How does someone who is not using a pointer device interact with this page (also part 2 and part 3)?
2. How does someone with a visual impairment interact with this page?
3. How does someone who has trouble hearing interact with this page?
4. How will the page work in browser with JavaScript off?

I’d also like to acknowledge that this series wouldn’t have been possible without the efforts of Sofia Celic-Li, whose presentations on keyboard and screen reader accessibility provided me with starting points for several of the articles, and whose passion for universal access kick-started this whole thing for me.

User Experience Matters: Why Wesabe Lost to Mint

From one of the Wesabe cofounders, why Wesabe lost to Mint:

Mint focused on making the user do almost no work at all, by automatically editing and categorizing their data, reducing the number of fields in their signup form, and giving them immediate gratification as soon as they possibly could; we completely sucked at all of that. Instead, I prioritized trying to build tools that would eventually help people change their financial behavior for the better, which I believed required people to more closely work with and understand their data.

I think that sums it up pretty well. When you hear people gush about Mint, they love that they can just see what they’ve spent money on and what their balances are at any given moment. Mint’s onboarding experience is a model for engaging new users right from the get go. By getting their data in the system as quickly as possible, users see value right away and are more inclined to stick around.

(I cancelled my Mint account prior to their acquisition, but it had nothing to do with their UI and everything to do with transactions missing from my accounts and failure by the support team to respond in a timely manner. Great presentation doesn’t help if the data isn’t valid and you can’t get the issue resolved.)

9 Good Documentaries on Art and Design (Available Streaming from Netflix)

I’ve been knitting a lot recently and when I knit, especially when it’s not a complex pattern, I tend to consume a lot of media. So I thought I would share a few of the documentaries on art and design that I’ve enjoyed recently on Netflix’s instant streaming, because some of you will be able to take advantage of it.

Visual Acoustics: The Modernism of Julius Schulman (2008)

Julius Schulman was a photographer known for photographing modernist architecture, including many of the Case Study Houses featured in Arts & Architecture magazine in the 1950s and 1960s. This documentary features many segments of Schulman, in his late 90s, visiting many of the houses he’s photographed over the years, chatting with the owners and talking about how he made the photographs. A great introduction to California mid-century modern architecture as well as Schulman’s work, and hell, I want his view on life if I ever get to live to his age (he died in 2009, the year the documentary was released, at the age of 98). I actually bought this on DVD, it was that good.

Between the Folds (2008)

My talent with origami pretty much ends at the paper crane. The people featured in this documentary explore it as fine art, as a technical challenge, and as a possibility for drug therapies. There are whole schools for realism and abstraction and minimalism. Really fascinating stuff, and beautiful. I might buy this one too.

In the Realms of the Unreal (2004)

Henry Darger (1892 – 1973) was institutionalized at eight in a home for “feeble minded” children, ran away to Chicago in 1909 at the age of 17, and spent the rest of his life working menial jobs. When in 1972 he was forced due to ill health to move out of the room he’d rented for 40 years, his landlords discovered his fantastical 15,000 page work In the Realms of the Unreal, along with piles of cutouts and paintings, drawings and collages around the same story: that of the seven Vivian girl princesses and their part in the daring child slave rebellion against the Glandelinians. The documentary tells part of the story through animations created from Darger’s artwork.

Art 21: Art in the 21st Century (Seasons 1-5, 2001 to 2009)

There are 20 episodes spanning five seasons in this series from PBS. Each episode is based around a single theme, and interviews four artists on their work and process around that theme. I like art but don’t know much about it, and usually my exposure to it is limited to what I see at SF MOMA or other large museums, so I’ve really enjoyed the range of works, styles and media this series has introduced to me, and the insights provided by artists into their creative processes. The Art:21 site also includes biographies and additional information about the artists.

Helvetica (2007)

A history of the ubiquitous Helvetica font featuring interviews with the often very outspoken type and graphic designers who love and hate it. Being a bit of a typography geek, I love this film. (Gary Huswit’s new film, Objectified, is also available on disc from Netflix and is also a great one for interaction designers.)

Edward Burtynsky: Manufactured Landscapes (2006)

Toronto photographer Edward Burtynsky makes stunning large-format photographs of man-made landscapes (quarries, dams, mines, garbage). This film documents a trip to China in which he photographs the largest dam in the world, huge factories, and huge piles of toxic crap pulled from discarded electronics. Disturbing and beautiful at the same time.

Rivers and Tides (2001)

Andy Goldsworthy’s work feels like the exact opposite of Burtynsky: he makes sculptures out of materials that occur in nature, often in the same environment where the materials started. It’s interesting to watch him create temporary sculptures from icicles or sticks knowing that when the temperature warms up or the tide comes in that piece is going to be destroyed, but considering that to be part of the piece. Lovely cinematography accompanied by contemplations of our relationships with places and the flow of water and life. The full documentary is also available streaming from Google Video.

Herb and Dorothy (2008)

This one starts out slow, but becomes quite endearing. It’s the story of Herb and Dorothy Vogel who managed to amass one of the most important collections of Minimalist and Conceptual art – in a one bedroom apartment in Manhattan, on their incomes as a postal service worker and a librarian. When they donated a large portion of their 4000 piece collection to the National Gallery of Art, it took five moving vans to move all the works to Washington to be indexed! Really charming.

The Cool School (2007)

The Cool School is the story of the Ferus Gallery, a contemporary gallery in Los Angeles from 1957 to 1966. Its initial focus on west coast post-war artists, who weren’t receiving any love from the New York-centric art critics, united the L.A. art scene and launched a number of artists including John Altoon, Ed Moses, Robert Irwin, and Edward Keinholz, who was also a founding member of the gallery. Good if you’re interested in the L.A. art scene, abstract expressionism, and pop art.