# Accessibility drift: how a clean Shopify store slips in a quarter > An audit is a photograph. A store is a river. Here is where the drift comes from, theme updates, app installs, product imports and staff edits, and what to re-check after each one. **Provider:** SiteRemora (https://siteremora.com) **URL:** https://siteremora.com/blog/accessibility-drift-shopify **Published:** 2026-10-19 ## The store was fine in July Most merchants who [get a demand letter](/blog/shopify-accessibility-demand-letter) did not ignore accessibility. A surprising number had paid for an audit, worked through the findings, and filed the report away. Then the store did what stores do. The theme got an update. Marketing installed a countdown timer for the sale. Someone bulk-uploaded forty products from a spreadsheet. By October the audit described a site that no longer existed. Every step in that sequence was reasonable. It is just that an audit is a photograph and a store is a river. Accessibility does not break in one dramatic event; it seeps back in through ordinary work, a little with every change. This post is about where the drift comes from, which changes are most likely to reintroduce which problems, and what is worth re-checking after each one. It is written for merchants and [the people who maintain their stores](/blog/agency-playbook-client-stores-accessible). ## Where drift comes from **Theme updates.** A new theme version usually ships new sections and new icon buttons. Icon-only controls (cart, search, menu, close) arrive [without accessible names](/blog/alt-text-contrast-aria-prevent-lawsuits) more often than you would expect, and a redesigned header can quietly reshuffle heading levels so the page jumps from a first-level heading straight to a third. If you customised the previous version, the update can also overwrite fixes that lived in the theme files. **App installs.** Chat widgets, review carousels, pop-ups, cookie banners, size guides, countdown timers. Each one injects its own markup into your pages, and that markup was written for every store at once, not yours. The common failures are focus traps in dialogs, controls with no labels, and brand colours that fail contrast against your background. Because the app renders at runtime, the theme files look unchanged while the page is not. **Product imports and CSV uploads.** Images uploaded in bulk almost always arrive with an empty alt field, see [alt text](/blog/alt-text-contrast-aria-prevent-lawsuits). Product descriptions pasted from a supplier's catalogue often bring their own heading tags, bold-as-heading paragraphs and inline colour. One import can add dozens of images with no text alternative in an afternoon. **Staff edits in the theme editor.** A hero image swapped for the season. A text button turned into an icon because it looked cleaner. A new announcement bar with grey text on a pale band. None of these feel like code changes, and all of them are. **Campaign pages and landing pages.** Built fast, under deadline, often from a page builder or a block the theme did not ship with. These pages are also where paid traffic lands, which makes them the first page a lawsuit tester sees. **Navigation and collection changes.** New mega-menus bring new keyboard behaviour; new filters bring new unlabeled controls; a renamed collection can leave empty links behind in the footer. ## Why annual audits miss it An audit measures a moment. Even a thorough one, done by hand with a screen reader, only tells you about the pages it covered on the day it ran. The store that was tested is already different a week later, and the gap widens with every change. There is a second problem. The audit's findings are written for the store as it was, so when a theme update arrives three months later, the report stays in its folder and the fixes go unchecked. Many fail to survive: a fix made in a theme file is overwritten by the update unless it was made in a way that persists, and a fix made to content is undone the next time that content is replaced. The lawsuit data points the same way. Roughly [45% of the federal website suits filed in 2025](/blog/ada-lawsuits-ecommerce-2025) named a company that had been sued before, 1,427 of 3,195 by UsableNet's count.[^usablenet-2025-report] Being sued once and fixing things once is not enough; the stores that get sued again are the ones that fixed and stopped. ## What to re-check after each change You do not need to retest the whole store every time. Match the check to the change; the full list of what each check looks for is in [the checklist](/blog/shopify-accessibility-checklist). - **After a theme update:** the home page, one collection page, one product page, and the cart drawer. Tab through each with the keyboard: can you reach every control, can you see where focus is, can you open and close the menu and the cart without a mouse? Then check that the icon buttons in the header announce something sensible, and that the page still has one top-level heading. - **After an app install:** only the pages where the app renders. Open its dialog or widget with the keyboard, confirm you can close it and that focus returns to where you were. Read its text against your background colors. If it adds a floating button, make sure it has a name. - **After a product import:** the new products' media. Every meaningful image needs a text alternative, and the description should not carry stray headings from the source catalog. - **After a campaign goes live:** the landing page and the announcement bar, with the same keyboard pass and a contrast check on any text over an image. - **After navigation changes:** the menu and the filters, with the keyboard, on a phone-sized window as well as a desktop one. Five minutes per change, done every time, catches most of what an annual audit finds in a day. ## Only the delta is news The useful output of a routine like this is not a list of everything wrong with the store. It is the list of what is new since last time, with the change that caused it. A report that says the same two hundred things every month gets ignored; a report that says "three new images without alt text since the Tuesday import" gets acted on. That is how SiteRemora is built. It scans the rendered storefront the way a tester would, attributes each issue to the theme file or the product that produced it, fixes what it can in the Liquid and the catalog, and keeps the history. The next scan tells you what moved, which is the only part worth reading. ## Beyond this article A keyboard pass and an automated scan find the mechanical failures, which are the ones complaints cite most. They do not tell you whether your alt text is any good, whether your checkout flow makes sense to someone using a screen reader, or whether your videos need captions. Those still need a person. Checkout itself is Shopify's responsibility and is reasonably accessible; everything before it is yours. ## In short Drift is not a failure of intent. It is what happens when a store keeps changing and the checks do not. Tie a short re-check to each kind of change, [keep a record of what you found and fixed](/blog/good-faith-record-demand-letter), and read only the delta. If you want to know how far your store has drifted since anyone last looked, a scan of the five pages that get tested first takes a few minutes and shows you where it stands today.