Query systems: Design for All approach

This document proposes some specific guidelines for designing query systems so that they are accessible to all, including people with disabilities. The most important proposal is formulated as an easy-to-implement minimal recommendation. Table of content:

Why query system accessibility is so important?

The user interfaces of Web search engines are of great importance, since they are used so intensively and since the user needs to deal with large amounts of data. Getting either too few or too many hits is a common problem to all of us. But problems of scanning through the bulk of results or quickly making a new, modified query often make things much worse to people with disabilities. It is essential that they can access information on a query results page as easily as possible, so that they can even attack the problem that we all have: deciding what's potentially relevant there.

Relatively small changes in search engine interfaces can make a huge difference in usability to the disabled as well as to people using small devices. A very small modification, which just provides a quick link to search results proper, can help a lot. And it can be made without affecting the visual appearance at all, if desired.

As so often, accessibility improvements that are crucial to many disabled people additional provide extra comfort to all. For example, those users who have no problem with using a mouse may still find keyboard shortcuts much more convenient in some situations.

This proposal should be understood in the general "Design for All" (DfA) framework. The general Web Accessibility Initiative (WAI) guidelines are implied as the basis. For an overview of the background, please refer to Guide to Web Accessibility and Design for All. This document at hand discusses the problems specific to query systems. Naturally, this is largely just a matter of finding suitable implementations of WAI principles in a particular type of context.

What constitutes a "query system"

In this document, the phrase query system refers to an arrangement where a Web page contains a form where some data, typically including free text input, can be filled in and sent as input to a server-side script that performs some search function and returns results, typically a "hit list". The use of such systems tends to be interactive in the sense that if the hits in the list don't correspond to what the user was actually looking for, he formulates a new query.

Most Web users are familiar with at least one query system. But for our purposes, it can be useful to list down explicitly how they work, in general terms. Web search engines, such as AltaVista and Google, typically return results where each hit consists of a document title, document URL, some short extract from document content, and perhaps some information like the size or last update time of the document. Naturally a link to the document is included in the information.

In other searches, like specialized database queries, e.g. Eurodicautom, a multilingual data base of terms, the details vary but the basic pattern is often similar.

High interactivity is essential

The specific accessibility needs related to query systems arise from the fact that the set of results is often bulky and the user needs to refine the search interactively. No hits is a bad thing, but so is usually a very long hit list.

Typically, the result page consists of ten or twenty first hits, with links to further results at the bottom. It can be difficult to estimate how succesful the search was, especially from a non-visual presentation, unless there is some explicit quick information like "42 matches found" at or near the start of the page.

For interactivity, the result page often contains a new search form, with the previous input as prefilled. Thus the user can modify the input and search again.

Getting a quick overview?

Problems arise when the new search form as well various general and contextual information precedes the most essential information, such as the total number of hits, information of occurrences of search terms, and the first few hits. This means that e.g. blind user needs to do quite some extra work to skip the preceding content before getting to the information that he needs first: how succesful the search was, in broad terms?

For example, suppose that you performed a search using the search string dfa forms web and got a result page that begins as follows, in a text-only presentation. If you think what it feels like to hear this text, you get some idea of the problems discussed here. Beware that this hypothetical example presents a relatively well-designed results page format; there are more problematic services around.

   REFRESH(300 sec):

   SearchEngine Try your search in: Images | Video | Audio | News

   Search for: Help  |  Customize Settings  |  Content Filter is off 
   __________________________________________________  [Any language]
   [_] Search within these results Search Assistant | Advanced Search


   Home > Search Results for dfa forms web , page 1 of 20


   We found 1,068 results:
   Arkansas Administrative Statewide Information System
   To  search  the  AASIS  web site, enter your query below: You must hit
   "Go"  after  you  click the "search button. Tips for searching. Forms.
   Help Desk Request. Procedures. Form On-line. Training. Cour...
   URL: http://aasis.dfa.state.ar.us/forms.htm | Translate
   More pages from aasis.dfa.state.ar.us 

This could be followed by nine similar hits and some information like the following:

   The  number  of words that match your search terms: dfa 154742 | forms
   17104198 | web 232233859

The example imitates existing search engine interfaces. You might compare it with the results of Google search with the given keywords. The problems with the example should be obvious. Yet, they would be easy to fix by simply reordering the parts by putting the most essential, summarizing info first and the new query form last. This would cause problems before users get used to the new interface, but it would be an improvement which is useful to all and especially useful to people with disabilities.

Minimal recommendation

If the results page contains a substantial amount of content before the information about the number of hits and a list of actual hits, a link to essential information about results should be provided at the beginning of the page or at least very early.

When desired, the link could be a "visually hidden" one, so that it would normally not appear in a graphic presentation but would be available in other presentations. The usual technique for this is to use an img element where the src attribute refers to a transparent single-pixel GIF and the alt attribute tells what the link points to. This means something like the following:
<a href="#main" accesskey="2"><img src="transp.gif" alt="Results" width="1" height="1" border="0"></a>

There is small problem with the idea of such an "invisible link". When using a graphic browser with image loading enabled, it creates a small mystery when the user moves from one link to another with tabbing. Thus, a normal link, with link text like "There were a total of 42 hits", could be better. The suggestion above is made basically to demonstrate that the graphic appearance could even be kept unchanged, if desired, when adding the suggested accessibility enhancement.

Proposed order

The proposed order of information on a query results page is the following:

  1. A short heading that says what the page is: a query results page, with the search service identified.
  2. Text that specifies the total number of hits, optionally followed by any relevant information about the general properties of the search, such as the impact of the different keywords used. Note: a word like "hit" is probably better than "page", since the latter is ambiguous: it could be taken as referring to the amount of pages (HTML documents, or maybe even printed pages) used to report the results!
  3. The hit list, to the extent that the hits themselves are reported on the page. Each hit should preferably be marked up as a paragraph. Within a hit, the textual order of various pieces of information should reflect its relevance when considering whether to access the actual page or not. In this "first things first" approach, it is desirable to have the format of the resource to be indicated early, perhaps even as the first item, if it may pose accessibility problems. For example, hits pointing to PDF files might be marked with "(PDF)" before the document title.
  4. A "next" link, if there are more result pages to come. In this context, information like "page 6 of 42" would be useful. Moreover, a link to the first result page could be included here, just in case the user wants to restart his processing the results.
  5. Tools for performing a modified search, such as a link or button for switching from Web search to Usenet search and a new query form.
  6. Any other content.

Echoing the search string used is recommendable, but it could be made implicitly in the form for a modified search, since it would normally be prefilled with the fields from the previous search. If this is not feasible, the search string could be echoed back last. Putting it into the beginning could cause mild frustration: after typing in a long string of keywords, and having them read aloud before submitting, you wouldn't like to hear them again. But if there is something relevant to report, like "42 matches for 'foobar', 0 matches for 'barfoo'", or "keywords 'web' and 'computer' ignored (as too common)", it should be reported early (item 2 above). It is often essential to know that some of your keywords were actually ignored or didn't match anything, before you start looking at or listening to the results.

The logical reason for making each hit a paragraph (p element) is that the information content corresponds to a typical paragraph. On the practical side, we can assume that any user agent can present paragraphs in some meaningful way, e.g. with pauses or vertical spacing or other presentational clues about moving from one paragraph to another. Moreover, speech-based user agents typically provide for some simple way of skipping to the next paragraph. This is essential for easier to skip uninteresting hits after hearing the first few words.

Quite often, query result pages contain, near the bottom of a page, a list of page numbers like
1 2 3 4 5 6 7 8 9 10
where each number is a link, except for one of them, which might additionally be in a specific color or bolded. Obviously, this works poorly in speech presentation. It's assumably intended to be illustrative, and to some extent it is, but the approach suggested above probably works well both visually and non-visually. Functionally, there's hardly a reason to jump from a result page to any other page than the next one or the first one.

Headings help, too

It is also beneficial if the logical structure of a query result page is reflected in its HTML markup. This applies in particular to the use of headings. Several browsers and utilities are capable of making use of heading markup, for example by displaying or reading all the headings on a page, upon request.

Thus, it would help if there were some second and third level headings in addition to the overall page heading. The second level headings could be named, for example, as "Summary", "Detailed report", "New search", and "About us". The hits could be presented under "Detailed report", so that each hit has a heading, which would be a third level heading, of course.

Typically search engines extract the value of the title element and present it first when reporting a hit. This is very natural and reflects well the intended use of title elements. Unfortunately, not all authors write good titles. A search engine might use some heuristics when there is no title element, or its content is empty, or matches one of the well-known dummy titles like "Put your title here" or "HTML document for the World Wide Web". In such cases, using the content of the (first) h1 element instead is probably an improvement.

This way, on a speech-capable browser that can be switched to "headings only" mode, the user could first listen to the summary, then the headings, and access any major part of the document as need, e.g. switch to new search when it becomes obvious that this one wasn't a success. It is true that "links only" mode could help in listening just the names of the documents found, but a search engine may wish to put additional links within the hits. Those links could point to cached copies, automatically generated text versions, automatic translation services, etc. They can be very useful, but typically not interesting when just going through the list of hits.

Style sheets could, and probably should, be used to suggest visual rendering that makes the headings less prominent visually than their default presentation would be. After all, the hit list should be visually compact. But this can be arranged by setting the top and bottom margins of headings small and their font size the same as or just a little bigger than normal text.

When things go wrong, make it clear what's wrong

Getting no hits, or getting millions of hits, is often considered by the user as an error. But in addition to such situations, a user's attempt to search for something may fail for various technical reasons, such as lack of any search terms by mistake, or a syntax error in the search clause.

It is essential in such situations to say explicitly and very noticeably that an error has occurred, so that the user can distinguish the message from a normal response. The error message should indicate the problem in non-technical language as far as possible, yet cleary enough and with a suggestion on how to proceed. Jakob Nielsen's alertbox about error messages in general, Error Message Guidelines, explains such principles in some more detail.

Notes on form design

The design of forms themselves is beyond the scope of this document, but the following principles can be used as basic guidelines: