Joe Clark’s idea to discard the term handicapped (or any other generalized term) in favor of words or phrases that specifically target a person’s disability is really helpful. This allows us to better conceptualize the difficulties people have in accessing web content, and how as designers we can craft sites that are easier to use and understand for people who might be deaf, blind, or have impaired motor skills. (One note: Clark’s reference to the word handicap as evocative of a derogatory image is a little off the mark. See Snopes for the lowdown.) Clark offers some excellent, and realistic, advice, reminding that there are limitations to how accessible a site can be, that some sites will never be usable for portions of the population, and that we live in an imperfect world.
Playing with the screen reader at WebAIM really drove all of this home. Namely, just how important structural design and identifier tags (such as “alt” for images and “title” for links) are for people who use screen readers. Trying to navigate through strangely titled links and repeatedly encountering navigation bars and meaninglessly named image files was an exercise in patience. Thankfully, Mark Pilgrim indicates that using CSS can alleviate many of the architectural problems, so our practice this semester can be reused here using the techniques outlined at WebAIM. I can see how duplicating the main content of a page in a hidden div above all other content makes your site much more agreeable to those using screen readers—having to listen to it read through the header graphics and navigation bar on each and every page was extremely tedious. Finally, adding an accessibility statement to summarize your efforts seems an easy and immensely helpful tool.
What is nice about working toward accessibility for your website, is that it simply pushes you in the direction of better web design. Being conscious of architecture, necessary vs. superfluous content, and additional markup (like alt tags), are hallmarks of good design, but also have the added benefit of making your site useful for a wider population.
Powered by ScribeFire.
 See comments at Leisurely Historian.
Ken, were you as baffled as I about the labels used in the screen reader exercise? We frequently use these one-word labels like “history”, “contacts”, etc. and expect them to be self-explanatory. Guess what, if the audience doesn’t have the luxury of looking at and pondering all the choices, they can be confusing. It is amazing how much information we infer from context, rather than knowing for sure. When stripped of context, it really becomes a guessing game. I will be more carefull about labels in the future.
Ken,
I agree with you about the need to take all of these issues into account when we design and program a site. These readings brought an even deeper understanding of how intricate and multi-layered web programming can be if you want to try to do it right. It is a time consuming process to make an engaging and accessible site.
Listening to the screen reader read through the header graphics drove me up a wall too. I had trouble with the voice on the simulator…a little two robotic for my full comprehension. At first I wondered if the simulator had chosen the voice just because it was hard to listen to, but then recalled that the JAWS voice on a dislexic (sp?) co-workers computer sounded the same. Very frustrating. I found the stie to test the color properties of you site in Joe Clark’s essay, but I’m wondering if there is anyway to test the readability of it without downloading the screenreader software.