6

I have a form that consists of an input box and a button. The button says "Search". For sighted users, it seems that no label element is required for the input box as it is obvious that you enter search terms into the box and submit the form to get results.

However, no <label> element for the input box... Is that an accessibility problem? If so, is there a non-hacky solution that would allow the label to show up only for users of screen readers and other assistive technology?

("Hacky" solutions might include hiding the text behind another element or off-screen or in a 1px x 1px element or having the text appear as the same color as the background. These all fail the smell test for me. Heck, I'm not even sure which ones of those would work. Smart screen readers might ignore them all.)

Improve this question

3 Answers 3

Reset to default
2

The relevant WCAG 2.0 guideline is 3.3.2 Labels or Instructions:

Labels or instructions are provided when content requires user input. (Level A)

A possible technique to achieve this is G167: Using an adjacent button to label the purpose of a field:

When a button invokes a function on an input field, has a clear text label, and is rendered adjacent to the input field, the button also acts as a label for the input field.

As example, it gives exactly your case: a search function.

So something like this should be accessible according to WCAG 2.0:

<input type="search" title="Type search term here" />
<input type="submit" value="Search" />

Edit: As @attack noted, the search field still needs a name to comply with guideline 4.1.2 Name, Role, Value. One way to specify such a name is using the title attribute, like shown in example 3 to the technique H65.The title attribute also adds a tooltip to the field.

Improve this answer
2
  • 2
    Sorry to resurrect an old topic, but I've been doing some research on this issue and the G167 guidelines include a "Note: The field must also have a programmatically determined name, per Success Criterion 4.1.2." Looking into 4.1.2, "programmatically determined" is defined as accessible by assistive technologies (w3.org/TR/2008/REC-WCAG20-20081211/…), so arguably the example above doesn't fit the bill. Adding "title" or "aria-label" to the input should make it work, though. Thanks for providing all of these links; they were really helpful in my research.
    – attack
    Jul 4, 2015 at 23:52
  • @attack: Thank you very much for your comment (chiming in, no matter how old the question might be, is always very welcome on Stack Exchange sites). I updated my answer.
    – unor
    Jul 5, 2015 at 0:30
5

There is an official aria-label attribute that seems to do what you're looking for. You would probably label the input field like this:

<input type="search" name="q" aria-label="Search query">

I haven't been able to find out whether or not screen readers support it.

Improve this answer
4
  • 1
    Would <input type="search" /> be a better and/or more widely supported option?
    – Niet the Dark Absol
    Jul 28, 2014 at 21:53
  • so test it with screen readers then...@NiettheDarkAbsol using <code>type="search"</code> is optimal in html5: even if its not supported (it should be!), the document will use an html4 fallback, which typically tends to be <code>input type="text"</code>; use practically all html5 form controls with no worries, as the bulk of them revert like i just described
    – albert
    Jul 30, 2014 at 8:08
  • 1
    Some colleagues and I recently ran some tests and discovered that aria-label support was actually pretty good: github.com/ucsb-wsg/ucsb-wsg.github.io/issues/30 More research is needed to compare support for aria-label against the market share of different versions of screenreaders, but support was great in the latest popular screenreaders and the latest browsers. I would actually argue that this should be the selected answer here (a lot of wonderful discussion on all of these answers in this thread, though!).
    – attack
    Jul 4, 2015 at 23:56
  • @NiettheDarkAbsol, and it also adds context-menu command to add it as a search engine to the browser (in some browsers).
    – jiwopene
    Mar 3, 2022 at 15:12
1

Generally speaking, it is a bad thing to omit a label for the reasons you state.

However, the search box is a slightly different edge case here. In general it is the first form on the page and screenreader users will often jump to the first button on the page (the 'search' button) and then shift+tab (or whatever shortcut key they use) to move over to the field associated with that button. Namely; the search field.

Therefore, provided your button is clearly marked up as the 'search' button then you can get away with not having a 'search' label associated to it.

But this is not official standards, and depending how you measure accessibility it's likely it'll fail automated tests as a result. But real world users that browse the web with screenreaders will be able to work with this approach.

(Possibly this is just because they've had to become accustomed to it because people omitted the search label in the past).

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.