Over-thinking, over-engineering, or going to extremes is rarely a good thing when acted upon.
I’ve seen it before, I’ll see it again, and I’ve been guilty of it myself. What is it? Extreme Accessibility, of course. But what is it really? What is Extreme Accessibility? And why should one want to avoid it? It sounds like a good thing after all. But it’s really the abuse of features, faulty or overboard implementations, and good intentions gone bad. Sometime in your life, did someone ever tell you that moderation is the key? This logic applies to web accessibility as well.
Moderation is the key
Diet, exercise, alcohol use… the above-heading applies to them all. It means that there is a good side and not-so-good side to each, but going too far towards any one side isn’t wise. Diet is a great example. Eating a sensible, well-balanced diet is probably best, but going to the extreme in any direction will probably carry some unwanted side-effects. Fat, for instance, is a dietary requirement, but too much will make you, well, fat. Web accessibility “features” are no exception — there is a such thing as too much accessibility, to the point of degrading the very thing you’re trying to improve. Now let me get more specific.
Dumbing it down
Write your content for your core audience. Be sure it’s clear and concise, written well and done so properly. But don’t dumb it down in the name of web accessibility. You may very well lose or insult some of your visitors, enabled or disabled alike. Write as you speak, and speak to communicate, not to condescend.
And when it concerns the user interface, make it simple, intuitive if possible, and rich enough to serve the user without going overboard. Think usability to avoid putting up barriers to accessibility. Think progressive enhancement, not a featureless domain. Make it smart, not stupid.
Using accesskeys, while helpful to a small subset of users, can pose serious usability problems and thus impede accessibility. The seasoned accessibilista might employ them carefully sticking to numbers to ensure their accesskeys don’t conflict with a shared function by the user agent or operating system. But even this is flawed. A form user, for example, may try to type an accented character (part of a foreign name perhaps), so they will start with alt+0 to begin the character and end up on another page by the inadvertent activation of an accesskey. It can happen. I’ve seen it.
So what’s the moral here? Accesskeys are supposed to enhance accessibility, yet they can cause problems. What’s this mean to a web developer trying to make an extremely accessible web site? Did they succeed? I don’t think so. In this case I won’t say use accesskeys in moderation; instead I’ll suggest not using them at all. The moderation here involves not the level of implementation, but rather moderating the breadth of features added to the site. Sure you may think it’s for the greater good, but in reality you might end up throwing up walls.
Tabindex faux pas
I made a web site once that was loaded with tabindex attributes. Why? Well, I was trying to dot every “i” and cross every “t” in accessibility. What I ended up doing, however, was making a usability disaster. I went completely overboard. It is that experience, if fact, that prompted me to write this article. I was trying to do a good thing and I ended up with very unnatural pages. The tab order was artificial and it showed. I had really ruined the usability and thus threw up a barrier to accessibility. (See how those two are intertwined?)
I should have left well enough alone, and that’s my advice to you. If you want to add them to forms that’s okay, but try to have a purpose in mind, then test it well to make sure you’ve done good by your actions.
Zoom in your face
I’ve seen some pretty eye-popping zoom layouts before, but fortunately they were user-selectable layouts. They were added to the sites as user features. And this type of bright, high-contrast styling will serve some users very well. But this doesn’t mean that type of page should be delivered to everyone on load for the sake of extreme accessibility. Instead a nicely styled page should be presented with text that is neither too small or too big. And the contrast should be reasonable as well: not too stark, not too subdued. Offering a page too “accessible” looking might not serve you well. Moderation is the key.
If you’re concerned you will have numerous visitors in need of high contrast zoom layouts and you don’t want them to pass you over unable to locate such a thing, just make the link or input to change style sheets “zoom” style so those who need it will see it. Taking it any further might be too extreme.
Instructions for instructions
As I wrote previously, the user interface should be simple and intuitive. If you have a site with instructions everywhere, and instructions for using the instructions, with a set of instructions explaining how to use the instructions for understanding the instructions, you must face facts, you did something seriously wrong.
We want to make things simple, and where we can’t we want to provide the information needed to make the feature or function usable, but anything beyond this level of instruction needs to be revisited.
Recent discussions on the Web Standards Group and GAWDS mailing lists have prompted me to consider this. One of the several relevant topics touched on how best to apply an “required field” asterisk to a form. Simple enough, right? But upon exploring this topic we discovered many possible ways of getting this done. The range went from simply adding the word required to the label and ditching the asterisk altogether, to using the abbreviation element to identify the symbol’s meaning. Some of the proposed solutions were quite involved. All shared common ground in that we were looking for a semantic solution so as to attain the highest level of accessibility. Truth is, though, some of the ideas may have been a bit extreme, but without extreme benefits to match.
Another discussion involved laying out a form on a page. Some felt more semantic value could be obtained if inputs and their associated mark-up were organized in a definition list (I didn’t agree). Truth is, though, this could be another example of an extreme approach. Forms have their own family of elements that, when used properly, make a form as a whole an accessible structure, with out added mark-up or an inability to style. Reaching for a definition list might have been an extreme measure, one that wouldn’t really improve the accessibility or usability of the form, just make it more complex. And a complex solution for a simple form just doesn’t sound right.
I see this sort of thing a lot. The question is posed: “How can this be made more accessible, more semantic, leaner, and better than before?” Sometimes the best solutions are the simple ones we’ve lived with all along. Sometimes the before is better than the after.
Over-thinking, over-engineering, or going to extremes is rarely a good thing when acted upon. Don’t stop thinking about off-the-wall solutions, though. This type of thinking has long been a source of inspiration and innovation, and some great web accessibility methods have been developed as a result, but use care in the implementation part of it. Moderation.
So what examples can you come up with? Have you ever tried to implement something that looked good on paper, only to realize that in practice that you had gone off the edge? Ever gone to extremes?