Mac VO may not read new volt/resistance value

[KatieWoe]

For phetsims/qa#313
Mac 10.14.4 Safari 12.1
I noticed one instance where Mac VO didn't read the new volt/resistance value when using keyboard nav. Once it came back though, it didn't seem to do it again. It happened one right after another for awhile, but when I managed to get it to come back, it stayed back. Not sure what caused it since I didn't reproduce it. Seemed like it might have been connected to interrupting an alert

[jessegreenberg]

It sounds like the aria-valuetext not coming through. @KatieWoe when this happened did you hear other alert information like "As letter V grows, letter I grows. Current now 10.0 milliamps."?

[KatieWoe]

@jessegreenberg yes I did

[jessegreenberg]

OK, thanks.

[terracoda]

@jessegreenberg, FYI, I have noticed a little bit of aria-valuetext inconsistency with GFL:Basics as well. I made a comment here phetsims/gravity-force-lab-basics#121 (comment)

I suspect what I noticed is similar to what @KatieWoe noticed.

[jessegreenberg]

Interesting, thanks @terracoda. Has this always been an issue for VoiceOver or is this relatively new?

[jessegreenberg]

I just tried to reproduce this on latest macOS with MacinCloud, but audio and VO are still not working on that service.

[jessegreenberg]

@zepumph just showed me that not hearing aria-valuetext is possible on NVDA too if slider movement is timed just right, so I will investigate there.

[jessegreenberg]

I just tried for several minutes to see this with NVDA but couldn't on my Windows 10 desktop in Chrome or Firefox. I am wondering if this is performance related. Ill try on my slower laptop.

[jessegreenberg]

I just tried on my Windows 10 laptop and heard all aria-valuetext in between alerts. When @zepumph had showed me over screen share we saw a number of alerts come through without hearing any aria-valuetext. But I couldn't get that to happen on my side on two different Windows machines.

[jessegreenberg]

I am able to produce this pretty easily with macOS 10.10.5 by doing this:

• Move the slider, wait for VO to read aria-valuetext and alert
  -While VO is reading the alert, move slider again. Next alert will be read but we miss subsequent aria-valuetext.

This is pretty similar to what @KatieWoe reported so I am going to try to debug this even though I only have macOS 10.10

[jessegreenberg]

So I am able to reproduce this bug with macOS 10.10.5 VO pretty consistently with https://jsfiddle.net/gj8zmhfy/3/. Basically, if the slider moves while the alert is being read, all subsequent aria-valuetext is ignored. @KatieWoe can you please try to do this on a more recent macOS and see if the problem happens there? Do you stop hearing "Value: 49" and so on?

[jessegreenberg]

Here is also a version where we separate aria-valuetext and alerts by 1000 ms, and I the issue happens there too on macOS 10.10.5 https://jsfiddle.net/gj8zmhfy/5/

[KatieWoe]

Tested first link so far. On 10.14.4. When interrupting "This is a new alert: #" I always heard the new value. It did cause the "This is a new alert" to read old alerts and repeat several of them.

[jessegreenberg]

Thanks @KatieWoe. On my version the lack of "Value: X" was easy to reproduce so it must be due to my very old OS. Ill keep working on it.

[jessegreenberg]

I tried to set up a macOS 10.14 system locally to debug but ran into problems with audio on the guest OS. I tried to debug just by watching the VoiceOver text display, but Safari kept crashing because audio was unsupported in the virtual machine. Then I tried to test in Chrome, but the system was too slow with VoiceOver to get any useful info. Unfortunately, I don't think I will be able to debug this any further without access to a device with macOS 10.14.

Based on the fact that we cannot reproduce this in #141 (comment) I am guessing this is either performance related or a screen reader quirk. Further investigation might include determining

• 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?

@emily-phet @terracoda do you believe that this issue should block publication of ohms-law? Either way, is it worthwhile to spend more time on this issue? I am unclear how disruptive this issue is to user experience.

I asked @KatieWoe how frequently this happened and she replied:

Not very often I don't think. I wasn't able to get it to happen reliably, but I think it happened about twice while I was testing that platform. Once it started it continued for some time, and continued whether I was interrupting or not. But after doing something else in the sim it would stop and I wasn't reliably able to get it to occur again.

[emily-phet]

@jessegreenberg Let's proceed with publishing the sim.

In the long term - Not sure atm whether this is worth investigating further. Let's let @terracoda weigh in before officially deciding. Seems like it could be a general quirk with VO and the current aria-valuetext/alerts setup, so my guess is we'll probably want to at least check through your bullet list above of next steps.

[terracoda]

@jessegreenberg and @emily-phet, I agree we should proceed with publishing the sim.

I haven't played with Ohm's Law in a long time, but the infrequent skips in aria-valuetext that I have recently experienced in Gravity Force Lab Basics are not that noticeable.

And to answer an earlier question, is this a new issue, in #141 (comment), honestly, I am not sure. I know VO has had trouble with aria-live alerts in the past, but I am not sure about aria-valuetext. In any case, I don't think this issue shoudl block publication.

[jessegreenberg]

Sounds great, thanks @terracoda and @emily-phet. I created the above issue in sun because this will impact all sims. Since we will continue with publication without this issue resolved, I will close this one. I will also added this to https://docs.google.com/document/d/12kTs-g-iKEIH1dyG7Q41_W_oNL4gUKbkW-IQgZjMUBw/edit since it is unclear whether this can be resolved or is a VoiceOver bug.