NVDA reads many 0's if you use shift + up/down

[KatieWoe]

Test device
Samsung
Operating System
Win 11
Browser
Firefox + NVDA
Problem description
For phetsims/qa#1043. Found while testing #388, but does not seem related.
On the Surface Albedo slider, if you press Shift + up/down as though to move in small increments the number read out will continue to read 0's after the number, seemingly endlessly until interrupted with another input.

Visuals

IMG_5131.MOV

Troubleshooting information:

!!!!! DO NOT EDIT !!!!!
Name: ‪Greenhouse Effect‬
URL: https://phet-dev.colorado.edu/html/greenhouse-effect/1.3.0-dev.4/phet/greenhouse-effect_all_phet.html
Version: 1.3.0-dev.4 2024-02-14 22:04:47 UTC
Features missing: applicationcache, applicationcache, touch
Flags: pixelRatioScaling
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:122.0) Gecko/20100101 Firefox/122.0
Language: en-US
Window: 1536x731
Pixel Ratio: 1.25/1
WebGL: WebGL 1.0
GLSL: WebGL GLSL ES 1.0
Vendor: Mozilla (ANGLE (Intel, Intel(R) HD Graphics Direct3D11 vs_5_0 ps_5_0))
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: {}

[jbphet]

I can duplicate this in Chrome on my Windows 11 system, and searching through the HTML for the sim while it is loaded in the browser, I found the following element:

<input data-focusable="true" class="a11y-pdom-element" data-unique-id="48-62-1109-1116-1111-1257-1256-1254-1219" id="display1-primary-48-62-1109-1116-1111-1257-1256-1254-1219" type="range" aria-valuetext="0.30000000000000004" min="0" max="0.9" step="any" aria-valuenow="0.30000000000000004" aria-orientation="horizontal" style="top: 0px; left: 0px; width: 1px; height: 1px;">

I looked at the Greenhouse-Effect-specific code for SurfaceAlbedoControl, and it is not explicitly providing the aria-valuetext or aria-valuenow values, at least not that I can tell. It is providing a constrainValue function as an option for the slider, but I added debug code and found that this was not being called during the sequence of events that leads to the long number strings. This is leading me to conclude that it is more of a common code problem, so I'm going to assign it to @jessegreenberg for him to have a look.

@jessegreenberg - This seems similar, and perhaps related, to other work that you and I did for #388, in case that helps. Also, it's hard for me to have much input on whether it is worth the effort to track this down and fix this problem, since I have very little idea how much it would negatively impact screen reader users. I'll leave it up to you to get input on this question if needed.

[jessegreenberg]

@jbphet and I reviewed this together. We can probably use the same workaround from #388 to constrain the precision but add an option to support greater precision in the future if needed (hopefully no one would ever need to do that).