Accessibility

More and more are doing it. The EAA and LPTT cover large parts of the private sector since 2025, and the DOS Act applies to the public sector. We clarify what applies specifically to you.

In short: The DOS Act affects public and publicly funded operations. The EAA and LPTT affect private actors who sell certain services to consumers, such as e-commerce, banking, transport, and digital books.

There are exceptions, including for the smallest companies, and transitional rules for services that were in place before the requirements came into force. We review your situation and tell you what applies before you spend money on measures.

A review of your service against WCAG requirements, with flaws listed and prioritized. You will find out where you stand and what needs to be addressed first.

We review the service against WCAG 2.2 at level AA, both with tools and manually, and test the most important flows with a keyboard and screen reader.

You will receive a list of the issues, where they are located, which requirement they violate, and how much they affect the user. The list is sorted, so you can start at the top and work your way down.

No, not if the service has been updated since then. The ongoing work is what keeps compliance alive.

An audit is a snapshot of what it looked like that day. Every new release, new page, and new document can introduce new flaws, and content is the most common source.

What lasts over time is that the requirements are integrated into the regular work: in the design, in the code review, and among those who publish content. We help you get there and follow up with recurring checks.

For the public sector, the DOS Act (Web Accessibility Directive) has applied for several years. For private services covered by the EAA and LPTT, the requirements apply starting in the summer of 2025, with transitional rules for certain existing services.

Exactly what applies to you depends on the service in question, the sector you operate in, and how large the company is. We will sort this out in an initial review, before you spend money on measures.

Our experience is that the work takes longer than expected, especially when the content is old and located in documents and PDFs. Better to start now than when someone asks.

No. We prioritize based on user impact and risk, so that the obstacles affecting the most people are addressed first. You will receive a step-by-step action plan that can be integrated into regular development work, instead of a major overhaul.

In practice, the actual barriers rank highest: forms that cannot be filled out with a keyboard, contrast that makes text unreadable, and flows that stop for screen reader users. Individual pages with low traffic can wait.

You will also find out what needs to be changed in your way of working, so that the list doesn't fill up as fast as you work through it.

Accessibility is not something you ever finish. New releases, new content, and new requirements move the goalposts. We set up continuous monitoring and recurring audits, and train the team so that the work becomes part of daily routines rather than just sitting in a report.

In practice, this involves automated checks in the build, manual testing for major releases, and clear routines for content editors. Images, headings, and link texts are where most new issues tend to arise.

We also hand over the accessibility statement and the routine for keeping it updated, as it is a requirement in itself and quickly becomes outdated.