1921984 - Event target can be wrong when "clicking" on a button with the keyboard

Status: NEW

(Firefox :: Disability Access, defect)

Description

[Calixte Denizet (:calixte)]

Attachment: plop.html

STR:

• enable NVDA
• load the attached html file
• open the console in devtools
• reach the button with the keyboard
• press either <enter> or <space>

Actual result:
The console shows that the target is the span inside the button

Expected result:
The target must be the button itself like when NVDA is disabled.

Comment 1

[Calixte Denizet (:calixte)]

I just wrote a patch to fix the issue we had in the pdf viewer (the secondary menu was not displayed with NVDA and the keyboard).
But it doesn't fix the bug I filed here.

Comment 2

[James Teh [:Jamie]]

When you're in NVDA browse mode, enter and space perform the default action (using the accessibility API) on the deepest node underneath the browse mode cursor. Default action maps to mouse click, and in this case, the deepest node is the span. NVDA does this because there are many controls on the web which aren't properly accessible, so clicking the deepest node is more reliable than relying on the author to correctly implement keyboard functionality. This is normally consistent with a mouse click; a mouse click will generally hit the deepest node at that point. In this case, it's a bit different because of the off-screen span.

One way to "fix" this would be to detect off-screen nodes and walk to the nearest on-screen ancestor. However, this would break interactive elements that are intentionally off-screen; e.g. skip links. I'm not a fan of this pattern, but it is in the wild and it is used pretty widely.

I'm leaning towards a wontfix on this, but I'd like to better understand the PDF viewer use case here. Was this really an off-screen span or something else? And if so, why was it off-screen?

Comment 3

[Rares Doghi, Desktop QA]

@James, the "More Tools" button from the PDF toolbar cannot be selected with Space or Enter if NVDA is enabled, there is also a similar issue in Bug 1912418

Comment 4

[Calixte Denizet (:calixte)]

In the pdf.js case, each buttons has a callback on click event and there is a global click callback.
When the user clicks on the button we show the menu, then the global callback is called and it checks that the event target is a button or not and hide the menu when the target isn't a button.
So because of this bug, the menu is shown and then hidden, consequently the button isn't doing its job.
The fix was to check if the target is under a button or not.

I think that it isn't obvious that a span under a button can be the target of a click event and I tend to think that it should behaves the same way what ever the context is (i.e. with or without screen reader).

Comment 5

[James Teh [:Jamie]]

(In reply to Calixte Denizet (:calixte) from comment #4)

I think that it isn't obvious that a span under a button can be the target of a click event

Sure, but why is there an off-screen span inside the button with content anyway? If it were on screen, a mouse click would also target the span, as I explained above. The only reason it doesn't in this case is that the span is off-screen, which seems odd given that there is content inside it.

and I tend to think that it should behaves the same way what ever the context is (i.e. with or without screen reader).

It would behave exactly the same as if the user were using a mouse, except for this off-screen strangeness. That's what I'm trying to understand.

Comment 6

[Calixte Denizet (:calixte)]

I tried to git blame pdf.js in order to figure out why it has been added more than a decade ago, but the original commit doesn't have any explanation.
Few months ago, I fixed bug 1886964 which is about NVDA which isn't reading a button title when hovering with the mouse:
https://github.com/nvaccess/nvda/issues/12047
The workaround was to add a span in the button.

Comment 7

[James Teh [:Jamie]]

The NVDA workaround is... annoying, but pragmatically, it's a valid use case for now. That said, I still don't know of a way to "fix" this without breaking other cases in the wild; e.g. skip links.