role=search should be allowed on form elements about html-aria HOT 7 CLOSED

thanks @jnurthen will review

from html-aria.

Form has no semantics for accessibility

I would note that this statement is incorrect as at least one AT (JAWS) allows navigation via form elements:

List of Form Fields INSERT+F5
Move To First Form Field INSERT+CTRL+HOME
Move To Next Form Field F
Move To Prior Form Field SHIFT+F
Move To Last Form Field INSERT+CTRL+END

from html-aria.

Steve - those are form fields, not the form element. So JAWS lets you move to INPUT etc, not to FORM

from html-aria.

Steve - those are form fields, not the form element. So JAWS lets you move to INPUT etc, not to FORM

@jnurthen you are correct and I am incorrect :-) will edit spec in next day or 2, to fix issue.

from html-aria.

Thanks Steve

from html-aria.

This is certainly not the only example of this. Other examples are menubars/tablists/insert_favorite_role_here that are actually also navigation landmarks. Obviously adding the landmark role in those cases is not a good solution because it would require removing the other role.

I understand that this proposed solution helps in the short term, but is there a better solution? For example, implement the concept of multiple roles or split out the landmark roles from widget roles into a new attribute?

from html-aria.

The philosophy behind the conformance requirements is that if an element has inbuilt significance, we should discourage overriding that (or adding default roles unecessarily) in favour of adding a 'role' to an element that does not have inbuilt significance. i.e. If the element role exposed in acc APIs. In the case of the form element it does have significance as it has a default mapping to the form landmark role. It appears that the form landmark is not well supported by AT (there may be a reason of choice by AT implementers). I do agree it makes sense to allow 'role=search' on the form element as it is a specific type of form landmark.

Note: arguments for allowing more roles on elements with default explicit semantics because we don't want to ask devs to add a div element with the role, don't hold much water. If people take time to look at code in the wild (for example the raw data available at webdevdata.org), it is more than clear that the div elements are already in the code in many instances and can be used to host the 'role' attribute.

Also note that the ARIA in HTML spec does not effect how ARIA attributes are implemented and work in browsers/AT, only what errors/warnings are emtitted by a HTML conformance checker. The requirements attempt to guide developers on usage.

@dylanb wrote:

I understand that this proposed solution helps in the short term, but is there a better solution? For example, implement the concept of multiple roles or split out the landmark roles from widget roles into a new attribute?

This discussion while useful is out of scope for the ARIA in HTML spec, suggest bringing up on the ARIA list or filing a bug against the ARIA 1.1 spec

from html-aria.