How should a Shopify store vet a new app for accessibility before installing it?
Every Shopify app you install injects markup into your storefront, and its accessibility problems become your problems. A 20-minute vetting pass before installation, keyboard test the app's storefront output, check its contrast and focus handling, and read its documentation for accessibility statements, catches most issues while uninstalling is still free. Apps are the number one source of surprise accessibility regressions on Shopify stores.
Why apps are the top regression source
Theme code changes on a schedule you control. App code changes whenever the vendor ships. An app that was accessible at install time can become inaccessible after an update you never reviewed, and you will not know until a customer complains or a scan flags it. Reviews widgets, upsell popups, size guides, and loyalty panels are frequent offenders because they render complex interactive components inside your pages.
The liability question is settled: it is your store, so it is your exposure. An ADA demand letter does not distinguish between your theme's code and your review app's code. Vetting before installation is the only point where you have full leverage, because the vendor still wants your business.
Test the storefront output with a keyboard
The single most revealing test takes five minutes. Install the app on a development or staging store, then operate everything it renders using only the keyboard. Tab through its widgets, open its popups, submit its forms. If you cannot reach something, operate something, or dismiss something with a keyboard, you have found a real barrier that will affect real customers.
Pay special attention to focus behavior. Popups and modals from apps are notorious for two failures: focus stays behind the modal, letting keyboard users tab into the page underneath, and focus is not returned to the triggering element when the modal closes. Both are disorienting and both are common.
Check contrast, labels, and announcements
Next, check the visual and programmatic basics. Do the app's buttons and text meet contrast minimums against your store's backgrounds? Are its form fields labeled, or do they rely on placeholder text that disappears? When the app updates content dynamically, like a cart drawer or a review filter, does it announce the change to assistive technology or update silently?
You do not need a full audit for this pass. You need the five-minute version of one: keyboard, focus, contrast, labels, announcements. If an app fails two or more, that is a strong signal about the vendor's engineering culture, and the problems will not be limited to what you tested.
Read the vendor's accessibility posture
Look for an accessibility statement, VPAT, or conformance report in the vendor's documentation. Its presence does not prove the app is accessible, but its absence tells you accessibility is not on the vendor's roadmap. Check the app's changelog for accessibility fixes; vendors that fix accessibility issues are vendors you can work with.
If the app is business-critical and the vetting surfaces issues, contact the vendor before installing. Ask specifically whether they test with keyboard and screen readers and whether they will commit to fixing the issues you found. The response, or the silence, is data.
Make vetting part of the install process
Vetting works when it is a gate, not a suggestion. Add it to whatever process your team uses for app installs: no app goes on the production store without the 20-minute pass and a one-paragraph writeup of the result. Keep the writeups in a single log so the next install benefits from the last one's lessons.
And keep watching after install. The vetting pass is a snapshot. Continuous monitoring of the app's storefront output catches the regressions that vetting cannot predict, which is exactly what the vendors' update cycles produce.