Personally, for elements where accessibility matters, like navigation menus, etc. I prefer hiding those elements with a short javascript statement I put right after the element I want to hide. This way the user does not notice the element getting closed and best of all, it remains accessible to all.

Quoting:
“The Surf Right Toolbar is really for anyone who wants to adjust the way they view content on the web to make it easier to read. This could include people with mild disabilities, the elderly, people with reading problems, cognitive problems, using dial-up, photosensitivity and so on.”

You can grab the beta, right here.

• Part one builds a resolution-dependent page layout and demonstrates the use or a reset style sheet.
• Part two demos the use of CSS selectors and dives into the realm of scripting and adds some neat effects using the jquery library.
• Part three covers the integration of ajax technology and starts up with a shout-out on resolution dependence.
• The fourth and last part in this series is about testing for extensibility with 8 benchmarks to thoroughly bulletproof your site.

Overall this is a carefully written Tutorial worth spending time on. Thumbs up!

The reason for the update is because version 1.0 was originally published back in 1999 and in that time both web browsers and assisting technologies have evolved considerably.

Note that the WCAG Samurai Errata is not a standalone document, you should really use it as an update along the original WCAG 1.0 guidelines.

Also note that there is a Web Content Accessibility Guidelines 2.0 working draft available, lastly updated in December 2007, which you should consider to use over the 1.0 counterpart.

The Basic Search Box

The search box should be kept simple, consisting of a text input element and a search button. While other fields or drop-down lists can be added to favour scoped searching, research has found that it is best to leave these out, as they are hard to grasp by the general user.

As of the time of this writing, the recommended size (number of characters) of the input element is 27 characters, and the trend seems to grow, as users gain familiarity with searching. 27 characters is the approximation of the search string size most users type into the search field, so you should probably stick with it unless you are running out of site space to accommodate for its size.

Another important thing to note, is the form and label of the search button. Despite the fact that you might want to get fancy with the looks of the submit button, I discourage you to get too far from the accustomed “button” look, as this might decrease the visibility and clarity of the search function on your web site.

If users can’t find it, they won’t use it, so place the search box on the top right corner of your site, because this is the place users are accustomed to find it. Alternatively, you can move it to the left, for example, but by all means try to keep it on the top (header) of the page. Also be sure to make the search facility available throughout the site – consistency always pays off.

Scoped Search

If your site features many different types of content (or products, services, etc.), you should probably provide scoped searching. Let’s take a look at Amazon for example. In the old days they started up by selling books, but right now there are nearing the thirty product categories mark, so it comes naturally to provide a scoped search facility.

Amazon scoped search facility

Note, that by typing in a search phrase and hitting go, it will default to search the whole site, but if you open the drop down menu, you are giving the option to limit the search scope to one of the categories you are most interested in.

Following are some alternative scoped search examples from popular web sites. Note, that instead of relying on a drop down menu, these sites provide clickable links to change the search scope. This is just another valid method, which works very well with a small number of scope groups.

CNN.com scoped search facility

Yahoo! scoped search facility

Of particular interest is the spotlight-like search gizmo on Apple.com, which features instant as-you-type results, like its desktop counterpart found in the OS X 10.4 and 10.5 operating system. It’s safe to expect this kind of search facility to be used more frequently in the future, because of its intuitive interface and immediate response to search queries.

Apple’s Spotlight-like Instant Search

Displaying Search Results

You should design the results page with care. Keep all the superfluous information out of the results, leaving only the necessary info for each search result. As a general rule, I recommend showing the following fields for each result:

• The document title (also serves as a clickable link to the document)
• An abstract from the result page, which helps the user decide if the target page actually contains useful information
• Optionally the URL of the document

Google’s Search Results Page

Try to display about – but no more than – ten results per page and provide pagination to access further results.

On the top of the search results page, above the results list, you should always repeat the search form and provide additional options to refine the search. It is also considered good practice to display the number of results pages along with the results count somewhere close to the top of the page. This makes it easier for the user to refine the search query he already typed in earlier in case of too many or inaccurate results.

For further reading on the subject, I recommend you check out the following books:

• Jakob Nielsen’s and Hoa Loranger’s Prioritizing Web Usability
• Steve Krug’s Don’t Make Me Think!: A Common Sense Approach to Web Usability

So that’s the end of this article. If you have any questions or comments, I invite you to drop a line below as I’d love to hear your opinions and experiences on the subject.