Why accessibility scores differ between staging and production
Staging passes, production fails, and nobody changed the code. The gap is usually environmental: different content, different third-party tags, different data, or different feature flags. Trust the production result and fix the staging setup.
The content is never identical
Staging runs on sample content. Production runs on whatever the merchandising team published this morning: product images without alt text, promotional banners with text baked into images, and copy full of emojis that screen readers announce one by one. Accessibility is content-sensitive in a way performance is not. A scan of staging with three clean demo products tells you almost nothing about a catalog of four thousand products uploaded by ten different people. The most common cause of a staging-production gap is simply that production has more content, and more content means more chances to fail.
Third-party tags differ by environment
Staging usually runs a trimmed tag manager container. Production runs the full one: chat widgets, review apps, personalization scripts, and marketing pixels, each injecting its own markup into the page. Every one of those is an accessibility surface your staging scan never saw. The chat widget alone can introduce focus traps, unlabeled buttons, and dialogs that hijack the tab order. If your accessibility gate only scans staging, it is grading a page that does not exist in production. Audit the tag list per environment and scan production with the full tag set, because that is the page your customers actually get.
Feature flags and personalization change the DOM
Headless storefronts personalize aggressively: different hero content for returning visitors, location-based banners, A/B test variants. Staging typically renders the default variant with flags off. Production renders whatever the experiment says, and experiment variants are often built fast and shipped without an accessibility review. A promo banner variant with a countdown timer that announces every second is a production-only failure. Scan the variants, not just the default, or at least require that new variants pass the same checks as the page they replace.
Data shapes the rendered page
Staging databases are small and tidy. Production has edge cases: product names with special characters that break aria labels, reviews with embedded HTML, prices in currencies the layout was never tested with. Long product titles push buttons out of their containers, and missing data makes components render empty states that were never designed. These are not exotic bugs. They are what happens when a design system meets real catalogs. Seed staging with production-like data, including the ugly stuff, or the scan is theater.
Make staging scores trustworthy
Close the gap in three moves. First, scan production regularly, not just staging, because production is the only environment that matters for ADA risk. Second, bring staging closer to production: same tag container, same feature flags, realistic data. Third, treat any staging-production discrepancy as a finding about your process, not just about the page. The score that counts is the one on the page your customers use. Everything else is a rehearsal, and rehearsals only help when they resemble the performance.