Join GitHub today
role=search should be allowed on form elements #18
I would note that this statement is incorrect as at least one AT (JAWS) allows navigation via form elements:
referenced this issue
Dec 15, 2015
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?
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
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.
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