fix: Various elements and their default roles #406
Conversation
|
This pull request is automatically built and testable in CodeSandbox. To see build info of the built libraries, click here or the icon next to each commit SHA. Latest deployment of this branch, based on commit 598b4de:
|
| @@ -69,16 +69,54 @@ function getImplicitAriaRoles(currentNode) { | |||
| } | |||
| } | |||
|
|
|||
| // <form /> with an accessible name? | |||
| if (currentNode.matches('form')) { | |||
There was a problem hiding this comment.
This is just restoring the old implementation that did not care about accessible name.
Technically <form> does not have the role="form" because the accessible name is missing (don't ask me why. I haven't tested it yet with AT; just following the spec). We could apply some heuristics to guess if it actually has one but if we want to be strict we would need to run accessible name computation (expensive).
Assuming I finish byRole('form', { name: 'some-name' }) we could leave this quirk and then ignore any element returned getImplicitAriaRoles if the accessible name is empty (and potentially warn if a form is queried without providing a name).
|
What's the status here now that |
|
Seems like I lost track of this as well. This PR is superseded by #446 |
DO NOT MERGE. new version of
aria-queryisn't released yet. Instead we're using a version built fromaria-query@master.Opening this already to get some comments on how we address the "with a accessible name" constraint.
What:
Bump
aria-queryWhy:
Fixes these bugs:
<input>being considered atextboxlistboxandcomboboxnot being recognized as implicit roles on certain elementsHow:
Built
aria-queryfrom theirmasterbranch via CodeSandbox CI.Checklist:
[ ] Documentation added to thedocs site
[ ] I've prepared a PR for types targetingDefinitelyTyped