VoiceOver stops reading aria-valuetext sometimes

[jessegreenberg]

Reported initially in phetsims/ohms-law#141.

Occasionally, macOS VoiceOver stops reading aria-valuetext in sims. We weren't able to reproduce this bug in examples outside the sim like https://jsfiddle.net/gj8zmhfy/3/ and https://jsfiddle.net/gj8zmhfy/5/. Our usages of setting aria-valuetext in ohms-law are pretty simple, the aria-valuetext is set on value change, then followed by an aria-live alert ~a second later. So I suspect this issue may be related to performance or a screen reader quirk. Here are some things that we could look into to isolate what may be causing this:

• What happens to the consistency of aria-valuetext if we disable all alerts?
• What happens to the consistency of aria-valuetext if we disable graphical updates?
• What happens to the consistency of aria-valuetext if we reduce number of DOM operations?
• What happens to the consistency of aria-valuetext if we change attributes on sliders or aria-live elements?

[jessegreenberg]

@twant you develop on a mac, correct? Would you be able to help investigate this issue? Could we schedule a time to pair on this?

[twant]

Definitely! I'm working pretty long days tomorrow and Thursday, but do you have time on Friday evening? I'm also available Saturday (or we can look at times next week, too).

[jessegreenberg]

Thanks @twant! Over slack we agreed to meet on 5/10/19 Friday evening to pair on this.

[jessegreenberg]

@twant and I met today for this and tested on a macOS 1.11.10 El Capitan, Safari 9. We tried in Safari and Chrome with both requireJS and built versions but we were not able to produce this bug. We did hear duplicate aria-valuetext every time. I saw this too with an older version of macOS, but @KatieWoe helped us verify that this is not happening in Mojave in phetsims/ohms-law#141, so this must be an old VoiceOver bug.

@twant is going to update her macOS and we will try again next week to see if we can produce the bug then.

[jessegreenberg]

@twant and I tested on a macOS 10.14.5 Mojave, version Safari 12.1.1.

We tried changing the slider rapidly, slowly, after VoiceOver had begun to speak the alert, after it began to read the aria-valuetext, after it had finished speaking, and combinations of these. We only hit the bug once. It happened after rapidly moving the slider then pressing "ctrl option shift down arrow" to enter slider with VO. After tabbing away then back to the slider we heard all aria-valuetext again.

We tried several times after we hit the bug to move the slider quickly and "enter" it with voice over, but it never happened again.

If we had reproducible steps for hitting the bug, our next move would be to see if the bug happens on @twant's machine outside of a PhET sim. But since this bug is so rare and VO is able to recover from it we weren't sure if it is worth more time.

@terracoda @emily-phet what do you think?

[terracoda]

Thanks @twant and @jessegreenberg, I agree that Voice Over can recover relatively easily.
Voice Over has an "interact" command which allows users to use the track pad on things like sliders.
I wonder if it might be related to that VO interact commands.

I think the commands are:

• Interact with an item: VO-Shift-Down Arrow
• Stop interacting with an item: VO-Shift-Up Arrow

I also agree that not much more time should be spent on this, but maybe just try these 2 commands if you haven't already.

[jessegreenberg]

Thanks @terracoda, yes those were the commands I meant in #508 (comment), and it happened once after doing that. But then we tried a few times afterwards with the same steps and couldn't get it to happen again. @KatieWoe when you saw this in phetsims/ohms-law#141 was it after you pressed "control + option + shift + down arrow" to enter the slider? Or did it just happen without that too?

[KatieWoe]

I didn't use "control+option+shift"

[jessegreenberg]

Alright, thanks everyone. It sounds like it isn't necessarily related to VO "interract" commands. Since @terracoda agrees that it isn't worth spending more time on this I am going to go ahead and close.

An entry has been added in https://docs.google.com/document/d/12kTs-g-iKEIH1dyG7Q41_W_oNL4gUKbkW-IQgZjMUBw/edit in case we encounter this in the future. We can reopen if it becomes more of a nuisance.