Improving accessibility of this blog

I’ve been studying accessibility. After reading a whole bunch of stuff I decided I should try to make my blog as accessible as reasonably possible. This blog post chronicles some of the changes I’ve made. If this helps you enjoy my blog more, please do let me know. If I made anything worse, please also let me know 🙂

Different wordpress theme

This new theme features:

  • High-contrast design (good old black-on-white)
  • relative font sizes in CSS
  • reasonable serif font
  • clean “pure” CSS for layout
  • layout/ordering of elements of html on the page is reasonable

Different theme configuration

Some of the changes:

  • Re-ordered the widgets
  • Replaced the calendar widget with a list of archived posts
  • Added more descriptive titles to the widgets
  • Changed the custom HTML for the RSS link (relative font size, alt tag for icon)
  • Stop using drop down menus for lists of links
  • Made the blog tagline more descriptive

I also tried replacing the search widget with something more reasonable but failed to hack that up. If someone from wordpress could please make it resemble something like

<form method="get" id="search_form" action="">
        <label for="s">Search:</label><br />
        <input type="text" name="s" id="s" />
        <input type="submit" value="Go" />

that would be great. Or, if someone knows how to do an accessible search box on a blog, please let me know 🙂

Secondly, it would be nice if the theme could be modified to have “skip to content” and “skip to navigation” links, which I seem to have no way of doing myself.

Change of blog contents

Some of the changes:

  • Fixed some bits of broken HTML
  • Added reasonable (descriptive but less than 100 characters) alt tags to images
  • Replaced use of <h4> with <h3> in blog post contents (so that the header structure goes h1 – h2 – h3 properly)
  • Cleaned up the page navigation to have just Home and About pages
  • Cleaned up the About page, in particular getting rid of the strike-through links which seems to be a subtlety that is easily lost when using a screen reader

“Doing” accessibility using tools

I got rather depressed a couple of years ago with the complete lack of tool support, and basically just gave up. Recently I talked to some front-end engineers at the BBC (which cares a great deal about accessibility) who gave me some useful pointers. Tool support has now gotten a lot better. You should take a look around!

Here’s three links:

  • WebAIM WAVE, an accessibility validator. I feel this validator is much better than any of the others; for example it doesn’t accuse me of using ASCII art when it encounters a block of java code. It also doesn’t sounds like a stern kindergarten teacher or some haughty user experience expert.
  • Fangs, an easy-to-use firefox plugin to do “screen reader emulation”. Basically it processes a web page and then spits out text that is roughly what a screen reader would say.
  • WebAIM Screen reader simulator, gives you an idea of what a screen reader does, good to try if you’ve never seen an actual screen reader in action.

Dive into accessibility

If you’ve never bothered about accessibility before but you’re interested now, I suggest you start your reading with Dive into Accessibility, a free online book with lots of clear practical advice by someone that knows his stuff and actually builds websites out there in the real world. From the introduction:

Don’t panic if you are not an HTML expert. Don’t panic if the only web site you have is a personal weblog, you picked your template out of a list on your first day of blogging, and you’ve never touched it since. I am not here to tell you that you need to radically redesign your web site from scratch, rip out all your nested tables, and convert to XHTML and CSS. This is about taking what you have and making it better in small but important ways.