Styled Search Component

Pattern Details

<form role="search" aria-label="unique identifier could go here">
  <div class="search-widget">
    <input type="search" <!-- or type="text" -->
      id="srch"
      name="srch"
      aria-label="Search for...">
    <button type="submit"
      id="srch_btn_v"
      aria-label="Submit Search">
      <svg viewBox="50 461 23 23"
        aria-hidden="true"
        focusable="false">
        <path d="..."
          id="icon_search"
          stroke="none"
          fill-rule="evenodd"></path>
      </svg>
    </button>
  </div>
</form>

Search forms can be one of the most important parts of a UI. A good search interface can allow users to quickly find the content they are looking for without the need to guess and check their way through different pages or screens in hopes of coming across the information that they're looking for.

To help promote the presence of a search form to assistive technologies, the search landmark (role="search") should be applied to the form element that contains the search UI. An aria-label for the landmark could be useful in the event there are multiple search landmarks in the current document. If there is only one, an aria-label (or other means to provide an accessible name) may be unnecessary, making the region more verbose than helpful.

Many search forms do no have an explicit label set, as many designers and developers mistakenly assume the presence of a search icon to give a visual indicator of the component's purpose is sufficient. However, even though visually the search icon is well recognized, an accessible name should still be applied to the text field of the search component.

In some of the examples, an aria-label is used on the input and on the button[type="submit"] to provide both an accessible name. The SVG within the button is hidden from screen readers and given an focusable="false" attribute to help ensure that Internet Explorer won't allow keyboard focus to enter into the SVG itself. With this in place, IE will only announce the submit button's aria-label value, like other browsers.

The second example provides a visible label to the search component. While either a visible label or an aria-label will adequately provide screen readers with an accessible name for the search text field, a visible label can help ensure that some people will not miss the purpose of the form control. For instance, people using a screen magnifier may not notice the search icon if the search text field goes beyond the width of the zoomed in interface.

Search form notes:

Be mindful that input[type="search"] and role="search" are not the same thing. role="search" surfaces the form as a landmark, and should not be applied to the input, as that would negate the input as being announced as an editable "text field".

More complex search forms might contain additional form controls, or might utilize a combobox in place of, or in addition to, a standard input[type="search"] form control. Regardless, search forms should have a submit button as a consistent indicator for how a form can be submitted.

Regarding the input field, there are a few distinctions between using an input type="text" vs input type="search". The primary differences between the two are that on mobile devices a "search" input will change the on-screen mobile keyboard's "Go" (iOS) or "Right Arrow" (Android) buttons into a "Search" (iOS) or "Search Icon" (Android) buttons. Webkit browsers additionally have some visual styling and an quick delete button (inaccessible to keyboard/screen readers) for the search text field. Some browsers allow for the Esc key to clear the text from a search input. Additional notes in the "Affects on Screen Reader Announcements".

Affects on Screen Reader Announcements?

The addition of the role="search", and any accessible name it is given, will expose this information to the accessibility API and convey that information to assistive technologies. Users should be able to find a search form by navigating with the tab key. Screen reader users should be able to find the search form when navigating by form controls, or landmarks/regions.

Beyond the mobile and visual changes between a standard text field and a search text field, screen readers often announce the search text input as an editable "search" field, as opposed to an editable "text" field. (exact announcements will vary depending on the navigation method used to reach an input field, and the screen reader used).

When used outside of a search landmark, the distinction between the two fields can be helpful. However, in context of a search component, its use will result in redundant "search" announcements.

For example, testing the patterns on this page will result in announcements like "Search region, Search for..., search" when navigating into the search component and focusing the search input. In contrast, the example that uses a standard text field will announce like: "Search region, Search for..., edit text." For additional thoughts on this topic, read Adrian Roselli's article "Ignore type=search" to decide for yourself on the best path forward for your implementations.