Documenting automated and manual accessibility findings

Documenting accessibility issues from automated tools vs manual checks gives teams a clearer view of barriers that one report can hide. Scanners provide repeatable site-wide checks, while evaluators using keyboards and screen readers assess whether an experience is genuinely usable. Strong records connect both forms of evidence to a user need and a standard such as WCAG 2.2 Level AA.

Automation is fast and consistent, but its findings need interpretation. It can flag a missing form label, weak colour contrast or duplicate identifier without human context. Manual review can show whether a busy checkout, confusing error message or inaccessible map prevents someone completing a task. Neither method is complete, so documentation should preserve what was tested as well as what was found.

For teams in Australia, this matters across government, banking, retail, transport and aged-care services. Users may encounter an interface in Sydney, Melbourne, Darwin or a regional town using a phone, desktop or assistive technology. A shared repository helps designers, developers, content specialists and independent evaluators avoid duplicate work and preserve a traceable history from discovery to remediation.

Why accessibility findings need context

An accessibility issue is not simply a tool warning. It is an obstacle that blocks or complicates a task. A scanner may report a technical failure in HTML; the record should explain the effect on a user, the page or component involved, the assistive technology or input method used, and the relevant WCAG success criterion. Severity should reflect impact, reach and the likelihood that users will encounter the barrier.

Useful evidence includes a unique issue identifier, screenshots or a recording, reproduction steps, expected and observed results, tester details, and the tool version and test date. Keep recommendations separate from findings: the problem creates a factual baseline, while a proposed fix belongs in the remediation record. This prevents a preferred solution from hiding alternatives. A centralised UX repository lets reviewers and delivery teams retain the same evidence instead of circulating screenshots across ticketing systems.

What automated scanners can reveal

Automated scanners inspect markup, style sheets and interaction patterns. They are effective for repeated checks such as image alternatives, accessible names, heading order, form instructions, colour contrast, link text and keyboard-focus visibility. Running the same rule across hundreds of templates makes these checks economical for release pipelines and reveals regressions introduced by component updates.

Scanner output still contains false positives and blind spots. An alt attribute may exist yet fail to communicate a chart’s purpose, and an automated keyboard test may miss focus moving behind a modal. Conformance evaluations should combine scan results with reviews of information architecture, content clarity, media alternatives and task completion. Each warning needs deduplication because one component error can appear on every page that uses it. Mapping observations to persona profiles helps teams judge likely reach without reducing people to a disability label.

What manual evaluation adds

Manual evaluation tests interactions that code inspection cannot reliably judge. Evaluators navigate without a mouse, switch among screen readers such as VoiceOver, NVDA or JAWS, zoom to 200 or 400 per cent, reflow content at narrow widths and apply increased text spacing. They check announcements, focus order, error recovery, time limits, captions, transcripts and whether instructions make sense under cognitive load.

Manual testing also exposes content and design barriers: a video described only by its title, instructions written in an unfamiliar register, a form asking for an Australian phone number without explaining its format, or a date displayed as 04/07 without explaining that it means day and month. Findings should record the browser, operating system, assistive technology and settings used. Because tester coverage is a limitation, sessions with people with disability and expert review produce broader evidence.

Accessibility work in the Australian context

Australian organisations operate across state borders and diverse service environments. Federal services in Canberra, Service NSW digital transactions, Victorian transport information and retail or banking platforms in Melbourne must support different content, devices and levels of digital confidence. Procurement teams commonly specify WCAG 2.1 or 2.2 Level AA, while internal standards may add requirements for captions, plain language and accessible documents. Records should name the standard and contractual threshold rather than imply that one standard covers every legal obligation.

Australian conditions also shape who may be excluded. Older people, people with disability, travellers with temporary impairments and workers using shared equipment can all encounter barriers when interfaces, support and equipment are not designed inclusively. Users outside major cities may also face unreliable connectivity. Mining employers can involve frontline staff and remote communities through structured research; mining co-design resources can support that process. Resulting requirements should be validated with local users rather than inferred from headquarters.

A repeatable documentation workflow

A repeatable workflow makes findings comparable and gives remediation teams enough information to act. Begin with the journey and expected outcome, run automated checks for broad coverage, then conduct manual tasks using keyboard and assistive technology. Store evidence in one place so QA can reproduce results and designers can understand user consequences. UCDmanager is a free collaborative option for organising personas, use cases, evaluations, requirements and status.

Records should follow a consistent pattern: source, user impact, technical detail, reproduction, recommendation, owner, status and verification. Prioritise barriers that prevent essential transactions, then address issues that affect many users or carry a high risk of legal and reputational harm. Accessibility work and usability testing may uncover the same defect, so link the records instead of merging them when their evidence serves a different purpose.

• Assign each confirmed issue a unique identifier and cite the WCAG criterion or organisational requirement involved.
• Capture the page, component, task, device, browser, assistive technology and reproduction steps.
• Save screenshots, recordings and scan output with tester notes, tool version and test date.
• Record user impact and severity separately from the proposed remediation, and track the owner and verification status.
• Retest the original task after a fix and link verification evidence to the original finding.

Used consistently, this approach turns scattered scanner alerts and evaluator notes into auditable evidence. It gives product teams a practical basis for prioritising fixes and makes the value of automated coverage and human judgement visible to stakeholders.