The European Accessibility Act 2025: what the law actually requires of you

We work with accessibility and WCAG in web projects every day. What follows draws on that experience and on guidance from Digg and the relevant supervisory authorities. It explains who the law covers, what the technical requirements mean and the order in which the work is usually done.

The EU’s accessibility directive, the European Accessibility Act (EAA), Directive 2019/882, requires certain digital products and services to be usable by people with disabilities. Sweden has implemented it through the Act on the Accessibility of Certain Products and Services, often called the Accessibility Act (LPTT), which began to apply on 28 June 2025.

Unlike the DOS Act, which applies to the public sector, the Accessibility Act targets private organisations offering products and services to consumers. That means it affects far more businesses than many people expect.

An estimated 87 million people in the EU live with some form of disability. As banking, shopping, travel and dealings with public authorities moved online, this group risked being excluded. Meanwhile, member states began introducing their own accessibility rules, making it harder for businesses to sell across borders.

The directive addresses both problems by bringing the requirements together in a common standard across the EU. For businesses, this means the same technical standard applies whichever EU country you sell to, making things simpler. The directive was adopted in 2019, member states were required to incorporate it into national law by 2022, and the rules began to apply on 28 June 2025, following a six-year phase-in period.

The most common confusion we encounter concerns Sweden’s two accessibility laws. They exist side by side and overlap in places, but apply to different organisations. The DOS Act, the Act on Accessibility to Digital Public Services, has applied since 2019 to government agencies, municipalities, regions and certain publicly funded organisations, with Digg as the supervisory authority. The Accessibility Act, which began to apply in 2025, covers private organisations offering products and services to consumers.

In some cases, a business may fall under both laws: a publicly funded organisation that also runs an online shop, for example. In practice, the technical benchmark is the same: WCAG 2.1 Level AA through the European standard EN 301 549. But supervision, exemptions and responsibilities differ. If you are a private company selling to consumers, the Accessibility Act is the law you need to focus on.

The law applies to products and services offered to consumers, regardless of who provides them. If you sell a product or service digitally to consumers in Sweden or elsewhere in the EU, you should assume the law affects you. This also applies to businesses outside the EU, because what matters is the market you sell to. In practice, it covers areas including:

• e-commerce, from product pages and shopping baskets through to checkout and payment
• banking and other financial services for consumers, including logging in, making transfers and managing requests
• electronic communications, such as telecoms services
• digital media services, such as streaming, e-books and subscription news services
• digital booking and ticketing processes for passenger transport, as well as self-service terminals

So an accessible homepage alone is not enough. The entire process, right through to completing a purchase or request, must work with a keyboard and screen reader. The most costly barriers are often at checkout, where a single inaccessible step can prevent a sale.

Businesses that provide services, employ fewer than ten people and have an annual turnover or balance sheet total of no more than two million euros are generally exempt. This does not mean all small businesses are exempt, and the exemption is narrower for those selling products. Once a business grows beyond the threshold, the law applies. Rebuilding a digital platform later costs considerably more than getting it right from the start. If you are unsure whether you are covered, a legal assessment is money well spent, as the boundaries are not always clear.

The law refers to the European standard EN 301 549, which in turn is based on WCAG 2.1 Level AA (Web Content Accessibility Guidelines). In practice, WCAG 2.1 AA is the benchmark for an accessible website or app. The standard rests on four principles, and below we explain what they typically mean in a web project. For an explanation of WCAG’s structure, levels and versions, see What is WCAG?.

Content must be available through more than one sense. Images need alt text (text alternatives) that a screen reader can read aloud, while purely decorative images should be marked so they are skipped. Body text must have a contrast ratio of at least 4.5:1 against the background, and large text at least 3:1. Light grey text on a white background is one of the most common issues we see. Video needs captions, audio needs transcripts, and information must not be conveyed through colour alone: a red field is not enough to indicate an error.

Anything you can do with a mouse must also be possible with a keyboard, as many people with motor impairments do not use a mouse. It must be clear where the focus is on the page, nothing should flash in a way that could trigger an epileptic seizure, and users must be able to extend countdowns and automatic logout time limits.

Menus and recurring elements should behave consistently across the website. If a form rejects an entry, it should explain what is wrong and how to correct it. Language should be clear, which is particularly important for users with cognitive disabilities. This is where accessibility and plain language meet.

The code must work with assistive technologies, now and in the future. This requires semantic HTML, where headings are headings and buttons are buttons, because screen readers rely on the code’s structure to interpret content. Custom-built components also need correct labelling, for example using WAI-ARIA, so they can be interpreted properly.

Level AA is the level required by law. Level A is not enough, and AAA is rarely a realistic requirement for an entire website. WCAG 2.2 has been available since 2023 and adds further criteria. Although the law currently uses 2.1 as its basis, 2.2 is a sensible target if you want to avoid having to redo the work.

More and more websites are being built with a headless architecture, where content is managed in a CMS and displayed through a separate layer built with JavaScript frameworks. Here, the developer determines whether the code is semantic and accessible, so custom-built interactive components need to be deliberately equipped with labelling, focus management and keyboard support. A modern technical foundation does not guarantee accessibility, but in the right hands it makes it easier to get things right from the start.

When we audit and rebuild websites, the same problems come up time and again. Most are straightforward to fix once you know they are there:

• insufficient contrast in text, buttons and form fields, often because the visual identity has never been tested against WCAG
• images with no alt text, or alt text that simply repeats the filename
• form fields without associated labels, leaving screen readers unable to explain what to enter
• custom-built menus, dialogues and carousels that cannot be reached using a keyboard
• focus moving to the wrong place when a dialogue opens, leaving the user disoriented
• video without captions
• heading levels used for their appearance, making the structure incomprehensible to screen readers

Automated testing tools find contrast errors and missing alt text, but whether a custom-built component works with a keyboard must be tested manually. A reliable audit therefore combines both.

A common misconception is that everything had to be perfect by 28 June 2025. From that date, new and updated products and services offered to consumers must meet the requirements. Certain existing services have transitional arrangements until 28 June 2030, and self-service terminals brought into use before 2025 may, in some cases, remain in use until the end of their economic life.

Every new feature, page or update must meet the requirements, however, so compliance is an ongoing commitment. Nor are the transitional arrangements a reason to wait: the longer an inaccessible platform remains in use, the more expensive it becomes to fix and the longer it excludes clients.

An audit is the starting point for any accessibility work, and a thorough audit combines three levels. Automated testing quickly scans the entire website and identifies systematic issues such as contrast problems, missing alt text and incorrect code structure. A manual expert review, testing with a keyboard alone, with a screen reader and against each WCAG criterion in turn, reveals the serious barriers that prevent people from using the site. User testing with people who use assistive technologies every day uncovers things that neither tools nor experts can fully anticipate.

The result should be a prioritised action list: what is wrong, how seriously it affects users and what is needed to fix it. That list makes it possible to plan and budget for the work.

Supervision of the Accessibility Act is shared between several authorities, depending on the service. The Swedish Post and Telecom Authority coordinates the work and supervises electronic communications services, e-commerce and banking services. The Swedish Agency for the Media oversees services providing access to audiovisual media services, such as streaming, while the Swedish Agency for Accessible Media oversees e-books. The Swedish Consumer Agency and the Swedish Transport Agency share responsibility for certain passenger transport services, including websites and apps for rail, bus, air and boat travel.

Digg supervises compliance with the DOS Act, and the two laws are often confused. The authorities can request information, order corrective action and attach financial penalties to those orders. A case often begins when a user reports a problem.

The financial penalty is rarely the biggest risk. Around one in six people lives with a disability, so an inaccessible website excludes a significant share of the market every day it remains online. A complaint can also attract more attention than the penalty itself, and fixing issues later often means rebuilding features that have already launched.

Responsibility lies with whoever offers the product or service to the consumer, even when an external supplier has built the website. You cannot transfer that responsibility to the agency through a contract. A competent supplier should, however, build accessibly from the start and be able to demonstrate how it works with WCAG. This is one of the most important questions to ask when commissioning a website.

For a business looking to comply with the law, this is a sensible order of work:

1. Carry out an accessibility audit against WCAG 2.1 AA, using both automated and manual testing, to produce a prioritised action list.
2. Start by fixing the barriers that exclude users: keyboard navigation, contrast, forms and screen reader support. An error that makes it impossible to complete a purchase matters more than a decorative detail.
3. Build accessibility into design and development so that new pages and features meet the same standard without relying on a separate final check.
4. Train your content editors. Heading structure, alt text and clear language are shaped by everyday publishing decisions, and a single poorly published article can make a well-built page inaccessible.
5. Explain how the service meets the requirements, in your general terms and conditions or another easily accessible place. Give users a way to report issues, and keep the information up to date.

The Accessibility Act requires service providers to explain how their service meets accessibility requirements, in their general terms and conditions or another easily accessible place. The information should describe how the service works and which testing or quality assurance methods have been used. The Swedish Post and Telecom Authority provides guidance on how to present it.

The public accessibility statement described by Digg is formally a requirement under the DOS Act, but it provides a useful model for organising the information. According to Digg’s guidance, it includes:

• the name of the organisation and the service
• whether the service is fully compliant, partially compliant or non-compliant with the requirements
• which content is not yet accessible, and why
• any accessible alternatives to that content
• the assessment date, the latest update and the evaluation method used
• a way for users to report issues

An honest account that acknowledges known issues builds more trust than a page claiming everything is flawless.

Accessibility supports several goals you already want to achieve. Excluding one in six potential clients rarely makes business sense, and accessible design also reaches the growing group of older users. Semantic HTML, a clear structure, alt text and readable copy make it easier for both search engines and AI services to understand a page. Clear forms, understandable error messages and reliable navigation help every visitor complete what they came to do.

That is why accessibility works best as part of building a good digital service, and worst as a check at the end.

In our projects, we consider WCAG from the design stage: colours and contrast are tested before they become part of a visual identity, components are designed for keyboard use from the start, and the structure is planned to make sense to users and screen readers alike. During development, we use semantic code and test continuously, both automatically and manually.

Because so much of a website’s accessibility depends on what happens after launch, we also help content editors work accessibly, with effective alt text, headings in the right order and clear language. This is the same work that makes a website fast and easy to find in search, so all three tend to improve together.

“It only applies to public authorities.” No. That is precisely what distinguishes the Accessibility Act from the DOS Act: it applies to private companies selling to consumers.

“An automated testing tool is enough.” Tools are a good first step, but they only cover some of the criteria. Keyboard use, focus management and understandability require manual testing.

“We’ve added an accessibility button, so we’re done.” So-called overlays that promise automatic compliance rarely solve the underlying problems and can create new ones, because the requirements apply to the website’s actual code and content.

“We only need to fix it once.” Every new page, feature and published article can introduce new issues, so accessibility needs ongoing attention.

We help you identify and resolve accessibility issues against WCAG 2.1 AA. Find out more about our work with accessibility and WCAG.

• Digg — Digital accessibility (Agency for Digital Government)
• European Accessibility Act, Directive 2019/882 (EUR-Lex)
• WCAG 2.1 (W3C)
• Act (2023:254) on the Accessibility of Certain Products and Services (Swedish Parliament)
• Swedish Post and Telecom Authority — Act on the Accessibility of Certain Products and Services (supervisory authority)
• Swedish Post and Telecom Authority — information on service accessibility (guidance)

This article is for information only and does not constitute legal advice. Consult a legal professional for an assessment of your specific circumstances. Last updated 3 November 2026.