How should an agency review a client's Shopify app stack for accessibility regressions?

Agencies should inventory every installed Shopify app, test what each app actually renders on the storefront, and re-verify after every app update. Most accessibility regressions in a client store come from an app the agency did not install and did not test.

Start with a full app inventory

Open the client's Apps list and record every installed app, who installed it, and what it touches: checkout, product pages, search, popups, chat, reviews, loyalty, or the admin only. Admin-only apps do not affect the storefront. Everything else does. Apps the agency did not install are the common source of surprise regressions, because nobody owns their output.

Map each app to a storefront surface

For each customer-facing app, list the pages and components it injects. A review widget injects into product templates. A search app may replace the header search and the search results page. A loyalty app can add account-page tabs and post-purchase widgets. Write this down once. It becomes the checklist for every future update.

Run the same five checks on every injected component

Keyboard access comes first: tab through the component and confirm every control is reachable and operable, and that focus is visible. Then confirm labels and names: screen readers should announce each control with a clear purpose, not "button" or an icon with no text. Then check focus management: modals and popups should trap focus while open and return it to the trigger when closed. Then contrast: app CSS often ships light gray text on white backgrounds that fail WCAG 2.2 contrast ratios. Finally, error handling: forms the app renders, such as newsletter or review forms, need the same identified, associated, and announced errors you would demand from theme forms.

Re-verify on the app update cadence, not yours

Theme changes are not the only source of regressions. Apps update on their own schedule, and an update can restyle components, rename classes your CSS targeted, or add a new modal. A practical rhythm is to re-run the checklist on each app surface after the app updates, or at least once a month per client. Keep a per-client log of app versions and check dates, so you can tell a client exactly what changed and when if a problem appears.

Negotiate app changes with the vendor, not around them

When an app injects inaccessible markup, the fix usually belongs to the app vendor, not the theme. Agencies that restyle app output with theme CSS take on ownership of that component on every future update. File the issue with the vendor, ask for a documented accessible pattern, and if the vendor will not fix it, give the client that answer in writing with the cost of a replacement app. A client who understands the tradeoff can make the call.

Fold apps into the demand-letter file

If the client has ever received an ADA demand letter, the app inventory belongs in the response file alongside the theme record: which apps were installed at the time, what each rendered, and what testing was done. Plaintiffs' lawyers ask how the store was tested. An inventory plus dated check records answers that question.