Building Accessible Sites (Part Three in a Trilogy)

![With a few key concepts in mind, building accessible websites is no different than building websites.](http://jamessocol.com/blog/images/accessicon.jpg)
So your site didn’t pass [all of the tests](http://coffeeonthekeyboard.com/assessing-accessibility-part-two-in-a-trilogy-67/ "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](http://validator.w3.org "Use the W3C Validation Services.") is the first step to making your pages look right.
Is my CSS valid?
Similarly, make sure your [CSS validates](http://jigsaw.w3.org/css-validator/ "Really, use the W3C Validation Services.") 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 `` and ``, instead use semantic tags like `` and ``. 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 `
`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](javascript:; "This isn't a real link, just a bad example."). - *Good:* If you’re curious, you may want to read our [privacy policy](javascript:; "This isn't a real link, just a good example."). - *Better:* If you’re curious, you may want to [read our privacy policy](javascript:; "This isn't a real link, just a better example.").
### 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 `em`s is also acceptable, but harder to follow.)
Are all widths and heights in `em`s?
This applies to block-level elements containing text, like `
` or `

`*. 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](http://www.kryogenix.org/code/browser/lir/ "This is a good image replacement technique."). **Do not use [Fahrner Image Replacement](http://www.stopdesign.com/articles/css/replace-text/ "Fahrner Image Replacement, which breaks screen readers.")**, 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 `

` can follow `

` but `

` can’t. (However, `

` can follow `

`, just like an outline.)

Do I only have one `

` element?

This is slightly flexible, but in general you should never have more than two `

` elements. I use `

` 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](http://coffeeonthekeyboard.com/use-semantics-to-guide-design-53/ "I’ve said before"), semantic names provide meaningful structure to code. `
` means nothing with style sheets turned off. `
` or `
`, 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: