It appears that `browser/components/urlbar/tests/engagementTelemetry/browser/browser_glean_telemetry_engagement_edge_cases.js` and `browser/components/urlbar/tests/engagementTelemetry/browser/browser_glean_telemetry_abandonment_tips.js` tests the mouse/touch-specific behavior: the test cases are [sending a click event somewhere on the window to test that the tooltip would, in fact, disappear or not](https://searchfox.org/mozilla-central/source/browser/components/urlbar/tests/engagementTelemetry/browser/browser_glean_telemetry_abandonment_tips.js#61) (depending on the test case), while there are other ways to dismiss the tooltip that are accessible (i.e. by pressing `Esc` key, testing which is included in one of the test cases).
Similarly, `browser/components/urlbar/tests/browser/browser_view_selectionByMouse.js` sends a `mouseup` events to the `<html:body>` to dismiss the url bar with a mouse-specific tests.
These clicks are not expected or do not have to be done by a keyboard-only user and it does not have to confirm the keyboard focusability as part of the accessibility of these elements.
We adding an exception from a11y_checks for these clicks, because the clicks are testing mouse-specific behavior where keyboard accessible alternative is available and is tested, and we removing the `fail-if` notation that was added by bug 1854660 before the investigation in the meta bug 1854661.
Differential Revision: https://phabricator.services.mozilla.com/D193699
This is a hack for the experiment and likely not ideal for screen readers, but better than what we have. I'm reaching out to a11y folks to figure out the right long-term solution here. I'll make an effort to get that ready for the experiment too, but would like to get this landed as a backup.
Differential Revision: https://phabricator.services.mozilla.com/D194501
We provide `role=button` to the image control that can be clicked (with a mouse or with an assistive technology as speech-to-text/voice control) as an alternative way of the urlbar search query submission, where other ways are accessible (and are tested here too).
Setting an environment to `focusableRule: false` allows us to flag to the AccessibilityUtils that this specific button is purposefully not made focusable and its keyboard focusability should not be tested.
The previously failing accessibility checks should now be passing, thus we are also removing the `fail-if` notations that were added by bug 1854660 before the investigation in the meta bug 1854661.
Differential Revision: https://phabricator.services.mozilla.com/D193703
With the AccessibilityUtils tests updated in D193591 to pass a11y_checks for for keyboard focusable URL bar's `.searchbar-engine-one-off-item` buttons and `.urlbarView-row-inner` results options that are purposefully made focusable with arrow keys only (instead of a Tab that would create more tiring, cumbersome experience navigating Awesomebar for keyboard-only users), we could now remove the `fail-if` notations from a series of tests that were previously failing. Also, there are 12 tests that would also be affected, but they have other elements that are throwing warning or failing a11y_checks besides the one-off controls, thus we'd be keeping them to expect to fail until these items are resolved separately.
These tests were `fail-if`ed by bug 1854660 and bug 1854528, before the investigation in the meta bug 1854661 and bug 1854529.
Differential Revision: https://phabricator.services.mozilla.com/D193849
We had to skip-if those tests that were crashing during a11y_checks and since the bug 1849230 is resolved now these test can be re-enabled (whenever possible). Two tests have also been failing intermittently, thus they are remaining skipped, but the comment is updated to remove the mention of the crash.
Differential Revision: https://phabricator.services.mozilla.com/D193230
