> ## Documentation Index > Fetch the complete documentation index at: https://docs.spurtest.com/llms.txt > Use this file to discover all available pages before exploring further. > ## Agent Instructions > Spur is an AI-powered QA engineer that lets teams create and run automated end-to-end tests for web and mobile apps using natural language. > When answering questions about Spur, cite the relevant page from docs.spurtest.com. # Accessibility Issues > Search, filter, triage, and export accessibility issues, with annotated evidence and one-click ticket creation. ## Overview The Issues page lists every accessibility issue Spur has detected in your current scope, grouped into Critical, Severe, Moderate, and Minor severity bands. Each row shows the issue's root cause, the WCAG success criterion it maps to, which flows it appears in, and its blast radius. It also shows when the issue was last detected and who owns it. Spur stores all search, sort, and filter state in the URL, so you can share a filtered view with a teammate and they'll see exactly what you see. ## Searching, sorting, and filtering * Search — the search box matches issue titles, rules, and ownership. The table highlights matches. * Sort — sort by root cause, flows, blast radius, last detected, or ownership. * Filter — combine filters for: * Severity — Critical, Severe, Moderate, Minor. * Confidence — Asserted, Needs review, AI advisory, Recommended. * Affects — the personas an issue impacts: screen-reader, voice-control, keyboard-only, low-vision, motor-impaired and touchscreen, and deaf and hard-of-hearing users. * Flow — the user flow the issue was observed in. * Seen in — the page state where the issue was observed. * Classification — Open, Triaged, Accepted risk, Won't fix, Regressed, Needs re-review. * Ownership — 1st Party, Vendor config, 3rd Party, Unknown. ### Suppressed issues The table hides issues classified as Accepted risk or Won't fix by default. When suppressed issues exist, a counter button appears next to the filters. Click it to include them in the table, and click Hide suppressed to hide them again. ### Blast radius The Blast Radius column shows how widespread an issue is: how many instances, pages, and page templates it touches. A high instance count is usually one pattern repeated across a template, not many separate things to fix. ## Confidence tiers Every issue carries a confidence tier. Only asserted findings count toward the health score: * Asserted — a confirmed rule failure. Counts toward the score. * Needs review — a behavioral or low-confidence probe. Verify manually before acting. * AI advisory — a confidence-scored model judgment. Confirm before treating it as a failure. * Recommended — a best practice, not a WCAG success criterion. Not a conformance failure. Filter by the Confidence filter to isolate a tier, and check an issue's side-peek for its tier and evidence. The dashboard's score popover shows how many findings each tier contributes. ## Issue side-peek Click any issue to open its side-peek, which shows: * Annotated evidence — screenshots with the violating element highlighted, plus the violating markup. When an issue appears on multiple pages, step through the evidence page by page. * What a screen-reader user hears — on screen-reader findings, a transcript of the lines a screen reader announces around the element, with the element's own line highlighted. A virtual screen reader reads the page's markup, so text added by CSS is not in the transcript. * DOM state chips — the state the defect was observed in, phrased as how to reproduce it: on page load, in a dialog, in a menu, after an error, after navigating, or mid-change. * Template frames — the crawl captures one screenshot frame per page template. When evidence comes from a sibling page of the same template, Spur labels it as a template frame. * Observed dates — when each piece of evidence was captured, so you can tell fresh findings from carried-forward ones. * Adjacent navigation — move to the previous or next issue in your current filtered order without closing the side-peek. ## Acting on an issue From the side-peek or the row action bar you can: * Classify — set the issue to Triaged, Accepted risk, Won't fix, or back to Open. Classification applies to every instance of the issue in scope. * Fix with AI — copy an agent-ready remediation prompt that includes the fix and source anchors for your repository. * Create a ticket — create a Jira, Linear, Azure DevOps, ClickUp, or Asana ticket directly from the finding, or attach an existing ticket URL. Creating a ticket marks the issue as Triaged and links the ticket to it. See [Integrations](https://docs.spurtest.com/analysing-tests/integrations/overview.md) to connect a provider. * Spur prefills the ticket with the issue's severity, WCAG violation, occurrence count, affected users, problem description, suggested fix, affected pages, violating element, and links back to the issue in Spur. * Linear tickets also include annotated screenshot evidence, with the violating elements highlighted on each attached frame. * Once a ticket is linked, the ticket button shows the provider, ticket key, and live status, with a refresh action to pull the latest state. * Copy an issue link — share a deep link that opens directly to this issue. Choose Link to this report to pin the link to the frozen report you're viewing, or Link to live to point at current data. ## Exporting to CSV Click Export CSV to download the issues currently in view. The export respects your active search and filters, so you can hand off exactly the slice you're looking at. ## Flows view The Flows toggle at the top of the Issues page switches from the issue table to a gallery of your user flows, so you can review issues flow by flow. In the Live view, you can also rename a flow inline: open the Flow filter, hover a flow, and click the rename icon. Renames apply everywhere the flow label appears, and you can reset a flow back to its generated label. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.