Access All Areas

One of the happy side effects of the CSS revolution has been the new spotlight that it has given to web accessibility issues. Often designers and developers who were initially drawn to table-less layout for other reasons (i.e. speed, adaptability, philosophical reasons, etc), have become increasingly convinced of the benefits and importance of providing accessible content as they progressed.

Of course, becoming a convinced of the worth of accessibility is one thing, but developing the workaday processes that translate those principles into well-tested, working applications is quite another.

Normally when an important new browser/device appears on the scene, supporting it is not much more difficult than installing the new client and testing your work on it. At worst, you may need to scrounge an old Mac to run Safari and IE5Mac on (as we do), or perhaps a Knoppix CD for Konquerer. And even if you’re not a dedicated Opera diva, you can still easily test your pages on that browser without any outlay.

Screen reader seem to be a much more difficult prospect.

Freedom Scientific’s Jaws, which is generally acknowledged to control a majority share of the screen reader market, is a case in point.

Imagine you just got through explaining to your boss why it would be useful to have? Great! Next just explain to him/her it will cost them $US895.

And after cleaning up the coffee he just coughed and spluttered across the desk, slip in that there will also another $US120 for ‘software maintenance’.

And that’s not even the ‘Pro’ version.

But.. what about the trial version? Surely we can improvize for testing?” your boss implores. “Sure!” you reply hopefully. “The ‘trial version’ is only $39.95 for a 60-day time-limited demo…. but don’t worry, that $40 is subtracted if you purchase the full purchase” you assure him.

Your boss doesn’t look overly assured as he searches wildly for something heavy to throw at you.

Evidently it’s cheaper to be cad.

So, is Jaws an incredibly complex piece of software to build and maintain? I’m not entirely sure of the answer to that question, but I do remember my Amiga doing a pretty fair text-to-speech in about 1984. Obviously screen readers are more than a voice, but how much more?

Perhaps Freedom Scientific aren’t actually all that interested in a more accessible web. While developers continue to churn out inaccesible content, there will always be a need for a complex ‘accessifier application’ to try to make sense of it all. Alternatively, if we all built sites that were easy to use without vision, maybe much simpler (and cheaper) tools would evolve, killing Jaw’s market.

If we wanted to be petty, maybe that’s a small motivation for more accessible design in itself?

So, assuming you weren’t able to convince your boss into shelling out for Jaws, what are some of the processes you can use to make your work as accessible as possible? We’re still looking for more answers to this question ourselves, but here’s a start.

CSS layout is a nice starting point, but not really the answer. Although well-structured, semantic CSS layout tends to lend itself to more accessible design, it’s been proven many times that it’s quite possible to build a very inaccessible CSS-based site.

Testing your design in Links, Lynx or even Delorie’s Lynx Emulator is a useful method for vetting your pages. Although text browsers and screen readers are fundamentally different beasts, a text browser will allow you to get a clear stripped back view of your underlying structure, while also making any dependancies on imagery or JavaScript obvious.

Of course, evaluating your pages using the numerous online accessibility rating tools such as Webaim’s Accessibility Valet, HiSoftware’s AccMonitor Online, Watchfire’s Bobby Service and others are brilliant for targetting problem areas towards the completion of a project.

What other tricks or processes you swear by?