Make WordPress Core

Opened 10 years ago

Closed 8 years ago

#34881 closed enhancement (fixed)

Invalid HTML around the input field for searching themes

Reported by: takayukister's profile takayukister Owned by: adamsilverstein's profile adamsilverstein
Milestone: 4.8 Priority: normal
Severity: normal Version: 4.3
Component: Themes Keywords: good-first-bug uniform-search has-patch
Focuses: ui, accessibility, javascript Cc:

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).

Attachments (4)

34881.diff (50.3 KB) - added by aryamaaru 9 years ago.
added form for theme search filter
34881.2.diff (1.3 KB) - added by afercia 8 years ago.
34881.patch (1.6 KB) - added by desrosj 8 years ago.
Fixes the theme install page to show the search field with proper styling and alignment.
34881.3.diff (1.7 KB) - added by afercia 8 years ago.

Download all attachments as: .zip

Change History (22)

#1 @adamsilverstein
10 years ago

  • Keywords good-first-bug added
  • Owner set to adamsilverstein
  • Status changed from new to assigned

@takayukister: Thanks for your ticket!

That makes sense, can someone from the a11y team weigh in on best practices here? Thanks.

Out of curiosity, how did you discover this issue: where you using a tool to scan pages for issues or looking for specific issues?

This ticket was mentioned in Slack in #accessibility by adamsilverstein. View the logs.


10 years ago

#3 follow-up: @iamjolly
10 years ago

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.

Here are links to this guideline for 4.1.1: http://www.w3.org/TR/WCAG20/#robust and the W3C's recommendation for forms: http://www.w3.org/TR/html5/forms.html#forms

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.

#4 in reply to: ↑ 3 ; follow-up: @Cheffheid
10 years ago

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:

http://i.imgur.com/CeDqUcs.png

#5 @afercia
9 years ago

  • Keywords needs-patch uniform-search added
  • Milestone changed from Awaiting Review to Future Release

I'd like to address this in the next release cycle. See also related #31818.

#6 in reply to: ↑ 4 @SergeyBiryukov
9 years ago

Replying to Cheffheid:

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

Related: #26601

@aryamaaru
9 years ago

added form for theme search filter

This ticket was mentioned in Slack in #core by kapils003. View the logs.


9 years ago

#8 @swissspidy
9 years ago

  • Keywords has-patch added; needs-patch removed

@aryamaaru Thanks for your patch. I'm updating the keywords accordingly. Note that there is no need to modify minified JavaScript files as these will be generated automatically.

#9 @afercia
9 years ago

Besides layout issues, the form will need to have its default action prevented otherwise pressing Enter will submit the form causing a page reload.

This ticket was mentioned in Slack in #accessibility by afercia. View the logs.


8 years ago

#11 @afercia
8 years ago

  • Keywords needs-refresh added
  • Milestone changed from Future Release to 4.8

After the work done on #26602 the only thing left here would be wrapping the search field in a form element. Moving to 4.8.

This ticket was mentioned in Slack in #core by jeffpaul. View the logs.


8 years ago

@afercia
8 years ago

#13 @afercia
8 years ago

  • Keywords needs-refresh removed

Refreshed patch.

#14 @afercia
8 years ago

  • Resolution set to fixed
  • Status changed from assigned to closed

In 40572:

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.

Props takayukister, aryamaaru.
Fixes #34881.

#15 @desrosj
8 years ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

Looks like this has caused the search input on Add Themes to be missing.

There is a search-form field there that also needs to be converted to wp-filter-search-form https://core.trac.wordpress.org/browser/trunk/src/wp-admin/theme-install.php?rev=40572#L167

This ticket was mentioned in Slack in #core by desrosj. View the logs.


8 years ago

@desrosj
8 years ago

Fixes the theme install page to show the search field with proper styling and alignment.

@afercia
8 years ago

#17 @afercia
8 years ago

I'd take this as an opportunity to use a form element for the theme install page too, see 34881.3.diff

#18 @afercia
8 years ago

  • Resolution set to fixed
  • Status changed from reopened to closed

In 40586:

Themes: Fix missing search field in the Theme Install screen after [40572].

Props desrosj, cristianozanca for reporting.
Fixes #34881.

Note: See TracTickets for help on using tickets.