It’s now available: Part 4 of the New Accessibility Guidelines series at Practical eCommerce. Part IV: Robustness.

Wouldn’t have thought I had that much to say on the subject of being robust, but there you have it. Enjoy!

President Barack Obama’s approach to information transparency is admirable. His connection to the public through the major media channels of the digital age: the White House web site, Facebook, Twitter, YouTube, and other social media methods is impressive. It’s a great way for the public to keep up to date on the activities of their government.

Unfortunately, the accessibility level of these web resources is — all in all — not really up to the levels one would hope for.

Obviously, the government has no control over the accessibility of the external resources they’re using to help promote their agenda and communicate with the public. These social media sharing sites are what they are, and regardless of their independent accessibility levels, I agree with the administrations choice to use them — to connect with their strong user bases — rather than attempt to build an expensive and potentially abandoned project to imitate the functionality.

However, the government does have direct and complete control over their own web presences, and would truly have wished to see a more thorough approach to web accessibility from the extensive network of new information-bearing web sites created by the Obama administration.

Read more: Obama’s Web Transparency: not for everybody.

Another new article at Practical eCommerce: New Accessibility Guidelines Part III: Understandability.

It’s exactly what it says on the cover: a discussion of the “Understandable” guideline from the four principles laid out in WCAG 2.

Enjoy!

The worst thing I can say about John Rhodes is that the writing coming from his usability blog has been alarmingly infrequent in the last couple of years. 13 posts in the last 12 months just doesn’t really cut it!

Thankfully, the reason for his blogging silence is pretty straightforward: he’s been writing a book. Sweet!

The book is entitled “Selling Usability,” which is a bit of a misnomer, since the subject of the book is perhaps more accurately described as “Making Usability Happen, Despite the Regrettable Lack of Understanding on the Part of Your Managers.” To be fair, that would be a pretty unusable title.

It’s clear within the first 20 pages that John and I share a core philosophy concerning the application of usability: as much as you’d like people to buy in to the core ideals of user experience, you need them to buy in to making the change. By hook or by crook, making the change is what needs to happen in the end.

You can only teach those who are willing to learn; but you can guide anybody to the right decision if you use the arguments they understand and care about.

Selling Usability: User Experience Infiltration Tactics is a guide to convincing decision-makers towards user-experience focused decisions by using business-focused arguments and tactics.

“Selling Usability” is about communicating effectively.

John’s writing is frank and clear. He writes in a casually persuasive voice which quickly drives through the description of a problem into the analysis of why this is a problem — and how you might start to solve it.

This book is not about usability. You’ll learn a lot about understanding and communicating the user experience by reading this book, but it’s not going to teach you how to study user interaction.

Buy it now. You’ll learn more than you think you will, no matter your background.

So, part II of my series on WCAG 2 for Practical eCommerce magazine was published on Tuesday of last week. Obviously, I need to subscribe to the RSS feed for new articles at Practical eCommerce — because I didn’t even know this had been published!

Usually, I spend a day going back and forth with the editor before a new article is published — but I guess that this one just didn’t need that much editing.

At any rate, New Accessibility Guidelines, Part II: Operability, published on March 24th, 2009 at Practical eCommerce.

Practical eCommerce magazine interviewed me on subject pertaining to web site accessibility and the world of small business e-commerce recently — the interview is available from Practical eCommerce now!

The interview includes discussion of the W3C, web standards and accessibility standards in general, and common accessibility issues with e-commerce sites.

A transcript of the interview should be available sometime next week.

Most new projects come with some kind of baggage. An old version of the site with, shall we say, incredible code, an expensive CMS with rotten core HTML generation, tools the site owner has fallen in love with which fail to offer even a nod in the direction of accessibility, or demands for some kind of concept which only barely registers as possible within the boundaries of HTTP protocol.

And, as the developer, it’s your job to figure out how to re-do these projects. Usually, there will be more than one way to get the job done: at minimum, you’ll see a quick and dirty method and an arduous, finicky, complicated method which makes tears spring to your eyes in anticipation of the painstaking hours.

Finding the “right” way to do the job is a matter of balancing needs. In an ideal world, the “right” way is the method which gives you perfect accessibility, fantastic usability, and helps sell a million copies of your client’s product in the first 24 hours.

In the real world, it’s the best compromise between your time, your client’s budget, and the needs of the site audience. It may even be a more specific audience — the users of the specific portion of the site which is creating this challenge.

The Challenge of Scale

When you encounter a dozen pages with code which is layered with font elements, excessive span elements and dozens of unnecessary style attributes it’s a trivial task to strip the extra HTML and replace it with the bare minimum required for your needs. When you encounter 12,000 pages like this, of course, you may be looking at man hours which aren’t available anymore.

The Challenge of Legacy Systems

Rebuilding that CMS to deliver a reasonable facsimile of conforming HTML may not only be beyond the scope of practicality — it could well be a violation of the client’s license to use the software. If it’s expensive software, sacrificing a support relationship with the software developer could be very damaging.

With major CMS rebuilds, the most important thing is to identify the scope of changes you can make. Maybe you can’t replace every problem, but it’s honestly not worth discarding $30,000 worth of software investment for the sake of validation. It is worth discarding $30,000 worth of software for the sake of legitimate accessibility barriers. If the system will not allow you to create an accessible form, or generates a shopping cart which cannot be operated without using a mouse, that software should be replaced.

The Challenge of Fancy Widgets

Your client is in love with that poorly-designed Flash widget provided from CrazySite.com. They’ve just gotta have it! It can’t be used by anybody who isn’t using a mouse, the font size can’t be adjusted and is set to 8pt Arial, and there’s a constant red flash which might trigger seizures. But it’s just so cool!

Before you even start discussing the issues above — the un-sexy and hard to sell accessibility problems — it’s good to have a serious discussion with the client the answer one key question: Why. Does the widget serve a purpose for their business? Does it help their users? Does it help sell their product? Sometimes you can successfully get a client to make the right decision on their own once they realize that a function does not actually support their business in any way.

If, on the other hand, it does actually support their business, you’ve potentially stuck yourself with the greater challenge: replacing the functionality of the widget using an alternate means. Programming APIs are great, but not every site actually offers one.

The Challenge of Impossible Functionality

“Impossible” functionality is actually a bit of hyperbole. In my own experience, I’m not sure I recall ever having been asked for something which was actually impossible. However, I have been asked for functionality where the labor to value ratio was extremely unfavorable to the client, which is probably close enough.

Now, this is a highly variable challenge. Sometimes, the best thing to do here is just to ask for a second opinion from a programmer with more specific knowledge than you have. However, assuming that the request is actually unreasonable, the challenge is pretty much the same as above – find out what the client really wants. Sometimes, the difficulty is simply terminology. Some clients might use technical terms in an overly general manner, which can sometimes lead to misunderstandings.

Learning to inquire about project needs without using technical terminology is one of the most valuable tools in your scoping toolkit — it can save you tremendous amounts of time, wasted effort, and frustrated miscommunication.

What is doing it right?

So, in the end, what does it mean to do something right? Ultimately, it means not getting lost in the impossibilities of requests and avoiding being distracted by confusing requests. Doing a project right always starts with good scoping: continually asking questions until you’re absolutely certain that what you’re working on is really the project requested. Once the project is properly defined, the tools are known and understood, then doing the project itself is simply a matter of time and normal best practices development!