-
Notifications
You must be signed in to change notification settings - Fork 470
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
Querying aria role superclass #675
Closed
delca85
wants to merge
3
commits into
testing-library:master
from
delca85:pr/querying-aria-role-superclass
Closed
Changes from all commits
Commits
Show all changes
3 commits
Select commit
Hold shift + click to select a range
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Appreciate the work but I'm not convinced this will actually be an improvement and not cause more confusion. I'd get behind including subclasses for abstract roles (not really though) but for concrete roles it's a bit confusing that this role would also be considered a
gridcell
. Because it actually isn't.In it's current form this will also be a breaking change. This is evident from the changes in existing tests.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I understand your point.
The
*byRole
queries could get only the abstract super classes if it sounds more reasonable. Otherwise an additional parameter could be added to decide if the hierarchies should be navigated or not.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wouldn't this change make testing library behave more like a real browser would? I don't consider bug fixes to be breaking changes. Either way I think it's worth it as long as this models browser behavior effectively.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not aware of any behavior browsers are adding for aria roles. What do you think would
getByRole('gridcell')
accomplish if it would return<th>
orgetByRole('input')
for<input type="search" />
?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As far as I understand, this part of the WAI ARIA spec requires that subclasses implement properties of superclasses. https://www.w3.org/WAI/PF/aria/roles#inheritedattributes
In that case it seems to me like these changes are important for matching browser behavior. Additionally, not supporting this would violate the Liskov Substitution Principle (replacing a type with a subclass type needs to still retain the interfaces of the original superclass type).
However one potentially issue I'm seeing is that a user may want to call
getByRole
when there's already another element of that role with a subclass, so the new behavior could now have multiple ambiguous results. This could be a confusing change in behavior of the tests, but as far as I understand is not actually a semver breaking change because it is a bug fix. Is there a better way to handle this situation? Perhaps we could warn users about this behavior in a minor release (FWIW this is consistent with how the React team has handled similar behavioral changes). Alternatively we could treat this as more of agetByAttribute
and add support for attributes other thanrole
while making it more clear that subclasses are intentionally not supported because the functionality is meant to represent literal attributes, not inherited rules.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the other concerns are mostly related to backwards compatibility. Abstract roles have no impact on that. If only abstract roles are included, then it seems like it should be easy to include while providing 90+% of what users actually want out of this.
A real use case for testing? The above examples are actual tests I tried to write for my application, so that is a real use case.
The application is dynamically generated from a schema, so validating that the inputs appear in the expected order is an important detail (while also saving me writing several different expect()s, one for each input).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
e.g. Here are exactly the same kind of tests on a table when viewing the data (rather than editing in a form):
https://github.com/aio-libs/aiohttp-admin/blob/ee9498171d0f608574c5c80fb7dc80c0dac51af9/admin-js/tests/simple.test.js#L19
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm open to looking at a new PR which handles abstract roles.
Can you show me how your test would change with this new feature?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The first test examples above, which operate on inputs of a form, would work. Today they don't (the last linked test is for the view mode, where data is in a table). My in-progress tests locally currently look like:
Which fails to test ordering while being very verbose. This would become:
Probably with a second line to assert labels as mentioned above.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That makes sense.
I don't actively maintain this project, but I think a PR would be the next step.