search

angular / components

Component infrastructure and Material Design components for Angular
https://material.angular.io
MIT License
24.34k stars 6.74k forks source link

bug(mat-select): value changes not always shown on a Braille display #27721

Open fcnjd opened 1 year ago

fcnjd commented 1 year ago

Is this a regression?

The previous version in which this bug was not present was

No response

Description

Hello, since I am blind, I use a screenreader, primarily relying on my Braille display (speech is nice to have, but I often work without it). I've reproduced this bug using both Firefox and Google Chrome on Windows 101, with Jaws screenreader version 2023. When interacting with a mat-select element using up and down arrow keys, the changed value isn't displayed on the Braille display. However, this can only be reproduced when just tapping onto the select and pressing the arrow keys. When expanding the dropdown first (using either the enter key or the mouse), the values change as expected. This means a downgrade from the native select, since there the bug doesn't exist. Both variants can be found on given REPL link.

Reproduction

The interactive example in this Angular documentation can be used to reproduce: https://material.angular.io/components/select/overview

Steps to reproduce:

  1. Turn on Jaws screenreader and either connect a Braille display, or use the Braille viewer
  2. Tap to the mat-select (don't expand it as described above), and press up and down arrow keys

Expected Behavior

Selected option on the Braille display changes synchronized to the actual value on screen.

Actual Behavior

The value on the screen gets asynchronous from the value on the Braille display. Changes are sent through as flash messages, but once they disappear we're out of sync, so following the convention would be better here. Continue tapping until you get to the native select on the same page, and there you find it working as it should.

Environment

zarend commented 1 year ago

Hello @fcnjd ,

Thank you for reporting this issue. I am looking into this. I was wondering if I could get more information form you to confirm that I am understanding the behavior you are experiencing.

The Select is an ARIA combobox with a listbox popup. Users can open the popup by pressing enter. When the popup is open, most screen readers will read each option as well as its number and position in set.

As an alternative to opening the popup, users can focus the Select then press up and down arrow to change the selected option. This allows users to change the value without opening the popup.

It sounds like you have been interacting with Select without using the popup. Does it work better if you press enter to open the popup?

Best regards,

Zach

fcnjd commented 1 year ago

Hello @zarend , thank you for looking into this. Yes you described it right, these are the two alternatives. It is correct that it works betterh, when I interact with the mat-select using enter (or alt+arrowdown) to open the popup, and then navigate using the arrowkeys. I hope this helps in narrowing down the issue. Best regards, Julian

zarend commented 1 year ago

Hello,

Thank you for clarifying. I had some time to look into this yesterday. I don't have a physical Braille display, but I believe I can mostly reproduce the behavior your are seeing using the virtual Braille display in JAWS. JAWS worked better for me when I would pass through the up and down arrow keys instead of pressing then normally.

When testing when virtual Braille display, I noticed that the display would appear to flicker when pressing up and down arrow. When I press down, it would display one thing then quickly display another thing. Although browser focus stays on the mat-select element, I noticed that screen reader focus would not stay on the mat-select element. It seemed to me that pressing down would cause JAWS to try to navigate somewhere and get confused about what to focus on. I think this explains the inconsistently you have been seeing on a native Braille display.

I didn't have any issue when I used a passthrough keystroke to press up or down arrow keys.

I believe using the JAWS "pass through keystroke" would be a good work-around. That way JAWS will not use a keyboard command when pressing up or down arrow keys. When collapsed, the mat-select will change it's value when pressing up or down. It seems like JAWS is trying to perform a command rather than passing the keystroke normally to the browser. On my JAWS, I can passthrough key strokes by pressing Insert + 3 – the exact key combination might be different depending on your version and configuration of JAWS.

I am not sure if there is anything we can do this. That's because changing the value of the select when the popup is collapsed isn't part of the official ARIA interaction pattern for combobox. When I have more time to look into this, the next thing I want to try is checking which mode JAWS is in, such as normal mode or forms mode.

Best regards,

Zach

fcnjd commented 1 year ago

Hello, thank you for looking into it with JAWS. I hope that I can save you some time in the future, by telling you that forms mode already points in the right direction - but every screenreader calls it differently. As for Jaws, what we care about is called the "virtual cursor", and gets relevant when using any web-based interface. When turned on, the whole keyboard navigation changes, Up and down arrow keys don't interact with elements, instead, they're used to move to previous and next line. This is much needed, basically when moving across any web page to look at it, and read the actual text. Also the behavior of the letters change, e.g. h moves between headings, f moves between form controls etc. That's why you needed to press insert+3 to pass the key through, getting around the virtual cursor. When toggled off, the normal keyboard navigation can be used, as you know it. To toggle between it, you may use the shortcut insert+z (or in my case, it is insert+y since I have a German keyboard, so it may depend on your keyboard layout). So let me mention the steps to reproduce the error in detail: Open the linked web page, and press the combination. Jaws indicates that the virtual cursor has been turned off. Now, press tab until you reach the mat-select. Now, use the arrow keys, and you should see the described bug on the virtual Braille viewer. Continue with tab to the native select, and you see, you can navigate normally. This way, you don't need to pass keys through. The "forms mode" you were talking about is very similar to a disabled virtual cursor. However, it is a bit harder to toggle individually, since it is activated when pressing enter, obviously making it harder to reproduce this bug, which also involves the use of the enter key to explicitly open the popup. Also, depending on the jaws preferences, it may occur that forms mode is enabled and disabled automatically. So, we better stick with testing using a permanently disabled virtual cursor, so it is clear how the keys behave. The virtual cursor isn't automatically toggled (unless you change windows or browser tabs, maybe). But pressing the combination always tells how it is toggled. I hope this description is understandable enough to make things clearer. Best regards, Julian

zarend commented 1 year ago

Hello,

Thank you for getting back to me. I am currently traveling, and I need more time to look into this further.

Best regards,

Zach