Accessibility audit

An audit answers one question: does this website or app meet a named accessibility standard, and where does it not? The standard is almost always WCAG, at a version and level fixed in advance, for example WCAG 2.1 AA for a Polish public body or WCAG 2.2 AA for a new product. Without that, the result cannot be compared with anything.

The W3C describes a method for websites in WCAG-EM, the Website Accessibility Conformance Evaluation Methodology. It has five steps: define the scope of the evaluation, explore the website, select a representative sample of pages, audit the sample, and report the findings. The sample matters because few audits can check every screen. It includes the pages people use most, every type of page or template, every complete process such as registration or checkout, and pages with forms, media and documents. WCAG-EM also adds a few randomly selected pages to check that the structured sample missed nothing. The same logic applies to mobile apps, with screens and flows instead of pages.

Each page or screen in the sample is checked against every success criterion at the agreed level. Automated tools run first: they catch missing text alternatives, empty labels, low contrast and some markup errors quickly. The larger part is manual. A tester moves through the interface with a keyboard only, with a screen reader on each platform in scope, with text enlarged to 200% and with the screen in both orientations. Many criteria, such as meaningful focus order, correct names for controls and errors that explain how to fix the problem, can only be judged by a person.

An audit at the end of a project is the most expensive way to learn about accessibility. Requirements for an app you are ordering:

• Fix the standard, version and level in the contract, and the scope: web app, mobile apps, generated documents, the admin panel if staff use it.
• Plan at least two audits: one on the first complete flows, while components can still change cheaply, and one before acceptance.
• Ask for findings mapped to success criteria and to specific screens. A percentage from a scanner is not an audit result.
• Make sure manual testing covers each platform in scope. Web and mobile apps fail in different ways.
• Treat audit findings as backlog items with an owner and a retest date. A finding is closed after a retest, not after a commit.
• Keep the final report. A Polish public body publishes an accessibility statement for its website and mobile app, and the audit is the evidence behind it.

For Centrum Komunikacji, an app for deaf, hard-of-hearing, blind and deafblind users, the requirements list from July 2025 included a WCAG audit, and the target standard was WCAG 2.1 AA. Screen reader rounds with our QA ran through development from November 2025. In March and April 2026 we worked through two lists of WCAG remarks in the front end, and our team prepared the WCAG report as part of the stage 2 handover, completed on April 27, 2026. The audit task in the requirements was closed in June 2026, and later findings from production users go through the same cycle of fix and retest.

For PSONI, the specification of Generator ETR requires WCAG 2.2 level AAA for an app that turns documents into easy-to-read Polish. The requirements list ties each item to a success criterion, the same structure an audit report uses. Findings from the screen reader rounds are tracked per platform and retested on iOS and Android separately.