Blog Accessibility: A Live Case Study

Blog accessibility, like web accessibility, is not an absolute, but rather a continuum. The Web Content Accessibility Guidelines 2.0 divides the guidelines into three levels – A, AA, AAA: conformance with Level A guidelines is a must for minimum accessibility; Level AA guidelines should be met; and, in an ideal world, Level AAA guidelines are met.

Admittedly, this blog about making blog accessible is less than optimally accessible. Some accessibility features – alt text for images, good colour contrast for a majority of the content, breadcrumb navigation – do already exist. Accessibility in other areas is lacking, which, as a Web Accessibility Consultant for the last twelve years, is annoying and frustrating (to say the least), and highlights the point I made previously that a blog’s accessibility is impacted by four contributors: the blogging platform, blog theme, widgets and plug-ins, and the blogger.

Making this blog as accessible as possible will be a process – one that I would like to offer as a live case study. I plan to document how I make changes within the confines of WordPress, the Headway theme, and any widgets or plug-ins I add.

The first step with any such process is to evaluate the existing state – evaluating a site for accessibility is no different. A web accessibility review involves several testing tools and evaluation methods. For simplicity’s sake for this post, I offer my “at first glance” highlights needed to further improve accessibility:

• Add “skip to main content” links to assist individuals using screen readers and those using only the keyboard to jump over the navigation bar and right to the good stuff
• Change the colour scheme of the post information (and other colour combinations) to enhance colour contrast to enhance readability.
• Move the TwitterLink Comments box to above the Submit Comment button so the order of information makes more sense, i.e. offer the submit button after the reader has entered the necessary information.
• Add a form label to the Search box for the benefit of screen reader users.
• Add a valid DOCTYPE in the code to aid browsers and assistive technologies to display the content correctly
• Add a text-to-speech feature for those individuals who benefit from the content being read aloud.
• Ensure the layout and font sizes are fluid and can be controlled by the reader.

The list will likely continue as I dive deeper into the code, add more content, and add plug-ins.

What have I missed? What would you like added or changed to further increase accessibility?