Incorrect ARIA Landmark Example (role=search)

[aardrian]

On this page: http://www.w3.org/TR/WCAG20-TECHS/ARIA11.html#ARIA11-ex4

Example 4 shows a role="search" on a form:
[form role="search"]

Doing this will cause the validator to throw a warning. I also understand (thanks to chats on the Gitter channel) that it is not good to apply this role directly to the form as it will override native semantics. It should be applied to a container element instead.

[aardrian]

The following text should probably be edited to remove "form field" (which I think mean to say "form element," though it implies an ):

The search role typically goes on the form field or a div surrounding the search form.

[LJWatson]

Suggested replacement content for the technique...

The following examples show a search form with a "search" landmark. The "search" role should be put on a div containing the form, or a div just inside the form, but not on the form element itself (because overriding the native semantics of existing HTML elements is not recommended).

<div role="search">
<form>
<label for="s6">search</label><input id="s6" type="text" size="20">
...
</form>
</div>

<form>
<div role="search">
<label for="s6">search</label><input id="s6" type="text" size="20">
...
</div>
</form>

If it's permissable to link to working draft notes, then I'd suggest including Notes on Using ARIA in HTML as one of the resources linked from this technique.
http://www.w3.org/TR/aria-in-html/

[awkawk]

Does this count as overriding native semantics? Isn't this just setting a landmark for a specific type of form?

Does this cause any actual problems, other than a warning in the validator? (Warning is "Element form does not need a role attribute.")

[yatil]

Note that this might be an ARIA and coordination issue, probably PFWG needs reiterate on this. I have talked to @michael-n-cooper and he proposed to file a bug against ARIA which I will do tomorrow morning (unfortunately no time to do it today).

[LJWatson]

It overrides the native semantics of the form element, yes.

What real-world impact this has on current ATs is unknown, but my hunch is that it's minimal. We can't know what impact it might have as more ATs support ARIA though (obviously).

Arguably a WCAG technique shouldn't recommend a practice that is generally problematic though.

[lauracarlson]

Related info:

• Gitter Channel Archive 19th of August 2015 (Discussion starts on line 20)
• Adrian's post "Where to Put Your Search Role"

[awkawk]

So, if PF/APA/ARIA feels that this is not a best practice we should modify the example. I'm not really seeing in the docs where authors are guided against putting role=search on a form element, and for that matter, I'm neither hearing anyone citing actual problems with AT nor am I convinced that a role of search is overriding native semantics (it seems that it might be seen as tightening the semantic scope of the form, but not overriding?).

All that said, the easiest path is to change the example to a form that we all agree is ok.

Example 4 intro:
The following example shows a search form with a "search" landmark. The search role typically goes on the form field or a div surrounding the search form.
changes to:
The following example shows a search form with a "search" landmark. The search role typically goes on a div contained within or surrounding the search form.

Example 4 (added the div, moved the role="search" to the div)

search ...

We will wait for the ARIA in HTML document to be published and then add a link at that time.

[michael-n-cooper]

I'd say this proposal should be run past PF. WCAG is being asked to issue guidance on an issue to which it does not know the correct answer, and we don't want to come out with a different answer than PF would if asked the same question (which they may be). Even if the proposal is not wrong, it may not be right either, and I'd rather come up with the closest to right answer possible.

[awkawk]

Surveyed August 25, left open pending discussion
http://www.w3.org/2015/08/25-wai-wcag-minutes.html#item06

[richschwer]

I looked at the HTML 5 specification. There is nothing that states that a role of "search" cannot be applied to

:
http://www.w3.org/TR/html5/dom.html#wai-aria
So, the question is why is the validator flagging it?

[richschwer]

Is this because it is excluded in HTML 5.1?

[aardrian]

My Gmail ate part of your message, but I assume you are applying it to a
[form].

I ran into this a few months ago, wrote what I found:
http://adrianroselli.com/2015/08/where-to-put-your-search-role.html

People smarter than I weighed in on it.

On Tue, Dec 1, 2015 at 12:31 PM, Richard Schwerdtfeger <
notifications@github.com> wrote:

I looked at the HTML 5 specification. There is nothing that states that a
role of "search" cannot be applied to
:
http://www.w3.org/TR/html5/dom.html#wai-aria
So, the question is why is the validator flagging it?

—
Reply to this email directly or view it on GitHub
#113 (comment).

[yatil]

Hi @richschwer, see this issue on ARIA for some overview on affected specs: w3c/aria#85

[richschwer]

I see. For there to be a validator warning there would need to be an indication in the HTML5 specification that you could not put a role of "search" on a form. It is entirely conceivable to have a form be used to perform a search and in fact it may be more accurate. ARIA allows the host language to restrict the application of some roles to HTML. There is no reason for the HTML validator to spit out a warning.

[richschwer]

I should add that ARIA already provides a Form role.

[joshueoconnor]

I like Leonies example

[joshueoconnor]

Draft response:

Currently this is allowed in the spec, and we will let it be unless we find a use case that determines it is an error. We may log a bug against the ARIA in HTML doc (5.1) as it only allows global ARIA attributes on form elements, and not roles.

We will leave the example as it is - the validator is at fault here, and this is a work in progress then take up this issue with the ARIA working group.

[awkawk]

Modified draft response:
The best judgement of the Working Group is that the validator is at fault in this situation. Currently, the WG does not believe that this example is overriding native semantics and provides useful functionality at present, but if normative information demonstrates that this is incorrect we will modify the example.

[stevefaulkner]

@awkawk it is not the validator (at fault) it is the spec http://www.w3.org/TR/html-aria/ which defines conformance requirements for use of ARIA in HTML,@jnurthen has opened an issue on the spec, to which i have commented w3c/html-aria#18 (comment) feel free to continue discussion on bug.

[richschwer]

I should note that the spec. Steve refers to is for HTML 5.1 as this bug does not exist in the HTML5 spec. The validator has made a change based on a spec. that has not yet reached recommendation. Isn't it a bit early to be modifying the validator? ... just saying. This is an easy fix for Steve. Steve, what is the time line for HTML 5.1?

[stevefaulkner]

resolved w3c/html-aria#18

[awkawk]

Proposed response: This issue is resolved with an update to the spec by @stevefaulkner and a bug filed on the validator. No changes will be made to the WCAG documents.

[richschwer]

+1

[yatil]

+1

[awkawk]

Proposed response accepted by WCAG group on Dec 18 (https://www.w3.org/WAI/GL/wiki/Decisions)

[OlivierNourry]

@awkawk Hi Andrew, this discussion has revolved around whether a role=search should be applied or not on the FORM element.
Yet there's still this uncertainty over this formulation in the ARIA11 example 4: "The search role typically goes on the form field or a div surrounding the search form".
Based on this I have always assumed that something like <input role="search"/> was ok, but this makes the Nu HTML validator send this error message: "Bad value search for attribute role on element input."
I couldn't find in the HTML5 spec that this role was forbidden explicitly (but perhaps I missed something). But at least VoiceOver/Safari seems puzzled by this: it does not render anything of a field that has role=search, although it's able to take focus. So I guess it's not expected by some ATs, which pleads in favor of avoiding it entirely.
Shouldn't the WCAG example be modified in this regard, as suggested by @aardrian here: #113 (comment) ?

[yatil]

@OlivierNourry The ARIA Authoring Practices Guide has the following information:

“A search landmark contains a collection of items and objects that, as a whole, combine to create search functionality.”

One form element with a role="search" is probably not really a “collection” (unless you count the shadow DOM…).

[awkawk]

@OlivierNourry I made the change in the source docs to reflect @aardrian's suggestion: 5ac01d9?diff=split

[OlivierNourry]

Agreed, and it could also be argued that an input field is not a landmark, properly speaking. The issue here is that the ARIA11 technique says you can use role=search on a form *field*, which is wrong as per what we are saying. IMHO this example should be fixed in this regard, don’t you think?

…

Le 25 mai 2017 à 15:09, Eric Eggert ***@***.***> a écrit : @OlivierNourry <https://github.com/oliviernourry> The ARIA Authoring Practices Guide <https://cdn.rawgit.com/w3c/aria-practices/master/aria-practices.html#aria_lh_search> has the following information: “A search landmark contains a collection of items and objects that, as a whole, combine to create search functionality.” One form element with a role="search" is probably not really a “collection” (unless you count the shadow DOM…). — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#113 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AC0Owbf6EuXK8l_ErTxcyGdnOXWND13xks5r9X19gaJpZM4FubGY>.

[OlivierNourry]

@awkawk awesome, thanks!

[yatil]

@OlivierNourry Totally agreed :-) Thanks for pointing it out!

[OlivierNourry]

My pleasure! Actually I had validated putting a role=search on an input field, and later on, the validator and the screen reader proved me wrong. So I felt it had to be fixed at source to avoid the same mistake to others. Glad if it helps!

…

Le 25 mai 2017 à 15:26, Eric Eggert ***@***.***> a écrit : @OlivierNourry <https://github.com/oliviernourry> Totally agreed :-) Thanks for pointing it out! — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#113 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AC0OwdSJIZy2Ln25wyf9dObeMj06lCQiks5r9YF1gaJpZM4FubGY>.