Mad Web Skills

Accessibility shouldn't cost a lot of money if your website is built with accessibility in mind from the beginning.

I was recently asked to evaluate a product called BrowseAloud in the interest of improving a website’s accessibility. This is a browser plugin which aims to help those people who have difficulty seeing the screen, maybe through old age or those with lower literacy or dyslexia who might find it helpful to hear rather than read the words on the page. It basically functions as a screen reader, but will only operate within the browser on websites who have subscribed to the BrowseAloud service.

My first reaction was to point out that many users who require this sort of accommodation would usually already have software installed on their computer to help them. Most operating systems have Text-to-Speech and screen-reading (available in Windows since XP by pressing the Windows Key + U), screen region enlargement and visual contrast functionality built into them and most web browsers have text resizing/zoom functionality available.

In addition to these tools already available, we invest a great deal of time and effort ensuring that the websites we build meet all mandatory (and many optional) accessibility guidelines and regulations, and take a long-term view to ensure that accessibility for all is maintained.

Having said that, I can see how this sort of technology would be useful. The main problem I have with this particular product is that it is something that actively must be downloaded and installed by the user in order to be available. Many people with text access issues are particularly unlikely to be able/willing to download and install anything additional to their computers. A competitor to this product, Talklets, seems like a slightly better solution as it does not require anything special to be installed apart from the Flash Plugin (which is almost as ubiquitous as the web browser itself.)

I’m personally also not a fan of BrowseAloud’s business model. Their plugin requires no changes to be made to a website or software to be purchased or installed. Paying them an annual fee simply adds your website to a white-list of sites that their plugin will work with. There’s no reason why BrowseAloud couldn’t work with ALL websites, but they cripple the plugin until you pay them what could be an expensive annual cost. (Granted, I don’t know exactly how much it costs, but from what I’ve read from others, it’s not cheap.) I would probably prefer them to sell the un-crippled plugin to the public for a nominal fee, or at least offer that as an option. I guess it’s easier for them to target enterprise organisations such as government and educational sites, mainly because traditionally they are the types to throw lots of money at a perceived problem.

The Opera browser, available free of charge, also has in-built speech capability which can assist with reading web page content. There are also free extensions to Firefox such as FireVox which adds web-page reading to the browser. While I’m not sure how effective these tools are in the real world, I would much prefer to use an accessibility page of a website to point users to these resources that will help them with ALL websites.

In summary, there are a lot of options for accessibility these days. Accessibility should mostly be built in to the website by following W3C standards for development and accessibility. Additional tools can be used to ensure that as many people as possible can access the content of the site, but I believe these users should get themselves a solution that works on ALL sites, not just on some that have been “enabled”. Otherwise, all you’re doing is setting up a nice walled garden for them, and as soon as you need to link out to an external site or whatever, you’re leaving them stranded. “Give a man a fish…”, etcetera.

For those who haven’t been following the recent drama regarding the proposed web standards behaviour in IE8, here’s a re-cap:

• Microsoft announces that IE8 can render the ACID2 test perfectly in IE8. Web devs get excited.
• In the name of “not breaking the web” (read: “not pissing off corporate clients that have spent many thousands of dollars on Microsoft CMS, Sharepoint, .NET controls and other web interfaces”) Microsoft announce a version targeting mechanism that allows web pages to be rendered using the IE version of choice. So far so good, however, by default, IE8 will render nearly all web pages exactly the same as if it were IE7. Standards-savvy developers would have to opt-in to IE8’s standards rendering engine.
• The web development community splits into two; those that believe the default behaviour is wrong and goes against the very nature of building valid, forwards-compatible websites; and those who believe it is in the best interest of the internets, protecting Microsoft’s partners who use thier dodgy web technologies and the vast majority of web designers who still use invalid markup, spacer gifs, layout tables and blink tags.

Now, I fit somewhere in the middle. I believed the default behaviour is wrong, but honestly thought it was not big deal. I understood that Microsoft was protecting their own interests. We’ve been accomodating IE since the dawn of time, so why stop now.

Anyway, none of that matters any more.

In Microsoft’s Interoperability Principles and IE8 on the IEBlog, IE General Manager Dean Hachamovitch has announced:

In light of the Interoperability Principles, as well as feedback from the community, we’re choosing differently. Now, IE8 will show pages requesting “Standards” mode in IE8’s Standards mode. Developers who want their pages shown using IE8’s “IE7 Standards mode” will need to request that explicitly (using the http header/meta tag approach described here).

I actually thought it was kind of silly that folks like Jeremy Keith were jumping up and down about the default behaviour, like they actually thought it was going to do anything about the situation. Trying to pressure Microsoft into doing anything would be like trying to convince an elephant to walk through a doorway. It just doesnt fit.

So, colour me flabbergasted. Kudos to Jeremy and others like him for championing for the cause rather than (like myself) be prepared to just grin and bear it. Also big snaps for Microsoft and the IE Team for actually listening to the developer community and making the right decision.