[a11y] Tabs do not respond to accessibility activation
Categories
(Socorro :: Webapp, defect, P2)
Tracking
(Accessibility Severity:s3)
Accessibility Severity | s3 |
People
(Reporter: Jamie, Assigned: willkg)
Details
(Keywords: access)
Attachments
(1 file)
(deleted),
text/x-github-pull-request
|
Details |
STR (with the NVDA screen reader):
- Open this crash report: https://crash-stats.mozilla.org/report/index/6f1be058-4a17-4e81-865a-24c8a0220430
- Press down arrow repeatedly until you reach the "Bugzilla" tab.
- Press enter to activate it.
- Expected: The page should switch to the Bugzilla tab.
- Actual: Nothing happens.
These tabs do respond to key presses, but screen reader users often browse web pages using their screen reader's document browsing mode. In this mode, the screen reader handles activation of controls via accessibility APIs. From the perspective of the page, these activations will be received as click events.
The problem is that the tab panel component used on this page embeds a link (<a>
) inside the tab (class: ui-tab). This link handles click events. However, the tab has aria-labelledby, which tells screen readers that they should ignore the content of the tab; in this case, the link. So, pressing enter activates (sends a click event) to the tab, which does nothing.
If the component itself can't easily be fixed, perhaps this snippet of Javascript (or something similar) could be added to the page after the tabs are loaded?
for (const tab of document.querySelectorAll(".ui-tab")) {
tab.addEventListener("click", evt => {
if (evt.target == tab) {
tab.firstElementChild.click();
}
});
}
Assignee | ||
Comment 1•2 years ago
|
||
I appreciate you writing this up. Doing an accessibility scan and spending some quality time finding and fixing accessibility issues has been in the backlog for a long time (bug #1470706), but I haven't had a chance to work on it.
While I completely understand that a11y issues in general are bad, Crash Stats has a pretty small user base and I'm really strapped for time to do things. Do you know which Crash Stats users are affected by this?
Reporter | ||
Comment 2•2 years ago
|
||
(In reply to Will Kahn-Greene [:willkg] ET needinfo? me from comment #1)
Doing an accessibility scan and spending some quality time finding and fixing accessibility issues has been in the backlog for a long time (bug #1470706)
FWIW, I find crash-stats to be pretty usable, at least for screen reader functionality.
Do you know which Crash Stats users are affected by this?
I'm personally affected, but I've found a way to work around it which isn't too arduous. Given the technical audience, it's not too unreasonable to assume that others would be able to manage to work around it. Thus, I don't think it's time sensitive that you fix this.
Assignee | ||
Comment 3•2 years ago
|
||
If you're affected, that counts! I'll toss it in my list of things to look at soon.
Assignee | ||
Comment 4•2 years ago
|
||
Assignee | ||
Comment 5•2 years ago
|
||
Assignee | ||
Comment 6•2 years ago
|
||
Sorry I hadn't gotten to this until now. I hit a plethora of issues.
I don't have a Windows machine I can install NVDA on to test things out with so while I can test that the tabs still work using a mouse, I don't know if the issues is fixed when using NVDA.
I think the problematic HTML looks like this:
<li class="ui-state-default ui-corner-top ui-tabs-tab ui-tab ui-tabs-active ui-state-active"
role="tab" tabindex="0" aria-controls="details" aria-labelledby="ui-id-1" aria-selected="true" aria-expanded="true">
<a href="#details" class="ui-tabs-anchor" tabindex="-1" id="ui-id-1"><span>Details</span></a>
</li>
The li
and a
are defined in the report view template, but the bulk of the attributes--including all the aria ones--get added by the jquery ui tab code. The way we're using tab navigation here seems pretty vanilla, so I don't think it's something we can fix by changing our code.
jquery ui is in maintenance only mode and no longer active:
The 1.13 version we're using now is the first release they've done in 5 years. At some point, I want to overhaul the ui to use libraries that aren't abandoned, but I'm at least 6 months from that project.
In the meantime, I applied your fix. I verified navigation still works with a mouse, but I can't test it with NVDA. The fix is currently deployed to our stage environment. Can you test it out there? Here's a report view page on the staging environment:
https://crash-stats.allizom.org/report/index/e2e7370f-93aa-4bfa-ac67-bc8150220908
Are there other pages on Crash Stats that have problems?
Reporter | ||
Comment 7•2 years ago
|
||
The fix on the stage environment works perfectly. Thank you very much.
I'm not aware of similar problems on other crash-stats pages. If I discover any, I'll file a separate bug.
Assignee | ||
Comment 8•2 years ago
|
||
Thank you!
Assignee | ||
Comment 9•2 years ago
|
||
This was deployed in bug #1790053. Marking as FIXED.
Updated•1 year ago
|
Description
•