Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make Preferences Menu screen reader accessible #441

Closed
4 tasks done
terracoda opened this issue Jun 6, 2023 · 14 comments
Closed
4 tasks done

Make Preferences Menu screen reader accessible #441

terracoda opened this issue Jun 6, 2023 · 14 comments
Assignees

Comments

@terracoda
Copy link
Contributor

terracoda commented Jun 6, 2023

I discussed with @emily-phet and @kathy-phet, and there was agreement that it makes sense to make the Preferences Menu screen reader accessible when a simulation is implemented with Alternative Input. Reasoning is once a sim is implemented with a PDOM, it is navigable with a screen reader. Even if the sim doe snot have interactive description it makes sense to keep the Preferences Menu accessible in case there are any features or particular preferences that need to be turned on or adjusted.

For Quad this means we need to :

  • make the Shape Sound Options heading accessible
  • Update the descriptions of the radio group to match the visual text

And additionally, if possible

  • Make the input tabs (i.e., Camera Input and Device Input) accessible as they are available without the Voicing feature. These are both prototype features that will be available through a query parameter on the prototype's page, so it does not need to be perfect.
    • Controls should have accessible names
    • Values on controls should be accessible on focus and upon making changes
@terracoda
Copy link
Contributor Author

Noting that @terracoda thinks the current descriptions should work for both Interactive Description and Voicing. There might be minor gaps.

@jessegreenberg
Copy link
Contributor

OK, PDOM content has been added for the quadrilateral sound options. I will instrument the input tab once #315 is done.

@terracoda
Copy link
Contributor Author

terracoda commented Jun 12, 2023

@jessegreenberg and I met to discuss a more general strategy for the on-boarding the team to making screen reader accessible a Preferences Menu.

  • @jessegreenberg will open a mark down file in phet-info repo, a quick start guide of some kind.
  • A link to that doc will be added to the Alternative Input documentation
  • @jessegreenberg will sketch out what is needed for devs
  • @terracoda will sketch out what is needed for designers, e.g. tips for designing the words that a voicing compatible and screen reader accessible.
  • Regarding the Localization Tab, first steps are to add names to the language buttons. Effort on making the UI for the Localization tab better (e.g. a giant combobox?)will need to be discussed further. JG & TS though just making sure that the buttons are associated with a language was a first good step.

This comment might need to move to a new issue.

@emily-phet
Copy link

@terracoda Just a thought - I would suggest keeping tips very minimal and focused primarily on how to evaluate a drafted text description. I think we will encourage novice description designers in particular to use LLMs to help them generate initial draft descriptions, so evaluating and tweaking will be the most challenging human task. We can provide examples to feed to LLM to support generating reasonable initial text.

@terracoda
Copy link
Contributor Author

There's lots of information in the description course, but nothing about how the current Preferences Menu works, so yes, it will be brief. I am sure LLMs can be helpful.

@terracoda
Copy link
Contributor Author

We'll follow-up on documentation in issue phetsims/phet-info#213

@jessegreenberg
Copy link
Contributor

For the quadrilateral specific stuff, descriptions for Voicing were added in #315 so this is no longer blocked.

@jessegreenberg
Copy link
Contributor

The input tab of Preferences for Quadrilateral is sounding good to me with NVDA in Chrome and Firefox. I read and could use both media pipe and BLE related controls. @terracoda would you like to review?

@terracoda
Copy link
Contributor Author

terracoda commented Jun 14, 2023

I checked all tabs. Everything sounds pretty good with VoiceOver in Safari, and in Chrome I think it sounds better Tabs, so just saying so ;-)

Small Issue:

  • The "Device Input" heading is not reachable/accessible when using screen reader software. Is it in the PDOM? I tried in both Chrome and Safari. Please make "Device Input" readable to screen readers.

Confusing Issue

  • There's a bit of funny business with focus and operation of the sliders. When I use the VO cursor key to read the help text below the slider, the focus highlight stays on the slider, and the slider is still operable with the arrow keys. When I move the slider thumb with the arrow keys after moving reading focus off the slider, the new values are read out inconsistently or do not read out at all. It works fine if I just move focus to the slider and keep it there. The inconsistent reading only happens when I move the thumb when my virtual cursor is off the slider and the slider still has visual keyboard focus.

Questions:

  1. @jessegreenberg, did you notice this "sticky focus" with other screen readers?
  2. I am wondering if we are not handling focus properly on sliders? I checked the Voice Rate and Pitch sliders and the same thing happens. I don't think I ever tried testing those sliders with screen readers because to see them, I have to turn on Voicing.

I don't think this should stop publication. A fix might not be straight forward, but could you investigate to see why focus stays on the slider. Maybe you already know why.

@terracoda
Copy link
Contributor Author

The direct screen reader accessibility is good otherwise, nice work.

@jessegreenberg
Copy link
Contributor

The "Device Input" heading is not reachable/accessible when using screen reader software.

OK, this is now an h3.

There's a bit of funny business with focus and operation of the sliders.

@terracoda and I met to investigate this. We created a simple test cased where we verified that this behavior is typical for VoiceOver and happens in contexts outside of PhET.

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <title>Title</title>
</head>
<body>

<label for="my-slider">My Slider</label>
<input id="my-slider" type="range" min="0" max="10">
<p>This is a test paragraph, with some descriptive content.</p>
<button>Button!</button>

</body>
</html>

@jessegreenberg
Copy link
Contributor

@terracoda is there anything else for this issue?

@terracoda
Copy link
Contributor Author

Nope. You got the h3 in, and I can access it.

And we won't fix the somewhat confusing focus issue since it seems like that is how VoiceOver works by default in both Chrome and Safari. NVDA and JAWS have different modes, so those screen readers work differently.

If issues come up in future interviews with participants who use VoiceOver, we can revisit.

@terracoda
Copy link
Contributor Author

Closing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants