How do you make a Shopify product quiz accessible?
Make a Shopify product quiz accessible by treating it as a multi-step form: one real question per step, visible progress, keyboard-safe option cards, and results that announce themselves.
One question per step, announced
Most quiz apps render each step as a generic container with a heading and a pile of clickable cards. For a screen reader user, the critical information is: what is the question, which step am I on, and how many steps are there. If the step change is not announced, the user clicks an option and the page silently swaps content underneath them. They are now lost on a question they cannot hear.
The fix is structural. Each step should be a real landmark or at least a labeled region, the question should be a proper heading, and moving between steps should move focus to the new question and announce it. The step indicator, Step 2 of 5, needs to be in the accessibility tree, not just painted on screen. These are not advanced techniques; they are the basics of multi-step forms, applied to a component that too often skips them because it looks like marketing, not a form.
Watch out for quizzes that auto-advance when an option is selected. Auto-advance is hostile to keyboard and screen reader users: the moment they arrow to an option, the step changes before they have finished exploring. Require an explicit Next action, or at minimum announce the advance and move focus deliberately. The quiz that feels snappy to a mouse user feels broken to everyone else.
Option cards that work with a keyboard
Quiz options are usually styled divs with click handlers, which means they are invisible to keyboards until someone adds the semantics back. Every option card needs to be a real button or a radio input, with an accessible name that matches the visible text. The selected state must be exposed programmatically, not just shown with a border color, because color alone is not a state for anyone.
Radio groups are the right pattern when only one option can be chosen, which is most quiz steps. A fieldset with a legend naming the question, radio inputs with real labels, and the group semantics handled by the browser. This gives you arrow-key navigation, screen reader announcements, and form semantics for free. Custom card styling can sit on top of native inputs; the quiz apps that rebuild radios from divs are choosing aesthetics over function, and it shows.
Test the whole quiz with keyboard only, from the first question to the results. Tab order should follow the visual order, every option should be reachable and operable, and there should be no point where focus disappears into the page chrome. If the quiz traps focus, drops it, or requires a mouse at any step, it is not accessible, no matter how clean the code looks.
Progress and results
The progress bar is information, and information needs a text equivalent. A visual bar at forty percent means nothing to a screen reader unless the step indicator is announced. Keep the text indicator, Step 2 of 5, in the accessibility tree and update it on every transition. If the quiz has a back button, make it a real button that restores the previous step's state, including the user's earlier answers. A back button that resets the quiz is a trap.
The results page is where most quizzes fail hardest. Results usually load dynamically, which means a screen reader user who just answered the last question hears nothing. Move focus to the results heading, announce the recommendations, and make sure the recommended products are real links with real names. The quiz exists to recommend products; if the recommendations are not perceivable and operable, the quiz is decoration.
Finally, give the quiz an accessible name and a skip option. Not every user wants to take a quiz to find a product, and forcing the flow is an accessibility issue in itself. A visible link to browse all products, placed before the quiz starts, respects the user who would rather just shop. Accessibility is not only about making the quiz usable; it is about not making it mandatory.