Joe Dolson: Accessible Web Design

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.

This is not a technical article. You will not learn how to code AJAX by reading this; either in an accessible and usable fashion or otherwise. This is a conceptual article. It will run through basic user-interface issues with AJAX (and other rich media). These are the reasons that AJAX functionality can be a problem for users — - if you consider these issues carefully during development, it should greatly enhance the usability of your end product.

The basic limitations encountered with AJAX are threefold:

• Discoverability of Functionality
• Usability of said Function
• Discoverability of Function Feedback

Best practice in any rich media format should always ensure that these three limitations are dealt with for all users.

Read more: Accessibility and Usability issues with AJAX

Shari Thurow, a regular on the search marketing speaking circuit, just published an article in the ClickZ network addressing three SEO Myths and Misconceptions. Although the article is generally pretty decent, I do take some issue with how she addresses one area — - the question of replacing images with text.

In fact, my complaint is with what I perceive to be the basic assumption she’s making in this SEO Myth: that web developers and marketers are recommending that web sites replace graphic images with CSS-styled text.

Read more: Replacing Images with Text

Although I deal with issues of usability fairly regularly, usability is not fundamentally one of the chief areas I work in. It’s certainly an area I’m very interested in, and is closely related to accessibility, but I haven’t been involved in any full scale usability testing. So, it’s rather interesting to me that one of the first sponsors of this blog should prove to be the makers of a usability testing software package called Morae 2. jo

This is not a paid blog post, although the product was being advertised on this website.

Read more: Usability Testing Software

Writing a website is a complex task. The website needs to cater to the very human needs of it’s visitors, but also requires a certain amount of consideration for it’s non-human visitors: web browsers of all sorts, search engine spiders, or any piece of software which gathers information from the internet.

These two aspects can’t easily be separated: humans are using computers to interface with your web-based information, so the information received by your visitor is biased by the device they’ve used to access it. Website design and development requires a very conscious and simultaneous consideration of both parts.

Accessible web design is often times very computer and device-centric. Much of the process seems to be:

• Validating code
• Checking browser compatibility
• Making certain that keyboard navigability is available.
• Writing client-side scripting which falls back and is usable when the technology isn’t.

These are, to some degree or another, measurable and definite. They provide a definitively testable scenario where you can state clearly that website A is more accessible than website B. This doesn’t mean that either website is actually usable.

The technical aspects of accessibility are easy. They’re a pleasant shortcut from not knowing what you have to a sense of confidence that you’ve done the right thing. They’re also quite necessary — - if your human audience is unable to make use of your site due to a technical issue you should absolutely be able to fix that. Your code is written for a computer, and you provide the best information to whatever device is being served your page in order to give it access to your website. This applies to user agents and web spiders.

But the ultimate audience is not the device; it’s the person operating that device. A second layer of much less measurable consideration needs to be applied to the people operating devices.

• You’ve provided the ability to change font size. Do you need to tell your audience?
• You’re using hidden skiplinks to help navigate. How does somebody know this?
• You’ve got a really cool AJAX search which discovers results as your visitors type: do they know this?

You can’t make assumptions about your visitors or their devices. Many techniques are questionable because of discoverability — - a screen reader may support the JavaScript you’re using to power a technique, but not have a means to inform the user of the change in the page. The JavaScript you’ve written may degrade when JavaScript is not available — - but how does it degrade when an earlier version of JavaScript is all that’s available?

At the end of the day, you have no way to know exactly how well you’ve done. Even a thoroughly tried and tested site may be flawed when it hasn’t been confronted with users. You can run every machine test conceivable on a website and pass them, and still produce a site with problems. Testing, communication, and a willingness to explore alternatives gives you a chance of success.

Device compatibility is certainly important, but human compatibility is more important. Human compatibility is ultimately a question of audience — - and in the web sphere, as often as not, the audience is filled with question marks. Market research isn’t just about marketing: it’s about knowing your audience so you can provide not just what they want, but what they are able to use.

Wordpress isn’t really designed to be used as a CMS. It’s designed for blogging - nonetheless, it’s a surprisingly powerful little content management system, and with a little bit of tweaking you can pretty easily turn it into a nicely flexible system.

One of the challenges that needs to be dealt with is the use of Pages. A “Page,” in Wordpress parlance, is a document which sits outside the blog chronology. For the purpose of a CMS, you don’t really want all of your posts to be chronologically organized. You could rewrite the Post templates and the permalink format to eliminate all date information, which would provide you with a nice CMS-like organization - but would also eliminate the blog function. Realistically, you probably want both.

It’s very easy to create a large number of WordPress pages and sort them into a hierarchy. For presentation, the default WordPress function wp_list_pages creates a very nice nested group of unordered lists. This can be styled using CSS to create either a long list of pages with inset sub pages, or a fancy CSS-driven set of drop down or flyout menus.

So far, so good. If you’ve got 10 pages, a single list is fine. But for larger sites, you’re running into other challenges. A straight list of your 150 pages is ugly, difficult to use, and difficult to navigate.

But the classic drop down or flyout menu has some usability issues. For people with mobility impairments, for example, the ability to use a mouse may be limited - and it takes a fair amount of core source hacking in order to attach the javascript needed to make these menus completely keyboard navigable. It’s easy to make certain that the top level link in each category is usable from the keyboard - so your responsibility is to make certain that the top level category link will provide access to all sub pages.

Again, there’s an easy solution: write links to all your further pages into your document content.

Ick. This solution sucks. First of all, if you’re creating this site for a client, you can’t necessarily rely on them to retain the content you’ve carefully created. Second, it’s very awkward to have to hand-maintain links to every page on the site. Why are you using a CMS if you’re going to have to do this anyhow?

Thankfully, although it’s not immediately obvious, Wordpress does provide a way to access the children of pages programmatically. Using this code, you can simply create a secondary navigation section which provides easily keyboard-navigable links to all pages below those top level documents.

The Code

<h3>
<?php echo get_post_meta($wp_query->post->ID, 'category', true); ?>
</h3>
<?php 
if(get_the_title($post->post_parent) != the_title('' ,'',false)) {
echo "<ul>";
wp_list_pages("child_of=".$post->post_parent."&title_li=");
echo "</ul>";
}  
if(wp_list_pages("child_of=".$post->ID."&echo=0")) {
echo "<ul>";
wp_list_pages("title_li=&child_of=".$post->ID."&sort_column=menu_order"); 
echo "</ul>;";
} ?>

What’s going on here?

First up has really nothing to do with the navigation menu itself. This is a header for the category navigation menu, arbitrarily placed in a level 3 heading element. It’s a little oddly phrased - this is because WordPress doesn’t provide access to Category labels for Pages the same way they do for Posts. Therefore, this is actually sourcing a Custom Field - a feature available in WordPress which gives you the ability to attahc any custom information to a document. In this case, I’ve created a custom field named “category” which contains the phrase I wish to be considered the category for this item. Generally, it’s the link text of the top level link, although you could set it to be anything you wish.

We’re trying to talk about usability, however, so I’m inclined to suggest sticking to something appropriate.

The second block of code is a tricky bit. This if query is checking to see whether the current page is a subpage of any other page. In general, Wordpress has great built-in conditional functions - you can very easily check whether something is a page (is_page() or whether it’s a category page (is_category(). There isn’t, however, an is_subpage() condition. So, this is the workaround - checking whether the current page is not it’s own parent. In Wordpress, pages at the top level of the hierarchy are their own parents. (Let’s not get into genetics, here…I’m concerned.)

Next we’ll use the normal wp_list_pages() function. Again, we’re using the information about the post’s parent in order to determine what pages to list, using the child_of argument to retrieve only the Pages which are children of the current page.

Whoa, there! I see a problem!

Yep, you sure do. At this point, we’re only retrieving child navigation if we’re not on the top level page itself. Well, that’s great. You can get between child pages if you can find your way there!

So that second block of code comes into play. Same idea, except this time we’re fetching children of the current page, without checking whether the page is top level. If it’s got children, great - we’ll display ‘em. If it doesn’t - also great - we won’t.

This sytem does also work for multiple hierarchy levels, although it’s a bit awkward. Here’s what you’ll get with three levels in the hierarchy:

• Top level page, no children: displays category heading, no children. (The category heading could be removed using another conditional statement; I just haven’t done it.)
• Top level page, with children: displays all descendants (children and grandchildren.) Grandchildren will be in a nested unordered list inside the list item for their parent.
• Second level page, no children: displays all sibling pages (pages with the same parent).
• Second level page, with children: displays all sibling pages AND displays the children of the current page, in a nested unordered list inside the list item for that page.
• Third level page, no children: display all sibling pages at the grandchild level.

And so on. This code functions in Wordpress versions 2.01 and above.

Following an article by Larry Constantine, I began a thread at Cre8asite Forums discussing the usability of open source software. The subject of the original article is the advantages (and disadvantages) of open source software - one of the chief weaknesses cited by Constantine is poor usability.

Now, I don’t have the kind of knowledge of open source software to be able to make that kind of judgement. Some open source software I know is quite difficult to use, but some is very easy. Some closed source software is very difficult, some is not. I’m not capable of drawing that line. Regardless of the reality, the impression that open source software is more difficult to use than its closed source counterparts is rampant.

I’m inclined to believe that people involved in the open source usability movement are those who are knowledgeable about the problems in open source projects. After all, it’s probably quite true that most open source projects are developed by engineers and code geeks - not usability experts. Some of these engineers are undoubtedly thinking about usability: but certainly not all. Establishing a movement to improve usability can hardly be a bad thing!

But is this usability challenge an illusion?

Ruud, at Cre8asite, states:

My guess is that poor usability isn’t always recognized as such in closed source though. The difficulty a company has to use that $75,000 CMS is expected: of course such an expensive system is “complex”…

But the strange clickthrough path in a freebie open source project? Bad usability, cloaked functionality…

To what degree do our expectations cloud our judgement? Is open source more difficult to use, or is it just that training and thorough documentation is less available? After all, the thousand hours of training required to install, administer, and use some complex software packages is simply not available for an open source equivalent: there isn’t necessarily a company established behind the product to provide these services.

On the other hand, Rashmi Sinha states:

Open source software projects are often feature driven. People join a project, they want to contribute. How can they contribute - by adding a feature. The user experience becomes more and more complex over time, as more and more features get added.

So open source projects are subject to feature bloat. Well…I’d argue this is equally true of many closed source projects. Many, many software packages add features in order to be able to ship a new version: in order to sell again, they need to offer something more. Perhaps this is less a division between open source and closed source and more a division between good project planning and oversight and bad.