Investigate how a Go button in browser_glean_telemetry_engagement_type.js test in the Search and Address Bar needs to be updated to pass a11y_checks
Categories
(Firefox :: Search, task, P3)
Tracking
()
Tracking | Status | |
---|---|---|
firefox122 | --- | fixed |
People
(Reporter: ayeddi, Assigned: ayeddi)
References
(Blocks 1 open bug)
Details
Attachments
(2 files, 1 obsolete file)
It appears that browser/components/urlbar/tests/engagementTelemetry/browser/browser_glean_telemetry_engagement_type.js
tests a behavior that is an alternative to the keyboard behavior provided for the urlbar input: the test case is sending a click event on a Go ->
button, while there are other ways to submit the search input that are accessible (i.e. by pressing Enter
key that is tested in the same file too).
The question is whether we want to make this Go button focusable and keyboard accessible.
With the existent pattern and while the Enter
key provides the same functionality as the Go button without needing an extra keypress (Tab to move the focus to the Go button) and without creating an additional tab stop for keyboard navigation, we may need to add an exception from a11y_checks for these clicks, because the click is not meant to be interactive and is not expected to be accessible. Thus, we are excluding this click event from accessibility checks and removing the fail-if
notation that was added by bug 1854660 before the investigation in the meta bug 1854661.
a11y_checks failing data:
FAIL
browser/components/urlbar/tests/engagementTelemetry/browser/browser_glean_telemetry_engagement_type.js
Node is not accessible via accessibility API
urlbar-go-button image urlbar-icon
"
chrome://mochikit/content/browser-test.js:test_ok:1583
chrome://mochikit/content/tests/SimpleTest/AccessibilityUtils.js:a11yFail:339
chrome://mochikit/content/tests/SimpleTest/AccessibilityUtils.js:assertCanBeClicked:658
chrome://mochikit/content/tests/SimpleTest/AccessibilityUtils.js:runIfA11YChecks/this.AccessibilityUtils:635
chrome://mochikit/content/tests/SimpleTest/AccessibilityUtils.js:handleClick:751
chrome://mochikit/content/tests/SimpleTest/EventUtils.js:synthesizeMouseAtPoint:652
chrome://mochikit/content/tests/SimpleTest/EventUtils.js:synthesizeMouse:555
chrome://mochikit/content/tests/SimpleTest/EventUtils.js:synthesizeMouseAtCenter:740
chrome://mochitests/content/browser/browser/components/urlbar/tests/engagementTelemetry/browser/browser_glean_telemetry_engagement_type.js:engagement_type_go_button/<:34
resource://testing-common/BrowserTestUtils.sys.mjs:withNewTab:146
chrome://mochitests/content/browser/browser/components/urlbar/tests/engagementTelemetry/browser/head.js:doTest:219
chrome://mochitests/content/browser/browser/components/urlbar/tests/engagementTelemetry/browser/browser_glean_telemetry_engagement_type.js:engagement_type_go_button:32
chrome://mochikit/content/browser-test.js:handleTask:1134
chrome://mochikit/content/browser-test.js:_runTaskBasedTest:1206
chrome://mochikit/content/browser-test.js:Tester_execTest:1348
chrome://mochikit/content/browser-test.js:nextTest/<:1123
chrome://mochikit/content/tests/SimpleTest/SimpleTest.js:SimpleTest.waitForFocus/<:1058
"
Assignee | ||
Comment 1•11 months ago
|
||
We intentionally turn off this a11y check, because the following click is send to test the telemetry behavior using an alternative way of the urlbar search query submission, where other ways are accessible (and are tested here too), therefore this test can be ignored.
Thus, we are excluding this click event from accessibility checks and removing the fail-if
notation that was added by bug 1854660 before the investigation in the meta bug 1854661.
Depends on D193699
Assignee | ||
Comment 2•11 months ago
|
||
Updated•11 months ago
|
Updated•11 months ago
|
Assignee | ||
Comment 3•11 months ago
•
|
||
The urlbar-go-button
is an image control that is only clickable. And while it is not keyboard focusable on purpose, it still has to provide appropriate accessible role so voice control/speech-to-text users and users of other assistive technology could still access it and send a click to it, if they choose to. To avoid making any major HTML changes, we could limit the fix to adding role="button"
to the <image>
element and providing a setEnv
for focusableRule: false
so an AccessibilityUtils are aware that this button is not keyboard focusable for a specific reason.
Resolving it would also affect the following two test files:
browser/components/urlbar/tests/browser/browser_locationBarCommand.js
browser/components/urlbar/tests/browser/browser_locationBarExternalLoad.js
Comment 5•11 months ago
|
||
bugherder |
Assignee | ||
Comment 6•9 months ago
|
||
Since, in the bug 1875654, we have updated the browser-toolbarKeyNav.js
to ensure the keyboard navigation handler accounts for intentionally non-focusable controls when calculating focus behavior of toolbar buttons.
We are updating the URL Bar Go
button markup to ensure it won't be included in the keyboard focus order (since a keyboard-only user could press Enter
to achieve the same submission of their search query), as well as associated mochitests since we do not need to separately set an environment to skip the focus check. This is because we also fine-tune the AccessibilityUtils' isKeyboardFocusableBrowserToolbarButton()
check to ensure more through confirmation of the image button in question.
Comment 8•8 months ago
|
||
bugherder |
Description
•