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.

Hat tip to John Rhodes of WebWord.

Sitepoint has recently released their Usability Kit, first edition: a binder containing 400 pages of documentation (usability evaluation and design techniques, forms, templates, blueprints, etc.), a CD-ROM containing digital versions of the contents, and a complete set of “Magnetic Web Widgets” (while stocks last.)

At $197, this isn’t precisely a “cheap” guide to usability: but hey — you get magnets.

Actually, if you’re going to buy this, I’d suggest buying it soon. The free magnetic web widgets could be a great tool for playing with different layout concepts and ideas. Certainly for myself, as a non-artist, being able to throw together alternate layouts very quickly would be nice. You can design your new sites on the fridge!

Judging from the sample download, I’d agree that it’s well-written and worthwhile. Granted, there are dozens of freely available resources for usability out there: but this compilation of documents might make for a great reference. If you’ve got $197 to burn, buy it (at least for the magnets).

On a day to day basis, I deal with W3C standards. However, there are certainly sets of standards (or guidelines) outside of the W3C which are good to be aware of. Thanks to Kim Krause Berg, I’m now aware of another document: Research-Based Web Design and Usability Guidelines, courtesy of the United States Government.

One of the keys which makes this worth noting is those two first little words: “Research-Based”. There’s nothing better than research (and user testing) to provide you with a better idea of how your ideas will go together.

From the foreword, by Dr. Ben Shneiderman:

Guidelines should be more than one person’s lightly-considered opinion, but they are not rigid standards that can form the basis of a contract or a lawsuit. Guidelines are not a comprehensive academic theory that has strong predictive value, rather they should be prescriptive, in the sense that they prescribe practice with useful sets of DOs and DON’Ts. Guidelines should be presented with justifications and examples.

Download it, read it, and absorb it.

Part of building an accessible website is making meaningful choices in the code you use to markup your content. In some cases, this is a very easy decision: <p> descrbes a paragraph, <blockquote> describes a blocked quote, and <acronym> describes an acronym. No problems.

But some issues are more complex: take the calendar. What is the logical structure of a calendar? Is it tabular data? Is it an ordered list? Is it a definition list? All of these are completely reasonable and logically justifiable structures for a calendar: how do you pick?

Tabular Calendar Structure

In a table structure, the columns represent days of the week, rows represent the week number of the month or year. In practical use, weeks of the year are rarely applied. The Vienna (Austria) transit system uses them: buying a weekly pass gives you transit access for that specific week of the year, but I’ve rarely seen them in other applications. Weeks of the month, however, are in frequent use: Thanksgiving is always the fourth Thursday in November, Election Day is the second Tuesday in November.

So, the tabular structure is reasonably well justified. Colloquial language does actually use those data references for the information, so, if appropriately marked up, this seems reasonable. It’s not perfect, however: the layout inevitably means that either the table will inevitably contain data for a previous month, or will contain empty cells. Not the end of the world; but imperfect.

Ordered List Structure

Time is, for most people, a pretty linear experience. As such, dates can very reasonably be structured sequentially. Again, only really usable for single month length calendars, as the numbering must repeat otherwise, but reasonable. This is certainly a data structure in normal use: the 22nd day of October, etc. The list itself could be labeled with the month, each day would be a list item. In addition, the days of the month would be automatically numerically labeled appropriately. Additional data for the day could conceivably be contained in a nested list.

This layout is a less common look for print calendars; so users are likely to be less familiar with it. However, it’s certainly a reasonable approach.

Definition List Structure

The days of a month can be described as the definition of that month: February is a month containing these 28 days. Each day, furthermore, can be defined by the events of the day. From a structural perspective, this is significantly similar to the ordered list approach. Definition lists do have one advantage, however: each list item has an independent definition. Although not necessary for a basic calendar, these could be useful for an events calendar.

I tend to feel that a definition list stretches the semantic association a bit too far: although a <dl> can be applied for a calendar, and with some justification, it seems to stretch a bit beyond the fundamental meaning of a list of definitions.

Conclusion?

Ultimately, there is no one structure which is perfectly suited for a calendar. Dates are referenced and used in a significant number of ways: the visual layout should generally be that of a table, because this is what most users are familiar with. Usability would certainly suggest that familiarity should carry some weight.

My own tendency is to use tables. That is the visual layout I want; and I see a very reasonable justification for the semantics. I don’t believe there are any major hurdles to accessibility, as long as the table has been appropriately designed.

Numerous articles in the last few days have suggested serious problems in either defining web accessibility or in the way it’s handled. Trenton Moss considers the future of accessibility. Alastair Campbell follows up with his own opinions. Gez Lemon and Mike Cherim co-published an article outlining two supposedly opposing views of accessibility at Accessites. Roger Johansson chimed in with his reasoning for universality. And, to cap if off, Mike Davies wrote an excellent (if possibly inflammatory) four-part series declaring Accessibility in Trouble.

All of these articles seem to revolve around two central points: whether web accessibility is about people with disabilities or whether it’s about universal access, and whether more advanced technologies (such as AJAX or Flash) are acceptable for use in accessible web design. These aren’t entirely separate issues: the whole universe of web accessibility is tightly entwined with the use of technology.

Who is Web Accessibility For?

First and foremost, web accessibility is about users with disabilities. It’s my firm opinion that the first goal of an accessible website is to ensure that users who, for whatever reason, are unable to make use of a website using standard user agents and settings, are able to use the website. This includes, amongst many other techniques:

• Providing for screen readers through alt texts, image long descriptions, and appropriate labels
• Using an acceptable default color contrast
• Using acceptable typography and providing the ability to alter text size (through browser settings or website settings)
• Providing appropriate link texts and explanatory information for acronyms and abbreviations.
• Avoid the creation of any access barriers requiring specific knowledge or abilities.

These are the first priorities: they make a website usable (in the sense of “possible to use”) by disabled visitors. A second priority is in making the site easy to use. Is this accessibility? Web accessibility is commonly defined according to the principles espoused in the WCAG. However, this debate seems to reach out more broadly. From a policy perspective, web accessibility means following the WCAG guidelines. But from a logical perspective, some of these guidelines are actually about making a website easier to use for visitors with disabilities. Usability is not identical to accessibility: it supplements accessibility.

Take, for example, the provision of WCAG 2.0 calling for skiplinks:

Blocks of repeated material, such as navigation menus and document headers, are marked up so that they can be bypassed by people who use assistive technology or who navigate via keyboard or keyboard interface. [V]

WCAG 2.0 Guideline 2.4

Bypassing a menu is not precisely an issue of accessibility: it’s an issue of ease of use. I’d say that this is the challenge of making the experience of a disabled user better, rather than possible. Is it any less important? Absolutely not. On the same grounds, I’d argue that any use of technology which improves the user experience is an acceptable part of accessibility.

One key with accessibility is to add features without ever subtracting from the overall accessibility. Many, many accessibility experts will recommend consistently against the use of AJAX, JavaScript, and Flash because these technologies have accessibility problems. I won’t argue against this: these technologies DO have accessibility problems. Are they inherent? Not really. It’s entirely possible to construct highly usable, accessible websites using these technologies: it does, however, take a very high level of knowledge to do it. I won’t do it. It’s not because I am fundamentally opposed to the use of advanced technologies, I’m just opposed to my own use of them. It would be a massive disservice for me to build anybody a Flash or JavaScript heavy website. I don’t yet have the breadth of experience to work effectively with these technologies.

For me, I will continue to recommend against them while consulting, unless the client is also willing to support extensive user testing: the only truly effective way to guarantee accessibility.

Universal or Accessible?

In Part 3 of his article series, Mike Davies states:

The position of disallowing technologies such as Flash stands quite contrary to providing accessible content. Here the goals of universality are conflicting with web accessibility.

Web accessibility has always been about reaching out to disabled people – using what we have at our disposal: technology and technique. Starting with an accessible website, and ripping out the Flash (because there’s no Flash plugin for Lynx) is a step backwards for web accessibility. And yet, this is what zealots want you to do.

Its very reminiscent of the tools that create a text-only version of a website – by stripping out the images and multimedia. Both the concept and the process do more to hinder the accessibility of a website.

He’s got a great point: universality and accessibility are NOT the same thing. Universality, though an acceptable goal, is measurable only in device specific terms. Accessibility is only measurable in human specific terms. The challenge for an accessible web developer, however, is in finding an appropriate balance. Let’s be honest: how many of us really do extensive user testing? I don’t. My clients usually can’t afford it, or won’t spring for it if they can. I would love to be able to, but for now, it’s not a practical approach for me. That simple fact renders Flash an unsupportable candidate for my own development. And, I’ll opine brashly, it should also leave it unacceptable for anybody else who isn’t doing user testing.

I’m not speaking against Flash explicitly: I’m simply saying that accessible Flash is a relatively untested field. It’s not impossible, and for the knowledgeable it’s probably not even all that difficult. (For more about accessibility recommendations for Flash, you may want to read Bob Regan’s 2005 white paper on the subject.)

What Does Accessibility Need?

Well, obviously, more user testing is always called for. What I’d love to see, although I’m not capable of putting it together myself, would be a full scale accessibility study of Flash and AJAX websites which have been specifically designed with accessibility in mind. User testing, limitations, the whole banana. Accessibility needs better awareness of using Flash. AJAX has received a fair amount of attention: articles from Standards-Schmandards, WebAIM, WebStandards.org, and many others have given developers a fair shot at addressing the limitations and possibilities in AJAX accessibility. Flash has been almost entirely disregarded by the web standards and accessibility community. I’d like to see it given an equal chance.

Accessibility does not, however, need a particular agreement on who accessibility needs to serve. At least, not an agreement which refines between “disabled” and “everybody”. In my opinion, a lot of this trouble in defining web accessibility comes from petty bickering on terminology. Fine, some people define accessibility as providing for users with disabilities. Others call it providing for all users, regardless of abilities. Perhaps the second group is better defined as providing universal websites; but I can’t bring myself to be too concerned. Both camps agree without hesitation that they need to provide access for users with disabilities.

Universal web designers won’t use Flash under any circumstances, because it isn’t supportable in some rare browsers (Lynx, for example.). Fine. Does this reduce the accessibility (for disabled users) of their work? I don’t think so: it merely limits the tools they’ll work in. I find it hard to support Mike Davies’ claim that:

If zealots have their way, websites would only use HTML, with an optional CSS for presentation. And yet, this combination of technologies is inaccessible to certain groups of disabled people – certain groups that can be reached with Flash and JavaScript.

I can’t help but be curious exactly what groups of disabled people can be reached with Flash and JavaScript, but not with HTML and CSS. I’ve sat here and tried to imagine that situation; but have had only limited success. I’m imagining individuals with ADD not being capable of sitting still long enough to read a text document; but that’s a problem correctable through content changes. I would love to know what user group cannot be reached using standards-based HTML.