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

JAWS doesn't read combobox using Arrow keys #7341

Closed
xiepingp opened this issue Nov 24, 2020 · 19 comments
Closed

JAWS doesn't read combobox using Arrow keys #7341

xiepingp opened this issue Nov 24, 2020 · 19 comments
Labels

Comments

@xiepingp
Copy link

Environment

Operating system

Windows

Browser

Latest Chrome

Automated testing tool and ruleset

IBM CI 162 Checkpoint Violation: IBM 1.3.1 Info and Relationships
IBM Guidance: https://www.ibm.com/able/guidelines/ci162/info_and_relationships.html
Test Tool Type: JAWS Screen Reader 2019

Assistive technology used to verify

Detailed description

When JAWS reads the page content in order automatically, it wll not read the combobox.
And the combobox cannot receive the focus via pressing Arrow key, unless I use Tab key.

What version of the Carbon Design System are you using?

carbon-components-react@7.24.0

What did you expect to happen?

Jaws can read the combobox automatically in order.
And the combobox can receive the focus via pressing Arrow key

What happened instead?

JAWS does not read the combobox.
The combobox cannot receive the focus via Arrow key.

What WCAG 2.1 checkpoint does the issue violate?

IBM CI 162 Checkpoint Violation: IBM 1.3.1 Info and Relationships

Steps to reproduce the issue

Use JAWS to read page content. See description above.

Please create a reduced test case in CodeSandbox

Use storybook here:
https://react.carbondesignsystem.com/iframe.html?id=combobox--combobox

Additional information

  • Screenshots or code
  • Notes
@dakahn
Copy link
Contributor

dakahn commented Dec 3, 2020

I can't reproduce on Edge on Windows 10. JAWS spoke the Combobox as expected. Here's my JAWS output
image

@xiepingp
Copy link
Author

Hi @dakahn, I used Insert+Down Arrow key to let jaws read the page content automatically (without using Tab key to move the focus), and below is my jaws output:
7341-retest
You can see the highlight part is what jaws reads for the combobox page, the combobox is not read by jaws.

@dakahn
Copy link
Contributor

dakahn commented Dec 16, 2020

Can you confirm that the options are read and accessible by JAWS at all with your setup? @carmacleod what is the expectation here for JAWS's automatic page reading regarding a combobox? The title is being read, but not the options -- which makes sense to me, but there could be something i'm missing.

@xiepingp
Copy link
Author

I didn't do any specific setup in my jaws, just using the default setup.
Here is the guidance I found - JAWS Accessibility Tests for Web:

Verify the following by "reading" (e.g., using Down arrow) with JAWS Virtual Cursor:

  • All "presented" content on the page, including static text (i.e., plain text that appears on the web page for purpose of reading, not for interaction) is fully read using the JAWS reading keys (refer to Appendix). Read line by line. Pay attention to continuity of the content.

For those users with visual impairments, hope to understand the screen content through jaws reading. If jaws reads content in order but cannot read the combobox, users will not be aware that there is combobox for operation.

@carmacleod
Copy link
Contributor

@carmacleod what is the expectation here for JAWS's automatic page reading regarding a combobox? The title is being read, but not the options

I would expect the combobox to be read but not the options. Right now, it is only reading the label. I would expect it to say:
ComboBox title
ComboBox title edit combo
Filter...

But it isn't reading the "edit combo" part. Not sure why.

Sorry, I am out of time to look at this in any more depth, but maybe you can compare it to one of the APG combos:
https://w3c.github.io/aria-practices/examples/combobox/combobox-autocomplete-list.html
Here's the Speech history for Insert+down arrow starting just before the Example heading:

heading level 2 Example
Open In CodePen
Button
Example separator << APG examples have a separator before and after the actual example
State << reads combo label
State edit combo << reads combo itself (including label)
States << reads the aria-label for the dropdown button
Button collapsed << reads the dropdown button
Example separator
heading level 2 Keyboard Support

@xiepingp
Copy link
Author

I would expect the combobox to be read but not the options. Right now, it is only reading the label. I would expect it to say:
ComboBox title
ComboBox title edit combo
Filter...

I totlely agree with @carmacleod.
Is it possible to make jaws read not only the label part, but also the combobox itself? It's acceptant I think that jaws doesn't read those options as only if users are aware of the combobox here, they will choose the options themselves.

@dakahn
Copy link
Contributor

dakahn commented Feb 5, 2021

Although not ideal our current Combobox reads "combobox, edit has popup, {selection or placeholder}, type and text"

Which seems to sufficiently describe that the component is a combobox that is editable, its current selection or placeholder, and that on edit a popup will trigger.

This is an improvement on what I was seeing previously where the editable nature of the Combobox wasn't described at all. I'm going to close since the core issue was resolved. That said we have further improvements to make can track further changes to Combobox in the 1.2 update issue here.

@dakahn dakahn closed this as completed Feb 5, 2021
@xiepingp
Copy link
Author

xiepingp commented Feb 5, 2021

Hi @dakahn, sorry I am not quite clear about your process.. can you tell me when and how I can verify the issue? waiting for the new release v10.28.0 or even later?

@dakahn
Copy link
Contributor

dakahn commented Feb 10, 2021

@xiepingp In testing the menu items are sufficiently read as expected and when expected. You can verify this yourself by testing against our latest sandbox seen here and then update accordingly. If you feel like this is insufficient link me to WAI-Aria spec that details what we're missing and I can reopen.

@xiepingp
Copy link
Author

@dakahn, I tested in https://react.carbondesignsystem.com/?path=/story/combobox--combobox (v7.28.0), jaws is still read the title only:
7341 - retest -0218
Not sure if the version includes the fix, could you please advise?

@joshblack
Copy link
Contributor

Hi @xiepingp! 👋 The fix will be included in our next release (v10.29.0) which you can preview over at: https://carbon-components-react.netlify.com/

@xiepingp
Copy link
Author

Thanks for the infomation @joshblack 😄
I tested in https://carbon-components-react.netlify.app/?path=/story/combobox--combobox and got the same results as above, the combobox itself is still not read by jaws:
7341 - retest in netlify
Could you please take a look?

@mashenka123
Copy link

@joshblack You said you could not repro, could you please attach your speech history? And your Jaws version?

@joshblack
Copy link
Contributor

@mashenka123 thanks for reaching out! @dakahn can confirm the steps that he used for verifying it earlier 👀

@dakahn
Copy link
Contributor

dakahn commented Feb 26, 2021

@xiepingp Spent a good bit of my afternoon looking into this. I can confirm this behavior is still present. I used the WAI-Aria Combobox as a control in my testing. That said I have two points:

First I'm just not convinced it's an implementation problem on the our side. Inspecting and comparing the markup between our example and the WAI-Aria example doesn't reveal any meaningful differences (at least to my eyes). Even closer inspection of the accessibility tree shows us that to a screen reader our combobox is marked up and should be understood like we'd expect, with good semantics and proper programmatic labeling.

Secondly, This is an interesting use case -- for both the aforementioned screen readers tab focuses the first interactable element on the page which is how I would expect a user to approach a form, toolbar or wherever else you might encounter a combobox. I don't personally test work using this "read all" method, because my my assumption (and I could be wrong) was that this feature is primarily intended for use when reading an article or a lengthy paragraph of content top to bottom. There are no focusable elements per se and so the user navigates to a heading and simply hits insert+down arrow and is read the text.

With that said 😩 I would still expect the combobox to be read with down arrow -- and it is not, so I'll reopen.

@dakahn dakahn reopened this Feb 26, 2021
@dakahn dakahn added severity: 3 https://ibm.biz/carbon-severity impact: high 😱 labels Feb 26, 2021
@mashenka123
Copy link

@dakahn This is blocking Code Engine eGA, could you please let me know the fix plan? Thank you!

@carmacleod
Copy link
Contributor

@mashenka123
The Carbon Combobox update to ARIA 1.2 pattern is now merged.
Are you able to update to a newer version of Carbon that contains this fix? (I think it's v10.30.0, but @dakahn can confirm that).

@dakahn The APG link that you were using to test combobox uses the older ARIA 1.1 pattern, which never did work well with screen readers. That is why Carbon needed to upgrade to the ARIA 1.2 pattern.

@mashenka123
Copy link

This is blocking Kubernetes bug fix for: https://github.ibm.com/alchemy-containers/armada-ui/issues/6087

@carmacleod
Copy link
Contributor

@mashenka123
Please update to at least Carbon v10.30.0 (Carbon React version 7.30.0). This bug is fixed in that version of Carbon.

@emyarod emyarod closed this as completed Mar 22, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

7 participants