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

[Accessibility] Payment methods should be radio options #1695

Open
gazjoy opened this issue Aug 17, 2022 · 8 comments
Open

[Accessibility] Payment methods should be radio options #1695

gazjoy opened this issue Aug 17, 2022 · 8 comments
Labels
accessibility Enhancement New feature or request Progress: on hold v6 Included in the next major release

Comments

@gazjoy
Copy link

gazjoy commented Aug 17, 2022

Describe the bug
As part of WCAG 2.1 - 1.3.1: Info and Relationships the payment methods should give meaning of their relationship to each other. This is because they are separate buttons with no relationship. This is important as giving the methods a mutually exclusive relationship means a screen reader user will understand there are options for the method of payment. We only want to give users one option but also describe to the user that options are available. input type="radio" does this. At the moment the only way for screen reader users to understand options are available is to jump forward and backwards in the document. They could easily miss the fact that they could pay with PayPal or any other option.

To Reproduce
Steps to reproduce the behavior:

  1. Go to payment step with screen reader
  2. Listen to description of payment step

Expected behavior
Users should be able to understand they can use their credit card or another means. When navigated to by a screen reader I would expect to hear:

  • Pay by Credit card - radio button 1 of 2
  • Pay with PayPal - radio button 2 of 2

Screenshots
image
image
image

Desktop (please complete the following information):

  • OS: macOS Monterey 12.5
  • Browser: Safari 15.6
  • Screen reader: VoiceOver
@ribeiroguilherme
Copy link
Contributor

Hey @gazjoy ,

Thanks for getting back to us with these accessibility issues. Can you also share what version of the SDK are you using during your tests?

@sponglord
Copy link
Contributor

And, as mentioned in #1691 (comment), this is also something we expect to be reported on in our ADA / WCAG accessibility review

@gazjoy
Copy link
Author

gazjoy commented Aug 24, 2022

@ribeiroguilherme

Hey @gazjoy ,

Thanks for getting back to us with these accessibility issues. Can you also share what version of the SDK are you using during your tests?

version is: "@adyen/adyen-web": "5.22.0"
implementation is: drop-in

@m1aw m1aw added Enhancement New feature or request and removed Progress: on hold labels Nov 29, 2022
@m1aw
Copy link
Contributor

m1aw commented Dec 6, 2022

A fix for this has been released in the newer version v5.30.0. Still not radio buttons, but we have plans on moving towards that in the next major.

@ribeiroguilherme ribeiroguilherme added the v6 Included in the next major release label Sep 20, 2023
@gazjoy
Copy link
Author

gazjoy commented Sep 29, 2023

@m1aw Hi is there any update on when these will be made into radios? Thank you.

@m1aw
Copy link
Contributor

m1aw commented Sep 29, 2023

Hey @gazjoy yeah. We are going forward with this in v6. We do not have a release date yet, but I we are thinking in the next 1-2 months.

@pedrogarmin
Copy link

Hi @m1aw
Do you have any release date for this?

@m1aw
Copy link
Contributor

m1aw commented Dec 8, 2023

We are now targeting the first few months next year, tho this is a concrete date.

One question, does the current solution not solve the problem? Because the list is correctly marked with the appropriate role.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
accessibility Enhancement New feature or request Progress: on hold v6 Included in the next major release
Projects
None yet
Development

No branches or pull requests

5 participants