WCAG Audit

Free consultation Projects

A WCAG 2.2 AA audit + a remediation plan. Compliance with the European Accessibility Act (28.06.2025). A report with priorities, a session with the dev team, validation after implementation.

We have worked with leading companies and startups

Challenges

Three moments when a WCAG audit is essential

Not sure whether WCAG / EAA applies to you? Book a consultation - we will check the regulations for your product and point to the compliance timeline.

  • „Public sector - mandatory since 2019”

    The act of 4 April 2019 requires WCAG 2.1 AA for all public-sector websites and apps. An audit + an accessibility statement is the mandatory minimum. Often combined with a front-end modernisation.

  • „B2C e-commerce - EAA 28.06.2025”

    The European Accessibility Act from 28.06.2025 requires accessibility of consumer products (B2C e-commerce, e-books, consumer banking, transport). Stores that are not ready risk a fine of up to ten times the average wage, capped at 10% of annual turnover.

  • „Pre-IPO enterprise / due diligence”

    Due diligence before an IPO often checks WCAG compliance (an ESG factor, reputational risk, compliance). An audit with a remediation plan is a standard data-room item - we prepare you for an external audit.

Who it is for

Who orders an accessibility audit from us

  • Product teams in SaaS selling to institutions and large corporates

    The procurement questionnaire contains an item on WCAG compliance and a request for a document that proves it, and the answer "we are working on it" lowers the score of the offer along with the rest of the technical section. An audit gives the actual state described criterion by criterion, and a date the tender can refer back to.

  • Software houses delivering public-sector contracts

    The contract with the awarding institution carries an accessibility clause and a sign-off at which you have to show more than a screenshot of a scanner score. We come in as a third party before sign-off, so gaps between the declaration and the code surface before they start costing contractual penalties.

  • Front-end teams maintaining a design system

    A defect in a single component - a modal, a table, a field with suggestions - repeats on every screen that uses it, and a fix on one page changes nothing on the rest. In that setup we audit the component library and its documentation rather than selected views, so the fix lands at the source.

  • Institutions with an accessibility statement from several years ago

    The statement has been in the footer since the previous audit, while the site has meanwhile gained new forms, a search engine and e-services that nobody has checked from this angle. In a user complaint or an inspection it is today's state that counts, so we start from what has changed since the last version of the statement.

Four printed interface layouts on a desk: a dashboard, a phone screen, a form and a table, with one block circled in marker

Our difference

How our audit differs from a compliance scan

  • Scope written down as a list of screens and paths

    Before we start we agree a scope document with specific URLs, views and paths, and the report refers exactly to that list. So it is clear not only what was checked, but also what was deliberately left out of scope - and that is what every inspection and every external auditor asks about.

  • A fix in the code rather than an accessibility overlay

    Overlay widgets promise compliance through a single script, and in practice add a layer that can break screen-reader operation while leaving the barriers in the markup untouched. Our recommendations target components and templates, so the product behaves correctly also when an external script fails to load.

  • Criterion failures kept separate from barriers that pass

    Some problems formally pass a criterion and still stop the user - such as a tab order that leads through the entire footer before returning to the form. Those observations go into a separate section of the report so they do not mix with the obligations that follow directly from the regulation.

  • The fix is verified by the auditor who described the issue

    Validation after implementation is run by the same person who wrote the original observation, so the comparison follows the same reproduction path rather than a fresh reading of the same criterion. That also removes the round of clarifications about what was actually meant, which usually consumes the first week of fixes.

Process

2-3 weeks. Automation + manual + a report ready for dev

  1. Day 1–3

    Technical audit (automation)

    Automated scanning: axe DevTools, WAVE, Lighthouse, Pa11y. Catches ~30% of WCAG errors (the most common: contrast, alt text, ARIA labels, form labels). A full list per screen.

  2. Day 4–10

    Manual audit

    Tests with screen readers (NVDA on Windows, VoiceOver on macOS/iOS), keyboard navigation, focus management, color contrast (Color Contrast Analyser), responsive accessibility. Catches the remaining 70% of errors.

  3. Day 11–15

    Report + remediation plan

    Writing up the report with every issue found + priorities + a reproduction path + a fix recommendation. Plus a remediation plan with t-shirt sizes and an implementation time estimate.

  4. After implementation

    Validation after implementation

    After your dev team implements the fixes - a validation re-audit (typically 1-2 weeks later). An updated report and a ready compliance document - a statement or a terms-of-service note, depending on the sector.

Deliverables

Three documents. Ready to publish and implement

  • WCAG 2.2 audit report

    A full 60-150 page report with every WCAG 2.2 AA criterion, compliance status, error reproduction path, screenshots and a fix recommendation. An executive summary for leadership on the first 2 pages.

  • Remediation plan with estimates

    A concrete action plan with P0/P1/P2 priorities (critical, important, cosmetic), t-shirt size estimates (XS/S/M/L/XL per task), an implementation schedule. Ready for the dev team to estimate.

  • Statement or a note in your terms

    For the public sector - the text of the accessibility statement compliant with the act of 4 April 2019, ready to publish. For companies covered by the European Accessibility Act - a description of how the service meets accessibility requirements in your terms of service, because the statement only applies to public bodies. Plus a compliance report template for internal compliance / an external audit.

Toolkit

What we use

Standard accessibility tools - every audit combines automation (~30% of errors) with a manual test by an auditor (~70% of errors).

A workbench from above: two printed interface layouts, a magnifier enlarging one block, a steel ruler and a greyscale step wedge running from white to black, with one line underlined in orange marker
  • WCAG 2.2 at level AA
  • EAA (European Accessibility Act)
  • axe DevTools + WAVE + Lighthouse
  • NVDA, VoiceOver (screen readers)
  • Color Contrast Analyser
  • Pa11y, Microsoft Accessibility Insights

Next step

Let us talk about your project

Tell us what you have to do. We will come back with scope and a quote.

Free consultation Projects

Selected work

Projects from the product types we audit

A cross-section of corporate sites, online stores and web applications - the products we run accessibility audits on most often. The reports themselves are the client's document and we do not publish them; we show excerpts during a consultation.

Projects

Outcomes

What comes out of the audit and by when

  • 10–15 days

    Working days from agreeing the scope to a report with a remediation plan your dev team estimates without follow-up questions

  • 3

    Documents at the end - the audit report, the remediation plan with estimates and a compliance document matched to your sector

  • 2

    Passes over the product - an audit before the fixes and a validation after they ship, run by the same person

  • 2019

    Since the Polish act of 4 April 2019 on digital accessibility, WCAG 2.1 AA is an obligation for public bodies rather than a good practice

The timings and the list of documents come from the scope and schedule described on this page; the legal obligation comes from the act of 4 April 2019 and the European Accessibility Act, both public sources. We do not quote issue counts from specific audits, because the report is the client's document - we show excerpts during a consultation.

Client voices

What our clients say

  • „Working with the Wzór team was a genuinely great experience! They always answered our questions quickly and were flexible about our comments. They have no shortage of creative ideas and are at the same time thoroughly reliable and on time. The end result fully met our expectations; we recommend them to anyone looking for professionals who care.”
    Maja Wieloch-Silecka Operations Director, Bosfor Group
  • „Our clients expect us to act fast and effectively across a very wide scope - from building a brand, through a website with a store, to running an effective sales campaign. Not an easy task, but doable when you have a tight-knit team and partners who take on challenges on the fly. For us, quality, accountability and commitment are key, and working with UX Agency Wzór gives us that 100%.”
    Piotr Alberski Chief Operating Officer, Agencja XO Media
  • „Our cooperation with UX Agency Wzór started with our own website. We really liked the way they work, so we decided to subcontract projects for our clients to them on a White Label basis. We loved their workflow, the way they hand projects over to our team, their documentation and their work on the design system. Now we can take on bigger risks.”
    Mateusz Swół Chief Operating Officer, Sellace

Time and scope

How long the audit takes and what drives the quote

10–15 working days

Ten days is enough for a narrow scope - one template family and a few paths. A full WCAG 2.2 AA audit together with a report and a remediation plan fits within fifteen working days; a native app relies more heavily on manual testing and moves the deadline towards three to four weeks. Validation after implementation is a separate pass, scheduled around your dev team's roadmap.

  • The number of unique templates and components, not the number of pages

  • The platforms in scope - web, a native app, PDF documents published on the site

  • Transactional paths and forms - registration, payment, file upload

  • Access to test accounts and environments behind a login

  • Whether post-implementation validation and an updated compliance document are in scope

FAQ

Questions that come up most often

What is the EAA and who does it apply to?

The European Accessibility Act - EU directive 2019/882, implemented in Poland by the act of 26 April 2024. From 28.06.2025 it requires accessibility of digital products aimed at consumers: B2C e-commerce, e-books, consumer banking, transport, mobile telephony. Micro-enterprises (<10 people, <EUR 2M turnover) are exempt.

Does the audit include implementing fixes?

No - the audit is a report + a remediation plan. Your dev team implements it (we provide the document with t-shirt sizes) or we do it as a separate service (Accessibility remediation plan + Implementation support). After implementation we run validation.

Is the audit an official WCAG certificate?

No - Wzór does not issue an official compliance certificate (accredited bodies do; in Poland the Widzialni Foundation, Utilitia, among others). Our report is the basis of the accessibility statement (the 2019 act) and can serve as a due-diligence document before an external audit.

How much does a WCAG audit cost?

We quote each audit individually - the price depends on the type of product (website, web or mobile app, B2C e-commerce with EAA compliance) and the number of screens (typically 20-200) and flows. Validation after implementation is available as a follow-up. After a short brief you get a concrete quote within 48 hours.

What about native mobile apps?

Yes - we audit native iOS apps (VoiceOver) and Android (TalkBack). Standards: WCAG 2.2 AA + platform-specific (Apple Human Interface Guidelines, Material Design accessibility). A native app audit is more manual than a web one - typically 3-4 weeks.

Do you combine a WCAG audit with other services?

Yes - we typically combine it with: a UX audit (it checks usability, we add accessibility), a redesign (we design to WCAG straight away), a design system (components with built-in accessibility), implementation support (accessibility QA per sprint). All as a package with a discount.

Related services

Related services

Book a free consultation with an expert to discuss your project and get answers to your questions.

- Patryk Korycki, CEO

Schedule a meeting
Book a free consultation