Web Excessibility

Posted June 12th, 2008 by Mike Cherim

They say too much of a good thing isn’t all that good. It’s true, and this fact remains as the statement is applied to web development. Especially when it’s applied to the web accessibility branch. Let’s explore this. Web accessibility is a good thing, right? You bet it is, from its benefits to myriad users to its benefits to the site in the area of search engine indexing. It’s win-win all the way. But before jumping in and going wild with its application and adherence on your next project, making sure your site is accessible to the nth degree and all that, it can be overdone.

How Things Go Bad

A web site is inherently accessible to all manner of user agents if the content is marked up with the proper elements, used semantically — and with the proper attributes — thoughtfully, and with basic usability and readability in mind. Yet, sites somehow become inaccessible. The majority, of course, simply use the various elements improperly — common oversights ranging from not using headings to laying out jumbled content with tables, and all manner of little things in between. There is potential to wreak havoc on a site’s inherent accessibility at every turn.

But this article isn’t about those sites. It really applies to the sites that are properly built, the ones made by developers who are trying to get it right, for whatever reason. It’s because they can still get it wrong. Inadvertently a site can easily be overdone.

A Layer of Accessibility

Scripted behaviors, styles, and images are layers, but accessibility is not. Accessibility is integral to every part of a site. It’s omnipresent. Accessibility is in the content, the markup used as I mentioned, it’s in the dependence on and application of scripting, styles, and images. All along the way, as a quality site is developed/designed, tough questions will have to be honestly answered:

  • Can the site still serve its purpose and offer content and functionality if the user lacks JavaScript support or plugins like Flash?
  • If page styles are added, will the site’s pages make sense or will it make some content inaccessibly hidden, difficult to read, or disorganized?
  • If a user — who may be on a dial-up connection, or may be blind, or may be a robot — doesn’t support images (visually, that is), can they still access the site’s content and navigate?

Affirmative answers to these questions don’t guarantee a site is accessible to all, but nothing does. When developers start thinking of accessibility as an add-on, though, they run the risk doing things that may diminish the user experience, confuse or clutter the site, or mask an underlying issue. For an example of the latter, visualize a site with a text-resize widget whose text cannot be resized with one browser — Internet Explorer (IE) — sans-widget, or cannot be resized more than the meager bumps provided by the widget without breaking or becoming an illegible, overflowing mess.

Developers can accentuate or enhance their sites, adding function and beauty, the message herein isn’t to the contrary. Moreover, usability/accessibility enhancement should be considered, such as addressing default browser styles. For example, many focusable elements (a, pre, input, etc.) should be accentuated by adding a more significant :focus pseudo element (:active in IE, and for links only) in the style sheet — since most graphical browsers don’t do well in this area with their difficult-to-see dotted outlines. It’s beneficial to also provide a few well placed navigational helpers such as jump links and breadcrumbs. And more! But scripts, styles, and images, and everything for that matter, must be implemented very carefully, with each treated as a progressive enhancement.

Good Intentions Gone Bad

Here are some other things, attributes if you want to be technical, that sometimes resemble poorly applied layers. One and all are meant to improve a site’s accessibility or somehow enhance it. For the sake of brevity, here are just three examples. Remember, there is potential to wreak havoc on a site’s inherent accessibility at every turn.

Bad Alt Text

Envision a company tasked with making their site more accessible. Almost invariably, one of the first things considered is the use of alt text. I’ve heard stories, some firsthand. It’s yet another example of the layer mentality at work. “What can we add?” they ask. And off they go. Someone, staff or design firm, is instructed to add alt text to the site’s embedded images. Unfortunately this sometimes leads to useless alt text like “Logo,” “Photo of Tree,” or, worse still, on multiple levels, “Spacer.” And this sort of act of wanton accessibility will have a negative impact by making the page more verbose to some users, without benefit of added meaning or function.

Embedded images need to be assessed, and meaning and function, if any, must be considered. The contextual relationship and readability must also be taken into consideration. If it sounds out of place if you read it aloud as ordered, maybe it is out of place. This doesn’t mean you have to move the image. Describing it within the text, naturally, might serve just as well. It is an option, just as is leaving the attribute’s value null: alt="".

Bad Accesskeys

Alt text isn’t the only accessibility coating applied to sites. Another that comes to mind is the accesskey attribute applied to links. It’s a nice idea, but for anyone who might not fully understand the implications of its use, they will probably end up applying logical assignments like Alt+H for Home. Others will understand that using letters will virtually guarantee operating system or user agent conflicts. They may try to get it right by using numbers only. Unfortunately, numbers can be problematic as well — such as when a form user tries to create a special character in his or her name and gets whisked away to some other page. It’s happened!

The best way to add accesskeys is to use a script that lets users set their own assignments. Of course this means supplying a form, giving them a cookie, teaching visitors what accesskeys are (my guess is most users don’t know), and supporting it all. Doing it this way, while it is the best method, may be overkill. I think the best approach is to just not offer them at all. If you really want to support those who might need them, offer a clear, concise, and consistent navigation, headings, a site map, and jump links instead. Make it easy to get around!

Bad Tab Indexes

The use of the tabindex attribute is another potentially problematic addition. Often bringing more harm than good to a site. I wrote that this is potentially problematic because the attribute does have value in rare circumstances (such as improperly fixing a broken page or manipulating a form), but the natural ordering of a quality web page is usually quite adequate, and in the interest of accessibility, it’s better. The natural order is what the user expects and user expectations have considerable bearing on what should and shouldn’t be done.

A word to the wise: Unless there is a very compelling reason to set tab indexing, don’t. Not only does it variate pages, you may encounter what could be a considerable amount of work if you find you need to insert something into the manipulated page flow.

Being Overly Helpful

They say that you can’t please all the people all the time. This, too, is a true statement. I want to add to it, though: Trying harder won’t help much. The best way to apply accessibility to a site is to first understand how other users will interact with the site and what their limitations are, then focus on the possible consequences the additions and changes you actually want and need to apply may carry, correcting what you can or finding alternatives along the way. Plan it out if you can. As I wrote, there is no guarantee of accessibility to all. It is impossible, in fact. But in trying to make it so, especially without the proper understanding, things can go awry and the situation may worsen.

A web site should be easy to use, intuitive, and shouldn’t need to be supported too heavily by the developer and his or her widgets and site add-ons. Accessibility should be passive, there when needed by those who need it. On-demand. It’s very much like usability in this regard. Remembering that can aid implementation of everything else that will get added on, thrown in, or changed on a well-structured and natively accessible site.

Making sure a site is accessible is not about making the blind see, or the deaf hear, giving an amputee limbs, or raising the arms of a paraplegic. It’s not about matching the user experience to that of the fully enabled with the works, it’s about meeting the needs of as many people as possible, and not doing so at the expense of another person or group’s own positive user experience. Everyone who can use a site should be able to enjoy it in their own way, with a minimal number of obstacles.

They also say that sometimes less is more. This is true as well. Run with it.

Article Notes: I had written an article similar to this before called Site Features Overload. As such, I probably wouldn’t have published this article here had it not already been written. Much to my surprise (shock if you will) I was contacted by some fellow with the initials JZ and asked to write an article for A List Apart (ALA). I “write well and with passion” I was told. Since I had once had an article for that site rejected (now posted at Accessites), I asked if a particular subject was requested. None was, I had creative license. I wrote about accessibility as I did last time. This article was also rejected so now it’s here. The reason for both rejections was that ALA readers already know about accessibility. I maintain that some do and many do not. I felt it was worthy of that site, but since it wasn’t, maybe it’ll be useful to someone here.

18 Responses to: “Web Excessibility”

  1. John Faulds responds:
    Posted: June 12th, 2008 at 8:41 pm

    Wow, you got contaced by Jay-Z? ;)

  2. Dan Schulz responds:
    Posted: June 13th, 2008 at 3:05 am

    Is it just me or am I the only one other than Mike who’s surprised this got rejected by ALA?

  3. Andrew Green responds:
    Posted: June 13th, 2008 at 5:25 am

    It’s not just you, Dan. Had they said “ALA readers know about CSS” they’d have had a point…

  4. Anthony Brewitt responds:
    Posted: June 13th, 2008 at 6:02 am

    I think this is a very good read with a very important message. Your blog has re-energized my enthusiasm for accessibility once again, I got lost for a while and just needed to make ends meet and so sometimes projects come along where making everything accessible wasn’t a priority and my paid time was better spent pleasing the users with good usability and Javascript features than worry about accessibility.

    I have know found a good balance and build in accessibility into my projects from the start and upfront I explain to the prospective client why accessibility can help them reach a larger audience, rank better with search engines and also as I’m in the UK; adhere to the DDA act, I don’t use scare tactics but if you point out that they could be sued, the accessibility message gets across.

  5. Federico Zoufaly responds:
    Posted: June 13th, 2008 at 1:06 pm

    It is clear to me that trying to make a site pass an accessibility test for the sake of it is not the right way to approach the accessibility needs.
    In my opinion, the first step is to make the site web standards compliant.
    Web standards are good discipline and they have a lot of interesting “side effects”, one of them being putting the site on a path towards accessibility.
    In addition to make a site is standards compliant you should then really make sure you are using the right devices to communicate your content to the broadest possible audience.
    I recently came up with an interesting Accessibility Check List on and added some additional comments on my blog at: . I think you mind find them helpful if you are interested in the accessibility topic.

  6. Federico Zoufaly responds:
    Posted: June 13th, 2008 at 3:04 pm

    Yes it is. Thank you, I probably made a mistake with the hyperlink….

  7. Georg responds:
    Posted: June 14th, 2008 at 6:37 am

    This article definitely should have been made available to the ALA audience.

    I adhere to a minimalistic approach that your article fits right into.
    My own “accessibility statement” is a bit site oriented, but describes how I deal with the issue for all my web oriented work. Less definitely is more for most people, in most cases.

  8. JackP responds:
    Posted: June 14th, 2008 at 6:40 am

    You might also want to look at the RNIB’s section Too Much Accessibility which looks at where good accessibility intentions have gone wrong…

  9. Blair Millen responds:
    Posted: June 14th, 2008 at 8:05 am

    Good article which I’d say should be essential reading for anyone interested in web accessibility. To state that ALA readers are familiar with this is a major oversight on their part. You know, I have a funny feeling that many ALA readers may have heard of accessibility but most aren’t actually interested in putting it into practise… lazy?

  10. Dominykas responds:
    Posted: June 17th, 2008 at 6:05 pm

    I’m not surprised by this article at all. I’m an ALA reader, and I know about accessibility. Yet it is much apreciated, since I can link to it and make sure others, who don’t know, read it. It is very strange of ALA to give that as a rejection reason. Do they not care about their “new” subscribers? The ones who haven’t read much before, but have the brains to understand that ALA is not a pile of crap? Internet is growing exponentially (still), and so is the readership of any website and “creatorship” of web based services. There’s a lot of people who do not know about accessibility. Not in the way it’s outlined in this article. What I mean to say is “thanks, good job”.

  11. Dave responds:
    Posted: June 23rd, 2008 at 9:49 am

    I like what you said about alt tags, especially listing “Photo of Tree” as a bad example. We’ve got lots of smiling faces on an education-related site I’m working on now, and it finally just clicked that there’s probably not any benefit from putting lots of tags like: alt=”Students using a computer”.

    alt=”" for the win, unless there’s actually some information being conveyed.

  12. Steve Firth responds:
    Posted: August 25th, 2008 at 9:21 am

    I think the ‘best intentions’ feel of this is particularly valid, I’ve been into the accessible side of things driven by a sense of fair play but in doing so I feel (early on) I had overkilled and/or used needless features.

    Accesskeys I felt initially could be really handy, then I started looking at conflicts etc and decided they might actually be counter productive. I have one on my skip to content anchor but thats all.

    Besides I cant see how some of the keyboard combinations required could be accessible anyway … shift+esc+s?

    I’m a nimble fingered gamer and I find that kinda clunky someone with an impairment (or even little hands) would struggle.

  13. Steve B responds:
    Posted: September 6th, 2008 at 4:47 pm

    I used to reference ALA quite often to many developer/designer friends and colleagues who came to me for accessibility advise and testing. I haven’t done so in quite some time. It’s nice to hear that all of their site visitors already know about accessibility and that they no longer need to inform/instruct accessibility.
    Now, they are truly A list “Apart”.

  14. SEO Results responds:
    Posted: September 12th, 2008 at 12:01 pm

    Well written post with great pointers, web accessibility can be very difficult to achieve with all the constraints of clients.

  15. Wendy Ballard responds:
    Posted: October 3rd, 2008 at 9:13 am

    I am an ALA reader who knows a bit about accessibility but I still wanted to read Mike’s post when I noticed it on the rss feed. It is a shame the article was not what ALA thought it’s readers needed to learn about.
    Life is one long learning curve. Live long, learn much and share what you know. Thanks Mike for sharing you wisdom.

Sorry. Comments are closed.

Note: This is the end of the usable page. The image(s) below are preloaded for performance only.