Make WordPress Core

Opened 11 years ago

Closed 10 years ago

#10108 closed defect (bug) (wontfix)

Invalid HTML in get_search_form()

Reported by: kchrist Owned by:
Milestone: Priority: normal
Severity: normal Version: 2.9
Component: Validation Keywords: needs-patch 2nd-opinion
Focuses: Cc:


The get_search_form() function outputs the following HTML:

<form role="search" method="get" id="searchform" action="' . get_option('home') . '/" >

The "role" attribute is not valid in any current version of (X)HTML. While it may be a part of XHTML 1.2, it may not even be used in HTML5, which is the direction things are going. Attributes defined in the XHTML 1.2 draft should not be implemented until they become part of a final recommendation.

Attachments (1)

10108.diff (4.4 KB) - added by Denis-de-Bernardy 11 years ago.

Download all attachments as: .zip

Change History (17)

#1 @Denis-de-Bernardy
11 years ago

  • Component changed from General to Template
  • Keywords needs-patch added
  • Milestone set to 2.8.1

#2 follow-up: @ryan
11 years ago

Those are WAI-ARIA landmark roles, which always generate debate. :-) See #9408.

#3 @Denis-de-Bernardy
11 years ago

  • Keywords close added


#4 in reply to: ↑ 2 @Elpie
11 years ago

  • Cc Elpie added

Replying to ryan:

Those are WAI-ARIA landmark roles, which always generate debate. :-) See #9408.

You know, WordPress uses so much JavaScript that adding roles through js would work, while also satisfying those who want to output validating X/HTML.

I've been using this successfully for awhile:

function setRoleAttribute(id, rolevalue) {
	if(document.getElementById(id)) {
		document.getElementById(id).setAttribute("role", rolevalue);
function setAriaRoleElementsById() {
	//Add all Id:s and aria roles here
	setRoleAttribute("header", "banner");
	setRoleAttribute("content", "main");
	setRoleAttribute("sidebar", "complementary");
	setRoleAttribute("footer", "contentinfo");
	setRoleAttribute("menu", "navigation");
	setRoleAttribute("searchform", "search");
window.onload=function(){ setAriaRoleElementsById(); }

It's accessible to assistive devices and browsers. The roles are not output if JavaScript is off, but if its off WAI-ARIA roles and properties are not needed either.

The other advantage of adding the roles through js is that as new roles are defined, updating the script is much easier than hunting through the code to hardcode them.

#5 @Denis-de-Bernardy
11 years ago

  • Keywords has-patch commit added; needs-patch removed

Attached patch drops it all on the front end. please close the ticket if we're not interested.

#6 @ryan
11 years ago

  • Milestone changed from 2.8.1 to Future Release

Going to leave as is for now.

#7 @Denis-de-Bernardy
11 years ago

  • Milestone Future Release deleted
  • Resolution set to wontfix
  • Status changed from new to closed

we'll reopen if/when we're interested.

@Elie: this can be overridden using a plugin or the theme's functions.php file. see the hooks in the WP_Widget class.

#8 @thomask
11 years ago

  • Resolution wontfix deleted
  • Status changed from closed to reopened

I disagree - yes, we can change it by own searchform.php in theme, but in my opinion the default wordpress should be 100 % valid. If you want to use role, then you should ad it to DTD schema or at least use some javascript as mentioned above

#9 @hakre
11 years ago

I don't think that using javascript for roles is healthy, this can break the concept. Adding it to the DTD will help us to easier validate and validation is usefull for the software releas cycles.

Anyway, when I validate the output I already know of these two things: ID errors and the ARIA attributes I will get as errors, so it's possible to deal with it properly on the human side as well, at least it does not produce much problems for me.

DTD would help at least for the ARIA things and I won't complain if this would be put in for the admin and/or the default theme at least.

#10 @hakre
11 years ago

  • Component changed from Template to Validation
  • Keywords needs-patch added; has-patch commit close html search templates removed
  • Version changed from 2.8 to 2.9

I did a bit research:

Hey, we're tight on shedule, December 15th is the date of the latest ARIA 1.0 draft.

This problem is not new, looks like the folks with the W3C validator do already work on it. The following Blog Post is about that: How Can I Validate (X)HTML + ARIA?.

So this might be more or less something to be changed in the doctype and the configuration of the validators used.

Using a custom DTD is not suggested, but I think W3C is a bit biased on this one :).

What I sometime did was to inject DTD into the XHTML document which is possible. That configures the W3C validator to accept certain elements and attributes which are not part of the linked documents DTD. As this is a workaround for an upcomming XHTML+ARIA DTD I assume that this would be a valid exception to "don't use custom DTDs".

#11 @hakre
11 years ago

  • Keywords 2nd-opinion added

I would suggest to wontfix this ticket as long as there has been formulated a standpoint how to handle this in wordpress. I see good chances that validators will respect ARIA the sooner or later so nohting to change on our side right now.

#12 @hakre
11 years ago

  • Milestone set to Future Release

Any objections with closing the ticket as wontfix for now?

#13 @nacin
10 years ago

  • Milestone Future Release deleted
  • Resolution set to wontfix
  • Status changed from reopened to closed

#14 @thomask
10 years ago

  • Resolution wontfix deleted
  • Status changed from closed to reopened

the DTD is allready there http://www.w3.org/TR/wai-aria/appendices#xhtml_dtd

The XHTML 1.1 plus WAI-ARIA DTD is available from http://www.w3.org/WAI/ARIA/schemata/xhtml-aria-1.dtd

So I think there is no need to wontfix. Or it could be an option, or just recommendation for those people, who desire valid documents

If you do not agree, close it again, not crucial for me when i know the solution.

#15 @demetris
10 years ago

I don’t know much about WAI-ARIA roles, but it seems that themes with the HTML5 doctype validate fine, both in the W3 validator and in validator.nu.

To confirm:

  • Activate Twenty Ten (the new default theme in current trunk)
  • Delete or rename searchform.php in the twentyten directory (WordPress will not find the file then and it will output the default markup)
  • Validate a page

If that’s the case, and since there is nothing preventing themes switching to the HTML5 doctype, then:

  • Maybe we can stop worrying about the issue, and wontfix this ticket for good
  • Maybe we can remove searchform.php from Twenty Ten

#16 @nacin
10 years ago

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

searchform.php was removed from Twenty Ten. Once again wontfixing.

Note: See TracTickets for help on using tickets.