Why WAI-AAA and W3 code validation don't equal accessibility

[<Eddie>]

Despite the best efforts of the W3, HTML/XHTML validation and their Web Content Accessibility Guidelines only go so far as to technically assist accessibility devices grab a websites content and make it usable. Your website can validate, pass the highly critical Bobby test and still be of no use to someone facing geniune accessibility problems.

If following the W3 isn't enough, what more can you do?

Take a look at the often overlooked subjects below.

Semantics
This is improving of late as designers move over to CSS but it is still very common to see incorrectly nested header <H*> tags being used. Headers are very important document elements and a well structured web page should consist of one primary header <H1>, then subsequent (and correctly nested) subheaders <H2-6> as required. Aside from paragraphs, the use of lists is the most commonly addressed markup structure due to the abundance of examples on how to deliver navigation which is good news as this was probably the single biggest semantic mistake going.

Why <P> instead of <BR>? There aren't that many reasons why something should include a break. Designers use <BR> because <P> adds huge margins to things and puts the look of things out. Every time a new line is needed, use <P> and apply appropriate CSS. The best example of why <P> works over <BR> is a tool for dyslexics called Read-E. As you mouseover a particular block of text, the lovely Microsoft Sam (if using Windows of course) starts to speak out the contents for you. If you create paragraphs using <BR> then the entire page gets read out, not the selected block of text. This is extremely fustrating if you need to know a phrase within a block of text very far down a page.

If you need to emphasise a phrase, use <EM> or <STRONG> as they are logical tags. Using CSS to make them appear emphasised will not convey the correct tone or message to someone screen reading, or even a search engine for that matter.

Links should also be descriptive. If anchor text can summarise the page it points to, it makes it easier for a screen reader user to make the decision to view the page or not. You can rely on attributes within elements but always try and focus on the core value of an element first.

Document structure also extends to websites common sidebars. Sidebars usually contain links to external sites and other useful resources but should always follow content and not precede it. The only thing that precedes content is navigation. Using CSS you can make this appear as you wish but if you disable styles make sure users, screen readers and search engines don't have to wade through "get FireFox" links before getting at your content.

Colours
Contrast is the main issue. Some colours should not sit together as they just don't work. Try screen grabbing and putting the shot into Photoshop before turning it to greyscale. Is it still readable? Ask someone else what they think. Remember, colour blindness commonly causes reds and greens to be misinterpreted so always run the greyscale check to see how things fare.

Context
We all do it. How many websites bleat on about the W3 standards. Ask yourself, who is your market? Does a business know or care about the W3? As an EU contracted consultant, I see many small companies and all they care about is whether it complies with the law, will the search engines like it and how much does it all cost. Tell your market what they want to hear in their language, not yours. If you have to use buzzwords or shorthand, use the associated <ABBR> and <ACRONYM> markup correctly or if you have to, include a glossary and link to it when required.

Mobility
Leave your mouse alone and see if you can navigate your website. Use tab, space and enter while forgetting access keys. Is your site accessible this way? If not, it should be. In theory, access keys aren't needed as a properly structured site should render them redundant. The big one here is those fancy 'so-called' accessible dropdown or DHTML menus. They aren't, so leave them out if you can help it. Just because someone has no arms or cannot use a mouse for whatever reason and relies on other devices to access the web, why should they be forced to run the site without styles and script enabled? Again, a website must be keyboard controlled as accessibility devices are far better conversed with a keyboard than a mouse.

Layout
Who says accessibility is about disability? I have intermediate to expert knowledge of Windows XP, Ubuntu Linux and Mac OSX, know several application and web programming languages and have been in I.T. for 10 years and I still struggle to use some websites. Keep layouts consistent. With your website, keep logo/header at the top, follow with navigation, either on top or to the left, provide the content in the middle then offer users other resources and information on the right or bottom. Consistency is the key. Familiarity means I, even my mother, can navigate your website and find what we're after without having to 'learn' your layout.

Conclusion
All the above are highly argumentative and come from my point of view and from my experience. Every website is inaccessible by someone, there is nothing you can do about it but by taking on board the W3's accessibility initiative and being aware of what practical usability consists of, your website can become far more effective.

I'm new to these forums so I'm interested in what peoples thoughts and comments are on this matter.