On the Perception of Relevance

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.

Quick Tips: URLs in WordPress development sites

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!

WordPress Call for Accessibility

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.

Page 1 of 11

Return to Top