Beast-Blog.com
Web Excessibility

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.

Filed under Access Counts —

Bookmarking Links » del.icio.us | Digg | blogmarks | StumbleUpon | Technorati |

These posts may be related:

Keyboard Support: Mysteries Unveiled »

The Best of the Beast in 2008 »