using JAWS, pressing space multiple times in balloons checkbox shifts keyboard navigation focus

[ghost]

Test Device

Hanson

Operating System

Windows 10

Browser

Firefox 60.0

Problem Description

For phetsims/qa/issues/112. If you tab to the balloons checkbox while JAWS is running and then press space multiple times, the keyboard navigation focus will shift to something else.

I've seen it shift to the following:

• One of the balloons
• The "Remove Wall" button
• Seemingly nothing

Steps to Reproduce

Tab to the balloons checkbox, and then press space multiple times.

Visuals

Troubleshooting Information

Name: ‪Balloons and Static Electricity‬
URL: https://bayes.colorado.edu/dev/html/balloons-and-static-electricity/1.4.0-dev.21/phet/balloons-and-static-electricity_all_phet_debug.html?accessibility
Version: 1.4.0-dev.21 2018-04-04 18:25:56 UTC
Flags: pixelRatioScaling
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:60.0) Gecko/20100101 Firefox/60.0
Language: en-US
Window: 1280x606
Pixel Ratio: 2.5/1
WebGL: WebGL 1.0
GLSL: WebGL GLSL ES 1.0
Vendor: Mozilla (Mozilla)
Vertex: attribs: 16 varying: 30 uniform: 4096
Texture: size: 16384 imageUnits: 16 (vertex: 16, combined: 32)
Max viewport: 32767x32767
OES_texture_float: true
Dependencies JSON: {"assert":{"sha":"928741cf","branch":"master"},"axon":{"sha":"ceb3cc00","branch":"master"},"balloons-and-static-electricity":{"sha":"f4f3cc64","branch":"master"},"brand":{"sha":"89d28f63","branch":"master"},"chipper":{"sha":"bc7c5d1f","branch":"master"},"dot":{"sha":"e5489d18","branch":"master"},"joist":{"sha":"2cf256a9","branch":"master"},"kite":{"sha":"b6071478","branch":"master"},"phet-core":{"sha":"d8804eee","branch":"master"},"phet-io":{"sha":"4bbddfaa","branch":"master"},"phet-io-website":{"sha":"b6c2b0f5","branch":"master"},"phet-io-wrapper-classroom-activity":{"sha":"1ecd81a1","branch":"master"},"phet-io-wrapper-lab-book":{"sha":"b1c5562c","branch":"master"},"phet-io-wrappers":{"sha":"025cc23d","branch":"master"},"phetcommon":{"sha":"de004c6e","branch":"master"},"query-string-machine":{"sha":"c379f1db","branch":"master"},"scenery":{"sha":"4a4afee2","branch":"master"},"scenery-phet":{"sha":"e68ebc03","branch":"master"},"sherpa":{"sha":"bb14a03a","branch":"master"},"sun":{"sha":"8a187c9f","branch":"master"},"tandem":{"sha":"f8147666","branch":"master"},"vibe":{"sha":"2dc20be7","branch":"master"}}

[ghost]

Possibly related to #293 and #308?

[ghost]

@jessegreenberg it would be useful to know how you were able to figure out where the focus is by doing something with the console.

[jessegreenberg]

Thanks @lmulhall-phet, weird.

it would be useful to know how you were able to figure out where the focus is by doing something with the console.

Sure, In the console, I added

window.setInterval( function() {
  console.log( document.activeElement );
}, 1000 );

1000 is the delay in ms, that can be tweaked if you want it faster or slower. This will tell you which DOM element has focus, which may be enough to indicate which scenery Node should have focus.

[jessegreenberg]

This also sounds performance related, like the virtual cursor isn't able to keep up with browser focus. @lmulhall-phet are you able to reproduce this in FF ESR 52?

[jessegreenberg]

I am not able to reproduce this with FF ESR 52. I think we need to decide whether we support "latest" FF or FF ESR 52.

[ghost]

@jessegreenberg I'm sort of torn on this...

1. https://support.mozilla.org/en-US/kb/can-i-use-my-screen-reader-new-firefox
2. http://www.freedomscientific.com/downloads/JAWS/JAWSWhatsNew#Enhancements

Performance is much better with FF ESR, but it seems like JAWS is trying to cater to those who transition to FF 60. The above links are pertinent.

[ghost]

In the "Web Browsers" section of the second link:

JAWS 2018 now includes improvements necessary for users who move to Mozilla FireFox version 60, expected to release within the month. It is advised that JAWS users remain on the ESR version of FireFox until Mozilla officially releases version 60.

[ghost]

Long term, it seems like a good idea to support the latest version of FF, even though it may cause headaches in the short term.

[jessegreenberg]

@lmulhall-phet I am equally torn, I agree with your interpretation. I agree that is the long term goal, but I want to avoid substantial short term work now if FF is going to significantly improve their performance anyway.

[ghost]

@jessegreenberg it sounds like we should support ESR 52 for now, and figure out when we should transition to FF 60? Maybe I'll continue to test sims on both versions, and if we see better performance on FF 60, we can begin the transition? What are your thoughts on this approach?

[ghost]

@jessegreenberg I also cannot reproduce on FF ESR 52.

[jessegreenberg]

Thanks @lmulhall-phet.

Regarding #404 (comment),
That sounds reasonable to me, lets proceed with FF ESR 52 since that is the one that really works for now. I made an issue phetsims/a11y-research#102 to discuss this in detail.

[jessegreenberg]

I expect that we will proceed with FF 60 based on recent comments in phetsims/a11y-research#102.

[jessegreenberg]

This one is really bizarre...After clicking a button once, if the button is clicked again, JAWS moves focus the the previous button in the navigation order.

[jessegreenberg]

...sometimes.

[jessegreenberg]

I am guessing this is performance related, or related to our rapidly changing DOM but we should test a JSFiddle just in case.

[terracoda]

@jessegreenberg, you have likely already given this great thought, but we might have to manage focus more tightly. Focus is easily lost if things are appearing and disappearing in the DOM. If focus is on an element that disappears the browser will try to put focus somewhere for us.

I am not sure how tightly we manage focus already??

[jessegreenberg]

Good point @terracoda, we definitely need manage focus in those cases but I don't think that is what is happening here. So far my understanding of this issue is that JAWS is making focus to to the previous focusable element after clicking a button or checkbox that doesn't change.

EDIT: @zepumph pointed out that the gif in the original ticket has focus moving back several elements

[terracoda]

@jessegreenberg, is it possible just to make sure we tell the browser where focus should be after an interaction?

Buttons can change context or not change context.:

• For example a button that opens a dialog is a change in context and focus has to be put in the dialog on the intended element. This does not happen by default by the browser.
• The Two-balloon Experiment, checkbox, it is not a change in context. Focus must remain on the checkbox. The user needs to Shift Tab or Arrow back or whatever to find the added balloon.
• The Remove/Add Wall button is also not a change in context. Focus must remain on the button when the button is pressed, regardless of the label text changing to "Add Wall" or "Remove Wall".

Just out of curiosity, how is the changed button created in the PDOM? Is it disappearing and reappearing or just getting new label text?

Also, I am wondering how likely is it for a user to pound away on a single button? Does this happen on after a couple of quick toggles, or many quick toggles?

[jessegreenberg]

I think it is too early to abandon support for FF and JAWS.

I understand and agree since FF seems to be the most widely used for a11y. I also agree about your concerns with Edge.

Can we get a little bit of QA Time to test JAWS and Chrome to see what kinds of issues come up?

If JAWS+Chrome works great, would we be willing to abandon JAWS+FF? If so, this is a great idea.

If there are no issues with ESR, including this one, we should claim support for ESR, and also claim support with FF 60 with some known issues.

This issue is not in FF ESR, but we will probably find others that are. But if we did this, the QA team would test FF 60 with NVDA and FF 52 ESR with JAWS? Then every month or so we see if JAWS works in FF quantum?

[terracoda]

This issue is not in FF ESR, but we will probably find others that are. But if we did this, the QA team would test FF 60 with NVDA and FF 52 ESR with JAWS? Then every month or so we see if JAWS works in FF quantum?

Oh my goodness, I see the issue now. We do not want 2 versions of FF, one for NVDA and one for JAWS.

If Chrome works great with JAWS, I think we could abandon support for JAWS and FF. Though I think we would need @emily-phet to confirm this decision.

When I think about it, its not like we are really abandoning support for any one Browser. We are telling users that we tested in these browsers and found no issues. Other browsers may have good support, but we can't guarantee it.

Adding and as JAWS improves, it will naturally have better support in other browsers (Edge and FireFox).

[terracoda]

@jessegreenberg, if we want to support Chrome Books at some point we will need to test on ChromeVox, too. Lately, I gotta say, ChromeVox has been great in Chrome on MacOs.

[jessegreenberg]

When I think about it, its not like we are really abandoning support for any one Browser. We are telling users that we tested in these browsers and found no issues. Other browsers may have good support, but we can't guarantee it.

I totally agree.

if we want to support Chrome Books at some pint we will need to test on ChromeVox, too.

Totally agree, once we want to start claiming support for ChromeVox or do user testing on that platform we can add it to the testing matrix.

[jessegreenberg]

An update is available for my version of JAWS, I am going to update on the off chance this bug as been fixed.

[terracoda]

@jessegreenberg, one other thought, completely random thought, does the checkbox have the same problem if it has an explicit label? We swapped the label for aria-label to reduce repetition. Just wondering if JAWS is having trouble without an explicit label.

[jessegreenberg]

Unfortunately, it does. I submitted a bug report.

[terracoda]

@jessegreenberg, can you elaborate on #404 (comment)?

[jessegreenberg]

Sorry @terracoda, didn't see your last comment.

Unfortunately, it does. I submitted a bug report.

Was for #404 (comment).

[jessegreenberg]

@terracoda Im not sure yet why it happens, but it seems to happen for several reasons on a few types of HTML elements. In this example, it will happen for "Update Readout" button, and the checkbox, but not for buttons 1, 2, and 3. Ill try without an explicit label.

EDIT: It also happens for the checkbox in this example, where the input has an explicit label.

[terracoda]

Thanks @jessegreenberg, I will check in with @emily-phet about testing JAWS with Chrome.

[jessegreenberg]

That sounds great. I am still not sure how we should proceed with immediate deployments, would be good to discuss at an upcomming a11y meeting.

[jessegreenberg]

Discussed in 6/8/18 meeting:

We will give it a little bit of time to see how VFO responds to the bug. I will also spend a little bit of time searching for a short term workaround to see if it is possible and worth the effort.

[emily-phet]

@jessegreenberg @terracoda I'll be available Monday to meet. I'll send an email re meeting times.

[terracoda]

@jessegreenberg and @emily-phet, I tested master with Chrome and ChromeVox, and it works very well when interacting.

Reading with the cursor keys is a little awkward due to the way that content lines wrap in the PDOM, but other than that BASE sounds great in Chrome with ChromeVox.

It is a very nice alternative.

Tested with:
MacBook Pro early 2015
MacOS High Sierra 10.13.4
Chrome Version 67.0.3396.79

[jessegreenberg]

We discussed on 6/11/18 -

Since this is a JAWS bug and we expect VFO to fix this bug in the next 4-6 months, we will proceed as we are with support for FF Quantum with JAWS. We will watch the VFO bug reporter in case the VFO team cannot reproduce or decides it is not their issue (like maybe it is a FF bug instead). Marking as wontfix.

@lmulhall-phet is there a good place to document this bug and decision so the QA team is aware of this problem until the AT vendor fixes it? This will show up in all of our sims.

[ghost]

@jessegreenberg, I will inform Jacob! No other testers atm, so that makes it easy.

[jessegreenberg]

I think we can close this issue. This has been tracked more generally in phetsims/a11y-research#107.

Thanks @lmulhall-phet sounds good.