Monthly Archives: September 2010

And When Do I Test for Access?

Web accessibility is a fluid moving target. As new technologies are designed and developed very rarely is accessibility considered. However, if you have the right mind set accessibility does not have to be like a dog chasing its tail. I am not going to talk about the general principles of good design but more about how to incorporate those principles in an accessible way. As in any development or design, technology testing and verifying is key. My general principles when thinking of testing and verifying always focus on the end-user. The marketplace is currently flooded with both free and expensive testing tools. Every one of these tools talks about how they help you comply with one standard or another. Automated web crawling for code violations in my opinion is like having a building inspector look at a Jell-O mold of your planned construction and saying it is structurally sound. Repeatedly websites pass automated evaluation tools only to be completely unusable when the customer tries. After all how does he automated tool know that the submit button on your website is labeled house.

This brings us to the question that I wanted to focus this blog on. When and how should you perform end-user testing? Many people are under the impression that if you code to the standards and only use known to be accessible technologies if you want to bring in end-users its right at the end. My opinion is that is way too late and way too costly. What happens when you find a showstopper accessibility problem at this phase? Many times, it never gets fixed or the redesign and reimplementation is cost prohibitive.

I like to think that the accessibility testing should always be interwoven to the development process. Even before you think about how your new website should be designed step back and look at what you already have. Bring in an end-user or two and watch them go through your current site take note of where the problems are and where the good things are. Understand what you are trying to accomplish with your website and set goals for your new design. Come up with a fixed list of what tasks, information and functions visitors will have. Ask the question, why are people visiting my website? Who is visiting my website question with the advent of wireless devices how are they visiting my website question but most of all what is the most important thing you want visitors to take away from your website?

Now that all these questions and criteria have been set up it is time to bring this information to your designers. Be sure they have a good understanding of what the product is. When the web designers have a first draft and/or a wireframe, it is time for a second quick review. This review does not have to be as in-depth or as meticulous. All you are looking for at this stage is structure and semantics. If you have multiple topics, are they broken down correctly? Do they all have headings and are all those headings laid out correctly? Is there any information being presented in non-accessible means? If you are using multimedia, how do you mediate that content? You will be surprised as to how much doing a review this early on can change your thought process and final product.

Even though you should not solely depend on automated tools, they do play a vital role in the process. Any good coder can be helped and saved hours of misery by a good validator. Searching for a bug such as an incomplete tag or an incorrect punctuation mark can be like cupping water in your hand. You might get a few drops but the majority has dripped away before it reaches your mouth. Looking for problems such as these is exactly what automated tools do best. Another thing most of these tools can do quite well is give the web designer multiple perspectives of their results. Many of the accessibility automated testing tools have the ability to show you various high contrast scenarios and text only versions of your site. This takes care of the majority of the support a developer needs on a day-to-day basis.

Now we are moving closer to the end of your process. You have all your content and your layout is complete. You’re still fussing with a little bit of moving this here and putting that there. Finally, you think you are almost done. Now it is time for the true in-depth accessibility review. Bring in the tester or testers you have already used. However, now it is time to bring in users of various different skill levels and using various different methods to access your site. Provide each with a list of the different tasks and goals you set up back at the beginning of this process. Watch and observe them complete each of these. When problems are found fix and repeat.

Repeatedly it has been proven that doing these kinds of accessibility test not only improve the accessibility of your website but also improve your ability to be effective for all your customers. It may be a worn-out line but accessibility does equal usability. Much of what you have done for accessibility will always make your website more usable. The many other benefits have been spoken about 100 times before.

There is never any guarantee that any form of testing will catch any problem or any scenario. However, if you do diligence and have a wide enough scope with the willingness and openness to improve you will have a happier audience. In addition, your customers will come back for future visits. Visit the Berkeley web accessibility page and feel free to use our testing rubric as a development tool. This rubric can be used as a checklist throughout your development process to help you keep focused on some of the big accessibility roadblocks. I would like to thank the webaccess group at Berkeley for creating the rubric. We have been using it for over a year now and we have found it has made our clinics more effective and useful to the client.