Coffee on the Keyboard

Assessing Accessibility (Part Two in a Trilogy)

The word “accessibility” is nebulous at best. We think of screen readers and how much they suck (and they do) and despair. But with a few simple criteria in hand, basic assessment for accessibility can be done in a little under 30 seconds, if you’re quick with the mouse.

Breaking Your Site

To develop criteria for assessment (I refuse to use the word “rubric” because I think it’s unnecessary) we need to first understand what kind of accommodations people need. I’ll focus on two modifications here that will accommodate almost everyone who needs accommodation at all: text size and colors.

The default text size in most modern browsers is “16 pixels.” (I quote this because that doesn’t make text the same size in every browser. Internet Explorer tends to be larger than Firefox, and everything changes between Windows, Apple, and Linux.) But that might be too small for any number of reasons, from visual impairment to sitting too far from the monitor to displaying pages on a large (or small) screen. While most readers will never second-guess our text size, for some there may be no choice.

Since the mid-1990s, we’ve all seen the standard web colors: #FFFFFF for background, #000000 for text, #0000FF for links, etc. These defaults can be changed in the browser, or by our style sheets. A quick look at the CSS Zen Garden shows the plethora of color schemes we’ve developed. But not all readers can read all colors. From color blind readers to visually impaired readers who need high-contrast color schemes to learning-disabled readers who may have trouble focusing on the text, you must assume that some people will turn off images or backgrounds, apply user style sheets, or simply turn your style sheets off completely.

Progressive Enhancement

What happens to your site when someone does anything like this? Do you know?

The idea is that basic content should be accessible to all browsers, regardless of capabilities or settings. If a reader has images turned off, but not style sheets—if, for example, they have severe ADHD or a slow internet connection—they should still be able to read your site. A popular bad example is the default WordPress theme, Kubrick. While it’s not unreadable to most, if you turn off images, the text has no background, leaving a low-contrast black on gray.

Go to your site and turn off images. In Firefox this is in the Options panel. What do you see?

The most common problem with changing text sizes is the way text wraps in fixed-width columns. Because of background images, or simply not knowing better, columns tend to have widths in either pixels or in percent. Go to the New York Times, hold “Ctrl” and hit the “+” twice (or hold “control” and use your mouse wheel; Mac users, it’s “command”). Already the text in the left column bleeds over and starts to obscure the next column over. Now try it on this site.

Go to your own site and try this. Do your columns scale with your text, or can you make words so big they cover up the words on the right?

Style sheets present a more difficult problem for most sites, but they really shouldn’t. Is your content in a logical order? If you strip the HTML does it still make sense? Did you use tables for non-tabular content? (Bad dog!) Did you properly nest headings?

Go to your site, and turn off your style sheet. In Firefox you can go View > Page Style > No Style. Does what’s left make sense?

Done in 30 Seconds

I use a Firefox add-on called Web Developer which adds a toolbar that makes this very fast. With it you can enable or disable images and style sheets (separately) in a matter of seconds. Combine that with “control + mouse wheel” and you can assess a site for basic accessibility in under thirty seconds.

The three tests and their three desired results:

Changing the Text Size.

The layout should scale with the text, so there are a (roughly) consistent number of characters per line in each column, regardless of text size.

Disabling Images.

Turning off images should never create low-contrast text situations or completely remove content (ie: a link that is only accessible by clicking an image).

Disabling Style Sheets.

The page should look like an outline of itself, and as an outline, it should be in a logical order. This is hard, and most sites will fail.

What About Screen Readers?

Screen readers pose an interesting problem. Without them, your site, no matter how accessible it may be, is inaccessible to a small percentage of readers. But screen readers suck.

The biggest problem with screen readers is that most use the Internet Explorer DOM (a few use the Firefox or Opera DOMs, instead) to read the page, instead of reading the source and style sheet themselves. (I know of no screen reader that does this, so if you do, please let me know.) So all that work the W3C put into to aural style sheets and screen reader support does absolutely no good whatsoever.

The best solution I have found is to pass the no-style-sheet test, and hope that (or encourage) any users with screen readers turn off style sheets. This causes the browser to render the page as close to the source as possible, so the DOM, and hence the screen reader, get the cleanest, most linear version. If source is well-constructed, you can provide a “text-only” solution without needing a second version.

Read the rest of the series:

• Universal Accessibility
• What is Universal Accessibility? (Part One in a Trilogy)
• Assessing Accessibility (Part Two in a Trilogy)
• Building Accessible Sites (Part Three in a Trilogy)

Posted in Accessibility

What is Universal Accessibility? (Part One in a Trilogy)

“Accessible,” in the provenance of the internet, usually means “screen-readable.” That is, we consider a website “accessible” if it is decently navigable by audio alone. We rarely test this, instead relying on the W3C Web Content Accessibility Guidelines (WCAG) or Section 508 of the Rehabilitation Act of 1973, a 35-year-old standard.

The Yoke of Accessibility

But we usually view these guidelines as a burden: they limit our creativity; take our most brilliant ideas and strip off the polish. Typical accessibility checks are run towards the end of the design process, and we go back and grudgingly fix the errors, unhappy but acquiescing so we get paid.

This definition of “accessible” assumes that every person is either perfectly capable, or completely blind. (Or deaf, I suppose.) In either case, we rarely assume readers will do things like change the text size or the page colors, or turn off background images or stylesheets all together. But these are all common practice for readers with a whole range of needs, from those with incomplete visual impairment to those who are easily distracted by excessive color to those who may simply like to customize things.

“Universal” has a sense of “everywhere,” and I also want to include “everyone,” and “everywhen.” (”All the time,” but that would have broken the rhythm I had going.)

Everywhen

The key to implementing “universal accessibility” is to begin at the beginning, and not finish until the end. We all know the changes we’ll have to make later, so start your design process with these in mind.

The benefit to us as designers is that our final product won’t feel like a bastardized version of our original concept. By incorporating accessibility from the beginning, we won’t feel like we had to “hack” our own design to make it work. It also saves us time in that step, when we may be too tired or too frustrated to re-implement everything accessibly.

Everywhere

Another concern of “accessibility” is the ever-increasing stable of web-capable devices. From iPods to Smartphones to Wiis, a wide range of devices with various support for standards can all access your sites. CSS supports differentiated styles, but not all devices do. Fortunately, if you’re out of other ideas, server-side solutions could ensure that broswers see the right code.

Everyone

But the real idea of “accessibility” is that everyone, regardless of ability, can access your content.

We need to widen our vision and consider all the impairments, not just blindness. It’s a simple numbers game: far more people have partial visual impairments than complete, far more people have learning or cognitive disabilities, far more access the internet from their phones. If we cater to the blind, surely we should cater to these people as well.

The Next Step

In the next article, I will talk about ways to assess a site for this “universal accessibility.” For the most part, these are simple steps that only take a few seconds to understand, and, with forethought, literally no time time to implement. They’re not perfect, or complete, but I hope to get people thinking about their own ways to build accessible sites from the ground up without sacrificing their designs and while improving their sites for everyone.

Read the rest of the series:

• Universal Accessibility
• What is Universal Accessibility? (Part One in a Trilogy)
• Assessing Accessibility (Part Two in a Trilogy)
• Building Accessible Sites (Part Three in a Trilogy)

Sorry this was so late. I’ve been busy and in the middle decided to alter the direction of the piece. Hopefully the next in the series will come sooner.

Posted in Accessibility

Universal Accessibility

Starting, hopefully, some time this week, I’ll be writing a three-part series on universal and accessible design.

The first part will focus on motivation and definition. What are the goals of web design in different contexts—commercial, educational, personal? What does “accessible” or “universal” design mean today? How can we work to ensure adequate content-delivery to all users?

With a definition in hand, the second part will try to motivate a method for assessing universal design. I won’t claim to have a formal, 6σ-type process, but rather a set of goals and the language to describe both those goals and the failures I see most commonly.

The third and final part will begin to describe ways of both fixing existing sites and building universally accessible sites from the ground up and will, again, be a set of goals and language.

I have two goals with this, primarily that most competent web designers and developers will be able to implement their own processes, or tailor their existing design and development processes, to achieve what I feel is a fundamental goal: universal access to content.

Secondarily, and more specifically, non-profit, governmental, and educational web design and development is often near non-existent, and I want to set a stage for arguing that these organisations need to take their web presence as seriously as any Fortune 500 company. They need to learn from commercial sites, who, in monetizing themselves, had a much keener motivation to improve.

My goal is to finish part one by the end of this week and have it posted, with hopefully not more than a week between posts. I make no promises—I work, same as you—but that’s the plan.

Update: Still coming! I promise, I just ran into a combination of writer’s block and work.

Read the rest of the series:

• Universal Accessibility
• What is Universal Accessibility? (Part One in a Trilogy)
• Assessing Accessibility (Part Two in a Trilogy)
• Building Accessible Sites (Part Three in a Trilogy)

Posted in Accessibility