• Assessing Accessibility (Part Two in a Trilogy)

    by  • 31 January 2008 • Accessibility

    Assessing sites for accessibility is much, much easier than you think.

    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:

    • Benjamin Hawkes-Lewis

      Screen readers are tools that present a non-visual interface to applications: they aren’t web browsers any more than they’re word processors, email clients, or spreadsheet programs. It makes no more sense for a screen reader to parse a DOM than to dig into an Excel document, though in fact many screen readers are forced to query bits of the DOM via the accessibility APIs used and provided by browsers, due to the inadequacy of typical APIs to directly represent some of the subtleties of the web technology stack.

      What you’re talking about is more like a self-voicing (or self-brailling) browser that applies aural (or braille) CSS to its speech (or braille) output. Actively developed projects include the following:

      1. Opera can be turned into a self-voicing browser on Windows.

      2. Emacspeak turns Emacs and Emacs/W3 into a self-voicing environment.

      3. The Fire Vox add-on turns Firefox into a self-voicing browser.

      All three solutions support some speech CSS. None of them are widely employed by users with visual impairments.

    • James

      Ben,

      You’re right. What I really want is for people to use self-voicing (braille) browsers. (And I’d like them to pass an aural [braille] Acid2-type test.) But they don’t, as you say. So we need to assume people are using JAWS or worse.

      And in that case, I maintain a well-structured, linear HTML document with no “display” style sheet is the easiest to read.

      I do like the Opera voice capabilities. I wish more people used them.

      ~james