How can a theme update break accessibility?

Themes ship markup. An update can remove a skip link, reorder headings, change focus styles, or alter ARIA roles across every page at once. Shopify theme updates also reset customizations that were applied to an older version. Without monitoring, a store learns about the breakage from a complaint or a demand letter.

Which apps most often cause regressions?

Anything that injects visible UI: reviews, upsells, subscriptions, size charts, chat, and page builders. An app update changes its injected markup store-wide overnight. Accessignal attributes failures to the responsible app so you can report the issue to the vendor with specifics and a capture of the failing state.

How fast are alerts delivered?

Critical templates like product and cart are scanned daily, so a regression there is flagged within 24 hours. Full-store scans run weekly. When a storefront change is detected, a targeted rescan runs immediately. Alerts go to email, and each one includes the failing state, the criterion, and the suspected cause window.

What counts as a regression versus a new issue?

A regression is a failure on a template or component that previously passed, which points at a change. A new issue is a first-time failure on a component that was never clean, usually newly added content or a new app. The diff log separates the two because they have different owners and different urgency.

Do alerts create noise?

They are deduplicated by root cause. One broken component shared by two thousand product pages is one alert with a page count, not two thousand alerts. Each alert carries severity, affected templates, and the fix step, so a developer can triage in minutes and close it with a verification rescan.

How much does Accessignal cost?

Every engagement starts with a free accessibility audit that sets your baseline: current issue count, severity ranking, and the change log going forward. Ongoing monitoring is quoted per storefront after the audit, based on store count and scan cadence. No long-term contract.

Monitoring Third Party Review Widgets for Accessibility Regressions

October 29, 2026

Review widgets inject star ratings, carousels, and photo lightboxes a store did not build and rarely retests. Here is how to monitor them before a widget update breaks a product page.

A product page can pass an audit in the morning and fail by lunch, because the review widget is served by someone else. Stars become clickable spans with no role, the sort menu opens without a label, the photo viewer traps focus. The store's own template did not change at all.

That is the procurement problem accessibility practitioners keep naming: you bought the widget, so you own its barriers. Title III responsibility does not transfer to the vendor whose script it is. Monitoring has to treat third party embeds as part of the page, with the same checks, and with a record you can hand the vendor when something breaks.

Name the widget workflows you will test

Do not test reviews in general. List the moves: read the average rating as text, sort by newest, filter by rating, open a review photo, write a review, page to the next set. Each move has a known failure. Star controls that work only by hover. Pagination that is a set of numbered divs. A write a review form whose rating input cannot be reached by keyboard at all.

Write the rating in text somewhere. An average of 4.6 shown only as filled stars gives a screen reader user either nothing or a confusing list of images. One plain sentence near the heading fixes it and helps every shopper scanning on a phone.

Put the requirement in the contract, then verify it

Procurement is the lever. Ask the vendor for a current accessibility conformance report, ask which WCAG version and level it claims, and ask how regressions get reported. A vendor who cannot answer has told you something useful before you sign, not after.

Then verify anyway. Add the product page to your regular manual pass, note the widget version, and keep screenshots of failures with dates. When you report to the vendor, a dated example with the criterion named gets a fix scheduled. A general complaint about accessibility gets a brochure.

Have a fallback when a widget breaks

If a widget update ships a focus trap on your highest traffic product page, waiting politely is not a plan. Know in advance what you can do: roll the embed back, hide the broken feature such as the photo viewer, or replace the carousel with a simple list of reviews until the vendor fixes it.

Decide that order now, while nothing is broken. The worst version of this conversation happens under time pressure, with a sale running, and it usually ends with the barrier left in place because nobody owned the call.

Frequently asked questions

Are stores responsible for a review widget's accessibility?

Yes. The widget is part of the page the store offers to the public. Contracts can require the vendor to fix defects and supply conformance information, but the shopper facing duty stays with the store.

What review widget failure is most common?

Interactive stars with no keyboard support and no text equivalent. Rating a product or reading a rating both depend on them, so one bad control breaks reading and writing reviews at once.

Should review carousels auto advance?

Avoid auto advancing content on a product page. If a carousel is used, it needs pause controls, keyboard operable navigation, and no focus loss when slides change. A static list is often the better choice.

What should a vendor conformance report cover?

The WCAG version and level tested, the date, the assistive technologies used, and known issues. A report that claims full compliance with no issues listed and no test method deserves follow up questions.