shadcn.io is not affiliated with official shadcn/ui
Accessibility Options Checkout Block for Ark UI
Display options for a checkout panel: a text size group and three switches for stronger borders, always-visible field hints and larger touch targets that restyle a sample form beside them, plus a button that raises a properly built example error.
Installation
Overview
Let people make checkout easier to read, with these accessibility options for React with Ark UI. A compact header from Clearhand, a shop for assistive kitchen tools, says in one sentence that only this panel changes. The first band is the options: a Toggle Group for text size (100, 125 and 150 percent) and three Switches for stronger borders, always showing field hints and larger touch targets, each with a line saying what it does. Beside them a sample form (email, name on card, ZIP) restyles as you change them: the type scales, the borders thicken, the hints stay visible instead of appearing only while a field is focused, and the fields and button grow to 48 pixels. A button raises one example error on the email field, built properly with an icon, words, the field marked invalid and described by the message, and focus moved to it. A polite status line says what the options are now, and Continue to payment is the only Shine Button. It's built from Toggle Group, Switch, Field, Input, Button and Guides. For checkouts that let people tune the form and for showing how a design system holds up.
FAQ
Does it change my page or my device?
No, and the copy says so. The options are state in this block and only restyle the sample form's own classes; no page style, cookie or device setting is touched. A real site would also respect the browser's own text size and the user's preferences, and these options would sit on top of them.
How do the always-visible hints work?
Each field keeps a reserved hint line. With the switch off the hint is hidden until the field has focus (visibility, so the line keeps its space); with it on, every hint stays. Because the line is always there, switching it never moves the fields.
What does the example error show?
The pattern to copy: a destructive-toned icon beside the words (so the message does not depend on colour), the input marked aria-invalid and linked to the message with aria-describedby, and focus moved to the field. The message is in foreground text. Editing the email, or pressing the button again, clears it, and the status line announces both.
How is the text size applied?
The sample sets a base font size from the group (the catalog's 0.875rem, 1.09375rem or 1.3125rem) and its labels, inputs and hints are sized in em from it, so everything scales together and the layout wraps rather than overflowing. The panel keeps room for the largest size so the foot does not jump.
How are the controls named?
Each switch carries an accessible name equal to its visible label, and the text-size group is named by its heading. Switches are foreground-toned rather than the primary colour, and a pressed size is solid foreground, so the one primary stays on the Shine Button.
What stays local in the demo, and how do I wire it up?
Everything. Nothing is saved, and Continue to payment only says that payment comes next. In your app store the choices per person (an account setting or a long-lived cookie), apply them as classes on your real checkout form, and keep the sample so people can preview before they continue. To go to your payment step: wrap an a element in the Shine Button with asChild.