Step 1 - Get used to looking at the code

If you use Dreamweaver as i do, i recommend moving into split screen mode from the start. The more you are aware of what is happening in the code area, the easier adjustments will feel at the fine tuning stages.

If you use Frontpage or other editors then the principle above applies. Still to this day many web designers are happy using notepad. What ever you do - Dont ever use Word. Yes you can make a web site - but no the code is dreadful. Almost a crime. So much so that Dreamweaver has its own command to clean up Word HTML!

It may seem very difficult initially to loose the WYSIWYG way of doing things, but try and combine the two. Use the WYSIWYG interface and then adjust the code thereafter. Having skills with HTML code is not an easy stept, especially for people who are not very comfortable with HTML. It is, however, a very important step toward Web accessibility. Proper, standards-based HTML lends itself toward accessibility. Assistive technologies rely on proper HTML more so than most Web browsers. Valid HTML has many other benefits as well, including a decreased likelihood for cross-browser differences or incompatibilities and better support for emerging technologies.

Step 2 - Get that HTML valid

To validate the accessibility of your page's HTML, use the W3C's HTML validator at w3.org. The results are often overwhelming at first. Most people are not even aware of the intricate rules and standards for HTML use. Even if you are using professional Web development software programs it is likely that your page will not validate as proper HTML when first validated. Be sure to read the explanations as to why the page does not validate as proper HTML. Learn about the common HTML mistakes and do what you can to fix them.

You may find it useful to download the lite version of CSE HTML Validator. It has no spyware and includes a spellchecker as well as an extremely powerful HTML validator. htmlvalidator.com/lite/

Creating proper HTML is a challenge, but one that every web developer should take upon him or herself. When you understand the rules of HTML, you are much more likely to choose an accessible web site service that is more usable and accessible to all.

Step 3 - Get that HTML accessible

Once you have created proper HTML within your page see (previous step 2), many of your accessibility issues will be gone, because proper HTML requires many accessibility techniques, such as alt text and summaries. The next step is to find other accessibility issues that may be present in your page. This is where automated accessibility tools come into play. It is noteworthy that aotomated accessible tools do not check all areas of a sites accessibility. There are many manual areas that will require your approval.

Below are some excellent tools we have used in making sites accessible:

WebXact http://Webxact.net/ Bobby Online Service bobby.watchfire.com/bobby/html/en/index.jsp Wave 3.5 wave.Webaim.org/wave35/index.jsp Accessibility Valet Demonstrator valet.webthing.com/access/url.html AccMonitor Online hisoftware.com/accmonitorsitetest/ Cynthia Says cynthiasays.com/fulloptions.asp TAW tawdis.net/ Torquemada Webxtutti.it/testa_en.htm see http://www.zanet.co.uk/ for full list of tools

The Wave accessibility tool is a great place to start - wave.webaim.org/. The Wave provides useful information about accessibility features and errors within your page. It is designed to facilitate the design process by adding icons to a version of your page. The icons represent structural, content, usability, or accessibility feature or problems within your content. You can easily see the exact location within your page where an error is present.

The Wave (or any other software-based validator) cannot check all accessibility issues, but it checks nearly everything that can possibly be checked in an automated process. As soon as you have fixed the errors and applicable warnings from the Wave, you may want to validate your page using other accessibility validators in the links above. This ensures nothing has been missed in the automating process.

If you need to validate or audit the accessibility of an entire site, there are many evaluation tools you can use, including HiSoftware's line of products (hisoftware.com/) or InFocus (ssbtechnologies.com/).

You have now completed some of the main challenges with the process of making accessible web sites. The next stage we will look at is Testing in a screen reader. This will enable you to get an idea of what it is really like to face your site from a visitors view point.

Step 4 - You become the user.

You have already written a valid HTML web site and have covered the neccessary changes to meet all the requirements to say "yes my site is now accessible" But the proofs in the eating of it. How does it really stand up to the tests. In fact if you were the user using a screen reader how would you really cope? Could you navigate to all areas of your site?

It is a great idea to have a copy of a screen reader available for testing. I suggest IBM HomePage Reader because it is easy to use and learn, whereas other full-featured screen readers are more expensive and have a very steep learning curve. First listen to the entire page without stopping. Did everything make sense? Did the screen reader access all of the content? Was the alternative text for images appropriate and equivalent enough to convey the content and meaning of the image? Was the reading order of the content logical?

Now try navigating the page with the screen reader. Are link labels descriptive? Were forms accessible via the keyboard? Were form labels included? If the page includes data tables, were data cells associated with headers? Did the navigation structure make sense? Was there an option to navigate within lengthy pages of content? Was content structure, such as headings and lists, correctly implemented? Was any multimedia accessible (i.e., did video have captions, audio have transcripts, Flash have an alternative, etc.)?

Another area to check is keyboard accessibility. Just access the page and make sure that you can navigate through the entire Web page using the tab key. Ensure that every link and form item is accessible and that all forms can be filled out and submitted via the keyboard. If any content is displayed based upon mouse actions, make sure the content is also available using the keyboard.

Now you have a much clearer understanding of what is really required to make a web site truly accessible to all members of the public.

Step 5 - Is Mr WCAG (Web Content Accessibility Guidelines) happy?

It is well worth bookmarking sites such as the WCAG site so that you can become familiar with the principles neede for current and future guidelines. Web Content Accessibility Guidelines. This reference document for accessibility principles and design ideas is where it all happens. Some of the strategies discussed in this document address certain Web internationalization and mobile access concerns. However, this document focuses on accessibility and does not fully address the related concerns of other W3C Activities.

The WCAG are a very complete set of accessibility guidelines. They are so complete that sometimes it is nearly impossible to comply with them. Though some of the guidelines are rather vague and some are outdated, they will give you a good idea of what it takes to be truly accessible. Manually evaluate your page against these guidelines. The WCAG guidelines are broken into three priority levels, based upon level of importance or impact on accessibility - at very least, try to meet the Priority I and Priority II guidelines. The Priority III guidelines are more of a wish list for accessibility, but contain some very important items that should be included whenever possible. The Wave toolbar can alert you of non-compliance with many of the WCAG guidelines.

Step 6 - The final judgement

If you want to know the real truth of how accessible your site is, you won't go far wrong with listening to your audience. At the end of the day its there say that dictates whether your site was accessed. So get feedback from individuals with disabilities. Most are very willing to give you feedback if it will help increase the accessibility of your content to the disability community.

Sometimes features of the site that you believed would increase accessibility end up being very confusing or inaccessible. Be willing to make changes based on user testing. Especially seek feedback on your navigation structure and use of language. These two things can pose huge accessibility barriers to a large group of individuals. As soon as their recommendations for changes have been made, have them test again and see if things are better. Encourage feedback from all of your site visitors.

Web accessibility is a continual process and one that should be evaluated often. Each time you update or change content, quickly run through the previous 5 steps. You will quickly get very good at them and eventually you will understand how to both evaluate and create accessible Web content.

see http://www.zanet.co.uk/accessible/youraccessiblesite.htm for full report