Digital accessibility in 2026: how to audit a business website or app

01

Facts: when did the Polish Accessibility Act start to apply?

The Act of 26 April 2024 implementing Directive (EU) 2019/882 entered into force on 28 June 2025. It covers the products and consumer services listed in the Act. Its digital scope includes telecommunications, access to audiovisual media services, selected digital elements of passenger transport, consumer banking and the distribution of e-books.

For covered services, websites and mobile apps must, among other things, be perceivable, operable, understandable and compatible. A service provider assesses conformity, makes information about the service and its accessibility available, and addresses identified non-conformity. Detailed requirements depend on the type of service.

This article was verified on 15 October 2026. It provides operational information, not individual legal advice. The duties should be confirmed for the particular service, operator role, digital channel and any sectoral or contractual requirements.

02

Facts: is every business website or app covered?

No. The Act lists defined categories of products and services. Merely having an online presence does not bring an informational website within the Act. What matters is the service that the website or app enables and the people to whom it is provided. Separate duties may arise from public-sector accessibility law, procurement, funding terms, sector rules or a contract.

Services offered or provided by microenterprises are excluded. This service exemption should not be treated as a blanket exclusion from product duties. The Act also contains exceptions and procedures for assessing a fundamental alteration or disproportionate burden. They call for a documented assessment, not a general statement.

Service contracts concluded before 28 June 2025 may continue under transitional rules until they expire, but no later than 28 June 2030. Separate transitions apply to products used to deliver a service and to older online content. A new implementation therefore needs a different assessment from an unchanged archive.

03

Facts: what does WCAG 2.2 provide — and what does it not provide?

WCAG 2.2 is a W3C Recommendation containing testable success criteria for accessible web content. It adds nine criteria to WCAG 2.1, including focus visibility, a non-dragging alternative, minimum target size, consistent help, redundant entry and accessible authentication.

WCAG organises technical requirements around content that is perceivable, operable, understandable and robust. It is a useful basis for specifications, design, testing and acceptance. It does not replace a scope analysis or service-specific requirements. PFRON also states that its guidance presents possible approaches but is not an authoritative interpretation of law.

No single scanner can assess the whole experience. Automated tools quickly find some code and contrast defects, but they cannot reliably judge the meaning of alternative text, logical order, understandable instructions, useful error messages or whether a person can complete the process without a mouse.

04

WEBee recommendation: begin with scope and critical journeys

Describe the service, its users and the most important outcomes first. Instead of testing random pages, select end-to-end journeys: sign-in, finding information, reserving or buying a ticket, submitting a request, downloading a document, making a payment, changing details, recovering access and contacting support.

For each journey, identify screens, documents, third-party components, the business owner and the completion event. A supplier dependency does not remove the barrier for the user. PFRON’s published recommendations state that, in an outsourcing model, responsibility for a covered service remains with the provider delivering it to consumers.

• determine whether the service and operator fall within the applicable rules;
• map all channels: web, app, documents, email and support;
• select critical user journeys rather than random screens;
• include sign-in, errors, time limits and empty states;
• record third-party components and contractual responsibilities;
• define the reference level, acceptance criteria and test evidence.

05

WEBee recommendation: combine four types of testing

An audit should combine layers because each reveals different barriers. Automated scanning helps identify missing names, invalid roles and some contrast defects. Manual review covers heading structure, focus order, link purpose, zoom and behaviour when the screen changes size or orientation.

The critical journeys should then be completed with the keyboard alone and with a screen reader. Forms, validation, accessible authentication, PDF files, media and dynamic messages need dedicated checks. Research with assistive-technology users can reveal barriers that a checklist misses.

• automated scanning of representative screens and templates;
• manual WCAG 2.2 review with evidence for each finding;
• keyboard, screen-reader, zoom and reflow testing;
• end-to-end user testing where the impact is significant;
• review of documents, media, messages and technical support;
• retesting after remediation and shared-component changes.

06

WEBee recommendation: prioritise by impact, not issue count

The report should not be a scanner export. Each finding needs reproduction steps, affected users, the reference criterion, evidence, a recommendation and an owner. Priority should reflect whether the issue blocks a journey, how widely the component is used and the associated risk — not only a tool’s “critical” label.

Remove barriers that prevent the primary task first: an inaccessible sign-in, a keyboard trap, unlabelled fields, invisible focus, an inaccessible document or an error without a clear recovery instruction. Fixing the shared component library usually creates more value than applying separate patches to many screens.

07

WEBee recommendation: make accessibility part of delivery

A one-off audit becomes stale quickly. Accessibility requirements belong in the definition of done, component library, acceptance criteria, design review and regression tests. Each significant change should consider content, step order, documents and support communication as well as code.

Maintain a decision and exception register, test results, remediation plan and reassessment dates. User-facing information should describe the accessibility of the actual service honestly and provide a channel for reporting a barrier. It does not replace remediation, but it helps resolve issues and collect evidence for improvement.

WEBee can connect a website or app audit with a technical backlog, component remediation, acceptance testing and a release plan. Accessibility then becomes a measurable product-quality practice rather than a document produced after launch.