The Accessibility­Directive 2025: What the Law Actually Requires of You

We work daily with accessibility and WCAG in practical web projects. The review is based on that work and on current guidance from Digg and the responsible supervisory authorities — and is aimed at those who want to understand the requirements for real, not just tick off a checklist. It is deliberately thorough: accessibility is an area where most summaries are too superficial to act on.

The Accessibility Directive — at the EU level European Accessibility Act (EAA), Directive 2019/882 — is the legislation that requires digital products and services to be accessible to people with disabilities. In Sweden, the directive has been implemented through the Act on the Accessibility of Certain Products and Services, often called the Accessibility Act (LPTT). It began to apply on June 28, 2025.

The key to understand: unlike the older DOS Act, which applies to the public sector, the Accessibility Act targets private actors offering products and services to consumers. That is why it affects significantly more companies than many think.

It is easy to dismiss new legislation as yet another administrative burden. But the background to the Accessibility Directive is worth understanding, as it explains why the requirements are as they are — and why they will not disappear.

Within the EU, an estimated 87 million people live with some form of disability. As more and more services — banking, commerce, travel, government contacts — have moved to digital interfaces, that group has effectively risked being excluded from parts of society and the economy. At the same time, EU member states had begun to introduce their own, disparate accessibility regulations, creating a thicket for companies operating across borders.

The Accessibility Directive solves both problems at once: it harmonizes the requirements to a common standard across the union, and it makes accessibility a right rather than an ambition. For a company, this means that the same technical level applies regardless of which EU country you sell to — which in the long run is a simplification, not just a requirement.

The directive was adopted back in 2019. Member states were to have incorporated it into national law by 2022, and the national rules began to apply on June 28, 2025. In other words: this is not a sudden rule, but the endpoint of a six-year phase-in.

The single most common confusion we encounter is the conflation of the two Swedish accessibility laws. They exist in parallel, they partially overlap, but they target different actors. Knowing which one applies to you is the first step.

DOS Act — the Act on Accessibility to Digital Public Services — applies to public actors: authorities, municipalities, regions, and certain private actors with public funding. It has been in effect since 2019 and has Digg as the supervisory authority.

Accessibility Act (LPTT) — the new law from 2025 — applies to private actors offering products and services to consumers. This is the law this guide primarily concerns.

The two are therefore not replacements for each other. A company can in some cases be covered by both — for example, a publicly funded actor that also runs e-commerce. The technical benchmark (WCAG 2.1 AA via EN 301 549) is practically the same, but supervision, exceptions, and who is responsible differ. If you are a private, consumer-oriented company, it is the Accessibility Act you need to be aware of.

The law applies to products and services offered to consumers — regardless of which actor is behind them. In practice, this includes:

• E-commerce — online stores and digital purchase flows
• Banking services and other financial services for consumers
• Electronic communication — telecom and similar services
• Digital media services — streaming, e-books, subscription news services
• Transport services with digital interfaces

If you sell a product or service digitally to consumers in Sweden or the rest of the EU, the starting point is that the law affects you. This also applies to companies outside the EU targeting EU consumers — geographic domicile does not determine, the market you sell to does.

Because the law is broad, it can be difficult to see exactly how it affects your particular business. Some typical cases:

• E-commerce. The entire purchase flow — product listing, product page, cart, checkout, and payment — must be usable with keyboard and screen reader. It is often at checkout that the most costly deficiencies are found, as an inaccessible step there directly prevents a purchase.
• Banking and finance. Digital services for login, transfers, and transactions are covered. Here, the requirements are particularly sensitive as the services are often difficult to replace with analog alternatives.
• Media services. Streaming, e-books, and subscription news services are affected, including requirements for subtitles and navigable reading interfaces.
• Booking and travel. Digital booking and ticket flows for transport are covered, as well as self-service solutions.

Common to all is that it is not enough for the homepage to be attractive — it is the entire functional journey, up to the completed transaction, that must work.

The exception for micro-enterprises: companies providing services and having fewer than 10 employees and an annual turnover or balance sheet total of no more than 2 million euros are generally exempt. However, the exception is narrower for those selling products — and being close to the threshold is not something to rely on long-term. A company that grows beyond the threshold enters the scope of the law, and rebuilding an entire digital platform afterward is significantly more expensive than doing it right from the start.

A common misconception is that the exception applies to all small businesses. It does not: it specifically applies to micro-enterprises delivering services, and there are industry-specific nuances. If you are unsure whether you are covered, it is worth a legal assessment — the boundary is not always clear.

The law points to the European standard EN 301 549, which in turn is based on WCAG 2.1 level AA (Web Content Accessibility Guidelines). Thus, WCAG 2.1 AA is practically the benchmark for an accessible website or app.

WCAG rests on four fundamental principles — often summarized as POUR. Below we go through each with concrete examples of what they mean in practice, as it is at this level that the work actually takes place.

Content must be perceivable regardless of sense. This means, among other things:

• Text alternatives for images — meaningful alt texts so that a screen reader can convey what an image shows. Decorative images, on the other hand, are marked to be skipped.
• Sufficient color contrast — at least 4.5:1 between body text and background, 3:1 for large text. Light gray text on a white background is one of the most common deficiencies we see.
• Captioning and alternatives for media — subtitles for video, transcripts for audio.
• Information must not be conveyed solely by color — a red field is not enough to signal an error; text or symbol is also needed.

Everything must be usable, regardless of how the user controls their device:

• Full keyboard navigation — everything that can be done with a mouse must be doable with a keyboard. Many with motor impairments never use a mouse.
• Visible focus — it must be clear where on the page the keyboard focus is.
• No flashing elements that can trigger epileptic seizures.
• Sufficient time — features that count down or log out automatically must be extendable.

Content and functions must be clear and predictable:

• Consistent navigation — menus and recurring elements should behave the same throughout the website.
• Comprehensible error messages — a form rejecting an input should explain what is wrong and how to fix it, not just mark the field red.
• Clear language — particularly important for users with cognitive impairments. Here, accessibility and plain language meet.

The code must work with assistive technologies, now and in the future:

• Correct, semantic HTML — headings that are headings, buttons that are buttons. Screen readers build their understanding on the structure of the code.
• Correct labeling of interface components (e.g., via WAI-ARIA where needed) so that custom components are correctly interpreted by assistive technologies.

Level AA is the level the law assumes — level A is not enough, and level AAA is rarely a realistic requirement for an entire website. It is also worth noting that WCAG 2.2 now exists and adds additional criteria; although the law today is based on 2.1, 2.2 is a reasonable level of ambition for those who want to be secure in the long term.

More and more websites today are built with a so-called headless architecture, where content is managed in a modern CMS and presented via a separate frontend layer. This provides performance and flexibility — but it also places its own demands on accessibility. When the interface is built with JavaScript frameworks, it is the developer, not the platform, who determines whether the final code becomes semantic and accessible. Interactive components built from scratch must be consciously provided with correct labeling, focus management, and keyboard support — it does not come for free. In other words: a modern technical foundation is no guarantee for accessibility, but in the right hands, it provides excellent conditions to build right from the start.

After reviewing and rebuilding a large number of websites, we see the same problems recurring. Most are not difficult to fix once you know them — but they are easy to miss without conscious testing:

• Insufficient contrast in text, buttons, and form fields — often a result of a graphic profile that has never been tested against WCAG.
• Images without alt text, or alt texts that only repeat the file name.
• Forms without associated labels, making them unusable with screen readers.
• Custom components (dropdowns, modals, carousels) that cannot be accessed with a keyboard.
• Poor focus management — the user loses track when a dialog box opens.
• Video without subtitles.
• Heading structure used for appearance instead of hierarchy, which confuses screen readers.

The important thing to understand is that automated testing tools only capture some of these. They find contrast and missing alt texts, but whether a custom component can actually be used with a keyboard — that requires manual testing. A credible review therefore always combines both.

A common misconception is that everything must be perfect from June 28, 2025. The picture is more nuanced, and it is worth understanding to plan the work reasonably:

• June 28, 2025 — new and updated products and services offered to consumers from this date must meet the requirements.
• Until June 28, 2030 — for certain existing services, there are transition rules that provide a phase-in period. Self-service terminals put into use before 2025 can in some cases be used even longer, up to the end of their economic lifespan.
• Ongoing — every new feature, page, or update after the deadline must meet the requirements. Compliance is therefore not a one-time deadline but an ongoing commitment.

The practical advice: do not let the transition rules become an excuse to postpone. The longer an inaccessible platform lives, the more expensive it becomes to fix — and the longer it excludes customers.

Since the review is the starting point for all accessibility work, it is worth knowing what it actually consists of. A serious review combines three levels:

1. Automated testing that quickly goes through the entire website and flags systematic errors — contrast problems, missing alt texts, incorrect code structure. It provides breadth, but not depth.
2. Manual expert review where a person tests the page with only a keyboard, with a screen reader, and against WCAG's criteria one by one. This is where the serious, user-hindering deficiencies are found.
3. User testing with people who actually use assistive technologies daily — the strongest way to discover problems that neither tools nor experts fully anticipate.

The result should not be an abstract score but a prioritized action list: what is wrong, how serious it is for the user, and what is required to fix it. It is this list that makes the work plannable and budgetable.

An important difference from the public sector: supervision of the Accessibility Act is distributed among several authorities depending on the industry — among others, the Post and Telecom Authority, the Consumer Agency, the Media Authority, the Agency for Accessible Media, and the Swedish Transport Agency. (Digg is responsible for the DOS Act, which applies to the public sector — a common confusion.)

The supervisory authorities can request information, order measures, and ultimately combine orders with fines. The process often begins with a user reporting a deficiency, after which the authority can request correction within a certain time. But the financial risk is rarely the first problem. Equally important is:

• Excluded customers — about one in six people live with some form of disability. Inaccessibility excludes a significant part of the market, every day it persists.
• Brand risk — lack of accessibility is increasingly perceived as a sign of negligence, and a public complaint can have a greater impact than the actual threat of fines.
• Retroactive cost — building in accessibility from the start is significantly cheaper than fixing it afterward, where corrections often involve rebuilding already launched functionality.

It is also worth knowing who bears the responsibility. It is the actor offering the product or service to the consumer who bears the responsibility — even when the website itself is built by an external supplier. You cannot contract away the responsibility to your agency. However, a competent supplier should build accessibly from the start and be able to show how they work with WCAG — it is one of the most important questions to ask when procuring web services.

For a company that wants to achieve compliance without fumbling, this is a reasonable work order:

1. Conduct an accessibility review. Map the current state against WCAG 2.1 AA — both automated and through manual testing, as automatic tools only capture some of the deficiencies. The result is a prioritized list, not just a score.
2. Prioritize by impact. Fix what excludes users first: keyboard navigation, contrasts, forms, screen reader support. An error that makes it impossible to complete a purchase weighs more heavily than a decorative detail.
3. Build accessibility into the process. Accessibility is not a one-time project but an ongoing quality level — new pages and features should meet the same standard. The best results are achieved by making accessibility part of the design and development flow, not a final check.
4. Educate the content team. A large part of accessibility is determined in the daily content work: heading structure, alt texts, clear language. A perfectly built site can be made inaccessible by a single incorrectly published article.
5. Publish an accessibility statement. Describe the website's accessibility and how users can report deficiencies — and keep it updated.

The accessibility statement is the public document where you report how well your digital service meets the requirements. It serves both as a commitment outwardly and as an internal receipt of where you stand. According to Digg's guidance, it should include, among other things:

• The name of the organization and the digital service.
• A statement of whether the service is fully, partially, or not compliant with the requirements.
• A clear list of content that is not yet accessible, and the reasons for it.
• Any available alternatives to the inaccessible content.
• Date of assessment and last update, as well as the evaluation method used.
• A messaging function so users can report deficiencies.

An honest statement that admits known deficiencies is better than a silent page claiming to be flawless — supervision and users value transparency.

It would be a mistake to see accessibility solely as a duty to fulfill. In practice, it aligns with several things you want to achieve anyway:

• A larger market. Excluding one in six potential customers is rarely a good business. Accessible design reaches more — including the growing group of older users.
• Better SEO and AI visibility. Semantic HTML, clear structure, alt texts, and readability strengthen both accessibility and search visibility — including in AI-based search and answer services. Google and accessibility tools read a well-built page in surprisingly similar ways.
• Higher conversion. Clear forms, comprehensible error messages, and fast, robust navigation benefit all users, not just those with disabilities. Accessibility work is often conversion work in disguise.
• Stronger brand. A company that takes accessibility seriously signals care and quality — values that are becoming increasingly important for both customers and employees.

It is this duality — duty and opportunity in one — that makes the companies that go the furthest rarely do accessibility reluctantly. They see it as part of building a genuinely good digital product.

In our web projects, we treat accessibility as a quality level throughout the process, not as a final inspection. Concretely, this means that we consider WCAG already in the design phase — color choices and contrasts are tested before they become a graphic profile, components are designed for keyboard use from the start, and structure is planned to be both logical for the user and correct for the screen reader.

In development, we build on semantic, robust code and test continuously — both with automated tools and manually. And since a large part of accessibility is determined after launch, in the daily content work, we also help teams work accessibly: how to write alt texts that work, structure headings, and keep the language clear.

It is the same approach that makes accessibility, performance, and search visibility tend to improve together with us — they are all expressions of the same thing: a well-built web that works for both humans and machines.

"It only applies to authorities." No. This is precisely what distinguishes the new Accessibility Act from the older DOS Act — it targets private, consumer-oriented companies.

"We can manage with an automatic testing tool." Partially. Automatic tools are a good first step but only capture some of the criteria. Keyboard usage, focus management, and comprehensibility require manual testing.

"We added an accessibility button/overlay, so we're done." No. So-called overlays that promise automatic compliance rarely solve the underlying problems and can in some cases create new ones. The requirements apply to the website's actual code and content.

"It's enough to fix it once." No. Accessibility is an ongoing level. Every new page, feature, and published article can introduce new deficiencies.

When did the Accessibility Directive come into effect?
The Accessibility Act (which implements the EU Accessibility Directive, EAA) began to apply on June 28, 2025. New and updated digital products and services offered after that date must meet the requirements.

Does the Accessibility Directive apply to private companies?
Yes. Unlike the DOS Act, which applies to the public sector, the Accessibility Act targets private actors offering products and services to consumers — such as e-commerce, banking services, and electronic communication.

Which standard must we meet?
The requirements are based on the European standard EN 301 549, which is based on WCAG 2.1 level AA. In practice, it is WCAG 2.1 AA you need to meet.

Are there exceptions?
Yes. Micro-enterprises providing services and having fewer than 10 employees and a turnover or balance sheet total of no more than 2 million euros are generally exempt. The exception is narrower for products.

Who exercises supervision in Sweden?
Supervision is distributed among several authorities depending on the industry, including the Post and Telecom Authority, the Consumer Agency, the Media Authority, the Agency for Accessible Media, and the Swedish Transport Agency.

What is the difference between the DOS Act and the Accessibility Act?
The DOS Act applies to public actors and has been in effect since 2019, with Digg as the supervisory authority. The Accessibility Act (LPTT) from 2025 applies to private actors offering products and services to consumers. The technical level (WCAG 2.1 AA) is practically the same, but they target different actors.

Is an automatic testing tool enough to become accessible?
No. Automatic tools only capture some of the WCAG criteria, such as contrast and missing alt texts. Keyboard navigation, focus management, and comprehensibility require manual testing for a credible assessment.

What is an accessibility statement?
It is a public document where the organization reports how well the digital service meets accessibility requirements, what deficiencies exist, and how users can report issues. It should be kept updated.

Unsure where your website stands today? We help you map and address according to WCAG 2.1 AA. Read 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)
• Post and Telecom Authority — Accessibility Act (supervisory authority)

This guide is prepared for informational purposes and does not constitute legal advice. For assessment in your specific case, consult with legal expertise. Fact-checked against Digg, verified Nov 2025.