New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

role=search should be allowed on form elements #18

Closed
jnurthen opened this Issue Dec 15, 2015 · 7 comments

Comments

Projects
None yet
3 participants
@jnurthen

jnurthen commented Dec 15, 2015

There is no issue with adding role=search on

elements. Form has no semantics for accessibility so adding a search on it seems entirely natural. The ARIA group seems to agree with this.

See w3c/wcag#113

@stevefaulkner

This comment has been minimized.

Collaborator

stevefaulkner commented Dec 15, 2015

thanks @jnurthen will review

@stevefaulkner

This comment has been minimized.

Collaborator

stevefaulkner commented Dec 15, 2015

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
@jnurthen

This comment has been minimized.

jnurthen commented Dec 15, 2015

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

@stevefaulkner

This comment has been minimized.

Collaborator

stevefaulkner commented Dec 15, 2015

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.

@jnurthen

This comment has been minimized.

jnurthen commented Dec 15, 2015

Thanks Steve

@dylanb

This comment has been minimized.

dylanb commented Dec 16, 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?

@stevefaulkner

This comment has been minimized.

Collaborator

stevefaulkner commented Dec 16, 2015

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

Haroenv added a commit to algolia/instantsearch.js that referenced this issue Mar 13, 2017

feat(SearchBox) add role=search to the form
This helps for screenreaders, and is valid html5 since december 2015. Before then it was working, but not valid. see also w3c/html-aria#18

vvo added a commit to algolia/instantsearch.js that referenced this issue Mar 15, 2017

feat(SearchBox): add role=search to the form (#2046)
This helps for screenreaders, and is valid html5 since december 2015. Before then it was working, but not valid. see also w3c/html-aria#18
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment