The problem is the stigma attached to the term “accessibility”. Now we know that web accessibility achieves more than simply facilitating access to web content. But a lot of government organizations and businesses don’t see the need to even try and conform to accessibility guidelines.

As part of a group of organizations (the advisory group for the Dutch Web Accessibility/Quality Guidelines) concerned with changing this way of thinking, several of us are trying to compile a list of themes/categories/factors which can be considered building blocks of really good websites, or less-obvious benefits of accessible websites. I’m aware of many, but lots of people in this industry are so incredibly smart; it would be such a pity not to ask.

So I’m asking! The idea is to create a list of things like “interoperable”, “search-engine friendly/findability”, “archivable” etc. to help convince government organizations and businesses that there are lots of non-obvious benefits in conforming to web accessibility guidelines. “Cuts down on bandwidth usage” is fine. I’ll parse the list and try to group like-minded suggestions together to come up with some high-level themes. I will post the results and link to any known follow-up usage or derivative of the resulting list.

Even if you can only think up one thing, please add it to the comments! Ask your friends (but don’t spam :) ). Don’t worry too much about accessibility, just quickly note whatever you think makes a great website.

Care to chip in? What constitutes a good website?

I didn’t think much about it until Vasilis van Gemert posted about it and Ian published some stats; at that point in time visitors clicked an average of 23 times per visit. 23 times is a lot of clicking, which means some conditioning and expectation are at work.

As pattern-seeking beings, we tend to follow our conditioning. A button must be there for a reason—let’s click it. It says “sit”, therefore the dog will probably sit, won’t it? 23 clicks on average indicates to me that the average user is not considering whether this is just an image or instead some type of interactive movie. 23 clicks indicates bell/salivate. Button/action-expectation.

Let’s say you have javascript disabled, for whatever reason. You fill out a form. You click the submit button, not knowing that in this case the developer has made a javascript-dependent button (this is common). You might say you have encountered a Defiant Dog: something which doesn’t do as it’s told, or doesn’t react according to expectations.

Ian’s fun experiment confirms two things which many of us know but are always worth repeating:

1. When users expect things to happen on our websites, it’s most likely that we have done something to trigger those expectations
2. Users will almost always think it’s their own fault (and may even click 23 times before deciding it’s not)

It’s been said that without expectation, there is no disappointment. While not a new idea, this take-away from the Defiant Dog is still timely, as you’ll notice anytime you see something you think should be clickable but isn’t. Or when a relationship is falsely implied between multiple UI elements.

Managing expectations is a design problem. It’s up to us as web designers to find the defiant dogs in our websites and applications, and get them to sit.

I’m assuming that readers of this website are at least vaguely familiar with the WCAG. If not, you can read more about them on the WAI website, as there is no reason to repeat that information here.

26 organizations worked in varying capacity on this translation, including Cinnamon, represented by myself. The translation was coordinated by Stichting Accessibility, and follows the official procedure for authorized W3C translations.

After the review period, this candidate translation will be modified where necessary. It is expected that a finalized version will follow in December 2009. The current draft is not the finalized version, and may not be published as such.

Please help us review!

If you would like to review, you’ll need both the original English version as well as the candidate Dutch translation. Please send all comments to public-auth-trans-nl@w3.org.

Please note that the review is intended to ensure the correctness of the translation. The actual content of the draft will not be changed.

Please help out if you can! If you can’t review yourself, perhaps you can spread the word about it.

A Dutch-language press release is available (PDF, 72kB).