{ "doc": { "id": "accessibility/guides/production-monitoring", "title": "Monitor accessibility issues in production", "description": "Monitor accessibility issues in production by running scheduled Cypress tests against live environments, capturing dynamic content changes, and generating automated reports for a comprehensive accessibility overview.", "section": "accessibility", "source_path": "/llm/markdown/accessibility/guides/production-monitoring.md", "version": "f60251bf707b0077a9535579c9f90d615440cc35", "updated_at": "2026-10-16T10:56:58.670Z", "headings": [ { "id": "accessibility/guides/production-monitoring#production-monitoring-and-website-crawling", "text": "Production monitoring and website crawling", "level": 1 }, { "id": "accessibility/guides/production-monitoring#using-cypress-for-production-monitoring", "text": "Using Cypress for production monitoring", "level": 2 }, { "id": "accessibility/guides/production-monitoring#scan-every-page-from-a-sitemap", "text": "Scan every page from a sitemap", "level": 2 }, { "id": "accessibility/guides/production-monitoring#example-visit-every-sitemap-url-in-a-single-test", "text": "Example: Visit every sitemap URL in a single test", "level": 3 }, { "id": "accessibility/guides/production-monitoring#example-visit-each-url-in-separate-tests", "text": "Example: Visit each URL in separate tests", "level": 3 } ] }, "chunks": [ { "id": "accessibility/guides/production-monitoring#using-cypress-for-production-monitoring", "doc_id": "accessibility/guides/production-monitoring", "heading": "Using Cypress for production monitoring", "heading_level": 2, "content_markdown": "## Using Cypress for production monitoring\n\nCypress Accessibility enables you to test dynamic content seamlessly. By visiting a production URL within your Cypress tests and performing minimal UI interactions, you can capture the page's accessibility state in reports. This allows teams to detect accessibility issues introduced outside the regular development lifecycle.\n", "section": "accessibility", "anchors": [ "using-cypress-for-production-monitoring" ], "path": "/llm/json/chunked/accessibility/guides/production-monitoring.json", "token_estimate": 68 }, { "id": "accessibility/guides/production-monitoring#scan-every-page-from-a-sitemap", "doc_id": "accessibility/guides/production-monitoring", "heading": "Scan every page from a sitemap", "heading_level": 2, "content_markdown": "## Scan every page from a sitemap\n\nIf your project lacks existing Cypress tests, a common approach is to drive Cypress Accessibility from a sitemap or an array of target URLs. Visiting each URL performs a light interaction that Cypress Accessibility records, giving you a first accessibility report for the pages your suite doesn't reach yet.\n\n### Example: Visit every sitemap URL in a single test\n\nThe example below fetches your `sitemap.xml` at runtime and visits every URL it finds in a single test. This is the quickest way to get started, with no list to maintain:\n\n```\ndescribe('Accessibility Scan', () => {\n it('Checks accessibility against the URLs in sitemap.xml', () => {\n cy.request('https:///sitemap.xml').then((response) => {\n const parser = new DOMParser()\n const xml = parser.parseFromString(response.body, 'application/xml')\n const urls = [...xml.querySelectorAll('loc')].map(\n (loc) => loc.textContent\n )\n\n urls.forEach((url) => {\n // Cypress Accessibility captures the accessibility state of each page\n cy.visit(url)\n\n // Optional: only needed when content appears as you scroll (lazy-loaded\n // images, infinite lists). Test Replay already captures the full page.\n cy.contains('').scrollIntoView()\n })\n })\n })\n})\n```\n\nThe `scrollIntoView` call is optional. Test Replay captures the full page for accessibility analysis on load, so you only need it when content appears through progressive scrolling, such as lazy-loaded images or infinite lists. It can also be worth keeping to exercise scrolling itself, since a page that cannot be scrolled to reach its content is an accessibility problem in its own right.\n\n### Example: Visit each URL in separate tests\n\nThe single-test scan above is quick to set up, but putting each URL in a separate test is often the better choice:\n\n* **Tracking**: each page becomes a distinct test in Cypress Cloud, so a page that fails to load shows up as its own failing test with its own [Test Replay](/llm/markdown/cloud/features/test-replay.md), instead of collapsing the whole scan into one pass/fail.\n* **Performance**: a single test that visits every page keeps accumulating DOM snapshots and command history as it runs, which slows it down and makes it harder to debug. Separate tests each start clean, so they stay fast.\n* **Isolation**: [test isolation](/llm/markdown/app/core-concepts/writing-and-organizing-tests.md#Test-Isolation) resets the browser state between pages, so one page's cookies or storage can't leak into the next.\n\nBecause Cypress defines tests when the spec loads (before any command runs), the list of URLs has to exist before the run starts rather than come from a sitemap fetched at runtime. You can hard-code it in the spec, import it from a committed file, or generate it in your Cypress config and pass it to the spec. This documentation's own test suite takes the last approach: it builds the list of pages in `cypress.config` and loops over them to create one test per page.\n\n```\nconst urls = ['/', '/about-us', '/pricing', '/contact', '/request-trial']\n\ndescribe('Accessibility Scan', () => {\n urls.forEach((url) => {\n it(`Visits ${url}`, () => {\n // Cypress Accessibility captures the accessibility state of this page\n cy.visit(url)\n })\n })\n})\n```\n\nThe result is a first-load accessibility report for every URL in your site. Any Cypress tests you write for specific workflows automatically expand the accessibility area to include the states and variations those workflows reach.\n", "section": "accessibility", "anchors": [ "scan-every-page-from-a-sitemap" ], "path": "/llm/json/chunked/accessibility/guides/production-monitoring.json", "token_estimate": 699 }, { "id": "accessibility/guides/production-monitoring#example-visit-every-sitemap-url-in-a-single-test", "doc_id": "accessibility/guides/production-monitoring", "heading": "Example: Visit every sitemap URL in a single test", "heading_level": 3, "content_markdown": "### Example: Visit every sitemap URL in a single test\n\nThe example below fetches your `sitemap.xml` at runtime and visits every URL it finds in a single test. This is the quickest way to get started, with no list to maintain:\n\n```\ndescribe('Accessibility Scan', () => {\n it('Checks accessibility against the URLs in sitemap.xml', () => {\n cy.request('https:///sitemap.xml').then((response) => {\n const parser = new DOMParser()\n const xml = parser.parseFromString(response.body, 'application/xml')\n const urls = [...xml.querySelectorAll('loc')].map(\n (loc) => loc.textContent\n )\n\n urls.forEach((url) => {\n // Cypress Accessibility captures the accessibility state of each page\n cy.visit(url)\n\n // Optional: only needed when content appears as you scroll (lazy-loaded\n // images, infinite lists). Test Replay already captures the full page.\n cy.contains('').scrollIntoView()\n })\n })\n })\n})\n```\n\nThe `scrollIntoView` call is optional. Test Replay captures the full page for accessibility analysis on load, so you only need it when content appears through progressive scrolling, such as lazy-loaded images or infinite lists. It can also be worth keeping to exercise scrolling itself, since a page that cannot be scrolled to reach its content is an accessibility problem in its own right.\n", "section": "accessibility", "anchors": [ "example-visit-every-sitemap-url-in-a-single-test" ], "path": "/llm/json/chunked/accessibility/guides/production-monitoring.json", "token_estimate": 244 }, { "id": "accessibility/guides/production-monitoring#example-visit-each-url-in-separate-tests", "doc_id": "accessibility/guides/production-monitoring", "heading": "Example: Visit each URL in separate tests", "heading_level": 3, "content_markdown": "### Example: Visit each URL in separate tests\n\nThe single-test scan above is quick to set up, but putting each URL in a separate test is often the better choice:\n\n* **Tracking**: each page becomes a distinct test in Cypress Cloud, so a page that fails to load shows up as its own failing test with its own [Test Replay](/llm/markdown/cloud/features/test-replay.md), instead of collapsing the whole scan into one pass/fail.\n* **Performance**: a single test that visits every page keeps accumulating DOM snapshots and command history as it runs, which slows it down and makes it harder to debug. Separate tests each start clean, so they stay fast.\n* **Isolation**: [test isolation](/llm/markdown/app/core-concepts/writing-and-organizing-tests.md#Test-Isolation) resets the browser state between pages, so one page's cookies or storage can't leak into the next.\n\nBecause Cypress defines tests when the spec loads (before any command runs), the list of URLs has to exist before the run starts rather than come from a sitemap fetched at runtime. You can hard-code it in the spec, import it from a committed file, or generate it in your Cypress config and pass it to the spec. This documentation's own test suite takes the last approach: it builds the list of pages in `cypress.config` and loops over them to create one test per page.\n\n```\nconst urls = ['/', '/about-us', '/pricing', '/contact', '/request-trial']\n\ndescribe('Accessibility Scan', () => {\n urls.forEach((url) => {\n it(`Visits ${url}`, () => {\n // Cypress Accessibility captures the accessibility state of this page\n cy.visit(url)\n })\n })\n})\n```\n\nThe result is a first-load accessibility report for every URL in your site. Any Cypress tests you write for specific workflows automatically expand the accessibility area to include the states and variations those workflows reach.\n", "section": "accessibility", "anchors": [ "example-visit-each-url-in-separate-tests" ], "path": "/llm/json/chunked/accessibility/guides/production-monitoring.json", "token_estimate": 380 } ] }