An interesting thought in indexing and handling page structure is the concept that different areas of a single page can be identified and considered independently from surrounding bodies of content. This particularly applies to specific and readily identifiable data-types, such as phone numbers, postal codes, or abbreviations; but can also be extended to include broader content labeling.
A well-structured XML document has an absolutely clear labeling system for data built into the structure. If you take any RSS feed, for example, the elements which identify <title>, <link> or <managingEditor> can’t readily be mistaken.
A well-structured, semantically sensible XHTML or HTML document doesn’t offer nearly the same degree of data particulation — - the higher level data elements can sometimes be fairly clear, as is the case with <address> or <cite> elements, but other potentially valuable elements end up providing relatively neutral value: <h2> or <div>.
Read more: Thoughts about Content Labeling and Data
Example:
Visit this site! http://www.joedolson.com/
I run into this, or into something like it all the time, and it’s pretty understandable why. Obviously, if you don’t know how to create a hyperlink, or if you’re working with a CMS which will automatically convert a URL into a hyperlink, this is the most reliable way to provide access to somebody else’s site.
Either they have the URL, and can use it “straight up” if they know how, or they can follow the hyperlink generated by the system. Nice and easy. I understand perfectly well why an inexperienced content manager might make use of hyperlinks au naturelle, or so to speak.
Read more: On the usability of contextual URLs
At least, in the final reckoning.
Something which comes up over and over in my work is the tendency of clients to request design changes which I don’t particularly care for. This isn’t to say that they’re ugly, per se — - after all, the fact that I don’t like them isn’t actually equal to “ugly.”
Early on, I would argue with clients concerning these design changes — - try and get them to see my perspective, etc. But the fact is that aesthetics are not objective. Opinion matters; and it’s ultimately the client’s decision.
Now, I only argue with decision which cause problems. You want that to be blue instead of green? Fine. Doesn’t matter to me that it’s going to clash with the rest of the color scheme. But you want that text to be blue against an orange background? That, I won’t do. That’s the kind of decision which will render the text unreadable — - and I’m not willing to do it.
Occasionally in my consulting practice I encounter designers (or stories about designers) who are so wrapped up in control over their design that they barely consider the client’s needs, let alone the needs of usability and accessibility. That’s unfortunate; since in the end, what your website looks like just barely registers for many visitors.
I sincerely believe (unscientifically) that most visitors only notice website design in one of three ways:
- The design prevents them from effectively using the site.
- The design is absolutely spectacular.
- The design is absolutely horrific.
Do you really want your design to be attracting attention? Certainly not for reasons numbers 1 and 3, and although the second reason is positive, it’s not necessarily best for every site. Incredible design doesn’t necessarily support your business in the best way; it could just get in the way. This can’t be decided universally, of course — - and it’s never a bad thing to strive for a great design.
It’s hard to ask questions about whether people noticed the design of a site. After all, it’s rather a quantum query: once you’ve asked, they will observe. The act of asking changes the experience of the visitor. Even in a usability test, it’s hard to identify this observation. Even though you can set up the scenario more effectively, if your testers are still aware that they are testing the site, they will tend to be more observant than otherwise.
You can’t TELL somebody to just “act normally” during a test, unfortunately. It doesn’t work that way….
Nonetheless, the rules I will work to avoid are clear: don’t make it horrible, and don’t let it get in the user’s way. Otherwise, what it looks like is open territory. I’ll try to make it look as good as I can, but if a client wants a change — - they’ll get it.
This is not a technical article. You will not learn how to code AJAX by reading this; either in an accessible and usable fashion or otherwise. This is a conceptual article. It will run through basic user-interface issues with AJAX (and other rich media). These are the reasons that AJAX functionality can be a problem for users — - if you consider these issues carefully during development, it should greatly enhance the usability of your end product.
The basic limitations encountered with AJAX are threefold:
Best practice in any rich media format should always ensure that these three limitations are dealt with for all users.
Read more: Accessibility and Usability issues with AJAX
Shari Thurow, a regular on the search marketing speaking circuit, just published an article in the ClickZ network addressing three SEO Myths and Misconceptions. Although the article is generally pretty decent, I do take some issue with how she addresses one area — - the question of replacing images with text.
In fact, my complaint is with what I perceive to be the basic assumption she’s making in this SEO Myth: that web developers and marketers are recommending that web sites replace graphic images with CSS-styled text.
Read more: Replacing Images with Text
Although I deal with issues of usability fairly regularly, usability is not fundamentally one of the chief areas I work in. It’s certainly an area I’m very interested in, and is closely related to accessibility, but I haven’t been involved in any full scale usability testing. So, it’s rather interesting to me that one of the first sponsors of this blog should prove to be the makers of a usability testing software package called Morae 2. jo
This is not a paid blog post, although the product was being advertised on this website.
Read more: Usability Testing Software
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:
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.
Return to Top
