Dynamically generated content must be retested after each update

What it is

A template tested last year does not make this week's article conformant. Content-management systems, A/B experiments, user-generated content, and route changes in a single-page app all rewrite the evaluated object after the claim. Retesting dynamic content means conformance is a snapshot of a state. When the snapshot expires, the claim is using an old photograph to underwrite a new page.

Why it happens

What is evaluated is a particular DOM, a particular media file — not the mockup in the repository. The template can pass, and an editor can still upload an image with no text alternative, skip heading levels, or rename a button “click here.” An experiment platform can send ten percent of users into a variant that was never tested. The second layer is treating “the template was tested” and “the instance was tested” as the same event: engineering owns the template, editorial owns the instance, and the claim is written on the site. Client rendering at route level can also swap an entire tree under the same URL, so an old test keyed to that URL does not cover the new tree.

Studying it

Run the same scope and method before and after a content publish or experiment launch, and record failures that appear. Separate template failures from instance failures. On single-page apps, capture the accessibility tree after each route change, not only on the first paint.

Independent variables: kind of update (copy / media / template / experiment variant / route). Dependent variables: whether the claim still holds; whether new failures belong to template or instance; failures present in only one variant.

Continuous monitoring can catch contrast and missing alternative text; it cannot catch every semantic fault such as a ruined heading outline on this article. Monitoring feeds retesting; it does not replace it.

Where it stops holding

A frozen static archive or a legal text whose content cannot change can keep a snapshot until the next edit. A change that only touches the copyright year in the footer does not require a fresh WCAG-EM of the whole site; there must still be a rule for what counts as touching structure or media. User-generated content cannot have a full manual audit on every post; the claim must state sampling frequency and the moderation gate, and must not pretend every item was checked. Hot updates of third-party scripts belong to the next layer of lost control; this layer only requires that variants you yourself ship, you retest.

Applying it

• Bind “accessibility re-check” on the release list to template changes, experiment launches, and bulk media import — not only to a calendar item called annual audit.
• Constrain CMS fields: an image cannot publish without a text alternative; heading styles must not impersonate heading nodes.
• Treat every experiment variant as a new page. Untested variants stay out of the claim's scope.
• How to check: sample last week's newly published items or a live experiment variant with the same method as the claim. If failures appear that the claim does not list, update the date and rewrite the conclusion. If the claim's date is earlier than this publish, the claim has already expired.

Related

• Same group: J1.10.1 A page-level claim and a site-level claim can reach different conclusions · J1.10.2 Passing almost every check is not overall conformance · J1.10.4 Third-party embeds usually sit outside the claimant's control
• Nearby: J1.12 Accessibility Statements and Conformance Documentation · J5.12 Live Regions and Dynamic Announcements
• Search terms: retesting dynamic content · conformance snapshot · WCAG-EM