#amyfang37 - accessibility
woeful yoke
golden cedar
hi @west iris ! Is this particular to your own integration, or something you see for all card element instances?
I'd like to gather any necessary conditions for this to reproduce and file with the team that builds elements to investigate
west iris
Hello! The only experience I have with Stripe is in my company's integration and we have two instances of using the card element that have the same issue
It's a fairly simple integration. We wrap the Card Element in a div
golden cedar
Do you see the same issue in our examples here?
https://stripe.dev/elements-examples/
Apologies I am not familiar with using NVDA or other readers to diagnose directly myself
west iris
Yes, it happens with examples #1, #4, and #5. Looks like these all use the card element
while the others use individual elements for each field
golden cedar
OK so its on the combined card element version, NOT the split fields
west iris
Looks like it
golden cedar
OK, can you describe the steps to follow to reproduce and what you'd expect vs actual?
After we narrow that down I can file the bug report, and I'll ask you to write in to support@stripe.com and mention my handle so I can keep you in the loop as the work on that progresses.
west iris
- Using NVDA screen reader, tab through the credit card form until you reach the card number field.
- Type in numbers using the top row of number buttons (ex. 4242...)
Expected: Numbers are inputted, NVDA reads out the inputted number
Actual: No numbers are inputted, NVDA reads out "no next heading"
golden cedar
You're describing the "top row" of numbers on a physical keyboard, and having different behaviour than a num pad?
west iris
Correct
golden cedar
That certainly seems unexpected. Perhaps a silly question, is it possible those keys are shared with other functions that are blocking the numeric inputs? I think no, since you say this works as expected in the split card implementations, but I want to confirm.
west iris
Yeah, in NVDA there are two modes: browse mode and focus mode. These are automatically switched around depending on your context. So if you're on a field, it switches to focus mode, which allows you to type in anything from your keyboard. If you're in browse mode (ex. clicking around), the top row number buttons are shortcuts to move to the next heading (h1, h2, etc.). So in this case, it for some reason is recognizing the card number field as something that should trigger browse mode.
golden cedar
ahh ok, that's great context, thanks for explaining
west iris
So I need to write stripe support?
golden cedar
I was trying to see if I could replicate but it doesn't seem like it since NVDA is windows only as far as I can tell.
Yes, can you please write to support@stripe.com and include the above and mention my handle?
If you let me know when you've done that I can go find your request and get it reported asap
west iris
Oh yes, you're right, it is Windows-only. Sorry, didn't mention that.
If I have more accessibility issues with Stripe Elements, should I include all of those in one email to stripe support or break them out into separate emails?
golden cedar
Hmm You can include those if you like, and we can see about filing as multiple bugs or a single one internally 🙂
Please make sure to include browser, os and reader versions etc
golden cedar
I'm signing off shortly -- did you have a chance to send this? OK if not, but I'll give my colleague a heads up if you need more time to go check for it.