#kev12kev

1 messages · Page 1 of 1 (latest)

quaint sonnetBOT
next pagoda
#

Can you elaborate on what specifically you need help with?

gloomy canyon
#

It is the same as this ticket

#

But I am struggling to see what the actual solution is

next pagoda
#

Not really aware of that issue but a brief read of that thread it appears there's no 'solution' if your concern is that screen redears can't detect the input

gloomy canyon
#

So basically I am using a service called accessibe which helps with ADA accessibility of the website

#

And at the minute because of certain private stripe elements I cannot successfully tab through a checkout of a payment intent

#

So I'm trying to find a solution on that

#

The only solution I can find when using inspector is adding a tabindex to the privatestripeelement class

next pagoda
#

Tab via the screen reader?

gloomy canyon
#

keyboard nav

#

navigation

next pagoda
#

Is there somewhere I can reproduce this? Anyway, I'm not really aware of any direct solutions/workarounds. My recommendation would be to post on the issue you shared, or create another

gloomy canyon
#

Yes can we transfer to direct message?

next pagoda
#

I'm afraid not

gloomy canyon
#

You can repro on this site

#

Trying making a purchase using only Tab Navigation

next pagoda
#

Which part am I reproducing? I'm able to tab to the Card Element and can fill the fields

gloomy canyon
#

So add a donation, and tab through the fields, you will see you cannot complete the purchase, it stops after the card element field

next pagoda
#

Yeah unfortunately it seems symptomatic of that bug you found. Not really aware of any workarounds

gloomy canyon
#

I was talking to a mod last week who sent me a few tickets similar but didn't find any solutions, coculd you pass to an engineering team to see if they can?

next pagoda
#

Re-reading your thread from last week, it seems that is likely only an issue when using services/tools that grade/check accessibility:

Looking in to this. I know Stripe.js typically trips up accessibility checkers. Basically we need to use iFrames to lessen your PCI compliance burden, that would normally throw a wrench in the tab index flow of the page, so we wrote logic that manages the tab index once the element is focused on and allows it to flow through

But the way we had to implement that, ironically, includes a combination of attributes that are typically problematic for accessability. So a lot of automated tools flag it despite it actually enabling the page to be accessible

So yeah, basically we had to add hidden to a focusable element to enhance accessibility, so we consider it to be a false positive when automated checkers flag it (as long as you actually get through the page when tabbing through yourself).
#1058486332235718666 message

#

If you disable that tool, then you can tab through the complete form as expected.

gloomy canyon
#

So disable the accessibe tool?

spare carbon
#

not sure if 'disable' is the right term, but the point is that the tool is reporting a false positive

#

so you should ignore it

gloomy canyon
#

Just to clarify then - So by default the element is accessible with tab navigation - however, once I turn on my services tab navigation, it trips the elements current default tab index state and causes the bug to occur, so I should have my service turned off during payments

spare carbon
#

seems like a fair summary

gloomy canyon
#

Ok and is there no way to change/ access the default state of the private stripe element

spare carbon
#

I doubt it

gloomy canyon
#

Is there any way you can confirm that? Thanks for your help on this

spare carbon
#

no there isn't