Crawl, accessibility and visual checks

How it works

1. Crawl. Give the crawl a start address. It follows links page by page and reports what it finds.
2. Accessibility. Add an accessibility check to a test. It runs axe-core on the page as it is at that point, against the standard you choose.
3. Visual. Add a visual check at the end of a test. The first run proposes a screenshot, and you approve it as the baseline.
4. Review. Later runs are compared with the approved screenshot, within the tolerance you set.

What is included

• Site crawl. A crawl follows links from your start address, page by page. It reports broken links, redirects, missing or duplicate titles, missing meta descriptions, images without alt text and slow pages.
• Polite by design. It obeys robots.txt unless you turn that off. It only follows links: it never fills in forms or clicks buttons, and it skips links that look like signing out or deleting. To crawl behind a login, run your shared sign-in steps first.
• Accessibility check (axe). It runs axe-core on the page as it is at that point in your test. Choose a standard from WCAG 2.0 A to WCAG 2.2 AA, and each problem comes with a how-to-fix view.
• Visual check. It compares the end of a test with a screenshot you approved. Set a tolerance, and paint out areas such as a clock or an ad.
• Separate baselines. Each browser, device and screen size keeps its own approved screenshot, so a phone is never compared with a desktop.
• Other page checks. Check for no browser errors, page load time, and the network requests a page made.

Plans. Every plan. Crawl length and page limits depend on your plan.

Good to know

Automated checks do not prove WCAG conformance. They find many common problems, not all of them, so keep checking with people too. The visual check compares the visible screen at the end of the test, not the whole scrolling page.

Questions

Keep reading

• Pricing and plan limits
• Record in Chrome
• Schedules and alerts
• All features