Short answer: An accessibility audit combines automated checks with manual keyboard, focus, semantics and interaction testing. A tool scan alone is not sufficient to assess the accessible operation of a digital system comprehensively.

Examine digital accessibility technically and reproducibly

Automated scanners detect only part of the possible barriers. Many relevant findings become visible only during actual interaction: focus management, keyboard order, semantic states, error messages, dialogs, dynamic content or interaction with assistive technologies.

The examination therefore documents system state, scope, reference criteria, tool versions and manual test steps. Technical findings and legal conformity questions remain separate.

Typical reasons for an assignment

before relaunch, procurement or publication where a website, web application or software product should be examined technically
when automated accessibility reports need professional classification and manual completion
when keyboard, focus, semantic or form problems should be documented reproducibly
when an existing accessibility assessment should be reviewed technically or as a second opinion

Typical technical questions

Which pages, components, states and user paths form an appropriate examination sample?
Which automatically detected findings are valid, false positives or only indicators for manual testing?
Do content and core functions remain perceivable and operable during contrast, zoom and reflow testing and relevant assistive-technology scenarios?
Are core functions keyboard accessible, is focus visible and logical, and are states exposed semantically?
Which findings apply only to the examined version, browser/device combination or sample?

Examination scope: The audit scope defines pages or screens, components, interactions, system version, test environment and agreed reference criteria. Unexamined states are explicitly not treated as passed.

From system state to a traceable accessibility finding

1 Scope & criteria Define system state, representative pages/flows and agreed accessibility criteria.

2 Automated examination Collect machine-testable patterns, document tool versions and verify findings professionally.

3 Manual examination Test keyboard, focus, semantics, dynamic states, error messages and critical interactions.

4 Finding & boundary Document problems, severity, reproduction steps and unexamined areas transparently.

A passed automated scan is not an overall accessibility approval. Likewise, one manual finding cannot automatically be generalised to all pages, devices or assistive technologies.

Combining automated and manual testing reduces blind spots; the required depth depends on scope and risk context.

Typical examination material

defined URL, screen or component sample and concrete system state
automated accessibility reports with documented tool and rule versions
manual keyboard, focus, semantics, form, contrast, zoom/reflow and dialog testing
DOM, accessibility-tree and state information plus agreed assistive-technology testing where required
screenshots or reproducible steps as supporting documentation — not as sole proof of cause

What you receive

Technical finding catalogue: reproducible barriers tied to the affected state and test step
Prioritisation: relevance for critical tasks and impact in the examined usage context
Reproduction guidance: environment, steps and required system states for verification
Statement boundaries: explicit identification of unexamined pages, states, devices or assistive technologies

Statement boundary: The technical audit is not legal advice and does not provide a blanket confirmation of statutory compliance. Which legal requirements apply to a particular provider or service must be assessed separately.

Related services

UX & Accessibility — Overview UX Audit Web & Mobile Assessment Technical SEO Assessment

Relevant knowledge

Examine accessibility technically

Combine automated and manual methods and understand their limitations.

Keyboard, focus and semantics

Examine interactive states and operability reproducibly.

Error states and feedback

Examine error handling and user control as part of accessible operation.

Define usage context

Define system state, task and user group as conditions of the statement.

Frequently asked questions

Is an automated accessibility scanner sufficient?

No. Automated tools detect only machine-testable patterns. Keyboard operation, focus management, semantic states and many interactions require manual examination.

Does an accessibility audit automatically prove legal compliance?

No. The audit documents technical findings within the agreed scope. Legal applicability and legal conformity are separate questions.

Must every page of a large system be tested?

Not necessarily. A risk-based or representative sample can be agreed. The resulting statement must then remain explicitly limited to that scope.

Prepare the accessibility audit scope

Useful starting information includes the target system, critical user paths, relevant pages or components, current release state and any existing accessibility reports. A traceable examination sample can then be defined.

Send enquiry