Placeholder should not replace label

[marinacastejon]

Placeholders replacing labels in certain input fields.

In Vanilla there are 2 instances of this:

• Search and filter component

  

• Search box component

  

Summary of previous analysis:

• Placeholders cannot replace labels. If the visible label is removed there should be at least a hidden label so that screen readers read the label.

• While there might be a workaround to make this accessible to screen reader users, there are mentions about this behaviour of the placeholder acting as label and then disappearing when clicking that indicate problems for people with cognitive disabilities.

• WCAG Placeholder text

• WCAG Labels

• Deque

• NNG

It is worth mentioning that W3C WAI has a search box without a visible label and the placeholder disappears when typing.

[bartaz]

Thanks @marinacastejon, I think we should bring this to Working Group meeting and discuss there. Especially around making Search & Filter more clear, as that's the one that doesn't have the button with search icon.

[clagom]

WG: double check if for screen readers this is well implemented. CC @bartaz

[marinacastejon]

Blocked until checked with users with cognitive disabilities. I'll try to find participants in Canonical for the research on the hiring dashboards.

[marinacastejon]

It doesn't look like I will be able to recruit any participants with Aspergers or autism spectrum. Therefore, I investigated and tried to find some research that explicitly advised against the use of placeholders as labels.

• What we already knew, NNGroup advises against that, but doesn't mention any sources.

  Users with cognitive or motor impairments are more heavily burdened. As we saw, placeholders can be problematic for all users: disappearing placeholders increase the memory load; persistent dimmable placeholders cause confusion when they look clickable but aren’t, and placeholders that do not disappear require more keyboard or mouse interaction to be deleted. These difficulties are magnified for people with cognitive or motor impairments.

Other sources I checked. I found nothing regarding placeholders replacing labels and disappearing on users input.

• Cognitive user research from W3C.
• Research gate paper: User Interface for People with Autism Spectrum Disorders
• National Autism Society

I suspect it is not the best practice but there is no solid evidence showing that this is blocking users. Since NNG does not point to any sources and WCAG cognitive working group does not mention it, I think we can close this issue @bartaz @clagom

We should still keep in mind the need of extra work to make it accessible for screen reader users, as per WCAG guidelines (see issue description).

[clagom]

WG: the accessibility guild is going to discuss this during the accessibility working group. @bethcollins92

[bethcollins92]

@marinacastejon

I've added labels to all the searchbox examples on Vanilla since this issue was created. I haven't checked all our websites, but everyone in the accessibility guild is now aware we need labels and not just placeholders, so they will check their projects and add them if necessary

[davegoddard42]

I asked the design team to try and find any input fields within our sites and products that lacked a label - every example was a search box. The Vanilla guidelines state that input fields consist of a text input and a label. This appears to be adhered to, and the issue is confined purely to search and search & filter patterns, as @marinacastejon mentioned.

As Marina also found from research, there doesn’t seem to be a “smoking gun” showing that using placeholder text for labels specifically on a search input is bad for people with cognitive accessibilities. There is however, evidence that using placeholder text for labels on input form fields does increase cognitive load, which in particular impacts those with cognitive disabilities (https://youtu.be/xjPqwsRIq7E?t=602).

A lack of a label does cause issues for screen readers but this has been addressed by @bethcollins92's work outlined above.

Does a search box need a label?

Nielsen Norman Group state that the main guidelines (https://www.nngroup.com/articles/search-visible-and-simple/) for search boxes are as follows:

• Provide an easily identifiable search box in the upper right-hand corner of the page, with an open text-field accompanied by a Search button.
• The search box needs no label. A Search button next to the field identifies the search for the user and tells them how to execute the search.

There are occasions when text fields may not need a label as "the purpose may be clear enough from the context when the content is rendered visually" (Web Accessibility Initiative).

It can be argued that the search button (Shown in Vanilla as a magnifying glass) acts as a label. As a very widely used pattern across the web (NN Group), the magnifying glass next to an open text field is well understood by most users.

Cognitive load and the impact on those with cognitive disabilities

The problem with using placeholder text to label a field in general is that it increases the cognitive load for a user, and this can be especially problematic for users with cognitive disabilities (Designing for Cognitive Disabilities axe con 2022).

The increase in cognitive load comes from:


• If user loses attention, they might not remember what they’re being asked
• Can’t easily check answer before submitting because the user doesn’t know what they’ve answered.
• Can’t correct errors easily
• May mistake placeholder data as filled in
• Filled fields are less noticeable

In pages with multiple fields, the problem is magnified

The search and search & filter components differ from normal text fields that might make it the exception.

• It is one field only, not multiple
• There are no errors or need to check the correct input - searches that return no results explain how to get better results
• Users are unlikely to think that “Search” is what they had previously typed in

Norman Nielsen introduce the Search capability using the opening sentence “Search lets users control their own destiny and assert independence from websites' attempt to direct how they use the web”. It appears there is a difference between a form field and a search box - namely, a form fields represent an interface asking a user for an answer, and so what’s being asked for should be visible at all times for the issues around cognitive load outlined above.

A search box however, is the user asking the interface a question - when the user interacts with the component they define what’s being input, and have the necessary context for the content.

Conclusion

An input field must have a label, and using placeholder text is not good enough. On the search input however, the magnifying glass acts as a label. The unique nature of the search interaction also means the usual issues around cognitive load are lessened. I'd argue there isn’t a need to add a label to the search component.

In Vanilla, the Search and Filter component lacks a magnifying glass icon. On typing in the field, the dropdown shows “Search for …”, giving context to the user. 

Despite this, I’d suggest that the magnifying glass icon should be added to the pattern.

[clagom]

WG: @davegoddard42 @marinacastejon (and @wgx from the other search-related issue) are going to review our search and filter spec and eventually amend/integrate it.

[clagom]

@davegoddard42 is going to work on the spec, closing this issue.