phetsims / qa

Quality Assurance Task Tracking
MIT License
13 stars 8 forks source link

Dev test: molarity 1.5.0-dev.23 (a11y instrumentation) #436

Closed twant closed 4 years ago

twant commented 5 years ago

@zepumph, @emily-phet, @Matthew-phet, @terracoda, @ariel-phet molarity/1.5.0-dev.23 is ready for dev testing.

This sim has been instrumented with sound and PDOM accessibility features.

Document issues in https://github.com/phetsims/molarity/issues and link to this issue.

Assigning @ariel-phet for prioritization.

General Dev Test

What to Test

- Click every single button. - If there is sound, make sure it works. - Make sure you can't lose anything. - Play with the sim normally. - Try to break the sim. - If there is a console available, check for errors and include them in the Problem Description. - Rung through the string tests on at least one platform, especially if it is about to go to rc.

General Dev Test Platforms

- [x] Latest macOS, Chrome and Safari - [ ] Latest iOS, Safari - [x] Windows 10, all browsers - [x] Latest Chrome OS, Chrome

Link(s)

- **[Simulation](https://phet-dev.colorado.edu/html/molarity/1.5.0-dev.23/phet/molarity_en_phet.html)**
Accessibility (a11y) Dev Test

What to Test

- Specific instructions can be found below. - Make sure the a11y feature testing doesn't negatively affect the sim in any way. - Load the a11y view and make sure that interacting with all elements in the simulation updates the appropriate descriptions in the PDOM.

Link(s)

- **[a11y View](https://phet-dev.colorado.edu/html/molarity/1.5.0-dev.23/phet/molarity_a11y_view.html)** - **[Simulation](https://phet-dev.colorado.edu/html/molarity/1.5.0-dev.23/phet/molarity_en_phet.html)**

Screen Readers

This sim supports screen readers. If you are unfamiliar with screen readers, please ask Katie to introduce you to screen readers. If you simply need a refresher on screen readers, please consult the [QA Book](link), which should have all of the information you need as well as a link to a screen reader tutorial made by Jesse. Otherwise, look over the a11y view before opening the simulation. Once you've done that, open the simulation and make sure alerts and descriptions work as intended.

Platforms and Screen Readers to Be Tested

- [x] Windows 10 + Latest Chrome + Latest JAWS - [x] Windows 10 + Latest Firefox + Latest NVDA - [x] macOS + Safari + VoiceOver - [ ] iOS + Safari + VoiceOver

Critical Screen Reader Information

We are tracking known screen reader bugs in [this Google Document](https://drive.google.com/open?id=12kTs-g-iKEIH1dyG7Q41_W_oNL4gUKbkW-IQgZjMUBw). If you find a screen reader bug, please check it against this list.

Keyboard Navigation

This sim supports keyboard navigation. Please make sure it works as intended on all platforms by itself and with a screen reader.

Final Requests

- [x] If this sim is being tested for a11y we may want to do some testing on Talkback to check on latest behavior of that screen reader. Please comment in the issue asking if Talkback should be tested. See https://github.com/phetsims/a11y-research/issues/144.
FAQs for QA Members
There are multiple tests in this issue... Which test should I do first? Test in order! Test the first thing first, the second thing second, and so on.

How should I format my issue? Here's a template for making issues: Test Device blah Operating System blah Browser blah Problem Description blah Steps to Reproduce blah Visuals blah
Troubleshooting Information blah

Who should I assign? We typically assign the developer who opened the issue in the QA repository.

My question isn't in here... What should I do? You should: 1. Consult the [QA Book](link). 2. Google it. 3. Ask Katie. 4. Ask a developer. 5. Google it again. 6. Cry.


KatieWoe commented 5 years ago

Bit confused about this part of the description:

concentration readout range for this solution 0 to 2.250 molar

This information isn't usually available, especially when the sim doesn't have solution values checked, which it doesn't by default. Can you explain this decision?

twant commented 5 years ago

@KatieWoe Thanks for the question! I am not sure about this choice, but @terracoda, @Matthew-phet and/or @emily-phet can probably give more insight.

KatieWoe commented 5 years ago

If I could make a suggestion, instead of giving numbers that aren't originally available you could say something like "concentration readout range is very small/moderately sized/large etc." @terracoda @Matthew-phet @emily-phet

terracoda commented 5 years ago

@KatieWoe, yes, thank you for this question.

@Matthew-phet, @emily-phet and I have discussed how best to describe the concentration readout range several times. And I agree that it does seem odd to include the values when Solution Values is not checked for this single detail. That said, we have considered many aspects of the descriptions.

We felt we would have to describe a lot of detail about the Solution Concentration bar itself before we would be able to then describe that the coloured section of that bar is a different size for each solute - and in addition describe it in a way that makes sense to a non-visaul user. We felt a big description of the Solution Concentration bar would draw too much attention to it. Playing with the sliders, hearing the provided alerts, and understanding that the solution in the beaker is changing are much more important details.

The learning goals of the sim are to develop an understanding of concentration (molarity), and also discover that each solute has a saturation point.

The description, "concentration readout range for this solution 0 to 0.500 molar" describes the exact range for the potassium permanganate solute without actually calling the max value "0.500 molar" the saturation point. We do not feel we are giving away an answer.

We came to a consensus that it might be more straight forward for a non-visual learner to compare actual numbers in this case. For example, a learner doing a deep exploration might put together that the readout range for Colbalt(II) chloride which is 0 to 4.350 molar is much greater than the readout range for potassium permanganate. That might help them make sense of why they can move the solute slider more before they hear the tinkle sounds and the "Solution saturated" alert.

Our goal, I think, in this case, is to provide an equivalently strong representation of the concept. The concept being that each solute has a different range between zero concentration and max concentration.

Another practice we try to follow in our description designs is to provide the most important or most recently changed information first, wherever possible.

For example, in the Beaker description we provide all the details of the solution first:

It is only at the very end that we provide the readout range.

Another thing to consider is how this description is accessed or delivered to users. The "State Descriptions" are only accessed on-demand while the user is reading. The actual readout range is never provided during interaction. This description is meant to provide the most useful information a user may need if they choose to read the entire description of the beaker description.

I hope that puts the description in context a little better. We could, at some point, provide the concentration readout range information differently, as you have suggested, but I think for now we will stick with the numbers.

This description was, indeed, one of our big challenges for this sim.

emily-phet commented 5 years ago

@KatieWoe Thanks for the good question!

I concur with @terracoda - we spent a lot of time trying negotiate the challenges brought up by the concentration readout...and we settled on the current solution (as @terracoda describes).

KatieWoe commented 5 years ago

Some lag on chromebook, especially on the left slider when particles are involved. Not too bad.

KatieWoe commented 5 years ago

QA is done

KatieWoe commented 4 years ago

Can this be closed since it is in rc @zepumph