Mount Baker Media

Terrill Thompson's Web Site

Accessibility Features

This page describes the accessibility features of the current website. The idea is to document what I've done, and hopefully by doing so to provide an example and some useful ideas for other web designers and developers.

It all begins with structure

• I started with a bare bones XHTML template, and added the structure and content with absolutely no concern for how it would all look visually. That would come later.
• I marked up all headings using XHTML heading elements (<h1>, <h2>, and <h3>). Headings are important for a number of reasons:
  1. They clearly communicate the organization of the page to sighted users. If one heading doesn't interest you, your eyes can jump quickly to the next heading.
  2. They make navigation more efficient for everyone. Some browsers support jumping from heading to heading. Opera has had this support for a long time (using the oh-so-intuitive "S" and "W" keys). In Firefox similar functionality is attained by installing the Document Map Add-on.
  3. They make navigation much more efficient for blind users. Blind users navigate the web using either screen reader software (which reads the content of the screen audibly) or a Braille output device. Either way, their assistive technology allows them to jump through the headings on a page with a single keystroke, just like a sighted user can. Without headings, they're stuck having to read the entire page from top to bottom.

Add a dash of style

The look and feel of the site is attained entirely using cascading style sheets (CSS). There are no tables. There are no font tags. The structure and content of the document are entirely separate from the presentation. This is important for several reasons:

• It results in much cleaner code! See for yourself. The site is much easier to maintain without a bunch of bloated markup.
• It's more portable. I've developed four style sheets: one for a standard screen, one for print, one for mobile devices, and one for audio output. Designing for each of these media required no change whatsoever to the content. I just had to make a few minor changes to the CSS.
• It's easy to make huge stylistic changes with very little effort. If I want to change the margins of all paragraphs on my site, all I have to do is change one property in my CSS file. If presentation is handled within the document itself using tables or presentational elements, I would have to change every file on the site. (OK, so this isn't exactly a huge site. But the idea is valid for sites of all sizes, even those with gazillions of pages!)

Size fonts for baby boomers, and for scalability

• In my CSS, I've specified font size using em's rather than pixels or points. An "em" is the size of the letter "M" in the current font. Em's and percents are relative units of measure, as opposed to absolute units such as pixels and points. Most if not all web browsers provide a mechanism for enlarging the font size on a web page. In Firefox and Internet Explorer 7 it's Ctrl +. In Internet Explorer 6 there was no keyboard shortcut, but you could enlarge the font size by selected View > Text Size > Larger, or Largest. The problem with IE6 was that it wouldn't enlarge fonts unless they were defined using relative units. If a website uses pixels or points, the text can't be enlarged in IE6, and a lot of folks are still using that browser despite Microsoft's best efforts to get them to upgrade.
• In addition to using relative units to define font size in my CSS, I'm also using relative units to define the widths of all containers. A big problem on the web today is that designers are starting to get the message about using relative font sizes, but they're still defining the divs and other containers that comprise the page as having absolute heights and widths (using pixels or points). The reason this is a problem is that in some browsers (most notably Firefox), when the user enlarges the font, the font gets bigger but its container does not. The result is a font that's too big to fit in its allotted space, so text overlaps or disappears altogether.
• The base font size for this site is 1.1em. That's slightly larger than users' default setting in their browsers. I'm a strong believer that all websites should at a minimum use 1em for a base font. Since 1em represents the user's preference for a default font size, it seems to me that we designers should honor that, rather than trying to make our users squint. My rationale for using a slightly larger font, rather than just settling for 1em, is that I'm trying to help out users who may need a larger font size but who don't know how to change their browser's default setting. I'm sending the message "I care, and I don't want to make you squint" (I'm assuming my mom might be reading this).

Provide access to images as needed

• Not everyone can see images. Most notably this is true of blind users, but it's also true of users who have turned graphics off in their browser. Who would do such a thing? For starters, all my friends that live in the foothills of the North Cascades, where there's no such thing as broadband and graphics take forever to download. I also know anti-graphics folks who surf the web on their mobile devices. I suspect there are lots of these folks because mobile browsers make it very easy to turn off images with just one or two clicks of a stylus.
• If images are informative, their content must be communicated to people who can't see them. This is accomplished in XHTML through use of the alt attribute (e.g., alt="Mount Baker Media logo")
• If images are decorative, not informative, they should be hidden from blind users. Otherwise, these users' assistive technologies such as screen readers may read the path and filename of the image, which could possibly be informative (that's why screen readers do it), but it's more likely to be obnoxious. There are two common techniques for hiding decorative images from assistive technologies:
  1. Use a null alt attribute (i.e., alt=""). Assistive technologies will ignore any image that includes this markup.
  2. Display the image as a background image in CSS. Since the image does not contain informative content, it may be best to keep it with the presentation, rather than with the content (in the spirit of keeping presentation and content separate). This is the option that's used on the ultimate css website, csszengarden.com, and it's the option I'm using with most of the images on the current site. Some may argue that these images actually convey meaningful information, but as the artist I can assure you that all my images are intended to be pure fluff. Their sole purpose is to win favor in the eyes of all you visual people.

Maximize contrast

There's a very cool new tool called the Colour Contrast Analyzer that allows you to check the color combinations on your site. If you have insufficient color contrast, it will be harder for folks with normal vision to see your content, and may be impossible to see for users who are color blind or have other visual deficiencies. Of course, you can't get much lighter than a pure white background, so it wasn't too challenging for me to attain high color contrast with the current site.

Assure that forms are accessible

The Drop me a line form includes a number of noteworthy accessibility features:

• Each form field is explicitly associated with the label that represents it (in the XHTML code). Without this markup, assistive technologies are forced to guess which label accompanies which form field, and sometimes they get it wrong.
• The set of radio buttons use a variety of XTHML tags that are necessary for correct and meaningful access for assistive technology users. Specifically, I'm talking about the <fieldset>, <legend>, and <label> elements. Rather than explain here how this all gets orchestrated, just have a look at the source code on my form page.
• The CAPTCHA (that funky bunch of barely-decipherable characters at the bottom of the form that keeps the spam bots out) poses significant accessibility challenges. CAPTCHAs not only keep spam bots out, but they also deny access to anyone else who can't see or otherwise make sense of the distorted characters, including people who are blind, people with other visual disabilities, people with cognitive disabilities, people with dyslexia, you, and I. The solution I'm implementing is an attempt to at least eliminate one of these erroneously excluded groups - people who are blind, who I've accommodated by providing an audible option. The problem is that the audible option can't be too audible, or spam bots will be able to crack it using speech recognition. So it has to be delivered in a barely decipherable voice, or accompanied by really scarey background noises like Google uses in their audio CAPTCHAs. This is a work in progress. Stay tuned for future developments.

Promote your accomplishments! (while promoting standards)

• The icons at the bottom of each page on my website show that I've validated my site using W3C validators. The site uses valid XHTML, valid CSS, and conforms to World Wide Web Consortium (W3C) accessibility guidelines. Clicking on any of the icons will take you to the relevant W3C site for a more detailed explanation.
• Note that these icons are informative, not decorative! Therefore, I'm not displaying them as background images in CSS, I'm including them in the content of the page and have included alt attributes so that their content is accessible to users who can't see the images.