Non-interactive content loses virtual focus when ‘activated’ in JAWS

[aardrian]

Summary

When navigating by content (headings, arrowing through the page, etc), the first time a user press Enter or Space while the virtual cursor is on non-interactive content after a fresh page load (but not a refresh), JAWS will move virtual cursor focus to the top of the page (rather, it loses focus and the user has to start over).

To re-create:

1. Open this pen in Debug mode in a new window using Chrome/JAWS;
2. Press Tab to put focus on the Nu HTML Checker link;
3. Press H to navigate to any heading (I suggest starting with the bottom ones) or press ↓ to move further into the paragraph or any other button to move the virtual cursor to plain content;
4. Press Enter or Space while the virtual cursor is on the content;
5. Observe virtual cursor focus is lost and subsequent navigation starts from the top of the page.

Expected result

Virtual cursor does not move.

Actual result

Virtual cursor focus/position is lost and subsequent navigation starts from the top of the page. Received some confirmation on Mastodon as well.

Example

• https://cdpn.io/aardrian/debug/ExemKjE (debug mode)
• https://codepen.io/aardrian/pen/ExemKjE (editor view)

Additional Information

JAWS version and build number

• JAWS 2023.2212.23

Operating System and version

• Windows 11

Browser and version:

• Chrome 110
• Edge 110

Video

Video is not audio described, but it demonstrates the issue. If you jump to 0:20 you can hear me 'activate' a heading and then start over from the top of the page. The 20 seconds leading up to that is just set-up to confirm how I am navigating the page.

https://user-images.githubusercontent.com/1376607/222728849-4777f86c-5b96-4b6b-bb0e-c0394db09387.mp4

[tmthywynn8]

Can also confirm this in Firefox Nightly 112.0a1 as well with Accessibility cache checked with JAWS Version 2023.2212.23 in Windows 10 22H2.

[JAWS-test]

I can confirm the problem.

@aardrian Why would someone try to activate a non-operating element with ENTER? I can only imagine that ENTER is to activate the link where the focus is still (also visible), but I suspect that no one would try this once the virtual cursor was moved away from the link

[aardrian]

Why would someone try to activate a non-operating element with ENTER?

1. In the case of a sighted screen reader user, if the virtual cursor visual indicator leads the user to believe the wrong thing has focus;
2. Accidentally;
3. A tester unfamiliar with screen readers tries it (and files a defect against a component that is really a JAWS bug as a result).
4. "as an end user, I sometimes press Enter on non-interactive content, e.g., to attempt to expand an answer in an FAQ."

Update: I added item 4 to reference @tmthywynn8's comment that appears after this. Weird approach, I know, but it reflects a use case.

[tmthywynn8]

I'm not an accessibility tester by trade so probably don't have much say in this (feel free to mark it as off-topic), but as an end user, I sometimes press Enter on non-interactive content, e.g., to attempt to expand an answer in an FAQ. If I get thrown back to the top of the page for pressing Enter on the wrong bit of text, I would then be trying to get around two issues, one from the web developer and one from screen reader implementation.

[JAWS-test]

@tmthywynn8

I sometimes press Enter on non-interactive content, e.g., to attempt to expand an answer in an FAQ

Non-interactive content is non-interactive i.e. nothing can be expanded there. In FAQ, if the answer can be shown and hidden by activating the question, then the question is interactive content (e.g. summary element within details element or button element with ARIA attribute aria-expanded). So in this case the problem would not occur

[aardrian]

@JAWS-test The use case @tmthywynn8 outlines is likely accounting for when a developer puts a click handler on a heading without otherwise making it into a proper control. I am guessing they have encountered these terrible developer practices and learned that sometimes it is worth trying to activate if the context suggests there may be more hidden.

I amended my example (https://cdpn.io/aardrian/debug/ExemKjE) to add a heading level 3 at the end ("Just a Normal HTML Heading") with a click handler. If you navigate to the heading and hit Enter or Space, you will get a browser alert. Then you can also experience the loss of virtual focus.

This valid use case is why I amended my numbered list above to add it.

[stevefaulkner]

@aardrian I could not reproduce this issue, am probably missing something. Ping me when you have time and will go through it with you on a call?

[joelearn]

I can confirm that pressing Enter when the virtual cursor is on a disabled interactive element causes JAWS to lose focus. Here's an example: https://codepen.io/joelearn-the-bold/pen/eYbWLKW

[bflon8]

I was also able to replicate this issue. Anyone have a fix or is there any movement here?

[aardrian]

Still an issue in JAWS 2024.

[stevefaulkner]

I can reproduce if I press enter with virtual focus on the disabled checkbox, but wondering why would somebody do this other than mistakenly? When enter is pressed and user tabs back or uses arrow key to move to previous checkbox. So i am wondering how much of an issue this is?

test case