Search engines and humans are always looking for relevance. When we first open a document on the web (or in our mail), one of our first actions is frequently to determine whether this document is relevant to our needs. In the case of e-mail or physical mail, this is entirely a “push” experience — messages are sent to us, and we evaluate them for relevance. Spam survives largely on that obscure edge case where we identify their messages as relevant.

When it comes to web documents, the experience is more of an even exchange: we provide search engines with instructions about what we want to find and they send back a response which we both hope will meet our concept of relevance for the given instructions.

Sales and conversions are driven by relevance.

But humans and computers perceive information and relevance in very different ways. This is a challenge for search engines, which need to be tuned to fetch information which appears relevant to a human searcher on the basis of a computer’s understanding of the document. This is also a challenge for people with disabilities — while a person with a disability will generally have the human ability to perceive relevance, their perception of information on the web may be filtered through a computer. For a person who requires the use of a screen reader, this filtering amounts to receiving only the facets of information which are made available both by the author of the document and by the assistive technology they are using.

So, in any online search for information, a person with disabilities is encountering three primary barriers to finding relevant information:

• Did the author consider their needs when the document was created?
• Does their assistive technology offer the resources to transfer that information?
• Did the search engine return information which will be considered relevant to a human?

Everybody encounters the flaws in search engine results. Although searching is far more sophisticated than it was just a few years ago, it is still limited. (And appears to be getting more and more subject to the filter bubble effect — though that’s a different subject.)

Some words have multiple meanings, which are dependent on context. We all use context to guess these meanings: humans use tone of voice, facial gestures, body language, location, environment, and many other factors to assess what the probable meaning of a word may be. Search engines have limited access to this information — some information is mechanically detectable; such as location, and to some degree, environment. They know what words you used to search, and they may know what else you’ve recently searched for. They can use this information to try and better assess your intent and deliver the most relevant information to you.

When it comes down to what information is on a web document, search engines and screen readers have very similar information. As a result, search engines and users of screen readers have similar limitations in their ability to quickly identify relevance on those documents. In some ways, search engines have an advantage, since they can absorb all of the information on the page far more quickly than any human can.

Where a search engine might simply absorb an entire page and move on, humans scan. A visual user will quickly glance over the page, identifying images, headlines, navigation elements, and noticing a few key words along the way down the page. That quick scan of the page can frequently provide all the information the user needs to decide the document deserves another look, or is clearly irrelevant.

Users with disabilities also scan, when it’s an option. This is a place where the capabilities of assistive technology and the attentiveness of a web author really come into play.

For a screen reader user, it’s clear that there won’t be any quick scan of images. Although images may have supporting alt attributes, it wouldn’t be any real savings of effort to check. They can scan through descriptive link text, accessible navigation, and headings, however — if they’ve been provided in a useful fashion. Repetitive link text, headings replaced with images without alt attributes or an inaccessible font replacement method, any of the multitude of inaccessible navigation techniques: they may not prevent the user from getting at your content, but they will absolutely prevent the user from being able to get an overview of the content by scanning.

I mentioned above that search engines have some degree of advantage due to their speed of information absorption. The slower speed with which humans absorb information means that where a search engine might find great relevance caused by repetition of key phrases (or it might not — I would call that keyword stuffing, myself); a human will instead be overwhelmed by the same repetition.

This comes back to context. A human visitor to your web site doesn’t care at all how many times you’ve stated ‘blue widgets’, unless it’s less than once. From our perspective, if you said at the top of the page that you’re selling blue widgets, we understand that everything from that point on is in the context of a blue widget. If you actually say, over and over again, that we’re reading the blue widget specifications, and the pricing on blue widget shipping, and that your blue widget support is superlative — we’re just going to get overwhelmed. It’s unnecessary, and creates the sense of what I’m choosing to call “information blur” (the effect when information is lost due to excessive adjectival description).

What’s my point, again?

Relevance is a prime factor in converting a web visitor into a paying customer. However, humans and computers perceive relevance using very different factors. The best performing web site is going to be created according to the compromise rules which will provide the most relevant information to both humans and to search engines. Visitors with assistive technology, and particularly screen readers, are an interesting test case in this scenario, because the information they receive is filtered in a similar manner to that which a search engine will see.

Creating accessible content: it’s not just the right thing to do.

Something I’ve occasionally found irritating when developing a web site outside of it’s long-term residence (on a temporary URL, in a subdirectory, etc.), is having to choose between either adding relative URLs, the URLs for the current address, or the URLs for the final address for internal links in the development site.

Obviously, using relative URLs will work, but I’m generally reluctant to use them in any CMS (Content Management System), knowing that I may later want to provide access to that content elsewhere on the site. One of the luxuries of a CMS is the ability to use a single source for content which is used in multiple locations, after all — but I don’t much like paying for that with broken links.

However, and especially with a larger web site, it’s not exactly a lot of fun to have to either do a big search and replace or manually run through and replace URLs at the time of launch.

Fortunately, WordPress’ shortcodes API provides an insanely easy way to get around this.

Add this to your theme’s functions.php file:

add_shortcode('url','home_url');

If you’re not comfortable editing your functions.php file, you can also download it as a plug-in.

This very, very short line of code will provide you with the simple inline shortcode [url], which will provide (obviously) the home URL for your WordPress web site.

You can use this in any page or post when you know the URL will be changing like this: <a href="[url]/pretend-page/">.

Even if you’re not planning on moving your web site, it’s clear that typing those five characters is probably a much faster way of getting your home URL than typing it out!

Jane Wells, the WordPress user interface lead, posted a call for accessibility reviewers for WordPress 3.2 and the new Twenty Eleven theme. I would dearly love to help with this, but in all practicality I don’t think I can commit to it right now. However, I hope that if there’s anybody out there with a good handle on accessibility issues and a little extra time they’ll volunteer to provide their thoughts!

WordPress has demonstrated an interest in accessibility, but they need your help!

If you’re interested, Jane has asked for names and information to sign up (although, so far, it seems like most people have just gone ahead and started making comments directly.)

Show your interest here: Make WordPress Accessible

Keep in mind, please, that the WordPress development team are asking for help, not criticism. They are asking for help because they know that they aren’t accessibility experts — keep the tone constructive! WordPress is a great application — and from the vantage point of making the web more accessible, making such a popular and widespread application as accessible as possible would be huge progress.

One of the main reasons for using a content management system (CMS) is that it can provide great advantages for future growth. Having the easy ability to extend your software to create new types of documents (as with WordPress’ custom post types), or to simply add new pages and new features without needing to scrap everything you currently have is a huge advantage.

However, much of that advantage can be lost through poor planning.

If you have any thoughts — at all — that you might want to add additional content to your web site in the future, it’s really not a bad idea to start planning right away when you’re building your web site. A little forethought now can save a lot of trouble down the road.

It’s not necessarily the case that your problem will be absolutely and insurmountably limiting — in fact, that’s extremely unlikely. It is very likely that it will be an inconvenience which will cost you time and money.

For example, let’s think about the most basic key element of your web site: the navigation. If you’re making changes to your web site which included adding, re-naming, or removing documents, you’re going to be making changes to the main navigation. With that in mind, does it make more sense to take the CMS navigation and style it to do what you need, or to remove it and replace it with a static menu that looks like you want it to?

Realistically, you can probably have it both ways — in my experience, a skilled web developer can take CMS output and make it look however you want. But I’ve certainly encountered many circumstances where that simply wasn’t what was done — which made later changes significantly harder than they needed to be.

This is just intended to be a quick post, so I’m not going to go into extensive details on all the possible ways that you can fail to plan for future changes on a web site — but I do want to make a few quick points:

• Unless you’re planning on your business failing, you should always assume that your web site will grow and change.
• Your web site will never be finished. It is a living document.
• You should always be prepared to simplify. Change is not always additive. Removing the right things can be a huge benefit.
• While building a new web site, it’s not at all unreasonable to ask your developer how much work it would be to change “x”, where “x” is something you may want to do next year. But it’s probably better to find out even sooner.

However much planning you do, not every change will be quick and easy. However, even though a complete redesign will always be a lot of work, adding a new page shouldn’t be.

I’m a firm believer that the first step to creating effective accessible web sites is to understand the nature of disability. Learning all the technological elements which can affect that accessibility is also necessary, but if you don’t understand why you’re employing the technology, you’re far more likely to make simple but costly mistakes.

My latest article, 10 Common Developer Mistakes, published at Ecommerce Developer, covers examples of some of those still-common mistakes which are fundamentally the result of a failure to understand how other people perceive and interact with your product.

What makes a web site inaccessible is your fault: your web site is not inaccessible because your visitor has a disability, it’s inaccessible because you have placed barriers on the site. These barriers are caused by a failure to understand how other people perceive or interact differently from yourself.

A self-focused perception of the world can be very damaging to accessibility or to usability. It’s not that you can’t build a great and even successful web site while primarily thinking of yourself as the user; but your site’s ability to cope with the needs and expectations of other users is greatly reduced if you aren’t able to understand how other people will interact with your web site.

First of all, I released version 2.2.7 today. This version is mostly a bug fix and error message improvement release, intended to help users solve their own problems more easily, as well as enhancing the overall stability of the plug-in with a wider variety of installation scenarios.

Second, I want you to know about my WP to Twitter Fundry page. Fundry is a site which helps developers raise money to improve their projects. There are a handful of pledges already, but I’m hoping to be able to use this as a way to both fund improvements to the plug-in and to know what kinds of changes are really the most desired in the user base.

Finally, I thought I’d mention that Vladimir Prelovac has recently released a new plug-in called WP Quick Deploy. This plug-in is meant to provide people with a method to quickly and easily install a variety of their favorite plug-ins, and he’s chosen to include WP to Twitter as one of the recommended tools available in the social media section of his plug-in. This sounds like a great time-saver of a project, especially for developers, so I highly recommend you take a look at it!

My Calendar version 1.7.0 is about to be released. This version contains a large number of significant changes, some of which may have consequences for your existing installation. I have taken every precaution I could, but there are aspects inherent in the automatic update process which cannot easily be tested thoroughly in advance. In preparation for the release, I strongly recommend that you make a copy of your current styles and note the settings of the Upcoming and Today’s Events widgets.

Both widgets have been entirely replaced with the WordPress Multiwidget class, which will allow you to use multiple individual instances of your widgets.

The stylesheet editor is moving from a database-driven editor to a file-based editor, which will increase the cacheability of the plug-in styles, improving performance of your site when using the styles. This also comes with the ability to choose between several different stylesheets.