Coffee on the Keyboard

Building Accessible Sites (Part Three in a Trilogy)

So your site didn’t pass all of the tests. How do you fix it? Or better, how do you build a new site that will pass the tests and meet accessibility requirements, like WCAG and Section 508?

Start with these checklists, geared towards passing the tests in part two. Then end with one of the free, online accessibility validators (about which I’ll write soon).

Starting Points

These should really be true for any web site, but are particularly important for sites that need to be accessible.

Is my (X)HTML valid?

Maintaining valid code is the first step to making your pages look right.

Is my CSS valid?

Similarly, make sure your CSS validates to ensure everything looks how you want it.

Do I maintain separation of presentation and content?

Keep all style information in external style sheets. Do not use deprecated tags, like <b> and <i>, instead use semantic tags like <em> and <strong>. Avoid style attributes, instead using id or class and keeping the styles where they belong: in a style sheet.

Do I avoid layout tables?

Tables are for tabular content. Use them for presenting data, never for layout. It’s wrong, it’s not easier, it creates huge code overhead, and layout tables are almost impossible to make accessible. Use <div>s and float directives, instead.

Do I use meaningful link text?

Never use click here as link text. Obviously we’re going to click: it’s a link, that’s just what you do. Consider these two examples:

• Bad: To read our privacy policy, click here.
• Good: If you’re curious, you may want to read our privacy policy.
• Better: If you’re curious, you may want to read our privacy policy.

Changing the Text Size.

To ensure your layout scales with the text, try to answer “yes” to these questions:

Are all my text sizes in percents?

By making sure all font-size settings are in percent (ie: font-size: 120%). This makes the relative text sizes the same, regardless of base size. (Using ems is also acceptable, but harder to follow.)

Are all widths and heights in ems?

This applies to block-level elements containing text, like <div> or <p>*. Heights may also be in percent. Remember that the average width of one letter is 0.5em, and that 45 to 80 characters per line is considered readable, and 66 is considered standard. That means main text content should be between 22.5em and 40em wide.

*: Images tags have their own height and width attributes, which must be in pixels. This is an acceptable exception. As you change the font-size, the text may not flow perfectly around images which remain fixed. Accept it.

Disabling Images.

Disabling images should never remove content or create low-contrast situations.

Do all sections with a background-image also have a background-color?

If you have a background image behind your text, make sure the container also has a background color that is the same as the main color of the image. For example, if you have a gray page background with black text, and your content div has a white background image, it should also have a white background color.

Is all my content available as text?

Make sure you provide meaningful alt tags to your images and embeds. Some of the best advice I ever got was “if the picture isn’t worth describing well, why is it there at all?” (alt tags are required, anyway. The important part here is being meaningful.)

If you absolutely must replace text with an image—for example in a logo—implement a CSS image replacement technique. Do not use Fahrner Image Replacement, or FIR, which is incompatible with most screen readers.

Disabling Style Sheets.

This is the hard part. While it’s relatively easy to properly structure new pages, it can be very difficult to go back and restructure old one, especially if you were bad and used layout tables.

When creating a new site, start with the content. When I start a new design, I always* lay out the content in outline order before I even begin to consider the layout.

*: Ok, that’s a lie. People don’t always give you the content at the beginning. They should, but they don’t.

Did I properly nest headings?

Heading order should descend properly, like an outline. So <h2> can follow <h1> but <h3> can’t. (However, <h2> can follow <h3>, just like an outline.)

Do I only have one <h1> element?

This is slightly flexible, but in general you should never have more than two <h1> elements. I use <h1> for the site or page title, and only once on a page.

Did I create an outline before creating a layout?

If your outline doesn’t make sense, your layout won’t make sense. This is true for all users. But in particular, without style sheets, your outline is your only page structure.

Do I use semantic names?

As I’ve said before, semantic names provide meaningful structure to code. <div id="right_column"> means nothing with style sheets turned off. <div id="content"> or <div id="user_info">, however, are still meaningful. Semantic names help you organize your content for all users, and this organization is, again, particularly important without style sheets.

Validate It.

This checklist is pretty short, but it would have been much longer if I hadn’t worked so hard on it.

By answering “yes” to all the questions on this checklist, you should be in a position to easily pass any of these validators. I’m not promising: your site may have other issues that I don’t address here. But with this starting point, it should only take a few minutes to fix any problems that arise with the validators.

Just click on through to any of these, which can help you validate your site.

• Web Accessibility Test at Tawdis.net. Pretty good, but no Section 508.
• CynthiaSays. Lists all the checkpoints but doesn’t actually check many of them.
• WAVE from WebAIM. Very pretty, does a decent job, but doesn’t list checkpoints or tell you which standards it uses.
• Functional Accessibility Evaluator from the University of Illinois, Urbana-Champaign. Pretty good, but lists their own checkpoints instead of the standard ones.

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

Bobby Offline

Bobby Offline

Bobby, the standard for checking web site accessibility since 1996, is no longer “publicly available” from IBM.

The Center for Applied Special Technology, or CAST, sold Bobby to Watchfire in 2002 where it was renamed WebXACT. Watchfire is, now at least, an IBM subsidiary. And now IBM has made WebXACT, né Bobby, part of its “enterprise platform,” striking a crucial blow against making the web accessible.

You can read their explanation for yourself.

There are alternatives, but none work as well as Bobby did.

TAW’s Web Accessibility Test is good, very good, but it lacks Section 508 support. For non-governmental projects, this is probably fine, since WCAG is a stricter standard, but for government work, it’s nice to be able to say you verified the Section 508 guidelines.

CynthiaSays is out of date (its list of browsers stops at the 6.0 series and doesn’t include Firefox) and doesn’t actually check much, though it will give you a list of things to check yourself.

Wave, from WebAIM, presents a much prettier interface, but it doesn’t give you a list of criteria and tell you how you fared, and doesn’t tell you which standards it uses.

And of course, all of these lack the “Bobby Approved” badge that had become so meaningful.

Posted in Accessibility

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