Accessible Styled Form Controls

Styled Search Component

Last updated:

Cross-browser styling for a search component.

Pattern Demo

Search form example:


Disabled search form:

Pattern Details

Pattern Markup
<form role="search" aria-label="unique identifier goes here">
  <input type="search"
    id="srch"
    name="srch"
    aria-label="Search for...">
  <button type="submit"
    id="srch_btn"
    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>
</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 pick through documents or navigations in hopes of coming across the link to what 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.

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 input[type="search"].

In the markup example, an aria-label is used on the input and on the button[type="submit"] to provide both an accessible name. The SVG within 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, instead only reading and pronouncing the submit button's aria-label value, like other browsers.

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.

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.

The use of the input type="search" will announce the input as an editable "search" element to screen readers (exact announcements vary between screen readers).