Triage remediation tickets

Tickets are built from the latest completed audit, not entered by hand

Remediation tickets are a projection of audit findings into tracker-ready work items — there is no blank-ticket form anywhere, because the source of truth is the audit.

The endpoints (API-only today)#

GET /v1/domains/:id/remediation-tickets lists them (Domain not found. for bad domains), and POST /v1/domains/:id/remediation-tickets/generate (201) builds them from the latest completed audit. Generation refuses to invent work: No completed audit exists for this domain yet — run an audit first. Existing tickets are deduplicated by findingId, so re-generating updates rather than duplicates.

Which findings qualify#

All accessibility findings (source: "accessibility") — keeping wcagReference (the audit's mapping, e.g. image-alt → severity critical, WCAG 1.1.1; color-contrast → critical, 1.4.3) and affectedSelectors.
Selected technical SEO findings (source: "technical") — only canonical, robots, sitemap, redirects, status, hreflang, pagination, crawl-links, duplicate-content, with selectors taken from the finding's evidence.

What a ticket carries#

A severity, the finding identity, verification steps written for a human — for example Apply the fix in the page's own markup/CMS — WebOptiva does not change accessibility semantics automatically., Confirm the fix satisfies WCAG success criterion 1.1.1., and Manually verify with keyboard-only navigation and/or a screen reader… — plus its status (open until exported). Note the boundary: there is no customer screen for tickets yet (see Work by severity).

Back to Triage remediation tickets