Give Your Content Some Attention

If you’re using a content management system (CMS) there’s always the temptation to assume that your content is fine. It’s being “managed” right? So what could possibly go wrong?

Plenty.

Use the New Year as an opportunity to review the quality of your content. While most CMS systems include some form of workflow, you might be surprised by some of the things that slip onto your website. Be on the lookout for content that is outdated, inaccurate, irrelevant, or just plain incoherent.

Validate Your Website’s Relevance

This is a different sort of validation than you’re probably used to, and one that definitely can’t be performed by an automated testing tool.

Website’s have a tendency to veer of course (some more rapidly than others). If it’s been a while since your organization launched its website now may be the time to verify that your site is still an accurate representation of your business.

If it’s been more than a year since you developed your current site you might be surprised to find out that many of the goals and assumptions that drove the initial development have changed.

Keep in mind that the following things have probably occurred since your website launched:

• Your understanding of the web has changed
• Your understanding of your customers has changed
• Your customers have changed
• The web has changed

Think About Your Customers

And by extension, stop thinking about your organization. Too many websites are still organization centric with an emphasis on departments and divisions. Most customers don’t have a clue what department they need to contact. Instead, they typically come to your website with a specific task in mind.

Have you identified the most common tasks that your customers have in mind when they come to your website? Does your website support your customers in completing these tasks?

If you’re not sure what your customers are trying to accomplish, and whether or not your website is actually helping them achieve their goals, there’s a pretty good chance that your website could use some improvement in this area. It might be time for a user survey.

Review Your Site Navigation

Site navigation is another area where a CMS can lull webmasters into a false sense of confidence. If your CMS allows multiple users to make modification to your global navigation and your site has been online for more than, say, a week, you probably have some review and cleanup to do in this area.

As sites grow navigation items has a tendency to sprawl. Without regular attention your site navigation will grow out of control and turn into an unusable mess of unrelated links.

Don’t assume that all of your site users immediately head for the search engine (although they might eventually end up there if they can’t easily navigate to what they’re looking for).

Take some time to review your navigation structure and ensure that it’s still coherent. Conduct ad hoc user testing to ensure that others can use your navigation as well. Just because something make sense to your web team doesn’t mean that it will make sense to your customers.

Be on the look out for:

• Navigation labels that use jargon.
• Sub-navigation items that may be misfiled.
• Navigation that leads to areas that have no content.
• Missing navigation items (hard to look for, but you’ll know them when you don’t see them).
• Misfiled content (the result of authors who quickly add content but aren’t sure where to put it).

Identify Accessibility Problems

Even if your site was developed to be WCAG or 508 compliant, accessibility issues can still creep into your site over time. Unless accessibility review is part of your ongoing workflow, chances are your site has at least a few accessibility issues that require your attention.

This is another area where CMS systems and distributed authoring can create problems. In a perfect world every contributor would be knowledgeable about accessibility and would work diligently to ensure that their content is fully accessible. Since we don’t live in a perfect world you’ll want to review your site for any issues that may exist.

While accessibility scanning tools are no replacement for manual review, they can be a good starting point for reviewing a large number of pages.

Be sure to document any accessibility issues you uncover for future reference. Also, make it a point to meet with any authors who are contributing non-accessible content. Use your accessibility review as an opportunity to educate your web contributors.

This is by no means a comprehensive list, but it should be enough to keep you busy in the coming months. If you can think of similar suggestions that we’ve left out, please let us know in the comments. Also, if you’d like us to expand on any of these suggestions in more detail, please let us know.

For those of you who aren’t familiar with the term, a folksonomy is basically a taxonomy created by the people and for the people. A community of users collaborates by “tagging” various types of content with user created keywords. This concept is flourishing on a handful of community driven sites that all seem to have a certain addictive quality. I think the best way to fully grasp how folksonomies work is to dive into one of the sites that makes use of the concept. Flickr, 43things, and del.icio.us are good places to start. Given the success of these early experiments in group tagging I have no doubt that we’ll be seeing folksonomies implemented on all sorts of sites in the very near future.

Lately I’ve been thinking about one particular artifact of the folksonomy phenomenon — the folksonomy menu that serves as a sort of buzz index providing users with a quick visualization of the most popular tags (technically I think it’s called a weighted list). Popular tags are displayed in a larger font and it’s relatively easy to identify hot topics at a glance. This visual representation of the popularity of any given tag is undeniably cool. However, once the coolness factor wears off it becomes fairly obvious that these menus are also not very accessible.

I realize these sites are currently trail-blazers and they deserve to be recognized as such. I have no intention of detracting from the innovative work that’s being done. My concern is that once folksonomies enter the mainstream, the next wave of sites implementing them will likely begin a wholesale copying of the work that’s being done by these innovators — markup and all.

Also, I need to point out that folksonomies are community driven. A few minor changes to the existing markup would go a long way towards making these communities accessible to everyone.

Analysis of the accessibility of weighted lists on five websites using group tagging and folksonomy

I spent an afternoon looking under the hood of the folksonomy menus on following sites:

• Technorati
• Flickr
• 43 Things
• del.icio.us
• MetaFilter

I was somewhat surprised to find that the markup on each of the folksonomy menu pages was entirely different. While all sites were basically implementing the same type of menu they all arrived at their respective results in different ways. Given this finding, I was even more surprised to note that each site shared most the same accessibility problems:

• Unstructured Links: With the exception of Technorati, each of these menus was rendered as an unstructured collection of links separated by only whitespace or a non-breaking space entity. It seems fairly obvious that these links constitute a list. Rendering these items as a list would provide visually disabled users with more feedback regarding the number of links as well as the ability to skip the list entirely.
• Extraneous Markup: While not technically accessibility related, each of these pages uses a fair amount of extraneous markup to achieve its goal. I encountered a startling number of span elements accompanied by inline style declarations. And while Technorati wins points for realizing that these links are actually a list, they should also win an award for the most creative use of the EM element.
• Absolute Font Sizes: Without exception fonts were defined in pixels. As a result I was unable to resize type in Internet Explorer. This was somewhat puzzling given the fact that it would be fairly easy to implement the font size variations using em’s. del.icio.us actually went as far as defining the font size in fractional pixels extended to the 13th decimal place. They must be using one of those 30 inch Cinema Displays .
• Lack of Context: These menus currently require a user to actually view the page in order to discern the relative popularity of tags. There is no additional context that could be used to determine popularity. Given the fact that the difference in font size for any pair of tags can be as little as a single pixel, additional context would also be useful to those who are not visually impaired.

Recommendations:

The good news is that these issues are all easily fixed. Most of the solutions will be quite obvious.

• Use Lists: Lists have become the standard way of rendering a collection of links. Lists provide additional structure that can have a significant impact on accessibility.
• Avoid Inline Style Declarations: I’m sure there’s room for debate on this recommendation, but personally I would assign a class to each LI element. There’s really no reason for extraneous elements or inline style definitions.
• User Relative Font Sizes: Defining font sizes in em’s would allow users to easily resize type in any browser. Fractional em’s are easy to calculate, and they make more sense than fractional pixels.
• Add Context: While it’s not a perfect solution, it might be a good idea to add each topic’s relative rank to the title attribute of the anchor. Something like title=”Politics – Rank 3 or 10″.
• Consider Alternate Views: There’s no reason that the current standard folksonomy menu has to be the only way of representing the relative popularity of tags. An ordered list sorted by popularity would eliminate some of the need for visual clues. Adding a link to such a list would provide users with more choice while addressing accessibility concerns.

Here’s a page demonstrating my recommendations.

I realize that it can be challenging to focus on these types of details while innovating in the way that each of these sites has. While folksonomies are still relatively new, I think we’ve reached a point where it’s time to start thinking seriously about best practices.

Abbreviation: Making a word shorter by removing lots of letters. Some examples: etc, req’d, cont’d, or ms.

Acronym: Where a series of letters (usually the first letter of each word, which is why we get some pretty strangely named laws in the United States) takes the place of a word. Examples include: NBC, USPS, HTML.

In this day and age, you’re more likely to encounter an acronym than a million bucks, and figuring them out can be a full-time occupation. Using acronym is the best type of accessibility — it opens up the crazy world of acronyms to everyone. No longer will people be reading your website and scratching their heads over the crazy alphabet of non-words on your site.

Adding acronym to your documents is fun and easy. The basic code is:

<acronym title="United States Postal Service">USPS</acronym>

I know, I know — so little work for so much good.

Okay, here’s where things get a little tricky. It is considered good writing to spell out the meaning of an acronym the first time it is encountered in a document. Thereafter, it is presumed the reader can a) remember the meaning, or b) return to the original definition if their brains can’t retain the information. It is my belief that you only need to spell out abbreviations and acronyms on first usage — it is your call as to whether you wish to code each instance. As far as I can tell, the guidelines are flexible on this point (please correct me if I’m wrong), and I think most readers are accustomed to the long-established usage rules. That being said, it won’t hurt anything if you decide to go overboard.

Update: It’s possible the acronym element may become deprecated, the theory being that acronyms are a subset of abbreviations. Hmm. I guess I can buy that. Of course, standardizing on abbr won’t help when it come to Internet Explorer, because, unless a miracle happens and everyone upgrades to a new, magically compliant browser, it still won’t read abbr.

Update 2: The current draft for Web Content Accessibility Guidelines 2.0 offers specific advice about the use of abbr and acronym: first appearance. This conforms with standard writing rules, so should make things standard for everyone.

But why? Everyone knows what I mean when I say req’d. It means required. No, it means requested. No…I’m absolutely, positively certain it means requisitioned. Or maybe not.

You could argue that the meaning of the abbreviation will be made clear from context. And your tax return forms are a breeze to complete, right? For example, in the following sentence, my meaning is perfectly clear:

What was req’d?

Silly example, and I’m sure nobody writes that way, right? But can you be so sure that your meaning is perfectly clear to every person reading your website (and every person listening to your website)?

Why not make it easy on everyone and expand your abbreviation. The markup is ridiculously simple (even more so if you have an HTML editor that reduces most of the work to a mouseclick or two. To expand an abbreviation, simply do the following:

<abbr title="requested">req'd</abbr>

Yes, I know. Too simple. So simple you don’t know why you haven’t always done it (probably that’s because it hasn’t always been an option). Now when your abbreviation is encountered, screen readers will spell out what you mean and a tooltip will appear when other users mouse over the item. Yes, I’m perfectly aware that this wonderful feature isn’t fully supported by browsers everywhere (but, frankly, isn’t it time we forced Microsoft and others to comply with the standards?), but abbr is a wonderful invention. Use it!