Skip to content
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

display contents accessibility tests #43740

Merged
merged 54 commits into from
Jan 31, 2024

Conversation

rahimabdi
Copy link
Contributor

@rahimabdi rahimabdi commented Dec 20, 2023

@cookiecrook
Copy link
Contributor

cookiecrook commented Jan 24, 2024

Copy link
Member

@annevk annevk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Very nice to see so much additional test coverage. Just a couple tiny nits from my side.

Comment on lines 40 to 44
promise_test(async t => {
el.focus();

assert_equals(document.activeElement, el, "Element is keyboard focusable");
}, `${testName}`);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The indentation here doesn't quite line up, but also, is there a reason this is a promise test? It seems this can just be a test.

Copy link
Contributor Author

@rahimabdi rahimabdi Jan 30, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you @annevk, I've now wrapped the focusability tests in an anonymous, synchronous test() function which seems to be the approach of other WPT tests.

Comment on lines 35 to 37
if (!els.length) {
throw `Selector passed in verifyElementsAreKeyboardFocusable should match at least one element.`;
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would leave this out. It should never be hit and makes it take a bit longer to read what is going on.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd prefer he keep it. The problem we've seen (on multiple occasions) is that PR authors have misspelled one of the selectors and not noticed a the silent failure of a missing test result in a larger list of subtests... It's sometimes difficult for reviewers to spot minor selector errors, too.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe use assert_unreached(msg) instead of throw

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is outside a test so asserts wouldn't work.

@cookiecrook this querySelector() is the static part of this test, no? Seems like it would not be changed anymore. It seems more likely someone would typo "ex-focusable" when adding a new element above, which we can't really guard against. Or maybe we could, but we aren't now.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I may be misunderstanding your point, but I'm coming around to leaving it out... This is only a help for authors while writing the test, and a classname typo would still result in a silent failure unless all of them had the same typo, so I can see your point about limited utility.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@annevk Also linking this PR as a potential avenue for improved error catching: #42769.

As there are other explorations, I'll leave the display: contents test as is but thanks for raising this issue!

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As long as that happens I guess that's okay.

Comment on lines 35 to 37
if (!els.length) {
throw `Selector passed in verifyElementsAreKeyboardFocusable should match at least one element.`;
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As long as that happens I guess that's okay.

@dbaron
Copy link
Member

dbaron commented Jan 30, 2024

I'm concerned that one of the tests shows "Harness status: error" across 3 browser engines.


<script>
AriaUtils.verifyRolesBySelector(".ex-role");
AriaUtils.verifyRoleAndLabelBySelector(".ex-role-and-label");
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, the reason for the error is that the function name here is verifyRoleAndLabelBySelector but the function name that you've added in AriaUtils is verifyRolesAndLabelsBySelector.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @dbaron, updated the <script> block with correct (and new) function name.

Copy link
Member

@dbaron dbaron left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The focus test looks good to me, though see one comment below and one earlier comment.

let testName = el.getAttribute("data-testname");
test(() => {
el.focus();
assert_equals(document.activeElement, el, "Element is keyboard focusable");
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this test seems reasonable, but I'd probably describe the test assertion as Element is focusable with Element.focus() since this isn't specifically testing keyboard focus.

If you wanted to also test something like tabbing you could use the approach that I used in the slot-element-tabbable.tentative.html test in #39247 , though it's probably not necessary.

Copy link
Contributor Author

@rahimabdi rahimabdi Jan 30, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed, I've updated the test name to be more specific. I've also modified the local focusability function name:

OLD: verifyElementsAreKeyboardFocusable() -> NEW: verifyElementsAreFocusable()

Copy link
Contributor

@cookiecrook cookiecrook left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@cookiecrook cookiecrook changed the title Create css/css-display/display-contents-accessibility.html display contents accessibility tests Jan 31, 2024
@cookiecrook cookiecrook merged commit 2883689 into master Jan 31, 2024
20 checks passed
@cookiecrook cookiecrook deleted the rahim/display-contents-accessibility-test branch January 31, 2024 17:16
github-actions bot pushed a commit to web-platform-tests/wpt-metadata that referenced this pull request Jan 31, 2024
github-actions bot pushed a commit to web-platform-tests/wpt-metadata that referenced this pull request Jan 31, 2024
mbrodesser-Igalia pushed a commit to mbrodesser-Igalia/wpt that referenced this pull request Feb 19, 2024
* New tests for display : contents accessibility, verifying role and label expectations
Authored-by: Rahim Abdi <rahim_abdi@apple.com>
marcoscaceres pushed a commit that referenced this pull request Feb 23, 2024
* New tests for display : contents accessibility, verifying role and label expectations
Authored-by: Rahim Abdi <rahim_abdi@apple.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

role/label tests needed for display: contents
8 participants