get_search_form() accessibility improvements

[afercia]

Noticed while testing Twenty Sixteen and discussed a bit in today's accessibility team chat on Slack. The standard search form generated by get_search_form() and primarily used by themes (e.g. in the 404 error page, in the search results page) and by the Search Widget has some redundant info and could be simplified a bit.

We're also a bit concerned about the usage of the placeholder attribute as "visual label" while, according to the specs, its purpose is to give an hint about the type of data to enter. In fact, some screen readers announce the placeholder as "hint". By the way we understand this would require some discussion in the community so let's focus on the redundant info for now.

Please refer to the screenshot below, it's the Twenty Sixteen theme without styles:

As you can see, there's a bit of redundancy. NVDA will read out this as:

search landmark Search for:                              <-- role="search" set on the form
Search for: Search … edit has auto complete Search for:  <-- the search label + input
Search                                                   <-- the search button

With styles applied, nothing changes: the label is hidden by default with screen-reader-text. In Twenty Sixteen the search button is hidden too. Both will be read out by screen readers.

The sequence: label + placeholder + title attribute is particularly redundant, we'd recommend to remove the title attribute (looks like it's used only in the html5 format).

Additionally, it would be preferable to associate the label explicitly using a for attribute, this would need a unique identifier but it shouldn't be too hard to have a counter or some clever solution in case of multiple search forms on the same page.

Side note: there's a space before the ellipsis in the placeholder, not sure if that's intentional, doesn't look right to me :)

Any thoughts more than welcome, we're open to suggestions about how to further reduce repeated and redundant info and looking forward to start the discussion about ​placeholders.

[GaryJ]

Replying to afercia:

We're also a bit concerned about the usage of the placeholder attribute as "visual label" while, according to the specs, its purpose is to give an hint about the type of data to enter. In fact, some screen readers announce the placeholder as "hint". By the way we understand this would require some discussion in the community so let's focus on the redundant info for now.

Relevant: ​Placeholders in Form Fields are Harmful.

Additionally, it would be preferable to associate the label explicitly using a for attribute, this would need a unique identifier but it shouldn't be too hard to have a counter or some clever solution in case of multiple search forms on the same page.

One suggestion, originally by @rianrietveld, is uniq_id(), easy if used in a ​search form class.

Side note: there's a space before the ellipsis in the placeholder, not sure if that's intentional, doesn't look right to me :)

British English and US English differ on the opinion for whether there should be a space or not before a trailing ellipses.

[afercia]

Replying to GaryJ:

British English and US English differ on the opinion for whether there should be a space or not before a trailing ellipses.

Good to know :) There's some inconsistency in the admin though, sometimes it's without spaces... sometimes with ...

[sharonaustin]

Thank you so much for this work. I've incorporated pretty much all of the suggestions above except for Rian's outstanding recommendation about a unique id search_form class, simply because it was not (as I understand it) the focus of this ticket. That said, I think her idea would make a huge difference in accessibility if it were implemented, so I hope work continues on that concept.

For NVDA only, I made the following changes, and it seemed to greatly reduce redundancy. Please note that I tested these as a NON-EXPERT with NVDA 2015

1. Starting off with a basic scenario, with classes removed (the same starting point as @afercia illustrates above, I hope) : ​http://jsbin.com/diwapi/edit?html,output

2. I altered the roles, removing the "complementary" role from the div id="secondary", but more importantly, changed the aside to a nav. I did this for two reasons. The first is that user agents SHOULD treat elements with the role of search as navigational landmarks. (Source: ​http://www.w3.org/TR/wai-aria/roles#search). But the second reason I found is that in certain parsers that test outlines, "asides" will not show up. I felt it was very important that if a user relies on "outlines" to navigate, then the search should be able to show up in that outline. Here's the test showing what happens when I remove the role of complementary and changed aside to nav. ​http://jsbin.com/qeximez/edit?html,output

3. Removed the placeholder and title attribute. Reading @afercia's concern about using titles and HTML5, I especially was concerned about this one, but it seemed to work, and there was literature saying that relying on title attribute is currently discouraged. ("Relying on the title attribute is currently discouraged as many user agents do not expose the attribute in an accessible manner as required by this specification (e.g. requiring a pointing device such as a mouse to cause a tooltip to appear, which excludes keyboard-only users and touch-only users, such as anyone with a modern phone or tablet)". Source ​http://www.w3.org/TR/html5/dom.html#index-aria-search

​http://jsbin.com/peqimu/edit?html

4. This last one is one I'm not totally comfortable with yet, but based on reading, if you are using an HTML5 document and use input type=search, then the browser understands that it is a search function, and adding role=search is redundant. Removing it DOES remove redundancy.

​http://jsbin.com/xeyana/edit?html

Again, this worked for me as a NON-EXPERT with screen-readers.

Thank you so much, everybody, for your committment to accessibiltiy.

[afercia]

Discussed in today's accessibility weekly chat. Decided to make just a first step and propose to remove just the title attribute. There's room for further improvements, for example about the placeholder that should be optional. The plan is to evaluate them as part of a more general approach in #31818.

For some background, the title attribute was added in [23801] see the related ticket #16539 for the argumentation related to issues with very old browser/screen reader combos (Jaws7/IE6).

Wort reminding get_search_form() is used both in the admin and by themes/plugins and for themes and plugins we can't predict if the label will be visible or hidden, same for the submit button etc. There's also the get_search_form filter to consider, for example Twenty Fifteen uses the filter to hide the submit button with screen-reader-text while Twenty Sixteen uses its own template in searchform.php.

Would also encourage bundled themes to remove the title attribute :) cc @karmatosed

[afercia]

A very simple patch to remove the title attribute from the HTML5 search form.

[sharonaustin]

Replying to afercia:

Discussed in today's accessibility weekly chat. Decided to make just a first step and propose to remove just the title attribute. There's room for further improvements, for example about the placeholder that should be optional. The plan is to evaluate them as part of a more general approach in #31818.

For some background, the title attribute was added in [23801] see the related ticket #16539 for the argumentation related to issues with very old browser/screen reader combos (Jaws7/IE6).

Sir, thank you so much to you and the team for the work being done here, and for all of accessibility.

I am still concerned about removing the "both" the title attribute and the placeholder.

I was wondering if I should have said something earlier, but I wanted to walk away from it and think about it for a while. After these months away, I am still uncomfortable about it.

In the first set of tests, it is true that I wanted to accommodate all earlier recommendations, including removing the placeholder and title attributes. When I did so, it removed some of the verbosity associated with the screen reader feedback, and of course that is a great thing.

That said, I am still reluctant to remove both the placeholder and the title attribute because of their additional function as a kind of "safety net" when other resources are not available to assistive technology.

From this reference: 6. Accessible Name and Description calculation -- one can see that the title attribute is used as an accessible name description of last resort

​http://www.w3.org/TR/html-aapi/#accessible-name-and-description-calculation

input type="text", input type="password", input type="search", input type="tel", input type="email", input type="url" and textarea element accessible description calculation

Use aria-describedby
Otherwise use the placeholder attribute if it wasn't used as the accessible name
Otherwise use the title attribute if it wasn't used as the accessible name.
If none of the above yield a usable text string there is no accessible description

I understand the move to remove the title attribute and placeholder, but is it possible that we can consider removing only one of them, and not both, as work progresses? I think a safety net should be in place.

Thank you for your consideration, and for the work done here.

One follow-up: I had given information from an older web page. The updated page is here, although the criteria for input type="search" seem to be largely the same.

​http://www.w3.org/TR/html-aam-1.0/

5.1.2 Element Accessible Description Calculation

[joedolson]

Hi, Sharon - thanks for your comments! Please note, however, that the current patch *does* only remove the title attribute, and leaves the placeholder for further consideration.

[sharonaustin]

Replying to joedolson:

Hi, Sharon - thanks for your comments! Please note, however, that the current patch *does* only remove the title attribute, and leaves the placeholder for further consideration.

Thank you so much, Joe, obviously I had misunderstood what was written, so please accept my apologies for the comments! I definitely appreciate the clarification.

[afercia]

To clarify, the comments above mentioned the "accessible description calculation" which is different from the "accessible name calculation". A description is just a description, it's optional and should be provided only to further expand the information provided by the name, if necessary.

get_search_form() already provides a label 'Search for:' so adding also a description that uses the same string 'Search for:' is just redundant.

Going to commit, please do feel free to follow #31818 for further discussion and improvements.

[afercia]

In 36222:

Accessibility: remove the title attribute from the get_search_form() HTML5 search field.

It was added in [23801] as a workaround for issues with very old browser/screen reader combos (Jaws7/IE6).
No more necessary today. Reduces redundancy and noise for screen reader users.

See #16539.
Fixes #33952.

[sharonaustin]

Replying to afercia:

To clarify, the comments above mentioned the "accessible description calculation" which is different from the "accessible name calculation". A description is just a description, it's optional and should be provided only to further expand the information provided by the name, if necessary.

This follow-up information clarifying the distinction between accessible name calculation, and accessible description calculation, and most importantly, the difference in the application between the two, is absolutely invaluable. Thank you so very much.