Closed KatieWoe closed 5 years ago
Reproduced, this is a weird bug. I verified that the old content is not in the a11y view or hidden in the HTML. I can't find any of this old list content in the Accessibility Tree inspector in Chrome dev tools.
It is reading all of the values as though they are not attached to a list. Then after it reads all of the initial values as though they are in a paragraph, it reads out the list items, indicating list role.
There is duplication on initial read too, it is just less jarring because the content is correct. My theory is that JAWS is reading the accessible name for the unordered list containing the list items, then reading out the list items individually. Accessible names for the list items are updating correctly, but accessible name for the entire list is not.
Adding these two lines in item.property.link in AccessibleSummaryNode fix the problem, probably because it forces Chrome to recalculate an accessible name in the a11y tree:
listNode.tagName = null;
listNode.tagName = 'ul';
EDIT: But ideally, it would be nice if we can prevent JAWS from reading the accessible name of the UL at all.
@terracoda do you know of a way to make it so that the ul of the scene summary in RIAW doesn't have an accessible name that gets read by the virtual cursor? Is it even a good idea to try this?
What does JAWS read as the accessible name for the list? I wouldn't think that a list element, a <ul>
tag would require an accessible name.
Is the problem occurring because the sliders are in a list?
In testing sonified sims, I have mentioned more than once that I think I am getting duplicate content, but then I haven't been able to consistently reproduce.
Could it have something to do with the iframe and the wrapper?
@jessegreenberg, the sim sounds fine in VoiceOver. I cannot reproduce the issue with that screen reader.
When I inspect the PDOM I see an empty paragraph element with id="262-340-353-427-429"
just after the description of the equation and and empty div element with id="262-340-353-443" just after the description of the wire.
I do not, however, see any duplicate or empty elements in the scene summary before the Play Area.
And maybe since this sim is for publication, there is no need for the wrapper and the iframe, as I do not hear or see any code for an iframe.
@jessegreenberg, I do not understand this problem, should I ask a JAWS user to try it out?
The problem is that for the following list:
<ul tabindex="-1">
<li tabindex="-1">resistance, <b>R</b>, is 0.667 ohms</li>
<li tabindex="-1">resistivity, <b>rho</b>, is 0.50 ohm centimeters</li>
<li tabindex="-1">length, <b>L</b>, is 10.00 centimeters</li>
<li tabindex="-1">area, <b>A</b>, is 7.50 centimeters squared</li>
</ul>
In Chrome, JAWS reading from top to bottom reads it as "resistance R is 0.667 ohms, resistivity rho is 0.50 ohm centimeters, length L is 10.00 centimeters, area A is 7.50 centimeters squared. List with four items. Bullet, resistance R is 0.667 ohms. Bullet, resistivity rho is 0.50 ohm centimeters. Bullet, length L is 10.00 cm, bullet area A is 7.50 centimeters squared."
So it essentially reads the list twice.
Ah, when I remove tabindex="-1" from the ul the repetition goes away. tabindex="1" was added as a workaround because IE11 adds tabindex=0 to all HTML elements, even those that are not focusable.
Since we are moving toward supporting Chrome instead of FF, I think we need to stop using tabIndex=-1, I created https://github.com/phetsims/scenery/issues/893 to track this.
Well, I certainly like removing tabindex=-1
from our code.
As browsers and AT all become more standards compliant, these sorts of work-arounds will be needed less and less.
The tabindex=-1
work-around, though useful, was kind of code invasive ;-)
Thanks for figuring this out @jessegreenberg.
Update: This does also occur in the section that reads out after the equation when looking at the play area.
@jessegreenberg I did see that when jaws was reading the keyboard nav dialog it read everything out twice in a similar manner, though of course nothing can change. Not sure if this is and issue, but logging here since it is connected.
Sounds good @terracoda thanks!
Thanks @KatieWoe that is really good to know. I expect it to be the same issue Ill check those cases too and see if they go away with https://github.com/phetsims/scenery/issues/893
This should be fixed in master and I believe it is fixed for all of the cases reported here. @KatieWoe can you please verify that this is fixed in master for the scene summary, the equation section, and the keyboard help dialog?
Looks fixed but a new problem showed up. After reading the values of the slider it says something to the effect of min or mid (I can't quite tell) and then a large number with many decimals. https://drive.google.com/file/d/1qtZHB-EISWZvAN3Me9ZAFxso1f22H5B6/view?usp=sharing
According to @jessegreenberg on Slack this is either a Jaws or a browser problem.
@jessegreenberg, this might be a problem with accessible slider. I posted a bug about values not rounding properly in https://github.com/phetsims/gravity-force-lab/issues/118.
@KatieWoe, is it sounding like a small slider value, but given to the the 16th decimal place?
That is correct, this was found and reported in https://github.com/FreedomScientific/VFO-standards-support/issues/112, determined to be a JAWS or browser bug.
Hmm, thanks @terracoda I think it is a very similar but different issue. The video @KatieWoe posted shows JAWS reading the "min" attribute to many decimal places, and I verified the min attributes are rounded values. https://github.com/phetsims/gravity-force-lab/issues/118 shows a rounding problem with the aria-valuetext and seems more like an AccessibleSlider problem.
@jessegreenberg the phetsims/gravity-force-lab#118 issue is not just a JAWS issue, so yes, not the same issue. It happens in VoiceOver as well.
OK, so once https://github.com/phetsims/scenery/issues/893 is reviewed, I will feel more comfortable about cherry picking the fix into the release branch. Reassigning to myself to track the scenery issue and then collaborate with @jbphet to pull the change into the release branch.
@jessegreenberg - time to move this to the 1.6 release branch of RIAW if possible. Marking as high priority, let me know if I can help.
I cherry picked the commits into scenery's resistance-in-a-wire-1.6 branch. I tested in JAWS with Chrome and verified that this issue is fixed. Reassigning to @jbphet so he is aware that this is done.
Thanks @jessegreenberg! This will be verified in the next RC test, unassigning for now.
This seems to be fixed in 1.6.0-rc.2
Test device: Dell Laptop Operating System: Win 10 Browser: Chrome Problem description: For https://github.com/phetsims/QA/issues/219#event-1953042350 and https://github.com/phetsims/QA/issues/217 When the scene description first plays it reads out the initial values for all the sliders and then goes in to a bulleted list with those same values. If you manipulate those sliders and then prompt Jaws to read the scene description again it will read out the (now incorrect) values that the sim started with, then read a list with the actual values. Steps to reproduce:
Screenshots: https://drive.google.com/file/d/1GgeMP0Nhgm7SZnTnZFrSWO02i-i79M1a/view?usp=sharing
Troubleshooting information (do not edit):