1872912 - In-content selectSearch input is unlabeled in Forms (Desktop UI)

Status: NEW

(Toolkit :: General, defect)

Description

[❌ Anna Yeddi [:ayeddi] ❌ On leave until 2027-01-04]

Attachment: selectSearch_testcase.html

When pref dom.forms.selectSearch=true and the list of options in the <select> is large enough, the selectSearch <search-textbox> is added to allow users to search for a specific <option> in the list. This search is an <input> that lacks an accessible name. We need to add an appropriate label to it so its purpose is exposed to an assistive technology.

It is done in other places like Bookmarks and History sidebars as well as places and preferences UI via placeholder attributes that would provide an alternative to an on-screen label for the search too.

Comment 1

[❌ Anna Yeddi [:ayeddi] ❌ On leave until 2027-01-04]

Attachment: screenshot_of_the_selectSearch_element_in_action.png

When this bug is fixed, the browser/base/content/test/forms/browser_selectpopup_searchfocus.js test will start passing a11y_checks (test locally with ./mach test --enable-a11y-checks flag or on try with swr-a11y-checks linux !wayland !tsan !asan !ccov !devedition !debug query for jobs), thus the fail-if notation would need to be removed from the test manifest alongside the bug fix.

Also, I think the string for the placeholder attribute could be added to the toolkit/locales/en-US/toolkit/global/htmlForm.ftl localization file, i.e:

# This string is shown in the search field that is added at the top of the
# <select> dropdown when the list of options is long enough. This placeholder
# creates an on-screen label for the search input and serves as its accessible
# name for screen readers and other assistive technology to use.
select-search-input =
    .placeholder = Search list of options

Comment 2

[BugBot [:suhaib / :marco/ :calixte]]

The severity field for this bug is set to S3. However, the accessibility severity is higher, .
:emilio, could you consider increasing the severity?

For more information, please visit BugBot documentation.

Comment 3

[Emilio Cobos Álvarez [:emilio]]

This feature is disabled by default, so s2 seems high. S3 seems appropriate IMO.

Comment 4

[❌ Anna Yeddi [:ayeddi] ❌ On leave until 2027-01-04]

(In reply to Emilio Cobos Álvarez (:emilio) from comment #3)

This feature is disabled by default, so s2 seems high. S3 seems appropriate IMO.

It is still available for users and an unlabeled element within a menu may mean anything, adding to a strain for screen reader users who are trying to navigate already long list of options.

That's being said, the severity of the bug vs the accessibility severity do not have to always match and this case may be that exception.