To most web-users the very notion of somebody browsing the web with little or no visual feedback is completely alien, and for this reason website accessibility is often delivered as an afterthought or, in most cases, not at all. I don’t profess to be a guru on accessibility; there are plenty of those out there already so if that’s who you’re looking for, I’m not your guy! Accessibility does, however, fall within my remit as a web developer. As I looked further and further into the subject, I noticed that there are certain correlations between accessibility and other more well practised topics such as SEO, The user experience, and of course good, well structured HTML.
I would even go as far to say that if you are a web designer who has never really explored the area of accessibility (bar pulling out the screen reader card every time you see some filthy heathen using table layouts) then learning about accessibility will make you a better designer. You constantly hear people waxing lyrical about form following function, but in practice this can tend to go straight out of the window as soon as huge swirly flash animations or ‘outside of the box’ designs manifest themselves. To a user who can’t actually physically see your website, this isn’t going to be much good, and in that sense accessible websites become the purest form of functional design.
So we’re going to cover this topic in three parts;
In part 1 (this part), we’re going to be performing a little experiment. I will create two websites, one of which adheres to many of the well established accessibility rules, one of which breaks every single one of them.
In part 2, I will go through exactly why the bad version was so bad by detailing some of the accessibility do’s and dont’s.
In part 3, I will show you exactly how a screen reader would interpret each of the sites, which will essentially form the “Results” of the experiment. I will also talk about how this crosses over with the aforementioned good web design practices. As well as discovering that most coincide, I did disturbingly find out that sometimes the two conflict. I’ll also summarize in a conclusion.
As I wrote this, I found myself becoming angrier and angrier at every bad piece of code I forced myself to write – I began questioning why anyone would ever end up with a site so bad that it’s physically un-usable to the visually impaired. I did form some opinions on this matter as I went along, so will also be dropping these in as we go.
I want to make one small point before we begin: what you are about to read is information I have gleaned through research alone. I have no direct personal experience with visually disabled users. Hopefully my research has been successful, but the last thing I’d want to do is offend anyone so if anyone more knowledgeable than myself notices that I’ve made a major faux pax then please point it out and I will correct my error quicker than you can say “IE6 must die”.
First things first: How do the visually impaired use the internet?
With tools called Screen readers, the most popularly used of which is called Jaws (so that’s what we’re going to go with as a precedent). Essentially a site session begins with Jaws describing the site to the user (Page title first) by interrogating the HTML and interpreting it as audible speech. Jaws combines the textual content of a site with “announcements”, whereby the tool informs the user of the context as well as the content. For example, a screen reader might exclaim the following;
[List of three items] [bullet][Link]Home [bullet][Link]Contact Us [bullet][Link]Help [List end]
Where those statements in square brackets are announcements.
Visually impaired users also tend to tab through links: as they tab, the screen reader will announce the content of the link (in the above example, while tabbing through, the screen reader would declare “Home”, “Contact us” and “Help”). Jaws also provides two other tools: One of which summarizes the headers on the page, the other of which summarizes the links on the page.
One of the other accessibility features available in most modern browsers is “access keys”. Including access keys in your markup allows a visually impaired user to access links on your page through a keyboard short cut. In Firefox, this is alt-shift followed by the access key, so the following link;
<a href = “#foo” accesskey=”x”>foo</a>
would be accessed by the user pressing alt-shift-X on their keyboard. It is also worth pointing out that there are well established conventions surrounding which access keys should perform which functions. At time of writing, the UK governement defines these as follows;
- S – Skip navigation
- 1 – Home page
- 2 – What’s new
- 3 – Site map
- 4 – Search
- 5 – Frequently Asked Questions (FAQ)
- 6 – Help
- 7 – Complaints procedure
- 8 – Terms and conditions
- 9 – Feedback form
- 0 – Access key details
So through a combination of these techniques you can kind of build up a picture of how a visually impaired user might experience the internet.
You can also probably build up an understanding of how frustrating it must be to find that most of the internet doesn’t really cater for your disability.
On To The Experiment!
Picture the scene: It’s the quarterly board meeting for a small, recently formed company who sell generic products in a generic country or location. The board is made up of a handful of ex managers and sales people who have worked in the business of selling generic products their whole lives and at some point decided that they could do a better job themselves. The business has been growing steadily over the past few years, and the board are looking for their next area of growth. The board agree that the company needs a website so they can start selling their generic products online.
Now imagine that the universe splits into two parallel dimensions…
In the first dimension: The managing director assigns ownership of the website project to one of his senior managers. A reasonable budget and time-scale is established, and the company sets about researching professional web design agencies who can fulfil their vision of the “My Simple Store” website. The MD states that no expense be spared in producing a professional, future-proof website that will be accessible to any customer who wishes to purchase generic products.
In the second dimension: The managing director proudly announces that he has a fourteen year old nephew who is “pretty handy” with computers and the like. The nephew is suggested as the perfect candidate to carry forward their company’s vision and is thus installed as the chief web design consultant for “My Simple Store” (a role which he will fill on Saturdays for a moderate fee, so long as his homework is finished). Unbeknownst to the MD, his nephew has no interest in web standards or accessibility, but that doesn’t matter because the website he’s created for the crass little indie band he plays bass in looks just fine.
In the next section, we will play out the project genesis!
Beauty and the BEAST!
Okay lets abandon the multiple dimensions scenario: I think I’ve demonstrated the point I was trying to make. Due to its interpreted nature, it is very easy for someone to just hack away at some HTML until it kind of looks like they want it. I’m now going to create two very basic HTML pages: One of which adheres to accessibility best practices, the other which does the complete opposite. From now on, we’re going to respectively refer to these as the “Good version” and the “Bad version”.
So here’s the code. You’ll need to blow this image up, basically because the WordPress platform won’t let me just paste reams of HTML straight into the post. Before anyone points it out, I am fully aware of the irony surrounding the fact that what I am about to do makes this post completely inaccessible to the visually impaired 😛
You’ll notice that the “good version” includes inline styles. Rest assured, these are only included because the “accessible” part of any website does not extend beyond the semantic layer and in practice these styles would be abstracted through css. One point worth mentioning though, is that a screen reader won’t mention any element with the css property of “display:none;”, however they will mention elements with the css property “visibility:hidden”. The two are unfortunately not interchangeable: as a designer you will be aware that changing the “visibility” property of an element leaves a residual “space” where the element should have been. This, I believe, is a major failing in the current specifications: there is no single css property lets you hide an element completely from your site while at the same time making it accessible to your visually disabled users: You basically need to resort to hacks as I have whereby you position the element ten thousand pixels west of where any user can ever go. Hopefully this will be addressed in future specifications.
Anyway, the pages, when rendered, look like this;
If I’ve managed to attract the right kind of readership, the “Good version” in the above image (the one on the left, of course) should be plainly characteristic of a typical un-styled HTML page and you’ll be salivating at the possibilities available to you given half a chance to pull out your ninja CSS and Photoshop skills. The “Bad version” on the other hand, should have you foaming at the mouth and turning the air blue with obscenities.
The other thing I’d point out (and we’ll cover this a bit more in the next sections) is that, to your average suit wearing cretin, the bad version is probably “winning” in more ways than just its layout. As I’ll also go on to point out: there is almost NOTHING right with the bad version at all.
I’m going to leave you now to stew on the above. Feel free to point out the hideousness of the “bad version” by commenting below (will help me write the next article if nothing else!).
In the next part we’re going to go through exactly what is good about the good version and bad about the bad version. It’s important to point out though, that while you can easily google your way to a list of do’s and dont’s, to do so is to sterilize your design principles down to an undesirable level. W3C do have a set of guidelines called the WCAG which have been through Version 1 and are now into Version 2 but as you’d expect, the recommendations made are hotly disputed and typically have spawned many splinter groups of influential hippy types who think they know better (and maybe even do). For this reason, when mulling over the above example, bear in mind that the techniques demonstrated are based on no single authority but formed out of what I consider to be the best practices suggested by each of those I have looked into.
Anyway, ta raa until next time and please subscribe!