A useful audit connects a reproducible observation to an affected task and a practical verification step.
Agree the website, sample and task
Begin with permission to assess the website and a clear question. A publisher may need article text, dates and authors to be understood. A retailer may need product information and conditions to stay connected. Those tasks guide the choice of pages and templates.
Record the domain, included URLs or sampling method, exclusions and access conditions. Count assessed resources separately from report pages. Note whether you checked the initial response, a rendered browser view or both. A sampled audit must not be described as exhaustive coverage.
Collect evidence before assigning a score
For each resource, inspect retrieval, status and useful content. Compare the initial HTML with the rendered page, then review the document outline, landmarks, links, tables and metadata that carry meaning. Check whether structured data agrees with visible information.
Keep the conditions attached to the evidence: the time, URL, method and relevant location or excerpt. A network error, a deliberate access restriction and missing HTML content require different explanations. If something could not be measured, say so instead of treating the missing result as a pass.
- Which response did the tested client receive?
- What essential information was present or absent?
- Which pages or templates are supported by the evidence?
- Which checks were not performed?
Separate findings, severity and dimension scores
A finding is an evidenced issue. Severity expresses its likely importance within the recorded scope. A dimension score summarises a defined group of checks. These describe different things: a high overall score can coexist with an important individual finding.
Read coverage, thresholds and limitations alongside the numbers. Do not compare scores from different scopes as if they measured the same sample. A low score does not identify a fix by itself; the observations and recommendations do that work.
Make the recommendation testable
Describe what should change and how the team will know it worked. “Improve agent readiness” is too vague. “Include the service description under its heading in the initial HTML, then confirm it is available without JavaScript” gives a developer something concrete to implement and verify.
Prioritise by the affected task and the reach of the template. Correcting a delivery problem across a shared template may matter more than adding another discovery file. An audit should identify that dependency instead of presenting every recommendation as equally urgent.
From finding to task
- Observation
- A comparison table’s data cells cannot be reliably associated with their product headings.
- Next step
- Use appropriate header cells and associations, preserve the visual layout, and verify that each value can be interpreted with its row and column context.
Review, deliver and follow up
Tityra requests an agreed website scope and an authority declaration before work is released. Automated results are reviewed before delivery. Expert Review adds deeper investigation within an agreed scope. Our AX audits check against the AgentReady essentials where they apply to that scope.
Use the report to plan changes, discuss evidence and track implementation. A customer marking a finding resolved records their progress; it is not an independent retest by Tityra. A follow-up assessment should identify its new date, sample and methods. No score is a promise of AI citations or a certification of full accessibility conformance.
Sources and further reading
See what your website delivers.
Choose an agreed scope and get findings your team can act on.
