-
Notifications
You must be signed in to change notification settings - Fork 3.1k
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
display contents accessibility tests #43740
Conversation
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.
Very nice to see so much additional test coverage. Just a couple tiny nits from my side.
promise_test(async t => { | ||
el.focus(); | ||
|
||
assert_equals(document.activeElement, el, "Element is keyboard focusable"); | ||
}, `${testName}`); |
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 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.
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.
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.
if (!els.length) { | ||
throw `Selector passed in verifyElementsAreKeyboardFocusable should match at least one element.`; | ||
} |
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 would leave this out. It should never be hit and makes it take a bit longer to read what is going on.
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'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.
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.
Maybe use assert_unreached(msg)
instead of throw
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.
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.
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 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.
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.
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.
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 long as that happens I guess that's okay.
if (!els.length) { | ||
throw `Selector passed in verifyElementsAreKeyboardFocusable should match at least one element.`; | ||
} |
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 long as that happens I guess that's okay.
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"); |
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.
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
.
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.
Thanks @dbaron, updated the <script>
block with correct (and new) function name.
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 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"); |
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 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.
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.
Agreed, I've updated the test name to be more specific. I've also modified the local focusability function name:
OLD: verifyElementsAreKeyboardFocusable()
-> NEW: verifyElementsAreFocusable()
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.
Approving with David's requested change in https://github.com/web-platform-tests/wpt/pull/43740/files#r1471328585
* New tests for display : contents accessibility, verifying role and label expectations Authored-by: Rahim Abdi <rahim_abdi@apple.com>
* New tests for display : contents accessibility, verifying role and label expectations Authored-by: Rahim Abdi <rahim_abdi@apple.com>
Closes web-platform-tests/interop-accessibility#60
WPT investigation as part of:
display: contents
interop-accessibility#60display: contents
accessibility interop#568Follow on work in web-platform-tests/interop-accessibility#97