Joe Dolson: Accessible Web Design

Here’s the first clue: it’s not creating a pixel-perfect replication of your ideal version of a site in all browsers.

In fact, cross-browser compatibility ultimately has very little to do with what a web site looks like, and a lot more to do with how it functions. It also has relatively little to do with browsers, and perhaps could better be explained as multiple user-agent compatibility.

“Compatibility” (in this context) is not a term which means “looks and behaves identically” — - instead, it may be better described as “performs equivalently under alternative conditions.” But developers and designers tend to most immediately seize upon appearance as the guiding line for cross-browser compatibility.

Of course, let’s be honest: there are a lot of very good reasons for this. Completely disregarding what we may know about the behavior of a site, clients tend to be very visually oriented. They POP their new site open at home one day during development and notice a whole variety of differences which they’re suddenly concerned about. If you’re lucky, they’re opening up Internet Explorer 6 after you’ve gone through the painstaking process of correct its inability to cope with standards-compliant code, rather than before you’ve gotten around to it. That can be awkward…

Another good reason is that despite what I’ve stated above, making the design behave more-or-less identically between different browsers is actually quite desirable. From a usability perspective, a seamless change in interactivity between different user-agents is very desirable. If you’ve ever tried to guide somebody through using a website which delivers a different experience to their browser than to yours, you are intimately familiar with one reason it’s a very bad idea.

But the absolute key to cross-browser compatibility is simply functionality. A lack of cross-browser compatibility doesn’t mean that something looks different; it means that it doesn’t work.

And a good thing, too. Otherwise, compatibility would be pretty well impossible between desktop browsers and mobile browsers.

With web design, it’s occasionally entirely possible to make two browsers render a design exactly the same…if you assume certain factors will remain constant, such as the user settings described in my last post. If any of those have been changed, everything pretty well goes out the window. As desirable as it is to make your designs look as similar as possible between the various desktop browsers, it always has to be acknowledged that there are limits.

There’s nothing at all that you can do to actually guarantee the same view for everybody; instead, you need to guarantee an equivalent view for everybody. Equivalent in that they will be able to get the same information and use the functions of the site to perform the same actions.

Without both, it’s very difficult to have a successful online business. Unusable web sites have an incredible ability to generate a lack of trust in the business — - as soon as one feature fails to work correctly, or doesn’t behave as you expect, there’s an immediate connection made:

“If they can’t get this right, what else might they have problems with?”

Will they lose your financial data? Will they ship you the right product? Will they bill you the right amount of shipping? What are they going to do with your private information?

It’s hard to fully trust a website which gets in your way when you’re trying to perform basic tasks. The above questions may come up as reactions to pretty severe site problems, such as incorrect product data or frightening error messages, such as this one:

“You cannot do that. This action is being recorded.”

Yikes! Not really an ideal situation. Now, having written error messages before, I can imagine what was meant, which might be better stated like this:

“You may not perform that action. We have logged the error and will work to take care of any problems!”

There are a couple of important differences between those statements.

First, there’s the tense of the statement: we are currently recording vs. we have recorded. The first leaves an ongoing implication that your actions are being monitored which may be a bit disturbing.

Second, we have the indication of what has been recorded. In the first case, it sounds like the system is recording your actions. The second message clearly states that the information recorded was the error which occurred, and assures you that the problem will be worked on.

Maintaining trust in your application depends on good data, clear and non-threatening error messages, and clear task pathways. If your task paths aren’t clear, you may lose users due to sheer confusion. If you aren’t checking your data and perfecting your error messages (and all other responses, of course!) you may lose the visitors trust that you’ve really got their needs in mind.

Working as a web developer, I find myself dealing with a lot of different domain registrars, hosting services, etc. It’s inevitable. It’s also not the slightest bit uncommon to run across one very specific usability inconvenience with how these services manage their services. (Not all of them — - but enough that it’s irritating.)

This specific problem is that when you’re managing domains, some of these services handle multiple-domain management in the following manner:

1. Select the action you wish to perform.
2. Select the domain you wish to change.
3. Rinse and repeat.

It should be readily apparent what the problem is: choosing the action prior to choosing the domain is an extremely ineffective way of making a large number of changes to a specific domain.

Now, the way I tend to work (and I don’t see any great likelihood that this will change) is to focus on a particular site and do everything I need to do on that site in one working session.

End result: if I need to make, say, five changes to a domain, I need to take 10 individual actions. If I selected the domain, and then performed a variety of actions on that domain, I could easily reduce this to only 6 actions.

Even if I needed to work a different way, such as making the same change to a large number of domains, this continues not to be an efficient way of making the same change on a large number of domains, which would be best handled by allowing selection of multiple domains for simultaneous changes.

At any rate, if you happen to be a large company which manages hosting and/or registration of domains, don’t set up your management interface like this. It’s annoying.

End rant.

An interesting thread at Cre8asiteforums, titled “When lots of your visitors go straight to search? discusses a member’s curiosity about navigation patterns after noticing that a significant percentage of his visitors — - 25% — - go directly to search after arriving at his site.

It’s an interesting element of site navigation to investigate, and the thread raises a pretty significant number of additional questions worth analyzing.

The navigation path of any given user will be fundamentally unique. However, when taken in aggregate, navigation paths begin to suggest a lot about your navigation structures. The percentage of visitors who immediately jump into a site search, however, suggests a very different thought process.

On sites which I visit frequently, for example, I generally have a very set system for finding information. If the site has a good search, then I may use the search. If they have a very clear navigation, I may use that, instead. If they have neither, it’s unlikely that I visit the site frequently…but if I do, I generally have separate bookmarks to the individual features which I actually use.

And that raises a separate question — - if a site has difficult navigation and inferior search, what would drive you to actually visit it frequently? For me, the site has to offer some specific information or functionality that I simply can’t get elsewhere. Otherwise, there’s simply no justification for the challenge of using the site.

You can learn a lot about the effectiveness of site navigation by following analytics data. Knowing that most users who use your search feature fail to find what they’re looking for, for example, should suggest that this is a feature of your site which needs work. Finding that users frequently enter several sections of your site before finding the right information can be significant as well — - it suggests that you need to rethink the way your site categories/sections are organized.

So…important question, then: HOW do you follow this? Where do you get this information?

You’re not going to get meaningful user information from standard statistics packages like AWStats or Webalizer. You need to use some tool which will provide a means to track the path of specific users. This can be parsed from your server logs. A high-end statistics package such as Clicktracks will give you user path data. There are a number of other services which can provide this information (and, if you know what you’re doing, you’ve already got the information).

I’m not really an expert on analytics packages, of course. If you want a lot of detailed information about web analytics and analytics packages, here are a few resources:

• Stone Temple Consulting: Analytics Report - Great resource. Extensive commentary and analysis of multiple packages.
• Occam’s Razor by Avinash Kaushik - Blog on web analytics from one of the top experts in the field.
• Web Analytics: An Hour a Day, by Avinash Kaushik - Same author, but you can read him in print.
• Ultimate Web Analytics Comparison - Manoj Jasra - lists numerous packages, providing immediate access to features lists and comparisons between different stats packages. Particularly good for comparing Google Analytics to other packages.

An interesting thought in indexing and handling page structure is the concept that different areas of a single page can be identified and considered independently from surrounding bodies of content. This particularly applies to specific and readily identifiable data-types, such as phone numbers, postal codes, or abbreviations; but can also be extended to include broader content labeling.

A well-structured XML document has an absolutely clear labeling system for data built into the structure. If you take any RSS feed, for example, the elements which identify <title>, <link> or <managingEditor> can’t readily be mistaken.

A well-structured, semantically sensible XHTML or HTML document doesn’t offer nearly the same degree of data particulation — - the higher level data elements can sometimes be fairly clear, as is the case with <address> or <cite> elements, but other potentially valuable elements end up providing relatively neutral value: <h2> or <div>.

Read more: Thoughts about Content Labeling and Data

 Example:

Visit this site! http://www.joedolson.com/

I run into this, or into something like it all the time, and it’s pretty understandable why. Obviously, if you don’t know how to create a hyperlink, or if you’re working with a CMS which will automatically convert a URL into a hyperlink, this is the most reliable way to provide access to somebody else’s site.

Either they have the URL, and can use it “straight up” if they know how, or they can follow the hyperlink generated by the system. Nice and easy. I understand perfectly well why an inexperienced content manager might make use of hyperlinks au naturelle, or so to speak.

Read more: On the usability of contextual URLs

At least, in the final reckoning.

Something which comes up over and over in my work is the tendency of clients to request design changes which I don’t particularly care for. This isn’t to say that they’re ugly, per se — - after all, the fact that I don’t like them isn’t actually equal to “ugly.”

Early on, I would argue with clients concerning these design changes — - try and get them to see my perspective, etc. But the fact is that aesthetics are not objective. Opinion matters; and it’s ultimately the client’s decision.

Now, I only argue with decision which cause problems. You want that to be blue instead of green? Fine. Doesn’t matter to me that it’s going to clash with the rest of the color scheme. But you want that text to be blue against an orange background? That, I won’t do. That’s the kind of decision which will render the text unreadable — - and I’m not willing to do it.

Occasionally in my consulting practice I encounter designers (or stories about designers) who are so wrapped up in control over their design that they barely consider the client’s needs, let alone the needs of usability and accessibility. That’s unfortunate; since in the end, what your website looks like just barely registers for many visitors.

I sincerely believe (unscientifically) that most visitors only notice website design in one of three ways:

1. The design prevents them from effectively using the site.
2. The design is absolutely spectacular.
3. The design is absolutely horrific.

Do you really want your design to be attracting attention? Certainly not for reasons numbers 1 and 3, and although the second reason is positive, it’s not necessarily best for every site. Incredible design doesn’t necessarily support your business in the best way; it could just get in the way. This can’t be decided universally, of course — - and it’s never a bad thing to strive for a great design.

It’s hard to ask questions about whether people noticed the design of a site. After all, it’s rather a quantum query: once you’ve asked, they will observe. The act of asking changes the experience of the visitor. Even in a usability test, it’s hard to identify this observation. Even though you can set up the scenario more effectively, if your testers are still aware that they are testing the site, they will tend to be more observant than otherwise.

You can’t TELL somebody to just “act normally” during a test, unfortunately. It doesn’t work that way….

Nonetheless, the rules I will work to avoid are clear: don’t make it horrible, and don’t let it get in the user’s way. Otherwise, what it looks like is open territory. I’ll try to make it look as good as I can, but if a client wants a change — - they’ll get it.