Reading Blog 7 (History 697): Maximizing Accessibility for All Comers

The readings for this week — from Joe Clark’s “How Do Disabled People Use Computers” to WebAim’s 10 accessibility tips to Mark Pilgrim’s “Dive into Accessibility” — all brought to the fore for me the importance of taking deliberate steps to make our historically focused Web sites accessible to all comers.  Joe Clark helped set the stage by defining the operative terms inherent in discussing various disabilities, and Mark Pilgrim’s personalized vignettes drove the nature of those disabilities home for me. But of the various disabilities discussed,  I was most struck by the remarkable challenges faced by blind people. During Clio-Wired I last semester, I sat next to a fellow PhD student who is blind, Andrew Salamone, and learned from him the obstacles he faced in making sense of online visualizations. His struggles with several of the digital tools we used further highlighted the significant challenges he and other visually impaired Web users face each day.  Although Andrew was able to do nearly all of the work in Clio-Wired I quite well, to include making effective use of several visually based digital tools such as Voyant, I witnessed his frustration at not being able to make sense of other tools that could have been accessible  if certain digital guideposts had been in place to help him . Those types of digital guideposts became much clearer to me after reading through “Dive into Accessibility,” WebAim’s 10 accessibility tips, and Paul Ryan Bohman’s unique CSS code that hides HTML needed for blind people from the visual users of the Web site.  In effect, they amounted to a word-based “breadcrumb trail” within and among the HTML that turned visualizations into word pictures for the blind.

After reading these various pieces, I opened the draft version of my Final Project Web site for Clio-Wired II and began examining my HTML code for ways to enhance accessibility for blind people. Bohman’s hidden HTML coding was a bit more involved than my novice coding skills permitted, so I went straight for WebAim’s 10 accessibility tips and began evaluating my site against those guidelines. A few of them did not apply, but I seized on three that I worked into my site immediately: adding captions to all images, adding basic landmarks, and making the title page into an “<h1>.”  First, I ensured that all of the images I used (mostly magazine or newspaper cover images from World War II publications) had a clear title and date so that a visually impaired user would know what I had placed alongside my text. What proved infeasible, though, was a lengthy word description of each image, which would have significantly altered the site’s visual and design impact. Next, I ensured that my main page began with an <h1> header and then cascaded downward with <h2> headers and so on. These headers would make clear the structure of the main page and each subsequent page to someone who had to navigate the site based on these guideposts. Lastly, I ensured that my navigation, body, and paragraph sections were all clearly marked  so that they fell under the appropriate headers. For the most part,  I simply needed to “clean up” and organize my HTML  and CSS code carefully and then validate it for errors. Lastly, I  reviewed my changes against WebAim’s 10 tips and felt satisfied that I had made some decent progress toward making my site reasonably accessible for visually impaired users.

After uploading my changes to my online Web page, I evaluated the site’s accessibility by plugging my URL into WebAim’s WAVE Web Accessibility Evaluation Tool (http://wave.webaim.org). The results were much better than I expected. For example, on my main (home) page, I had only three errors on a red alert bar, primarily because my alternative text for each of the page’s three images was insufficient.  Clearly, my captions were not suitable; but, if I expanded the captions’ text significantly in the HTML, I would alter the visual design of my page. In this case, Bohman’s hidden HTML would likely come in handy, so I will explore that possibility in greater detail later. I received one “green” feature (a kudo!) for having clearly labeled my navigation bar, but I also received one “yellow” alert for each of my navigation links, because my HTML mentions each one twice in the code. That redundancy might be useful to a visually impaired user, so I decided to leave it in place.  I also received one “blue” (or positive) alert on each of my headings (<h1>, etc.) for having identified each one clearly and making the structure clear. The last alert was a “red” word-bubble icon that, when clicked, told me that I had not identified the site’s language (English, French, etc.).  First, I need to figure out how to do it. More to follow!

Overall, the few simple adjustments I made to my code actually made my site reasonably accessible to someone who is visually impaired.  Naturally, my site does not use complicated logos or visualizations, and those areas (like my cover images) need the greatest attention.  My charter for the near future is to figure out how to “crack that code” (no pun intended!) and make my project site as accessible as possible.

Steve Rusiecki

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>