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:
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.
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.
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.
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):
http://www.engine.example/search?q=dfa+forms+web
SearchEngine Try your search in: Images | Video | Audio | News
Search for: Help | Customize Settings | Content Filter is off
__________________________________________________ [Any language]
Search
[_] Search within these results Search Assistant | Advanced Search
Advertisement
Home > Search Results for dfa forms web , page 1 of 20
_________________________________________________________________
Advertisement
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.
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.
The proposed order of information on a query results page is the following:
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.
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.
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.
The design of forms themselves is beyond the scope of this document, but the following principles can be used as basic guidelines:
Credits: I am especially indebted to the following people for valuable comments, suggestions, and discussion on query system accessibility: Virpi Jylhä, Reijo Juntunen, Petri Laatunen, Jori Mäntysalo, and Charles McCathieNevile.
<http://www.jkorpela.fi/forms/qdfa.html>