Invalid HTML in get_search_form()

[anonymized_92042]

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.

[ryan]

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

[Denis-de-Bernardy]

wontfix?

[Elpie]

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.

[Denis-de-Bernardy]

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

[ryan]

Going to leave as is for now.

[Denis-de-Bernardy]

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.

[thomask]

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

[hakre]

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.

[hakre]

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

[hakre]

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.

[hakre]

Any objections with closing the ticket as wontfix for now?

[thomask]

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.

[demetris]

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

[nacin]

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