I am still working on reinstating my rss feeds from the Great Reimaging Event of 2007, and today I added back 456bereastreet.com. I quickly fell into reading “adding vs. removing accessibility“, which in turn lead me to Jeremy Keith’s article on “the language of accessibility“.

I had the chance to see Keith speak at @media last June, and I was quite impressed with his ability to make topics palatable for the layperson. This article did not disappoint!

I had actually been speaking earlier today about my love for languages and linguistics and how I feel they contribute to my work in the technology field, and how that relates to my work on accessibility. It’s all about communication. These articles fell directly in line with what was on my mind.

Keith mentions the translation for the concept of “accessibility” into German - it roughly means “barrier-free”. Certainly, the concept is similar, but there is one stark difference. Something that is moderately accessible is still accessible, whereas if something has but one barrier, it is NOT barrier-free. It is a matter of a definition being positive or negative. This is something I have been trying to communicate when I’ve been talking to folks at work about assessing our products for accessibility (specifically Section 508 compliance). It can be easy to look at a site and say it is not compliant (one instance of missing alt text can do that), but it is more difficult to positively affirm its status.

The articles speak of simple sites (when coded semantically) being accessible, but how layers of complexity may render it less so. It made me think back to my work with Maxim, when we had a focus on accessible sites. At the time, we took that to mean “build sites that work on Lynx, with few graphics and little interaction”. Pretty boring stuff, but we met our goals at the time.

Now, we want to figure out how to build the latest and greatest site, but we have to ensure we are not losing anything in the process. I have seen a movement away from using standard HTML elements for the sake of visual style or ‘neat-o effects’, but in the end, I think we have to remember that we are working within the web medium, and not foresake that. The built in controls are there for a reason. This is not to say we can’t extend that, but we should leverage what the platform offers us, rather than reinventing the wheel.

A specific example I have in mind is the use of images of checkboxes rather than checkboxes themselves. The checkbox is a standard form control with specific behaviour. We should capitalize on the familiarity of the element, rather than obscuring it with site-specific behaviour that will require the user to re-learn something.

Wow, talk about a tangent….. that’s what happens when wordpress eats your post and you’re forced to start anew. The first post was succinct. In trying to recreate, I wandered… apologies, all! Basically the idea was that we need not lose site of the purpose of our field: to ensure our users can get the service they desire. While we can add to make that experience more enjoyable for some, we must not do it at the expense of others.

“One person’s preference is another person’s real need. It may be that a group of users finds it easier with Ajax, but if another group of users finds it completely impossible then you’re cutting people out, and you’re doing it for basically nothing.

“I think of it as a hierarchy, basically, where accessibility is the most important thing, and usability comes next, and preference and design and aesthetics comes next. All of those things are important, but if one affects the other then you have to think which is the most important.

“And to my mind, accessibility is always the most important, because accessibility impacts on what people really need. Everything else is just preference.” - James Edwards (co-author of “The Javascript Anthology: 101 Essential Tips, Tricks and Hacks)