Description

There seems to be an invalid HTML structure in the Themes (wp-admin/themes.php) and Add Themes (wp-admin/theme-install.php) pages in the admin screen. There is an input field for searching themes, but it's not in any ancestor <form> element.

I'm not sure, but it might cause troubles in some environments such as screen readers. So I propose adding <form> element somewhere appropriate to make it valid HTML.

I found this issue at WordCamp US Contributor Day (Accessibility Team).

Technically, this is OK. Having input elements outside of form elements should pass W3C validation.

However, I understand the concern. Potentially, having the label, input, and submit elements outside of a containing form element, in essence, goes against the "Robust" principle of web accessibility. Specifically, the guideline pertaining to this issue is a Level A guideline. Emphasis is mine:

4.1.1 Parsing: In content implemented using markup languages, elements have complete start and end tags, elements are nested according to their specifications, elements do not contain duplicate attributes, and any IDs are unique, except where the specifications allow these features. (Level A)

The main concern is this: when HTML elements are not used in the recommended way, user agents may render them in unexpected ways. It can also become a problem for compatibility with older or even future browsers, devices, or other software.

Since this doesn't exactly map to a true validation issue, it can be left as-is. However, I'd recommend enhancing these inputs to have a form wrapper for compatability when, say, JavaScript issues occur or a user has their JS disabled. That way, you can explicitly give an address for the input to submit to.

However, I'd recommend enhancing these inputs to have a form wrapper for compatability when, say, JavaScript issues occur or a user has their JS disabled. That way, you can explicitly give an address for the input to submit to.

It's probably important to note here that these search input fields are pretty much entirely reliant on JavaScript. They will automatically filter the list of themes based on what the keyword is, but will also not appear at all when JS is disabled. It also doesn't have a submit button, so it's not usable as a "traditional form" in its current state.

Regardless of what we do in regards to adding the form element and making it work without JS, I'd probably strongly urge to not keep it inside of the h1 on themes.php because of what it does to the heading list:

Regardless of what we do in regards to adding the form element and making it work without JS, I'd probably strongly urge to not keep it inside of the h1 on themes.php because of what it does to the heading list

Accessibility: Wrap the installed themes search field within a form element.

Valid code is important not just to formally meet the specification, but also to
ensure user agents, including assistive technologies, can accurately interpret
and parse content. When HTML elements are not used in the recommended way,
user agents may render them in unexpected ways. It can also become a problem for
compatibility with older or even future browsers, devices, or other software.
See W3C WCAG 4.1.1.