Pete Love

@ deafbowti
Your comments on the use of the word “impairment” as opposed to “disabilities” and “loss” is really interesting. I agree that the specific terms that are used to describe conditions influences people’s perception of them, and I have to say I sometimes find it hard to gauge what terms are the least problematic to use.

@ James
You say “Based on your argument, if we build a ramp beside stairs, we’ve designed the building incorrectly. Obviously this isn’t the case..”

Actually it is the case. If you build both a ramp and stairs, you are unnecessarily dividing people into groups that can use stairs and those that can’t, not to mention constructing two means to the same end, where one (the stairs) has no significant benefits to its users over the other. I’d say that was the very essence of bad design. Why not build just a ramp that everyone can use?

Actually the standards for building accessible websites have moved on since 1998. There has been continual debate around accessibility since then, and the WCAG 2 guidelines published in late 2008 are a definite step forward.

As Florent V. rightly points out, modern screen readers are quite capable of interpreting javascript. That’s not to say that there aren’t numerous challenges in writing javascript that creates UIs that screen readers can navigate with ease (and most of us get it wrong sometimes) but there is absolutely nothing inherently inaccessible about using javascript.

You’re right that the code produced by many WYSIWYG editors is semantically flawed, but these days some, such as CK Editor, are much better in this respect.

@ Florent V.
Thanks for your comments. I think you’re right – there are some WCAG 2 guidelines that benefit users with very specific conditions, and they have to be implemented consciously with those users in mind. I don’t think that this necessarily goes against the principle of ‘universal’ or ‘inclusive’ design though, as most of these guidelines can be implemented without any adverse effect on other users. A visible ‘skip navigation’ link for example is primarily of benefit to users who navigate via the keyboard rather than a mouse, but its presence on the page has no adverse effects for mouse users.

But of course, addressing all of these specific issues is time consuming, and requires considerable expertise and insight. Sometimes (in fact most times) time and budget restrictions don’t allow us to be as thorough as we’d like to be, in which case we have to be pragmatic and prioritise those condition-specific guidelines that we implement, based on our knowledge of our target audience.

@ vip_uc
Thanks for your comments. I totally agree that providing an ‘accessible’ version of a site is an indication of bad design. A properly designed site shouldn’t need an alternative version.

Regarding WAI ARIA – I think that awareness of the challenges involved in writing fully accessible javascript-based interfaces is beginning to pick up momentum. In the past I think many designers (myself included) have concentrated on the principle of progressive enhancement, believing that those users with screen readers will be experiencing the non-javascript-enhanced versions of our sites. But screen reader technology has moved on, and we must certainly consider how our javascript-enhanced interfaces will be interpreted by screen readers, not just web browsers, to ensure that the ‘enhancements’ we make aren’t actually putting up more barriers for some people.

I get what you are saying. Design sites that work well for all users without having to double up on functionality, access points etc..

I must say that your page title is severely flawed. While you may find it witty with the heading you have, it actually contradicts your article.

More work and emphasis needs to be given to the accessible website development world.

You’re right in saying good planning, structure, text-links, contrast etc… are a great way to start. But if you think that’s the end of it, try surfing the web blindfolded for a few days.