Simply Accessible

Search Results Page Layout

When we use systems that include searching capability such as back end administration tools, we often see search forms presented both on the page that you search from and the page that displays the search results. This can be very useful for both the user and the programmer:

• the user doesn’t have to go “back” to search again or refine their search
• the programmer gets to keep their code modularized and reuse the same bit of code over again by maintaining one page instead of two.

However, this does cause some problems for visually impaired users, and (I’ll freely admit) sometimes throws me off for a number of reasons:

• the search form is presented first and, depending on its complexity, pushes the search results below the fold
• there is often no indication that anything has changed – a screen reader user or screen magnifier user are presented with what looks like the same page. On several occasions I’ve been asked in user testing “didn’t I just fill that form out?”
• a keyboard user is required to go through the entire page and search form before getting to the results.

View a typical search and results page that demonstrate these problems.

Fortunately there are a number of things that can be done to improve this functionality.

First, we can change the action of the form to include a fragment identifier/named anchor for the results page.

<form method="post"
       action="whatever-page.php#results >
   ... form elements here ... 
</form>

Next, we create that element within the results page, and use that element to do two things: 1) provide a statement about how many results were found, and 2) link that statement to another node within the page.

Found <a id="results" href="#details">25 results for keyword</a>

This accomplishes two things:

1. including the statement itself lets any user know right away that something has changed on the page
2. posting directly to that node places the focus where it is most relevant
3. linking the statement is very clear, and acts as a very precise link that “skips over the form” without actually being called a skip link.

In my final example, I’ve also included a link after the search results that submits back to the form itself to make it easier to “Search again.”

View the improved search and results page

Other considerations

You might also consider it useful to change the page’s <title>...</title> to indicate that you are viewing the results page as well as the number of results found, or which ones you are displaying.

It may be useful when this is implemented within a template to actually submit to a named anchor or ID that is just above the desired target so that the target isn’t right at the very top of the viewport.

Providing some other visual cue to draw attention that particular node/link would likely provide benefit as well.

This technique could be applied to any form on a page that submits to itself.

Permalink to this article

Search Form Layout

As we’ve seen in the first two examples, forms provide some interesting issues to users of assistive technology like screen readers, in particular as it relates to visual layout versus the linear source order. In this example we’ll take a look at a search form that includes some “optional” radio buttons for refining the search. A typical example might appear as illustrated as follows:

The HTML for this example might be:

<div>
  <label for="searchtxt">
    Search Terms:
  </label>
  <input id="searchtxt".../>
  <input type="submit" value="Search" />
</div> 
<div class="group">
  <div>radio buttons</div>
</div>

This is a fairly natural way to code the form when using a CSS based form layout – visually the first “row” of the form includes a label, a text box and a search button, and the second “row” includes the optional radio buttons that help refine the search.

View the Search Form Example

Based on what we know about source order, this presents a minor obstacle to a screen reader user as they will encounter the text field, then the search button, and then the radio buttons. They may not realize that the radio buttons exist – the natural tendency is to submit the form once the submit button is reached.

This form layout also causes a minor inconvenience to a keyboard user – to choose the optional radio buttons they must tab past the submit button, and then navigate backwards (often using Shift + Tab) to submit the form.

This problem can be solved by improving the source order and using CSS to absolutely position the Search button as follows:

First, we modify the HTML source:

<div>
  <label for="searchtxt">
    Search Terms:
  </label>
  <input id="searchtxt".../>

  <div class="group">
    <div>radio buttons</div>
  </div>

  <input id=”submitbtn” value="Search" />
</div>

Then we apply the following CSS to visually place the Search button at the top right of the form, much as in the previous examples:

input#submitbtn {
  position: absolute;
  left: 31em;
}

The result is that we have a form that visually shows the Search button beside the text box, but has a better source order for keyboard and screen reader users. It may also be useful to not position the Search button at all for a Zoom layout, allowing the Search button to fall vertically at the end of the form (while I have implemented the zoom layout in the example, note that it has not been tested with low vision users)

View the Search Form with source ordering Example

Next: Search Results Page Layout

Permalink to this article

Form Error Messages

The techniques used in the Required Form Fields example to place the asterisk after the input control can easily be reused to apply to an equally important scenario: displaying error messages for a form.

In this case, the error message is emphasized within the label for the form field. Semantically this makes sense – we highlight error messages with colour, different text weight or other visual means in order to emphasize them anyway. Using a <label>... <em></em></label> not only provides us the elements for styling but also makes sense – the label (and therefore the error message) is specifically associated with the form field using the for attribute.

This technique is essentially an extension of the one used for denoting required fields. The exception is the HTML:

<div>
   <label for="uname">Username
     <em>must not contain spaces</em>
   </label>
   <input id="uname" type="text" name="uname" value="" />
</div>

Placing the error message to the right of the field for easy scanning is useful, and the fact that it is still part of the label, and found before the text box in source order allows it to be read out by screen readers. This is a case where a zoom layout could also be used to provide a version to low vision users.

View the Error Messages Example

Next: Search Form Layout

Permalink to this article