And, naturally, it always fails. Something goes wrong in the system; gross negligence of maintenance causes a malfunction; or some unanticipated exception allows the hero to escape.

This is an important thing to keep in mind when designing or building a web site, in every aspect. When you think you’re adding fabulous new functionality or greater accessibility, you should always be thinking about whether you’re ultimately supporting your visitor’s needs — or just making your system needlessly more complex.

Jared Smith, from Web AIM, recently published an article on web accessibility preferences expounding on the notion that in most cases, providing tools for your disabled users to change their experience usually means that you haven’t done your job right in the first place. Perhaps, rather than adding a tool to enable people to adjust your site, you should simply fix the site. Jared makes the very good point that in most cases, the people who need text enlargement have already taken care of it through their browser settings or operating system; and those who need extreme enlargement can’t be helped by a common accessibility widget — they need software support.

So, given this case, what do you actually accomplish by adding accessibility widgets to a web site?

If you’ve added them to a global element, to make them available throughout the site, you’ve made your site more complex: there’s more information on every page which needs to be sorted through or skipped over. You’ve added an additional technical element which needs to be supported and maintained — as browsers change, you’ll need to be rechecking not just your default settings, but all of the various combinations you’re providing, as well.

If you’ve added the same options to a page dedicated to these accessibility options, you’ve pretty well avoided the problem of having a globally more complicated interface. However, you need to ask yourself whether the problems your accessibility options fix will prevent the users who need them from finding the options! Take this example: you’ve chosen a relatively low-contrast (but attractive) text color for your footer and secondary header navigation. Since this color is below the WCAG 2 color contrast requirements, you’re providing a link to a page where the user can select a high-contrast option.

Unfortunately, since the link is in your footer, that user who needs a high-contrast page can’t actually find the page where they can make the change.

Problems with site complexity don’t only effect web accessibility, however. Any additional function to your web site needs to be carefully considered before implementation: is it worth while to add an audio player with auto start to your home page? What are the consequences of making this change? You may think that it’s a great opportunity to immediately promote your band’s music to those who want to hear it; but you’re making the gross assumption that those visitors want to hear it right now. They may not. And if they’re in a sensitive situation — checking you out from their quiet office cubicle, for example — then their first reaction is likely to be “How do I turn this off!”

Assuming you have decided to add this audio player to your web site — you may not realize that the most important control you need to have is a prominent STOP button. Otherwise, the most natural way to stop the music is to leave your site.

Any piece of new functionality adds complexity to a site. It may create an undesirable reaction, it may create user confusion — or it may be a brilliant idea which turns your home business into a multi-million dollar corporation. You shouldn’t avoid adding functionality on the grounds that anything complicated is going to be a problem; but you should certainly take a very close look at every new feature and decide whether it will add to the user experience. When making that decision, the points to consider are not limited to the value of that feature alone. You need to also consider all the other features which will be simultaneously available; you may want to add a new feature, but move an existing one. It’s usually not any given feature which causes problems; it’s having too many paths to follow which may confuse your visitors.

When More is Less
Copyright 2004 – 2010 Joseph C Dolson, Accessible Web Design

Shari Thurow, a well-respected researcher in the search engine optimization and usability realm, suggested that separating the two concepts is, in fact, ridiculous.

Well, that may be. However, I think that it’s crucial to break a task into parts if you want to gain a thorough understanding of the whole. Search engine marketing is an excellent example of a whole which is greater than the sum of it’s parts.

As I see it, building a search engine friendly site is one of the first stages of best practice search marketing. The adage “if you build it, they will come” fails to hold, however: a site which is constructed merely to be search engine friendly will gain little to no traffic.

Being part of the process

Being search engine friendly is a part of the process of search engine optimization; which is, itself, a part of the process of search engine marketing. In addition to these two aspects, search engine marketing may also include pay-per-click advertising, print advertising, link building and social media participation. Search engine marketing is a large area, and very, very few people are expert in all aspects. I’m certainly not.

From a marketing standpoint, what parts of this marketing whole are necessary for your business to succeed is going to vary radically depending on your industry and the way your business intersects with the internet. It will also depend on your definition of success. If you’re looking to maximize growth, you’ll probably want to be investing in all aspects of marketing.

So I’m arguing that search marketing, while clearly a practice in which the parts of the whole are highly interwoven and carry clear dependencies on each other, can nonetheless be separated into it’s component parts for a variety of reasons, including for the sake of discussion.

Now let me take this a step further. Not only is it possible to separate search engine marketing into separate aspects for discussion, it’s valuable.

If you want to understand the interactions between the different aspects of a task, it’s important to have some information about all parts. In this context, it’s necessary to treat the whole of search engine marketing in a given discussion. However, when you want to understand the details of a specific task, it’s important to stay focused on your part of that task.

It’s necessary for practitioners in search engine marketing to know, in general, what the impact their work will be on all aspects of the marketing campaign. It is crucial for practitioners in search marketing to know, in detail, exactly how to perform their own tasks in the best possible manner for their clients. It’s important to treat an area of expertise specifically. Talking through the nature of that area; comparing and contrasting it to other related areas; considering the specific nature of tasks within that area of expertise: these are all ways of better defining and refining knowledge on a specific subject.

Why does this matter?

It doesn’t, really. It’s all semantics. Search engine optimization is the commonly known term, and it frequently is understood to encapsulate search engine marketing. Or the other way around. The industries around search engines and marketing (and just about anything internet) are young, and the vocabularies aren’t really all the firmly established. As a result, some people have a very firm opinion of what a given term means which may not always coincide with others definitions.

Well, that’s why we write about it. We’re all hoping that our definitions will ultimately win.

Taking a holistic view of SEO in parts.
Copyright 2004 – 2010 Joseph C Dolson, Accessible Web Design

(The original also did this for meta keywords and meta descriptions — but the demonstration of this “logic” only requires one field.)

 
<? if (is_front_page()) { ?>
	<title>Handwritten title</title>
<? } elseif (is_page("page-name")) { ?>
	<title><?= get_post_meta(334, 'meta_title', TRUE); ?> | <? bloginfo('name'); ?></title>
<? } elseif (is_page("page-name-2")) { ?>
	<title><?= get_post_meta(383, 'meta_title', TRUE); ?> | <? bloginfo('name'); ?></title>
<? } elseif (is_page("page-name-3")) { ?>
	<title><?= get_post_meta(381, 'meta_title', TRUE); ?> | <? bloginfo('name'); ?></title>
<? } elseif (is_page("page-name-4")) { ?>
	<title><?= get_post_meta(383, 'meta_title', TRUE); ?> | <? bloginfo('name'); ?></title>
<? } elseif (is_page("page-name-5")) { ?>
	<title><?= get_post_meta(387, 'meta_title', TRUE); ?> | <? bloginfo('name'); ?></title>
<? } ?>

And so on. For approximately 40 separate pages. It made my brain hurt. For reference, the exact same thing — for all pages on the site — could have been accomplished (with better fallback conditions, in fact) with this code:

 
<?php if (get_post_meta($wp_query->post->ID, 'meta_title', true)=="" && is_page() ) { ?>
	<title><? wp_title('|', true, 'right'); ?> <? bloginfo('name'); ?></title>
<?php } else { ?>
	<title><?php echo stripslashes(get_post_meta($wp_query->post->ID, 'meta_title', true)); ?> | <? bloginfo('name'); ?></title>
<?php } ?>

Now, the original code may actually look cleaner — it does, after all, have fewer functions and fewer variables. However, the second example is a hell of a lot more maintainable.

If you add a new page to the site in the first example, you have to:

1. Create the new page.
2. Add a custom field with the title.
3. Check the new page’s ID.
4. Find the theme file which contains the meta data references.
5. Add a new line in the elseif loops which references your new page first by slug and then by ID

With the second example, you simply:

1. Create the new page.
2. Add a custom field with the title.

No coding, no PHP, no editing themes — it just works. Well, isn’t that handy? This is just basic good coding practice: make your code reusable. There’s absolutely no reason to code something into your WordPress Themes which is not readily transportable unless you’re doing yourself a favor by avoiding an unnecessary server call by hard-coding the site name or other known elements.

The basic difference between these two examples is simple: the first requires you to hard code the ID and page slug for each example; the second grabs the post ID from the existing post object. The second example also has a fall-back if no information has been entered in a given custom field — which is lacking in the original code.

Word to the wise: save yourself some work!

How NOT to use Post meta fields in WordPress Themes
Copyright 2004 – 2010 Joseph C Dolson, Accessible Web Design

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.

“Selling Usability,” by John Rhodes.
Copyright 2004 – 2010 Joseph C Dolson, Accessible Web Design

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!

Let’s find a way to do this right!
Copyright 2004 – 2010 Joseph C Dolson, Accessible Web Design

Obviously, no survey is perfect — but observing the overall scope of responses can effectively expose some aspects of screen reader usage.

In fact, the preliminary results evidence a number of interesting conclusions. Among the statistics are indications that screen reader and web site evaluators who do not have a disability sometimes have a very disparate idea of what is more accessible than those with disabilities — an issue possibly connected to the evaluator’s lack of sophisticated familiarity with the screen readers.

It’s not altogether surprising that we in the web accessibility industry do not always choose the path which is actually most preferred — our impressions are necessarily biased by our own understanding of the technology, our presumptions of what is sufficient information, and our lack of ability to fully ignore the visual input we do receive.

That’s what makes this survey so particularly valuable: it begins to expose the difference between common misconceptions of what is accessible and those which are truly of benefit.

In the evidence in this study are included indications that disabled users would prefer that photos which are part of a page should be fully identified: as a photograph, and as the object depicted. There are indications that while site maps may be valuable, they are not in fact widely used by disabled users. There are indications that on-site search and navigation by headings are two of the most important navigation methods on a site for the disabled.

And, unsurprisingly, there’s fairly definitive confirmation that Flash is difficult for the disabled to use.

Nonetheless, the conclusions drawn from this information aren’t really that simple. With Flash, for example: the problem with Flash is almost certainly that the Flash web sites visited were not designed with accessibility in mind. Flash can be used accessibly, but in 9 cases out of 10 (a number I’m making up for hyperbolic purposes) it’s been developed with no regard whatsoever for accessibility issues. So the issue is not precisely with Flash — rather, the problem is with Flash developers.

The preliminary observations from this survey are well worth reading; and I’m definitely looking forward to seeing further analysis of the results.

Thank you, WebAIM!

WebAIM Survey on Screen Reader Usage
Copyright 2004 – 2010 Joseph C Dolson, Accessible Web Design

Current Version: 1.2.1

Download WP Post Styling.

Read more about this plugin.

Support this Plugin

New in Version 1.2.1:

• Added ability to delete CSS from the style library

New WordPress plugin: WP Post Styling. The plugin serves only one purpose: to create a place to add custom styles which will only apply to the current page or post in your WordPress blog.

Although not widely used on the internet, it’s a valuable magazine design technique to give each article a unique look and feel. A look and feel which shows the face of that article in a light which best represents the subject, topic, or style.

This plugin is intended to make that kind of post-by-post styling simpler.

It’s not that you can’t readily do this in WordPress — either by using a theme which applies style hooks for unique articles, by utilizing WordPress conditional functions to check whether a given page is active, or by whatever other means you might imagine — but this makes it much simpler, since you can simply enter the desired styles into a textarea directly in the post.

Comments and requests should be made at the WP Post Styling home page.

Wordpress Post Custom Styling
Copyright 2004 – 2010 Joseph C Dolson, Accessible Web Design

• Part 1 (Contracts, Site Requirements,Information Architecture)
• Part 2 (Hosting and Security)
• Part 3 (Navigation, Scent)
• Part 4 (Semantics, Structure vs. Design, Universal design)
• Part 5 (Interaction, Errors, and Administration)

After all the labor you put into designing an elegant site which allows users to readily follow the scent of information, all the work dedicated to developing effective semantics and separating your structure from design, it’s easy for you to still end up with a royally screwed up web site.

Designing interactions with your users and managing errors (expected and unexpected) are a critical part of best practices web development. It hardly matters at all whether somebody can find their way to the right information if they encounter so many problems along the way that they lose trust in your site or give up on their purchase out of frustration!

It’s not that difficult to keep user interactions running smoothly, if you just keep a few basic rules firmly in mind:

• Your users don’t care about error codes.
• Messages should tell people what to do next, not what they did wrong.
• Every action taken by a user should have a response.
• Users will do the things you can’t imagine them doing.
• If you’re going to require something, you better mean it.

Interaction Design

Even the most static web site has interactive features. If your site has a single hyperlink, there’s interaction built into your site. A very small amount of interaction, granted, but there is interaction. The interaction information you can communicate using that single link is based on five specific states:

1. link: A link in it’s normative, unactivated state.
2. hover: The state of the link while a mouse-type pointer is hovering over it.
3. focus: In most browsers, the state of the link when focus is placed on the link by means other than a mouse-type pointer.
4. active: In most browsers, the state of the link while the requested action takes place.
5. visited: The state of the link after the action is completed.

HTML doesn’t provide a lot of options by default, but these four pieces of information are critical to making basic interactions effective for all users. Simply communicating to the user that what they are doing has an effect is invaluable.

Similarly, providing interactive information when no interaction is possible can be very confusing. Simply put: if the user can do something with a control, give them information (scent, anybody?) which indicates that this area has a function. If the control is a link, you are able to ensure that it:

• has an appearance different from the surrounding text (blue, underlined,)
• provides information to mouse users that they are in a position to activate the control
• provides information to keyboard or alternative devices users that they have focused on the control
• indicates that you have performed an action, and that the link is activated
• indicates that the control has been used.

Now, from a practical perspective, this much information isn’t always necessary or helpful. For basic links, it’s rarely necessary to differentiate between hover states and active states. Because of flaws in Internet Explorer’s use of these commands, it’s frequently necessary to assign the same appearance to active and focus states.

Nonetheless, the basic principles at work in these five states are valuable, and can be used to guide your approach to interaction design. Simply keeping in mind that form inputs and script responses are not the only ways to communicate interactively with your users will help you shape the behavior of interactive pages.

Error Management

The possibilities for errors in any complex project are endless, so I’m going to contain myself to a very simple example: a standard contact form. Possibly the most standard expectation for many sites is a means for the visitor to contact the site owner (or whatever appropriate person is involved.) Although providing a phone number and address is generally expected — it may not be the preferred means of communication for either party. Since email addresses are essentially a big, open invitation to spam, contact forms are left as the best method of defining a way for visitors to contact you.

The basic contact form I’m going to discuss is asking for four pieces of information: a name, an email address, a phone number (which is optional,) and a written message. It’s not a lot of information, but still leaves a lot of room for screwing up.

When creating a programming example of this form, all that’s generally covered is the basics: how to gather the information in a form and send it to an end user (usually, by email.) This is the core functionality of a contact form, so it’s reasonable that it’s the first thing to be covered.

This is only a problem if you stop programming before working through the rest of the scenario.

Depending on how it’s written, the program described above will do one of two things on being submitted: display a blank screen to the user, or show itself again, with the information submitted removed from the fields. Neither of these options are particularly palatable by themselves, but they each serve a purpose in providing best practice responses to the users.

First, let’s assume that the user is making a lot of errors. They’re putting a phone number in the name field, gave a web address for an email, and left out their message entirely.

Without any data checking, this message may simply be sent off: the site owner gets useless information, and the visitor wonders why that damned site owner never answers his email.

Obviously, doing a little data checking is good for more than just security: it helps make sure that you’ll actually get the information you needed from the form.

Now, having checked this information, we want to let the user know that something just wasn’t working quite right. But this is a crucial thing to do right — I’m sure we’ve all been to forms where one of the following happened:

• The error message didn’t tell you what your errors were, and requires you to use the Back button to return to the form.
• The error message doesn’t tell you the errors, and deleted all the work you did with the form.
• The error message tells you what errors you made, but doesn’t tell you that it also blanked the password field (which was fine.)
• The error message informs you of an error which you wouldn’t have made had the information been available before you used the form.

Ideally, if an error is made with the form, the response will:

• Identify which fields included errors.
• Return the user to the form itself.
• Retain any information the user supplied in the form.

If relevant, the response might tell you what was wrong with the data you supplied — but, ideally, this shouldn’t be necessary. To take passwords as an example, a response error might inform you that passwords are required to include a capital letter, a number, and a non-alphanumeric character. It may appear helpful for the message to tell you this — but in truth, the form should have already contained that information.

If you’re going to check data, you need to make a point to inform the user what data is required before they submit the form. With the wonders of AJAX available, it’s possible for a form to point out your errors as you make them: but you can’t count on the perceivability or availability of AJAX to your user, so this shouldn’t be the only means of gathering the information.

Information which should be made available to the user in advance includes any required formatting (999-123-4567); any required fields; any specifically forbidden information (profanity or HTML); or any specific requirements or restrictions on length (passwords must be at least 8 characters, message a maximum of 1000.)

Preventing errors before they are made is possibly one of the most important aspects of error management!

“Error management” is actually a bit of a misnomer, when you get right down to it. Above, I mentioned a scenario in which a form is submitted resulting in either a blank page or itself: while having the form re-appear following a user error is an absolute must, the blank page introduces an equally valuable scenario: the success response.

After all, “error messages” are merely a subset of all the responses a form might make — having a useful success message is equally important.

Obviously, a blank page is not a great success message. All it tells the user is that something happened — but what that was, who knows? An effective success response should clearly state to the user what happened with their request. Specifically,

• What information they entered.
• What information was sent.
• Whether the script believes the information was sent successfully.
• Whether they should expect any response, and when.
• If a response is expected, what to do if they don’t receive it within the specified time.

Whether the form is offered up to the user again following submission is going to depend on the context. Some forms (like a basic contact form) are primarily intended to be submitted only once in succession. It’s preferable, in my view, for these kinds of forms not to be displayed after submission. Other forms (like a photo uploader) may be expecting repeat use — it’s far more helpful to the user to allow them the option to upload a second image immediately following the first, without having to return to the form.

What about server errors?

Yes, obviously I haven’t addressed basic error messages such as a 404 “missing” error or other important messages from the server. This is a long article already, so I’ll be brief: provide a customized error message. Make sure that it includes pointers to key pages including the home page, site map, and search page.

Site Administration

It may seem like long-term administration is a completely different issue from best practices in web development. After all, administration is pretty far removed from doing all the design, configuration, and development work you’ve worked hard on!

However, you also need to acknowledge that the vast majority of the lifespan of most projects is the time after you’ve finished. Whether you’re going to be maintaining the site yourself, passing it over to an assistant, or passing it off to the client, there are a lot of things you can do to help protect the site.

For yourself, you can establish a style guide for the site: a list of pre-established styles and elements, what they look like, how they’re used, etc. For myself, I use a custom piece of database-driven software which ties a database of elements and script fragments for a given site to the templates for that site. This allows me (or anybody else) to readily browse either for the element I want or the appearance I want and grab the template code I need.

This kind of a tool helps you remember what you’ve done, even if you’re looking at the site a year down the road — and it can provide a guide for your clients or assistants to know what is expected for a given site.

When a client is maintaining the site, the best thing you can offer them (in addition to a style guide) is education and documentation: teach them what they need to know. Document everything they need to do. There’s absolutely no way you can truly cover everything, but you can certainly try.

In the long run, your site belongs to your client, and there’s nothing you can do to prevent them from screwing it up. However, the more you’ve done to make sure they know how to do things right, the better the chances are that they will.

This concludes the Best Practices in Web Development series. Although much has not been covered, those subjects will just have to wait!

Best Practices in Web Development: Part 5
Copyright 2004 – 2010 Joseph C Dolson, Accessible Web Design

• Part 1 (Contracts, Site Requirements,Information Architecture)
• Part 2 (Hosting and Security)
• Part 3 (Navigation, Scent)
• Part 4 (Semantics, Structure vs. Design, Universal design)
• Part 5 (Interaction, Errors, and Administration)

So, we’re finally getting to the meat of best practice web development. This is what people are usually thinking of when they ask about best practices in web design or web programming: actually building the web site itself.

Web design best practices encompass a wide range of needs — everything from the visual look of the design and use of well-chosen markup to the implementation of alternate styles for mobile devices or print shows up in this area. Covering it in one article is, perhaps, ambitious. Fortunately, I’ve written on parts of this subject frequently in the past, so I’ll be providing a lot of links.

It’s important for best practices to clearly separate the structure of your web design (the internal labeling and definition of page elements) from the design elements (the appearance of these elements.) In the last article in this series, I discussed a few key elements of design: not in terms of color, layout, or typography, but in terms of communicating information.

Best practices ultimately leads to creating a universal or accessible design, and this practice hinges on two key concepts: web semantics and the separation of your structure from your design.

The Semantics of HTML

You can argue for days (or years, if you take look at the search results for “HTML semantics” or “web semantics”) on the detailed semantics of how HTML tags should be used. I’ve written on this several times, myself, including articles discussing the value of empty elements, the age-old debate between table-based or CSS layout, among many others.

Semantics are very important. However, when you really look closely at HTML you’ll inevitably notice that it’s not a strongly semantic language — the mark-up language doesn’t even come close to describing all possible uses of the tags. Many tags end up inevitably serving multiple functions.

So what web semantics really require is interpretation. The HTML specification provides one version of this interpretation, with suggested uses and meanings for elements. I’ve provided my own interpretation, as well. There are without question differences of opinion between those documents.

Obviously, you can argue very convincingly that any interpretation which disagrees explicitly with the HTML 4 specification is wrong. Feel free. The core of best practices in web semantics is to use them and make decisions: it’s about thinking, not specific rigor.

We need to differentiate, however, between the semantics of HTML and web semantics. The semantics of HTML are specific and defined: meaning as applied to the elements of HTML. This is a finite list of items, although the complete definition of meaning is less so. Web semantics, on the other hand, describe the application of meaning on the web. This is a more global concept, and applies to all aspects of your web development process.

Web semantics includes everything used to add meaning to your site, providing better comprehension of code and content. Using describe class and ID naming conventions, descriptive function names in server or client-side scripting, or providing helpful comments within your code can all be considered points of web semantics. Best practices means providing a site which is meaningful in both the front and back end.

For specific suggestions about element use, refer to my guide to semantic HTML.

Separation of Structure from Design

This is such an old question to harp on, but the importance of separating the organization of your page from the way it looks has never really flagged.

At a superficial level, it may appear that any markup you use has an effect on the appearance of your site. After all, there’s a clear visual difference between unstyled text marked as a heading and unstyled text marked as a blockquote! However, this visual difference only truly exists because the description “unstyled” is truly a misnomer.

If you disable stylesheets on a web site, you’ll see an extremely plain view of the site. It is not precisely “unstyled,” however — the design has simply been reduced to the default styles applied by the browser. In general, every browser has very similar defaults — but they’re not exactly the same. This is one of the reasons that it’s common to begin a stylesheet with a set of reset styles.

If you conscientiously remove the browser default styling, it can make your own development easier: the slight differences between browsers can then be ignored.

The point is that you should never place anything in your markup which exists purely to create a different appearance. Attributes or tags which define font faces, colors, or styles are obvious problems — but the use of small or strong can also be problems. It’s not that you should never use small: but your use of the element shouldn’t depend on the text being rendered smaller than the surrounding text.

It might not happen, after all.

This is one of the key complaints about using tables for design layout. A table is designed to organize information by providing easy access to it in a matrix. The columns and rows visual appearance of a table is a formality used because it is an expected way to view this type of data organization.

When you take a table and use it to layout your design, you are violating the separation of structure from appearance: your design is now dependent on the default organization of tables. Should somebody attempt to re-organize your table (for example, to linearize the information,) they may encounter a radically illogical data structure.

Fundamentals of Universal Design for the Web

The goal of universal design is very simple: make the information in your website available to every person or device which attempts to access it. This includes mobile devices, search engines, assistive technology, disabled users, and standard desktop browsers.

Universal design is where we bring everything above together. Attention to web semantics and a strong separation between structure and design give your web site at least a fighting chance of being universally usable. Obviously, you can still screw things up!

In the same way that following web standards doesn’t mean that you’ve made a web site accessible, following best practices for general web development doesn’t mean that you’ve made a site which will be great on a hand-held device or with a screen reader.

Different devices (like people) have different special needs.

Creating a web site which is truly universal requires you to be aware of the special needs of every device you’re working for — but a few basic principles will get you 95% of the way there.

The Principles of Universal Design provided by The Center for Universal Design at North Carolina State University are a good guideline for thinking about universal design. Although these principles are truly designed to be universal, in that they are intended to be applied well outside the realm of web development, the basic principles are sound in any context.

If you break the concept of universal design down to a single core issue, it could be that dependencies break access. Whenever you set up a situation in which a specific technical or design element must be present (a dependency on Javascript, a requirement that a control matches the description provided, or a requirement that a user must see a given image, for example,) then you are creating the potential for design failure. Avoid creating anything which depends anything out of your control.

Knowing what is and isn’t in your control (and, more importantly, what seems like it’s in your control, but really isn’t) is critical to best practices in web development. Acknowledging that although you can set the color of the text, you can neither guarantee that a visitor will be capable of seeing that color nor that the text will in fact be that color at the point that a visitor sees it is a critical step in understanding universal design.

Best Practices in Web Development: Part 5 (published on Friday, September 5th) covers interaction design, error management, and long-term site administration.

Best Practices in Web Development: Part 4
Copyright 2004 – 2010 Joseph C Dolson, Accessible Web Design

• Part 1 (Contracts, Site Requirements,Information Architecture)
• Part 2 (Hosting and Security)
• Part 3 (Navigation, Scent)
• Part 4 (Semantics, Structure vs. Design, Universal design)
• Part 5 (Interaction, Errors, and Administration)

You could say that this part of the series is really breaking the concepts of information architecture down into components immediately relevant to web development. Practically speaking, I’m going to cover the necessities of navigation design, the concept of “scent of information” and the question of design “noise.” (Canonicalization was supposed to be covered in this part of the series, as well, but I’ve moved it.)

Navigation design is obvious: the primary organization of all aspects of site navigation. This is an area of web design and development where it’s very easy to go massively and devastatingly wrong — like most best practice concepts, avoiding the pitfalls is 90% of the battle.

“Scent” refers to information design which provides “clues” to help show the user where they are, where they’ve been, and how to get where they need to go. Planning your site should include careful planning to think about these processes.

“Noise” is a term I’m using to describe the opposite of “scent.” Noisy elements of design are those elements which detract or distract from a user’s needs. They may generate confusion or prevent users from following the path of action they need.

Navigation Design

Navigation design has two parts: organizing the documents and sections of your site into links, and generating the visual and interactive method which will be used to access that navigation. It’s important to do this in the correct order — and this is the point in the development process where you simply need to know the scope of content on the web site.

It’s neither necessary nor desirable to actually know every single item which will be on the site. In fact, it’s usually not even possible. A website should grow after it’s initial development, so you should always provision for the addition of future documents. What you need to know now is as much as possible about the documents which will definitely be on the site.

To get started, ask your clients for this information:

• A list of content categories,
• A list of representative content titles and summaries,
• A list of additional features which will require access.

Ideally, you’ve already got a lot of this information from the contract phase. But, if not, now is the time to get it.

For the first steps in navigation design, you’re going to focus exclusively on the content and features.

The organizational needs will be different from site to site. Obviously, a site which is focused primarily around a specific tool will need to primarily concentrate on getting people to that tool. Text content, such as help files or related articles, will automatically be relegated to a secondary position in the navigation. In general, however, this article is dealing with text and content oriented sites: sites which need to communicate certain types of information to users.

A classic method for categorizing documents is to perform a simple card sort. You can perform this test with as large or as small a test group as you feel comfortable with. Restrict users to people who have a reasonable chance of being able to use the information — you may not want to use your grandmother to sort documents on structural engineering. (Depends on your grandmother, naturally.)

Ultimately, you may want to perform two separate card sorts: an open sort (with no established groupings) and a closed sort (using the client’s requested groupings.) For the sake of brevity, I’m assuming that you’ve worked with the client to refine the requested categories.

The guidelines for the process are simple: write the document titles (and brief descriptions, if the title is ambiguous) on index cards. Give people a pile of cards (usually between 30 and 100), and ask them to sort them into groups of like items. This is an excellent way to gain insight into how potential users of the site might expect to find information.

A card sort certainly shouldn’t be your only method to find a logical navigation structure, but it will provide valuable clues concerning what might be expected by visitors. You should also realize that disagreement between sorters doesn’t mean that you need to pick one option: it may simply mean that additional lists of information using different sorting mechanisms may need to be available.

Your ultimate goal in sorting information is to avoid requiring users to look in more than one place: the apparent likelihood that a given document will be found in one category should always lean in one direction.

The second step is relatively simple: building and designing the navigation. Best practices pretty much insist on accessibility and the use of web standards to construct navigation. I’ve written an extensive article on accessible navigation design already, so I’m simply going to refer you to that article for this section.

Scent of Information

Providing a strong scent of information is a good follow up to categorizing your information. Having spent all this time filing information away, I’m sure you noticed that some information just flat out belongs in more than one place. A classic example (for almost everything, actually) is the iPod. Is it computer equipment? Is it audio equipment? What about entertainment equipment?

Ideally, you want to provide enough information about your categories to help users visit the right category first — and not by using the site-cluttering cop-out of putting your items in all relevant categories.

Seed your navigation with extra information

When there’s a possibility of doubt, one of the first steps you can take is to add information which describes your category. Instead of just listing “Computers” in the navigation, say “Computer: Laptops, monitors, mice, keyboards.” You can’t (and shouldn’t) list everything in the category, but providing a representative sample can help users target their navigation more accurately.

Provide navigation to related information

A second method you can use it to provide links to related information. When you have a site set up where there’s a possibility of confusion, you should be able to identify most of these potential problems in advance. Using the same example, you may want to provide a link to iPods and digital music players if somebody is browsing under sound cards or audio software.

Use descriptive linking

A link which tells you precisely what it links to is far more valuable than a generic link text. It’s more likely to attract the eye, more likely to result in an action by the user, and will help your users quickly target the right document.

It’s not just for accessibility that you want to avoid repetitive or meaningless link texts. From a usability or marketing perspective, the right words can make all the difference.

Use meaningful trigger words

What behavior do you want to encourage? When somebody writes “Click here,” they are obviously interested in the short term: they want a click. If somebody writes “Read ‘The biography of a whale’ Now” they’re asking you to read the document. Similarly, using words like “Buy,” “Explore,” or “Hire,” you’re providing a specific, task-oriented clue within the text of the link. Because of this, the user knows better what to expect when they follow the link — and are more likely to follow the link they really want first.

Or, thinking persuasively, are more likely to want what you’re trying to offer. It goes both ways.

Design Noise

On the opposite side of the coin from scent, we find noise. Bad information, information pollution, stink — whatever you might want to call it, the end result is the same. This is information which leads the user the wrong way.

Identify your primary goal

If you’re a sales-oriented site, the strongest scent should be provided to guide users to products and along the purchase path. You may want to provide a lot of essential and valuable information about your products, about your business, or about the industry you’re working in — but if information isn’t your primary business, you should let these parts of your site take somewhat of a back seat.

Link to your documents accurately and understandably

Make sure that whatever you’ve used to link to a page is accurate. If you’ve stated that an article contains certain information, or has a certain product on it — it bloody well better! This seems like it should be obvious, yet I can’t even begin to count the number of times I’ve found myself following a seemingly valuable link just to be stymied by the document itself.

Following a related logic, you should be careful to link the document in a manner which is readily understood. If you’re providing a tool for people to estimate what the salary for their desired job should be, don’t link it using “Proximal Salary/Earnings Indices by Region.” Instead, link to it saying “What should you earn where you live? Find out here!”

Using easy language may sometimes be less precise, but will almost always be more useful.

Don’t try to give everybody everything at once!

Too much information crammed into a finite space means only one thing: you don’t know what your users need. And as a result, your visitors probably only need one link — the back button in their browser.

The reason for information organization, at heart, is to reduce the problem of information overload. It’s certainly possible for people to find information given a page of 700 links, but is it an efficient way of working? No. Ultimately, it’s far faster to follow two or three links with a strong scent than to have the possibility of offering a single-click path to information.

Additional Resources

• Information scent: helping people find the content they want
• Deceivingly Strong Information Scent Costs Sales
• Card Sorting: A Definitive Guide

Web Development Best Practices: Part 4 (published on Wednesday, September 3rd) covers semantics, separation of structure from content, and the fundamentals of universal design for the web.

Best Practices in Web Development: Part 3
Copyright 2004 – 2010 Joseph C Dolson, Accessible Web Design