Keyboard Nav Pink Highlight appears when using touchscreen VO on IpadOS 13

[loganbraywork]

Test device
IpadOS 13 Test Device
Operating System
IpadOS 13.1.2
Browser
Safari 13
Problem description
From phetsims/qa#438

When using VO, if any item is double tapped (such as to mute or unmute sound) the pink keyboard nav highlight appears. Does not occur on single tap or when manipulating sliders through swipes.
Steps to reproduce

1. Activate VO
2. Double tap any item, sound button for ease
3. Using left and right swipe change VO focus
   Visuals
   
   

Troubleshooting information:
!!!!! DO NOT EDIT !!!!!
Name: ‪Gravity Force Lab: Basics‬
URL: https://phet-dev.colorado.edu/html/gravity-force-lab-basics/1.0.0-rc.2/phet/gravity-force-lab-basics_all_phet.html
Version: 1.0.0-rc.2 2019-10-14 22:08:31 UTC
Flags: pixelRatioScaling
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/13.0.1 Safari/605.1.15
Language: en-US
Window: 1024x1228
Pixel Ratio: 2/1
WebGL: WebGL 1.0
GLSL: WebGL GLSL ES 1.0 (OpenGL ES GLSL ES 1.00)
Vendor: WebKit (WebKit WebGL)
Vertex: attribs: 16 varying: 8 uniform: 128
Texture: size: 4096 imageUnits: 8 (vertex: 8, combined: 8)
Max viewport: 4096x4096
OES_texture_float: true
Dependencies JSON: {}

[jessegreenberg]

Thanks @loganbraywork, I am seeing very similar things in other web contexts with iPadOS13 VO. For example, see the focus selector activated here after double tapping, then the VO outline around the next item:

So this is expected behavior.

[jessegreenberg]

Seeing exact same behavior with Talkback.

Should anything be done about this? Previously there were no focus events for iOS. We have begun to design with that in mind. Since focus doesn't appear with the VO cursor, there is no break between focus and activation. So we cannot design things like "provide this help text on focus".

I think this is good to know, but that we shouldn't change our design strategy. But I am curious if @terracoda @zepumph or @emily-phet have thoughts.

[zepumph]

I totally agree.

[zepumph]

I'm going to proceed with GFLB publication unless I hear otherwise.

[jessegreenberg]

Sounds great to me, I think any changes that come out of this would only impact future designs.

[emily-phet]

Agree on proceeding with GFL:B.

In parallel - I don't know enough about mobile screen reader behavior to know why there seems to be two things with focus in the first screenshot above of GFL:B. I think ideally we wouldn't want that, but perhaps I'm either misunderstanding the screenshot or we don't have control over the black box thing that appears around the right sphere/robot/force arrow...? Though some kind of double focus indication seems not that bad if it's all indicating the same general focus area.

[terracoda]

To @emily-phet 's point,

Though some kind of double focus indication seems not that bad if it's all indicating the same general focus area.

I think the way we handle focus is slightlydifferent than the way screen readers do it, so there are times (perhaps before a new control has been fully activated) where things can get out of synch visually.

I think this is something that we may want to look into further as we learn more.

In my recent interview with Molarity, the participant did mention a couple things (nothing detrimental, neither bad nor good) about focus, but something about focus and activation was noticeable to the participant.

I agree, we can move forward with the way things are currently.

I want to include an FYI for us, that there has been a discussion ongoing on twitter and the w3c-wai-ig list for about week around "focus", group focus in particular. I have been trying to follow it and have made a [note to check the archives]((https://lists.w3.org/Archives/Public/w3c-wai-ig/2019OctDec/0013.html).

I do not know at this point how relevant the conversation is to our implementation or to this issue, but at the least, it is likely informative.

[jessegreenberg]

I think that #1005 (comment) proves that this isn't about how PhET manages focus but just how focus works with screen readers and browsers in general. The black highlight shows where the virtual cursor is. The red text in #1005 (comment) and our pink focus highlight shows where DOM focus is, and they can be different. This isn't something we can control and it is the expected behavior for mobile VoiceOver and Talkback. It is also the expected behavior for VoiceOver NVDA and JAWS if the user disables "Synchronize focus with virtual cursor" setting.

Prior to iOS13 we didn't get any focus events with mobile. And so we decided that we can't have any aria-live alerts or changing aria-valuetext or anything else when focus changes. But this issue shows that we have some focus events now (though they are provided in a way that is not too convenient for us). I wanted to flag this in case the design team thought it could be leveraged in future designs.

[terracoda]

Thanks @jessegreenberg and the links I posted above may be more relevant to Molarity's combobox and issue phetsims/molarity#158

I like not relying on focus for aria-live, and I think thus far we have improved our designs by no relying on focus for aria-valuetext.

Every sim is different, but I think so far, so good.

[jessegreenberg]

the links I posted above may be more relevant to Molarity's combobox and issue phetsims/molarity#158

Gotchya, yes I agree, that makes sense.

OK, in that case I think we are good to close this issue.