-
Notifications
You must be signed in to change notification settings - Fork 3.2k
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
[Accessibility] - Test for elements not in viewport contained within content-visibility: auto CSS property #50004
base: master
Are you sure you want to change the base?
Conversation
Results:
|
promise_test(async t => { | ||
let computedLabel = await test_driver.get_computed_label(el); | ||
let computedRole = await test_driver.get_computed_role(el); | ||
|
||
console.log('el-text-content: '+el.textContent+'; comp-role-f: '+computedRole+'; comp-label-f: '+computedLabel); |
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.
You can still use the existing aria utils logging to abstract this... Just leave the expected role and labels as something no engine will ever use, like data-expectedrole="SPEC_AMBIGUOUS_LOG_VALUE" and all engines will log a message like ~"Role for for element was group
; Expected: SPEC_AMBIGUOUS_LOG_VALUE"
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.
Is it acceptable for all engines to fail, even if the outcome is uncertain?
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.
In a tentative test that we are leveraging to determine the correct behavior, yes! Absolutely. Tentative tests don't get counted in the total WPT metrics, so there is no downside.
The much more concerning downside to putting in an expectation for a potentially ambiguous spec, is that the implementations may make a change based on the tentative test. That would be bad, because if the WG later determines the expectation to be invalid, now the engine would have to roll back the change and it causes a webcompat issue.
<h2 class="el">test heading</h2> | ||
<button class="el">test button</button> | ||
<a class="el" href="#">test link</a> |
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.
needs data-expectedrole="heading"
, etc.
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.
Closing and reopening to kick the bots again and see if we can get that last CI result.
FYI you have a bunch of lint errors that need to be corrected before seeing the final CI results or merging. |
Lint errors solved |
Closes: web-platform-tests/interop-accessibility#168
Relates: w3c/html-aam#572
This PR introduces tests for elements outside the viewport that are contained within another element with the content-visibility: auto CSS property. The console log output includes:
Note: The test outcomes are simply logs to observe browser behavior. There are no set expectations at this point, as these will be discussed in relation to w3c/html-aam#572.