...And why you'll never pass them with a perfect score.
I'll warn you now, this is a lengthy article, but for good reason - I've tried to make this as easy to understand both in terms of how this stuff works, and why its developed the way it has.
So how do you if your site has accessibility design problems in the first place?
Reading the Web Content Accessibility Guidelines documentation (WCAG) developed by the World Wide Web Consortium (W3C) would take too much time and probably not help you alot because it gets so technical.
You could get some great help from someone who uses assistive technology, but they couldn't tell you what part of the web page code was causing problems they are running in to - they could only tell you that something sounds weird, or doesn't work the way they expect it to (important to know still though, but still hard for you to track down the source).
You need to make use of the FREE and automated compliance checking tools out there on the web. These checkers scan your page line by line and identify the problem areas. They produce a report telling you where those problems are and they do it in a matter of a few seconds!
But wait - two things you need to understand before you move ahead. Your website, basically, is made of two main parts.
1. The content itself, your text, your images and so on (which written within HTML code).
2. The formatting of that content (which is handled by a code called CSS, or Cascading style sheets).
Why is it 2 parts like that? Years ago HTML was used to both hold your content and to format its appearance. But the W3C got smart! They realized if you wanted to change one aspect of your design (like changing all your titles from the colour red to the colour green) you would have to edit every single instance of that title on every page on your site. Very time consuming. The development of CSS was to let you tag your text with a style name. Now your titles are wrapped in a code that says it's a title. So instead of having to edit every page, you edit one peice, your CSS code, for the style called "Title", and that change is reflected instantly on every single page of your website where the style "Title" is used. If you have ever used the Styles formatting in MS Word, this is exactly the same idea.
About Accessibility Levels
There are 3 priority levels of accessibility standards. Each higher level defines increasingly more specific structural design that is supposed to reflect a better accomodation of needs for persons using assistive technology. This is a very cursory explanation of them.
Meeting level 1 A Web content developer must satisfy this checkpoint. Otherwise, one or more groups will find it impossible to access information in the document. Satisfying this checkpoint is a basic requirement for some groups to be able to use Web documents. For example, your fonts may be defined in rigid terms (i.e.: as 12 point Arial). This means the site visitor cannot over-ride your text size with one they prefer to make it easier for them to read your site.
Meeting level 2 A Web content developer should satisfy this checkpoint. Otherwise, one or more groups will find it difficult to access information in the document. Satisfying this checkpoint will remove significant barriers to accessing Web documents.
Meeting level 3, A Web content developer may address this checkpoint. Otherwise, one or more groups will find it somewhat difficult to access information in the document. Satisfying this checkpoint will improve access to Web documents. In theory, your page should be user friendly for just about anyone using any assistive technology.
The Validators!
http://webxact.watchfire.com
WatchFire WebXACT is a very intenstive scanner. It reports not only on your page's ability to meet all 3 priority levels of the WCAG, but also informs you if you have other basic errors in your page. For example, broken links, missing page titles, missing anchors. When you get to webxact, just enter the URL address of the page you want to scan. A progress bar will show that it's working away, and then you'll get a report on the status of that page you scanned. Click the report tabs to see the details. Within it you can even see the specific HTML code that webxact says is not compliant, and find suggestions on how to fix it.
http://jigsaw.w3.org/css-validator
The address here looks odd, but its the World Wide Web Consortium's (W3C) validator service for checking the Cascading Style Sheet (CSS) of your site. This is not as big a player in the overall accessibility check, but if you have errors in your CSS, it can mean your pages are not displaying text, colours and other formatting exactly as you want them to be.
http://validator.w3.org
This second W3C validator checks the HTML of your page to make sure it too is correctly formed. This is the content of your page itself. If you have incorrect code in your HTML you could be causing confusion to visitors of your site by having things such as duplicate named form fields, left-open structure codes (remember that <B> marker mentioned above? If it's not closed with a </B> everything after that opening B gets displayed as bold text).
Why You Won't Pass the Accessibility Checkers
Just to be clear - you SHOULD always be able to pass the CSS and HTML validators. Those are tests of the basic structure of your page.
But the automated tools that examine your page for accessibility features just can't truly understand what you are trying to present.
You get two types of status for your page.
1. Fails. Something is quite wrong and your design has something that the checker feels is a complete contradiction to the rules.
2. Warnings. Something might be wrong - the checker cannot be sure because it doesn't understand the purpose of the content in question, or if you have an alternate method in place on the page to resolve this potential problem. You will never escape warnings.
Example of a Fail - table Summary text.
See, years ago when the web first took shape, web designers fell in love with using tables as a page structuring tool. If you use MS Word or Word Perfect, you might already have a feel for where this is coming from. Tables on the web allow us to put things pretty much where we want them. This site uses tables to create the two columns on each side where the menus go, and the center space for the article text. Probably 90% of the web uses tables for their display structure.
While you can use CSS to create your layout structure, this aspect of CSS is still problematic and needs further rule development. Part of the problem is that different browsers (i.e.: Internet Explorer, Netscape, BeOpera) do not display CSS layout rules in the same way (yes, that means they're not being nice about following the rules of the W3C). So as a result, alot of designers find that trying to create layouts using only CSS just won't produce a user-friendly environment for the designer, or for those people who would come after them to do further editing (such as people using Macromedia Contribute to do simple page updates). So we use tables.
And so this is one spot where the checkers fail you. For level 3 compliance with the WCAG rules, the Accessibility checking software expects that every table on your site has a Summary description text for it. But this isn't practical for tables that are used strictly for structure layout. If designers add summary descriptions to their structural tables, the visitor using assistive technology gets a boat load of unneccesary information read to them about "This table is used to form 3 columns for the site design". A single page could contain dozen tables nested within each other as a means of structural management! Im fact, this page has 5 on it, so only meets up to level 2 compliance.
Example of Warnings...
Roll-over images are very common as buttons for visitors to click on to get to the different parts of your website. These will always produce warning messages in your reports because the checker doesn't know why you have a roll-over image. The warning will read "If an image conveys important information provide that in alternative text format."
You'll also get warnings about any use of colour.
"Check that the foreground and background colors contrast sufficiently with each other."
And you'll even get warnings about what your text says.
"Use the simplest and most straightforward language that is possible."
Summary
The web has become very segmented when it comes to design. Do you design your site to work best with Internet Exporer version 6.0? If you do you could be preventing those who use Netscape or BeOpera from being able to access your site.
Do you focus on just a single medium of output (computer screens)? If you do, you cut out the opportunity for people using PDA's such as BlackBerry devices to use your site - one more audicen gone.
And finally the web has begun to address an audience that has long been left behind - persons using assistive technology.
It sounds impossible at first, but it can be done! People are doing it! And if you don't incorporate a design that meets the needs of this audience, you're losing important customers. John or Jane Doe may have a visual limitation, but you can bet that they share their opinions on products and services with others just like you do. If they can't use your site effectively, thats negative word of mouth for your business. But more importantly, wouldn't you like to know you are serving everyone equally?
- Paul D.