3 August 2008
The most commonly made mistakes of inaccessible web sites
Using tables to organise visual content
On a technical level, this is the most common, entry-level mistake and the first thing I look for when I am assessing sites for accessibility. Once and for all, let’s get this clear: tables are for representing data in a tabular form, not for controlling layouts.
Many years ago, when the web was young, many sites used tables to organise their visual designs because they are convenient and flexible mechanism. However, the demands of the accessibility agenda have rendered this practice an absolute no-no. Learn how to use DIV tags to control your page layouts instead.
Including styling information in your mark-up
Best practice dictates that HTML should be used to define the structure of your content, while any visual implementation should take place in a physically separate CSS file. It makes absolute sense from a development point of view: creating genuine separation between content and design makes sites easier to maintain.
Providing Multi-media without any alternatives
Movies and animation look great on websites, but they fall a bit flat if you happen to be blind. Likewise sound presentations and the deaf. If you are trying to get across anything remotely important
Badly-written or irrelevant content
It’s not just the technical issues that make a difference – the posture of your site is an important consideration. You need to ensure that the language that you use on a site is clear, direct and relevant. The most beautifully put-together site can be rendered inaccessible by poor copy-writing and confused instructions.
Over-estimating your audience’s technology
There are often some pretty grand assumptions made about the capability of browsers and internet connections. For example, Adobe may estimate Flash penetration at around 98% of all browsers, but according to my corporate web stats, more than 11% of our users either have an old version of Flash or no Flash at all. This is a lot of people to potentially leave out in the cold.
True measures of browser capabilities are difficult to come by as they will tend to vary given the different audiences each website attracts. It’s always best to assume to worst and provide alternatives for people who are labouring under old equipment, poor download speeds, and dated software.
Only developing for one browser
I’ve always been an Internet Explorer man, but I do recognise the existence of other browsers. The exact take-up of Firefox is hard to measure – as with any technology the level will vary depending on the nature of your site’s audience. Bloggers I know with large audiences report a 40% Firefox uptake, while my corporate data suggests something closer to 15% on half a million unique visitors.
Whatever the true uptake of different browsers, there are a myriad of subtle differences in rendering between them. Some of these differences can turn a carefully laid-out masterpiece on one browser into garbage on another. Learning to appreciate the differences between browsers and testing for them is key.
Oh, and make sure you always test on a Mac.
No wider appreciate of your audience
Accessibility isn’t just about meeting the priorities of the WAI checklist – you genuinely need to understand why you are making websites accessible as well as how it helps people to use them.
I first gained an appreciation of accessibility issues many years ago by downloading JAWS and using some of our web software with it. Apart from being the single most annoying piece of software I have ever used, JAWS was also one of the most instructive: a badly laid-out, inaccessible web site is impossible to navigate using assistive technology such as screen readers. Screen readers describe a web page, often in quite excruciating detail, and if your pages are not laid out in properly structured HTML, then screen reader users will be lost in a haze of misleading descriptions.
Accessibility isn’t just about people with disabilities. You also have to cater for people with poor internet connections, so keep an eye on bandwidth usage and make it as lightweight as you can. There are, believe it or not, still a small but significant population using 800×600 monitors, as well as computers that haven’t seen an upgrade in a generation and don’t even have speakers attached to them.
Any developer should try using their sites from the other side of the fence so to speak. Download a screen reader, use a modem, dig out an old monitor and turn down the sound. It can be quite an eye-opener.
Filed under Web accessibility.