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

RangeSelector does not announce value changes when changing thumb position with arrow keys #3538

Open
1 of 2 tasks
marcelwgn opened this issue Oct 21, 2020 · 3 comments · May be fixed by #4442
Open
1 of 2 tasks

RangeSelector does not announce value changes when changing thumb position with arrow keys #3538

marcelwgn opened this issue Oct 21, 2020 · 3 comments · May be fixed by #4442
Assignees
Labels
accessibility ♿ bug 🐛 An unexpected issue that highlights incorrect behavior In-PR 🚀 sample app 🖼
Milestone

Comments

@marcelwgn
Copy link
Contributor

Describe the bug

A clear and concise description of what the bug is.

When using RangeSelector with narrator, pressing left/right arrow key changes the thumb value, however users are not being updated on the new value of the thumb.

  • Is this bug a regression in the toolkit? If so, what toolkit version did you last see it work:

Steps to Reproduce

  • Can this be reproduced in the Sample App? (Either in a sample as-is or with new XAML pasted in the editor.) If so, please provide custom XAML or steps to reproduce. If not, let us know why it can't be reproduced (e.g. more complex setup, environment, dependencies, etc...)

Steps to reproduce the behavior:

  1. Start Narrator (Ctrl+Win+Enter)
  2. Open RangeSelector page
  3. Focus one of the RangeSelector thumbs
  4. Move thumb with arrow keys, notice that narrator does not announce changes

Expected behavior

A clear and concise description of what you expected to happen.
Narrator should announce changes, ideally also announce upper and lower limit (RangeValuePattern)

Screenshots

If applicable, add screenshots to help explain your problem.

Environment

NuGet Package(s): 

Package Version(s): 

Windows 10 Build Number:
- [ ] Fall Creators Update (16299)
- [ ] April 2018 Update (17134)
- [ ] October 2018 Update (17763)
- [ ] May 2019 Update (18362)
- [ ] May 2020 Update (19041)
- [x] Insider Build (build number: 20236)

App min and target version:
- [ ] Fall Creators Update (16299)
- [ ] April 2018 Update (17134)
- [ ] October 2018 Update (17763)
- [ ] May 2019 Update (18362)
- [ ] May 2020 Update (19041)
- [] Insider Build (xxxxx)

Device form factor:
- [x] Desktop
- [ ] Xbox
- [ ] Surface Hub
- [ ] IoT

Visual Studio 
- [ ] 2017 (version: )
- [ ] 2019 (version: ) 
- [ ] 2019 Preview (version: )

Additional context

Add any other context about the problem here.
The UIA experience of RangeSelector is not ideal, maybe providing the RangeValuePattern for both thumbs improves this. Also more fitting UIA names for the thumbs could be chosen.

Another thing I noticed is that you can move the max-thumb with the minthumb if you keep pressing right-key. Similiarly, focusing the max-thumb and pressing down left-key eventually moves the min-thumb. Moving the thumbs with the mouse does not exhibit that behavior. Is that arrowkey behavior by design?

@marcelwgn marcelwgn added the bug 🐛 An unexpected issue that highlights incorrect behavior label Oct 21, 2020
@ghost ghost added the needs triage 🔍 label Oct 21, 2020
@ghost
Copy link

ghost commented Oct 21, 2020

Hello chingucoding, thank you for opening an issue with us!

I have automatically added a "needs triage" label to help get things started. Our team will analyze and investigate the issue, and escalate it to the relevant team if possible. Other community members may also look into the issue and provide feedback 🙌

@Kyaa-dost Kyaa-dost added sample app 🖼 help wanted Issues identified as good community contribution opportunities labels Oct 22, 2020
@Kyaa-dost Kyaa-dost added this to the 7.0 milestone Oct 22, 2020
@Kyaa-dost Kyaa-dost removed help wanted Issues identified as good community contribution opportunities needs triage 🔍 labels Oct 22, 2020
@marcelwgn
Copy link
Contributor Author

So there seems to be a small issue with providing a good way to use this control through UIA. There doesn't seem to be a pattern that does exactly what this control does, the closest would be RangeValue, but that isn't really a good choice here.

So raising a property changed on the RangeSelector control is a bit problematic (what property did change?). Another option would be to raise property change on the thumb elements. However this is where we encounter the next problem, Thumb is unsealed, so we can't simple inherit it to provide a custom AutomationPeer. So we would need to implement our own control to be able to provide a custom AutomationPeer that would allow us to notify narrator of a value change.

@marcelwgn marcelwgn removed their assignment Nov 3, 2020
@Kyaa-dost Kyaa-dost modified the milestones: 7.0, 7.1 Feb 18, 2021
@michael-hawker michael-hawker modified the milestones: 7.1, 7.2/8.0? Nov 2, 2021
@Arlodotexe Arlodotexe self-assigned this Dec 29, 2021
@Arlodotexe
Copy link
Member

Arlodotexe commented Dec 29, 2021

Can verify that this bug is reproducible in the sample app. It's not announcing thumb values at all, only "Max thumb / thumb" and "Min thumb / thumb".

Maybe we're looking at this the wrong way.

RangeSelector is just 2 sliders (min and max value) bundled into 1 control, so rather than trying to use a single IRangeValueProvider on the entire control, perhaps we implement a RangeBaseAutomationPeer on each individual thumb and treat them as separate sliders.

Arlodotexe added a commit to Arlodotexe/WindowsCommunityToolkit that referenced this issue Dec 29, 2021
@Arlodotexe Arlodotexe linked a pull request Dec 29, 2021 that will close this issue
11 tasks
@ghost ghost added the In-PR 🚀 label Dec 29, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
accessibility ♿ bug 🐛 An unexpected issue that highlights incorrect behavior In-PR 🚀 sample app 🖼
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants