The iframe problem

Express payment buttons are the fastest path through checkout and one of the least accessible parts of it. They render inside iframes controlled by the payment provider, which means the merchant cannot reach into the button and fix it. To a screen reader, an unlabeled iframe announces as frame, or as a bare button with no name, or gets skipped entirely. The shopper hears the regular checkout form in detail and hears nothing useful about the express options sitting right above it.

The irony is sharp. Express buttons exist to reduce friction, and for shoppers using assistive technology they add a different kind of friction: a control that is visible, apparently available, and unusable. This is not a rare edge case. Express buttons sit at the top of most Shopify checkouts, which puts the least accessible element in the most prominent position.

What merchants can control

You cannot rewrite the inside of the iframe, but you control everything around it, and the surroundings do most of the work. Give the button group a proper heading or label in your own markup: Express checkout, followed by the options. That text is fully under your control and gives the screen reader user the context the iframe itself fails to provide.

Placement in the reading order matters as much as labeling. The express buttons should come before the form fields in the tab order, matching their visual position, and the transition from the button group into the form should make sense when heard linearly. If your theme injects the buttons in a way that scatters them through the tab order, that is a theme problem worth fixing, and it is fixable without touching the provider's code.

Keyboard and focus behavior

Every express button must be reachable by keyboard, activatable with Enter or Space, and must show visible focus. Test this yourself with the keyboard alone, because provider implementations vary and some fail in specific browsers. The failure to check is a focus trap: the shopper tabs into the iframe and cannot tab out, stuck on a payment button they may not even want.

Watch what happens after activation too. Some express flows open a sheet or redirect, and focus management through that transition is frequently broken. The shopper who activates Apple Pay should land somewhere sensible when the sheet closes, not dumped at the top of the page with no announcement. You cannot fix the provider's sheet, but you can choose providers and configurations whose flows behave, and you can document the ones that do not.

The fallback that saves you

The most important accessibility feature of express buttons is the alternative sitting underneath them: the regular checkout form. As long as the standard path, email, address, payment fields, is fully accessible, a shopper blocked by the express buttons still has a way to buy. The compliance disaster is the checkout that pushes everyone toward express and neglects the form.

Do not hide the regular checkout behind a collapsed section or a tiny link to make the express buttons look cleaner. The form is the accessible route and it should be presented as a first-class option. Design the checkout so both paths are visible, both are labeled, and the shopper chooses. When the express buttons fail assistive technology, and sometimes they will, the form is what keeps the sale.

What to ask the provider

Because the button internals belong to the provider, part of the work is vendor pressure. Ask for their accessibility conformance documentation and specifically whether the button exposes an accessible name, whether it is keyboard operable in all supported browsers, and how focus behaves through the payment sheet. Vague answers are an answer: the provider has not tested this.

Then test it yourself with real assistive technology. NVDA or VoiceOver, keyboard only, attempting the actual task: identify the express options, choose one, complete or abandon the flow. Fifteen minutes of real testing finds what no conformance document will tell you. Document the gaps you find, keep the accessible form path strong, and revisit the provider question every year. The buttons update constantly, and an accessible implementation can regress silently in any release.