1767566 - [a11y] Tabs do not respond to accessibility activation

Status: RESOLVED FIXED

(Socorro :: Webapp, defect, P2)

Description

[James Teh [:Jamie]]

STR (with the NVDA screen reader):

1. Open this crash report: https://crash-stats.mozilla.org/report/index/6f1be058-4a17-4e81-865a-24c8a0220430
2. Press down arrow repeatedly until you reach the "Bugzilla" tab.
3. 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();
		}
	});
}

Comment 1

[Will Kahn-Greene [:willkg] ET needinfo? me]

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?

Comment 2

[James Teh [:Jamie]]

(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.

Comment 3

[Will Kahn-Greene [:willkg] ET needinfo? me]

If you're affected, that counts! I'll toss it in my list of things to look at soon.

Comment 4

[Will Kahn-Greene [:willkg] ET needinfo? me]

Attachment: pr 6182: bug 1767566: fix clickability of tabs in report view

Comment 5

[Will Kahn-Greene [:willkg] ET needinfo? me]

willkg merged PR #6182: "bug 1767566: fix clickability of tabs in report view" in dcb49fb.

Comment 6

[Will Kahn-Greene [:willkg] ET needinfo? me]

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:

https://blog.jqueryui.com/2021/10/jquery-maintainers-update-and-transition-jquery-ui-as-part-of-overall-modernization-efforts/

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?

Comment 7

[James Teh [:Jamie]]

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.

Comment 8

[Will Kahn-Greene [:willkg] ET needinfo? me]

Thank you!

Comment 9

[Will Kahn-Greene [:willkg] ET needinfo? me]

This was deployed in bug #1790053. Marking as FIXED.