Givewp: Tabbing should work properly for iframed CC fields

[alaca]

User Story

As an admin, I want that when tabbing through the on-site CC fields (Hosted Fields) the tab order of the fields should be such that the user can fill them out left-to-right and top-to-bottom in a logical order using the tab key, not reaching for their mouse.

Details

Currently with Stripe, PayPal Donations, Square and others the "Cardholder Name" field is not properly allowing tabbing through the credit card fields.

Expected Behavior

The tab order of the fields should be such that the user can fill them out left-to-right and top-to-bottom in a logical order.

Steps to Reproduce

1. Enable Stripe Credit Card payment gateway
2. Go to the Donation form page
3. Select Donate with Credit Card option
4. Press the Tab key to navigate through the fields

Visuals

Additional Context

Acceptance Criteria

• [x] User can fill CC fields in a logical order using the tab key for Stripe - Credit Card PG
• [x] User can fill CC fields in a logical order using the tab key for Paypal Donations PG
• [x] User can fill CC fields in a logical order using the tab key for Square PG

The Acceptance Criteria is not complete, I will update accordingly.

[JasonTheAdams]

@alaca I notice that you listed out the payment gateways in the details, but the acceptance criteria is still a single line. I suggest breaking apart the acceptance criteria so it's one checkbox per payment gateway. That way we're confident each one has been tested and is working properly. 😃

[kevinwhoffman]

I just reviewed the markup of the multi-step form, and I think part of the reason we are having trouble with tabindex is because we have explicitly set tabindex="1" on several inputs (e.g. First Name, Last Name, Email). The problem with setting a tabindex is that once you set it for one input, you need to carefully maintain it through the rest of the form. We've essentially taken over management of the tab order from the browser, and if we don't manage it exactly right, then we end up with an unintuitive tab order that we have now.

Ideally we would not use tabindex at all and instead order the form elements in a logical sequence so that the browser can naturally move from one focusable element to the next.

As noted on MDN:

Avoid using tabindex values greater than 0. Doing so makes it difficult for people who rely on assistive technology to navigate and operate page content. Instead, write the document with the elements in a logical sequence.

So rather than adding even more tabindex attributes, I'd recommend seeing if we can actually remove our current use of tabindex and let the browser handle the tabbing order based on the order of our markup.

[kevinwhoffman]

@alaca I think I've narrowed down the cause of the problem. The tab order issue only occurs when Stripe is NOT the default payment option. When Stripe is not the default, this means that rendering of the Stripe Elements (iframes) is delayed until the user actually selects the credit card payment option. At this point the Stripe Elements display, however the tab order skips over them.

See my screencast for more info.

[alaca]

@kevinwhoffman the problem is not only related to the Stripe PG, but to all Payment Gateways which are not set as default PG. Why tabbing works when Stripe is set as default PG is because the input fields of the default gateway are loaded immediately, the rest of PGs are loaded via ajax when you click on the radio button to choose another PG.
The function responsible for setting the tabindex is this one. Basically it sets the tabindex attribute of each input element on the give_gateway_loaded event which is fired when PG is successfully loaded via ajax. At that moment the loaded HTML is not yet in the DOM, and that's why tabindex is not set for those fields.

Try this, set Ofline Donations as default PG. Navigate to the Donation form and load the Stripe Credit Card PG. Try tabbing through the fields. Now go back one step, and after that go forward one step. Try the tab key again. Now it should work because the setupTabOrder function gets called also on form navigation i.e go back or go forward.

[kevinwhoffman]

@henryholtgeerts Can you provide some context here regarding why we are explicitly setting tabindex in the multi-step form?

https://github.com/impress-org/givewp/blob/826fbbbf6dff371429940a62d09a102e1a8e2083/src/Views/Form/Templates/Sequoia/assets/js/form.js#L620-L632

[canny[bot]]

This issue has been linked to a Canny post: Tabbing should work properly for iframed CC fields :tada:

[henryholtgeerts]

@kevinwhoffman Believe this route was taken to account for the back button (top left) and navigation buttons (along bottom of the form), and to ensure that focus moves to the correct element from when navigating via the navigation buttons or back button.

[alaca]

This is what I get when I remove the setupTabOrder function. I used Tab key to navigate through the form elements.

We could try wrapping the setupTabOrder function with setTimeOut function, and set 300 milliseconds delay, enough for the loaded elements to be inserted into DOM. I think this will solve the tabbing issue we have now.