Websites and stores
The European Accessibility Act: from scope to a practical plan
Start an EAA assessment with the service and the business providing it. Then commission the right audit and changes. Simply having a website does not give every company the same obligations.
Establish whether the rules apply
Poland’s legislation implementing the EAA began applying to covered products and services on 28 June 2025. The Ministry of Digital Affairs explains electronic commerce in the context of concluding consumer contracts. Services offered or provided by microenterprises are listed as exempt.
Do not decide from website size or order volume alone. Establish business status, the service, intended customers and the contract process. Assess uncertain cases against current law with a qualified adviser. This guide helps organise the work; it does not determine your individual legal position.
Prepare the facts before buying a compliance solution
Collect a service description, terms, contract process and information about whether the customer is a consumer. Identify the legal provider, operating markets and channels: website, app, marketplace or booking platform. Microenterprise status should be assessed using the applicable criteria and business documents, not an informal statement that the company is small. A website supplier may not hold these facts. Whoever establishes the legal scope needs evidence rather than an assumption that low order volume automatically creates an exemption.
For example, a website may mainly describe business services while a separate form lets consumers order a service. A B2B label on the homepage does not describe the whole process. Another store may conclude part of the transaction through an external checkout. Record that dependency rather than automatically excluding everything outside the main domain from the audit. The first deliverable should be an agreed scope and a list of questions needing qualified assessment. Use them to commission testing of the relevant services, channels and customer interactions.
Distinguish the directive, Polish law and WCAG
The EAA is a European directive. Poland implements requirements through the Act of 26 April 2024. WCAG supplies technical criteria for web content. A single scanner score does not capture every business obligation. Record the legal basis separately from the interface standard used in the audit. If a supplier refers to EN 301 549, ask which version, which parts apply and how they relate to the requirements for the particular service. A standard’s name in a report footer does not settle those questions.
The Ministry maintains information about standards and technical specifications for e-commerce. Check its currency and the underlying documents on the assessment date. An announced revision is not evidence that it has already been published or acquired a particular legal status. This matters in a project running over several months: document the date and basis used. You may choose a more demanding technical design target, but do not describe it as a universal legal obligation without checking. Keeping these decisions separate clarifies responsibility, acceptance and later updates to the assessment.
Break checkout into states that can be tested
Walk from finding a product to order confirmation. Include option selection, quantity changes, unavailable stock, discounts, delivery details and payment choice. Add withdrawal, return from a gateway and unsuccessful steps. This list defines interface tests; the legal assessment of the service is a separate task. Testing only the ideal purchase misses situations requiring another decision or showing a message. These states are frequently absent from static mockups, even though real customers encounter them and need a way to continue.
For example, a customer opens the basket with enlarged text, but the panel covers the continue button. Someone else must choose a collection point on a map without a usable list or search alternative. Another person never hears the rejected-payment message. Record each case with a starting state and expected finish. Include keyboard use, a screen reader, larger text and a small display. Use test identities and test payments. Do not make real purchases or copy customer records merely to demonstrate the process or capture a screenshot for an accessibility report.
Assign work across the company and its suppliers
Identify who can change each element. Copy and photographs may have a different owner from checkout, and an external provider may maintain the payment widget. Create a simple matrix: component, problem, supplier, possible correction, contact and verification date. Do not assume an agency can edit code it cannot access. It should recognise the dependency and identify a realistic route, such as configuration, a supplier issue or a different integration. A clear owner prevents a critical barrier circulating indefinitely between support teams.
Ask for evidence relevant to the actual version in use, supported assistive technologies and the reporting process. A general sales statement without scope may not describe your implementation. For example, a module may work in its demonstration while the store’s custom styling removes visible focus. Test the integration, not only the standalone product. Another case is a failure introduced by an external script update. Agree who detects it and what temporary assistance is realistic. Telephone support may help, but do not assume without assessment that it replaces all requirements of the digital process.
Describe the actual service in customer information
The legislation and Ministry guidance distinguish public information about the service and its accessibility from notifying the competent authority about nonconformity and corrective action. Do not automatically copy a declaration intended for a public-sector organisation. Prepare information appropriate to the legal basis and actual operation of your service, with the person responsible for assessing obligations. Publishing a document does not remove an interface barrier. Editorial and technical work need to describe the same real version of the website and its customer process.
From the customer’s perspective, explain what the information covers, how to use the service and where to report difficulty. The person receiving reports needs a route to the responsible supplier. Record the assessment date, reviewed elements and owner for updates. For example, replacing a payment provider may make the previous description inaccurate. Reviewing the information should be part of accepting that change. Do not claim full conformity based on a future repair plan. The current condition and intended improvements are different records, and both need clear ownership and an appropriate review process.
Prioritise impact and dependencies, not ticket counts
Identify barriers preventing completion, then recurring component and content defects. Each task needs an owner, supplier dependency and completion evidence. Improve accessibility is not a verifiable assignment. Enable keyboard delivery selection and demonstrate order completion in a test scenario is much clearer. Do not equate closed-ticket volume with progress in essential processes. Ten minor changes may do nothing for a person blocked by one broken step. Use impact to explain why a difficult issue may deserve attention before several easy cosmetic adjustments.
An example workflow is reproducing the barrier, correcting the shared component, updating content, checking the external integration and repeating the complete process. This is an organisational proposal, not a statutory schedule or a promised delivery time. Where a component appears widely, inspect representative uses, different languages and longer content. A correction should not remove an explanation, change a price’s meaning or break validation. Tie acceptance to the customer task and agreed audit scope. Then the supplier knows what evidence to deliver and the business can assess a concrete result rather than a reassuring statement.
Assess exceptions and sanctions using the legislation
The Polish Act provides supervision and administrative financial penalties for specified infringements. A screenshot alone cannot establish the risk to a particular business. The relevant obligation, facts and procedural context matter. Instead of basing decisions only on a maximum figure in a headline, prepare the documents and establish scope. A notice already received or a required response date calls for an individual review of current law and correspondence. A technical audit helps identify barriers but is not a substitute for that legal assessment.
Likewise, saying that a repair is expensive does not by itself establish disproportionate burden. Ministry guidance describes assessment, documentation and information duties when invoking exceptions. Do not turn a missing budget into an undocumented exemption. Separate decisions requiring legal assessment from improvements already possible, such as repairing labels or keyboard order. Record the reasoning, evidence and review date. This preserves continuity when the supplier, business offer or commerce platform changes. For each unresolved question, name the person who will collect the missing information and agree the next step.
Prepare acceptance evidence and ongoing ownership
At handover, collect the assessment scope, report, change list, repeated-test results and known limitations. Acceptance should cover the actual implementation, rather than only a prototype without payment and content. Agree who reviews customer reports, when tests are repeated and who approves new components. Give editors practical instructions for images, link names, accessible documents and understandable messages. Otherwise, a later product import or promotional banner can undo a correction that was successfully demonstrated at the end of the original project.
To start work on a store, prepare its address, sales model, key module suppliers and known problems. Send these through DigiDraft’s contact page to discuss testing scope and possible technical work. Base legal assessment on the business situation and current official sources listed below. Identifying basic barriers does not require waiting for a major redesign, but it does require an organised scope and checks after changes. At handover, return to customer tasks: can people complete an order and recover from a problem? The documentation should describe what actually works in the store.
Questions and answers
What should a business prepare for an EAA scope assessment?
Gather a description of the service, how contracts are concluded, who the customers are and documents establishing the business status. Include every channel used, including external sales platforms. This gives the assessor a basis for determining relevant obligations rather than judging by the website alone.
Does a WCAG audit settle every EAA obligation?
A WCAG audit assesses technical accessibility criteria for web content. The business obligations require a separate assessment of the legal basis and the service scope. Specify what the audit report covers and which questions require separate review.
Which parts of an online shop need accessibility testing?
Follow the whole journey from choosing a product through delivery and payment to order confirmation. Include errors, unavailable items, returns from payment gateways and third-party components. Testing only the homepage misses places where a customer may be unable to continue.