Avoiding Extreme Accessibility
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.
Accesskey woes
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.
Semantic tagitis
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.
In summary
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?
Tommy Olsson responds:
Posted: May 30th, 2007 at 6:06 am →
A very good write-up, Mike! As you point out, you can overdo anything. And not every site needs to be AAA-compliant.
The accesskey issue is really a user agent issue. There’s nothing wrong with the idea in the HTML specification; the problem is that most browsers use the same modifier key to active accesskeys as accelerators in the operating system. The only browser I know of that has a working solution is Opera, but even that mechanism is a bit awkward. (It does, however, provide a list of available accesskeys on a page, which solves one of the other big issues).
My main ’sin’ is that I work from the W3C specifications. I start with semantic markup in a logical source order, apply CSS to achieve styling and, when necessary, unobtrusive JavaScript for usability and performance enhancement. Progressive enhancement, in other words.
The problem with this approach is that it cannot always be implemented in IE6/Win, due to its lack of CSS2 support. I occasionally end up with designs that are highly accessible and usable in CSS2-compliant browsers, but which is rather mediocre in the one browser that 75% of the visitors use. Not the sharpest knife in the drawer, eh?
Mike Cherim responds:
Posted: May 30th, 2007 at 8:43 am →
Thanks for mentioning that, Tommy. The fact that there is no standardized implementation (not even a recommendation that I know of) regarding the use of accesskeys, they tend to be different on each and every site. This in itself is a huge barrier. Each user that needs accesskeys must figure out what they are. If they’re having a lucky day, maybe they’ll be posted on the site on some hopefully well-marked and easy-to-find back page. But if they’re not (and sometimes even if they are), the user must see it as some cruel experiment.
Yeah. Internet Explorer’s non-standardization has got to be the bane of web developers everywhere. It makes the craft far more challenging than it need be.
John Faulds responds:
Posted: May 30th, 2007 at 8:55 am →
I think accesskeys can be a usable solution if you let your users choose their own.
And on the ‘required’ field issue, I came across an interesting alternative via an article by Cameron Adams on Sitepoint today in which he suggested the asterisk be added as an image with the alt attribute of ‘required’ which would be good for both sighted and non-sighted users.
Mike Cherim responds:
Posted: May 30th, 2007 at 9:02 am →
Very true, John. I see that as the only acceptable solution in fact. Regarding the asterisk/image idea… very clever. I like that.
Dennis responds:
Posted: May 30th, 2007 at 3:40 pm →
Great article Mike. I totally agree with not doing tab index; if coded well, the flow of content (and thus links) on the page should already make sense. I’ve used AccessKeys only in a few sites (and only in conjunction with numbers), and I wonder how many people actually use them.
Also, what’s your opinion on sites that have the A+/A- buttons for resizing text? On one hand I think it’s silly; but on the other hand, browsers keep hiding that functionality…
Mike Cherim responds:
Posted: May 30th, 2007 at 4:50 pm →
Hi Dennis. The text resizing widget is something I want to explore further, in line with my mini-series on the replication of browser functions (so far I’ve done the top link and the print function). Even though I made one, my gut says it’s fluff, but I do want to explore the subject further to properly weigh both sides. The point you make about browsers hiding it a bit is a good one so stuff like that will be taken into consideration. Just like the fact that user knowledge is lacking to a degree. This last part is a such valid argument that offering text-size widgets might be seen as very beneficial.
Jermayn Parker responds:
Posted: May 30th, 2007 at 10:53 pm →
@Tommy - Do not forget that to get the website AAA accessible, it needs to have multiple translated languages…
@Dennis - Personally I think text re-sizing is a waste of time and not necessary.
Good article Mike and I agree, accessibility is just one part of a successful website, too much of it and teh website will be ruined. Just like adding too much butter, icing, sugar etc in a cake…
Tommy Olsson responds:
Posted: May 31st, 2007 at 12:39 am →
The only thing that comes close is the recommendation from the UK government:
0 Accessibility options and statement page
1 Home page
2 What’s new
3 Site map
4 Search
5 FAQ
6 Help
7 Complaints
8 Terms and conditions
9 Feedback Form
S Skip to content
This has been adopted in the Swedish guidelines for public agency websites, too.
True, if you use the strictest interpretation of checkpoint 11.3. You’d also have to provide video or an animation with a translation into sign language, and since there are national variants of that …
Nick Dunn responds:
Posted: May 31st, 2007 at 4:06 pm →
I’m embarking on several new projects and am still weighing up the options for tabindex/accesskeys and the like. It’s very easy to try to do everything and end up doing nothing well. We should take a pragmatic approach to implementing more accessible “features”, much as we do when being pragmatic about implementing with web standards etc. Thanks Mike for a timely article.
Helena Boylen responds:
Posted: June 1st, 2007 at 4:30 am →
Oh I so agree with you Mike! I saw the discussion about laying out forms and your use of line breaks (which I use too) and I was jumping up and down!
While discussion is always useful I do think that sometimes we (and by we I mean designers who try to do the “right thing” as far as semantics, accessibility etc) tear ourselves apart or throw stones at each other for the most ridiculous things.
As far as the asterisk thing goes - I gave up with it and just write “(required)” now instead - less angst all round.
Morning Brew #21 responds:
Posted: June 4th, 2007 at 7:22 am →
[…] Avoiding Extreme Accessibility - over-thinking, over-engineering, or going to extremes is rarely a good thing when acted upon. […]
steve responds:
Posted: June 4th, 2007 at 10:11 am →
DEJA VU!
had the same discussion on BrotherCake.com some months ago.
If the link’s no longer active,here are my comments then, below..
http://brothercake.com/discuss/resources/reference/hope/
Michael responds:
Posted: June 5th, 2007 at 10:10 am →
Mike,
I generally agree with your post, but would like to play devil’s advocate for a moment. Take statements like this:
“Using accesskeys, while helpful to a small subset of users, can pose serious usability problems and thus impede accessibility… Sure you may think it’s for the greater good, but in reality you might end up throwing up walls.”
And change them to read:
“Assigning the closest parking spaces at the library to handicap-only, and having to retrofit the building to accommodate ramps and elevators, while helpful to a small subset of users, can pose serious usability problems and thus impede accessibility…”
These are the very same, and valid, arguments made against making our society at large “more accessible” to that “small subset” of people for whom that is not the case. I have worked on sites used in the classroom, where it was absolutely required that things like accesskeys be used. Are these perfect solutions? Far from it. Do they, in rare cases, make the site less accessible for the larger masses? Yup. But the instance you describe (an accented character in a form) is an even smaller subset than the one for whom you would pitch accesskeys altogether.
My point is that we should be furthering accessibility by using what is available to us now, and building upon it while fostering improvements. We should not retreat from what we can do (although flawed), and wait until a standard of our liking is developed (forced upon us).
My personal solution is to put the accesskey legend right on the page itself. Either in the footer, next to the link, or in some type of visual queue in the link itself (like an underlined character). I also then offer a link to an accessibility statement with a full description. Does this cause users who are unaware of these keys from getting led astray on my site some times? Probably. Do they help those that do know about accesskeys move about my sites more easily? Absolutely. So why not educate the “unaware” about the needs of the “aware”, instead of ignoring these needs until a better solution is at hand? If we address this solution to the best of our ability, then the burden is put on the browser and OS manufacturers and standards bodies to get their house in order. If we instead retreat from accessibility, we put the burden back upon the “small subset of users” to find their own way to experience the sites we build, as they have had to do with society as a whole.
Beaconfire Wire » Blog Archive » Can A Site Be Too Accessibile? responds:
Posted: June 5th, 2007 at 10:19 am →
[…] In an interesting post, Web Designer Mike Cherim wonders what damage we can do to the accessibility of Web sites by overdoing it with accessibility features. I’ve been thinking about this myself and find that I agree with Mike when he posits that some accessibility features are either so misunderstood, poorly implemented, or unknown that they are probably best steered clear of (Access keys) or used in moderation. […]
Max Design - standards based web design, development and training » Some links for light reading (5/6/07) responds:
Posted: June 5th, 2007 at 10:20 am →
[…] Avoiding Extreme Accessibility […]
Mel Pedley responds:
Posted: June 5th, 2007 at 11:19 am →
@Dennis: I’m not sure that your analogy of equating accesskeys with wheelchair ramps quite works. Primarily because I’ve never come across a situation where a ramp created a problem due to the fact that ramps are either built with a low incline (where they are the only means of access) or are offered as an alternative to steps. One of the current issues with assigning accesskeys is that you cannot offer alternatives. So the barriers you may create could be unavoidable.
Secondly, one of the reasons why users don’t seem to avail themselves of accesskeys is because there is no real standard usage that is transportable from site to site. Having been forced to rely completely on keyboard navigation for some months a while back, just trying to remember all of the standard keyboard shortcuts plus the shortcuts for Dragon were quite enough for me. I simply didn’t have the spare energy to learn a complete set of site shortcuts which would only change when I visited the next site.
I’ve also tried the approach of visually indicating shortcuts using underlines in the hopes that this would lower the visitor’s learning curve to something far more practical. Guess what? One of the well-known screen readers stuttered over words where the first character was underlined! Talk about being between a rock and a hard place! To date, I’ve still not come across any method of visually conveying keyboard shortcuts that didn’t significantly impact upon another user group.
With regard to accented characters in forms, I have Swedish and Icelandic friends whose names contain a range of accented characters. As designers we have to think well beyond the QWERTY keyboard.
As a result and all things considered, I know avoid accesskeys completely unless I can implement a solution that allows users to set their own keyboard shortcuts. The one exception I would make you have touched upon - sites that are designed to be used in specific situation with a known user base - such as a classroom or an intranet. Because, in these circumstances, so many other factors are either known or controlled, there can be a very good argument for implementing accesskeys. But I do think that’s a very different situation from releasing a web site “into the wild”.
You have suggested that the burden should be put on the browser and OS manufacturers to get their house in order. I agree. But that burden has been there for years and we’re still only a little further from where we started with a long way to go yet. In the meantime there are users who need support now - not tomorrow or next year. User whose needs may be varied and complex and who may not fit neatly into any one disability group. Given that the needs of one group may run completely contrary to the needs of another, I’d argue that what we are doing is not retreating from what we can do but trying to reach the best possible compromise for all users.
Michal (without the 'e') responds:
Posted: June 5th, 2007 at 12:22 pm →
Isn’t it like saying that not every car needs to be safe just because some of the people drive their cards 1 mph around their houses at the middle of nowhere?
Mike Cherim responds:
Posted: June 5th, 2007 at 10:41 pm →
Truthfully Michal, I don’t know if a true AAA site is possible. But that’s okay, we instead make them as accessible as humanly possible, and hopefully don’t go overboard — for the sake of the rule book — to the point of hampering usability.
Mark Kirby responds:
Posted: June 6th, 2007 at 6:28 am →
Good article, we find many issues with our site AIDS and sexual health site avert.org. We try to please everyone but often end up in long discussions about doing things one way or another, and find we actually waste too much time. We must try and simplify things!
suraj naik responds:
Posted: June 6th, 2007 at 9:19 am →
Hi,
Kind of good article..since i am a newbie in this world of website development..But I would like to make a note her & I would suggest not to use access keys while doing website..The information overload is so much, people are rarley on a webpage for a minute or so…& so that i think this is not something very seriously taken into account.. thanks
Gill responds:
Posted: June 6th, 2007 at 12:04 pm →
Good point Mike. I think we get over keen. I stopped using accesskeys a long time ago after spending hours trying to come up with something that wouldn’t conflict with browsers. Having found a few that looked promising, I then applied those to the site wholesale, along with tabkeys for every possible use. I then trotted off to the local disabilities computer club and asked them to play with it. Lets just say it was an object lesson in not going overboard. I went home, removed the lot and then went back the following week. Success, they could all happily navigate their way round without ending up completely lost.
As for your comment about plain English….. I’ll come up with a contract and a privacy policy that cover all the bases if it kills me.
signed
the party of the first part
;-)
Web Site Design, Internet Marketing, Ecommerce - ryanj - From the Web Developer’s Wiki - Accessibility responds:
Posted: June 8th, 2007 at 3:22 pm →
[…] Avoiding Extreme Accessibility - Beast-Blog.com […]
Avoiding Extreme Accessibility | Yelotofu responds:
Posted: June 22nd, 2007 at 3:29 pm →
[…] Mike Cherim of Beast-blog.com has written a nice little article on Avoiding Extreme Accessibility. “Over-thinking, over-engineering, or going to extremes is rarely a good thing when acted upon.”—Moderation is the key. […]