Investigate how a FXVIEW-CATEGORY-BUTTON in the Firefox View tests needs to be updated to pass a11y_checks
Categories
(Firefox :: Firefox View, defect, P3)
Tracking
()
Tracking | Status | |
---|---|---|
firefox123 | --- | fixed |
People
(Reporter: ayeddi, Assigned: ayeddi)
References
(Blocks 1 open bug)
Details
(Keywords: access)
Attachments
(4 files)
In the Firefox View side navigation component, the <fxview-category-button>
elements with role="tab"
include <button aria-hidden="true" tabindex="-1">
which are ultimately receiving clicks from the mochitests. This hacky markup is providing as-expected behavior for the end users who are interacting with tabs within a tablist - as expected.
But on the markup side, this implementation uses those inaccessible (via aria-hidden
) buttons, which causes the a11y-checks failures and would likely cause automatic HTML tests to flag this approach too, because it is not an expected pattern and, in general, we do not want this to be reused in any other component.
Since it is working, we would likely not need to re-markup the entire component in this specific case, but we would need to add comments in the test files, describing that this is a one-off instance and to setEnv
to tell Tier 2 a11y-checks that as well.
Assignee | ||
Comment 1•1 year ago
|
||
// TODO: Rewrite the description. Testable example: browser/components/firefoxview/tests/browser/firefoxview-next/browser_firefoxview_next_navigation.js
In the Firefox View side navigation component, the <fxview-category-button>
elements with role="tab"
include <button aria-hidden="true" tabindex="-1">
which are ultimately receiving clicks from the mochitests. This hacky markup is providing as-expected behavior for the end users who are interacting with tabs within a tablist - as expected.
But on the markup side, this implementation uses those inaccessible (via aria-hidden
) buttons, which causes the a11y-checks failures and would likely cause automatic HTML tests to flag this approach too, because it is not an expected pattern and, in general, we do not want this to be reused in any other component.
Since it is working, we would likely not need to re-markup the entire component in this specific case, but then we need to add comments in the test files, describing that this is a one-off instance and to setEnv
to tell Tier 2 a11y-checks that as well.
With this patch the a11y-checks won't be failing for the affected test files, we are removing the fail-if
annotations from the test manifest that were added by the bug 1854625 before the investigation under the meta bug 1854626 happened.
Depends on D194944
Updated•1 year ago
|
Updated•1 year ago
|
Assignee | ||
Comment 2•1 year ago
|
||
Depends on D195198
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Assignee | ||
Comment 3•1 year ago
|
||
When the D195198 would be ready to land, there are a few tests that are going to be passing all a11y-checks since the AccessibilityUtils would be able to automatically check focusable tabs in tablists (that were previously failing these tests) or some of them, thus we need to update the manifest to remove fail-if
notations when appropriate and update the comments in the remaining tests
Depends on D195745
Assignee | ||
Comment 4•1 year ago
|
||
When the D195198 would be ready to land, there are a few tests that are going to be passing all or most of a11y-checks since the AccessibilityUtils would be able to automatically check focusable tabs in tablists (that were previously failing these tests), thus we need to update the manifest to remove fail-if
notations when appropriate and update the comments in the remaining tests.
Depends on D197025
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Comment 6•1 year ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/54b256edce57
https://hg.mozilla.org/mozilla-central/rev/8c4ae92db831
https://hg.mozilla.org/mozilla-central/rev/88e5fb826292
https://hg.mozilla.org/mozilla-central/rev/e247bde2e205
Assignee | ||
Updated•1 year ago
|
Description
•