Re‑auditing dynamic content: cy.wait vs cy.intercept

The goal is to capture all accessibility violations that appear after a page has loaded dynamic content, such as components rendered by API calls or client‑side routing.

cypress‑axe injects axe‑core and exposes cy.axeCheck(), which audits the DOM snapshot at the moment it is invoked. By default, it does not re‑audit automatically after asynchronous updates, and the plugin documentation offers no single pattern for complex UIs that change after the initial cy.visit() or cy.get().

Test authors typically choose between two documented approaches: inserting a cy.wait() after a user interaction to allow the UI to settle, or using cy.intercept() to wait for a specific network request that triggers the DOM change. Each method has trade‑offs in terms of flakiness, test maintenance, and coverage of dynamic updates.

What are the most reliable ways to ensure cy.axeCheck() runs after the page’s dynamic content has fully rendered? Does cy.intercept() guarantee that all asynchronous requests affecting the DOM are complete before the audit? Which approach offers better long‑term maintainability for tests that involve multiple sequential updates?