The Accessibility Act: what does it mean for your website?

Picture a customer who wants to book a window cleaner through your website. She has low vision and uses a screen reader. She gets through the home page fine, but the date picker in the booking form only works with a mouse, and the payment button is announced simply as “button”. She gives up and calls a competitor. That is exactly the situation the Accessibility Act is meant to prevent, and it is also a situation that costs you revenue, quite apart from the law.

The Danish Accessibility Act implements the EU’s European Accessibility Act (EAA). It covers a range of products and services, and for most companies the relevant part is e-commerce: webshops, booking solutions and apps where a consumer can enter into an agreement online. Sikkerhedsstyrelsen (the Danish Safety Technology Authority) supervises in Denmark. We are a digital product studio without a legal practice, so use this guide as a practical overview and have your specific situation assessed by a lawyer or through Sikkerhedsstyrelsen’s guidance.

Who is covered by the Accessibility Act?

The law targets services and products aimed at consumers. On the service side, the main categories are e-commerce, consumer banking services, e-books, electronic communications, access to audiovisual media services and certain parts of passenger transport such as ticket sales and travel information. On the product side it covers items such as computers, smartphones, payment terminals, ticket machines and e-readers. For an ordinary Danish company with a website, the question is therefore fairly simple: can a private individual buy, book or enter into an agreement with you online?

The micro-enterprise exemption

Micro-enterprises providing services are exempt from the requirements. The definition is fewer than 10 employees and annual turnover or balance sheet of no more than EUR 2 million. The exemption helps the small webshop, but keep two things in mind. First, companies grow, and once you pass the threshold the requirements apply. Second, an inaccessible webshop is still a webshop that loses customers: older users, people with low vision, colour-blind people and anyone shopping on a phone in bright sunlight. We therefore recommend that small companies build to the same principles whenever they have something new made anyway.

Transition rules and disproportionate burden

The law contains transition rules for certain existing contracts and products, and in particular cases a company can argue that a requirement would impose a disproportionate burden or require a fundamental change to the service. Both require a specific, documented assessment, which typically has to be available if the authority asks. It is not a shortcut to plan around. If you see it as an option for you, speak to a lawyer before relying on it.

What does the law actually require of a website or app?

The law describes requirements in functional terms: the service must be perceivable, operable, understandable and robust. Those are the same four principles that WCAG is built on. In practice, the harmonised European standard EN 301 549 points to WCAG 2.1 level AA for web and apps, and that is the level we recommend as your target. WCAG 2.2 has been published and adds a handful of criteria about things like focus visibility and dragging movements. If you are building something new, include them from the start, because it costs almost nothing when it happens in the design phase.

• Perceivable: text alternatives for images, captions for video, sufficient contrast and content that can be zoomed without breaking.
• Operable: everything works with a keyboard, focus is visible, there is enough time to complete forms and nothing flashes aggressively.
• Understandable: clear labels, error messages that explain what went wrong, and navigation that behaves the same on every page.
• Robust: correct HTML and ARIA, so screen readers and other assistive technology can read buttons, fields and status messages.
• Information: an accessibility statement or equivalent information in your terms explaining how the service meets the requirements.

WCAG checklist: what should you test on your website?

Automated tools only find part of the issues. They can see that an image lacks alt text, but not whether the alt text makes sense, and they cannot tell whether a checkout flow is logical to move through with a keyboard. The best test combines an automated scan with half a day of manual work. You can copy the list below straight into an email to your supplier or work through it yourself one afternoon.

1. Can you complete the whole purchase or booking using only Tab, Shift+Tab, Enter and the space bar?
2. Can you always see where focus is, including on dark backgrounds and inside pop-ups?
3. Do all informative images have descriptive alt text, and are decorative images hidden from screen readers?
4. Does every form field have a visible label that does not disappear when you start typing?
5. Do error messages explain what is wrong and how to fix it, in text and not only with red colour?
6. Is contrast at least 4.5:1 for normal text and 3:1 for large text, icons and field borders?
7. Can the page be zoomed to 200 % and shown on a 320-pixel-wide screen without horizontal scrolling or overlapping text?
8. Do buttons and links have names that make sense out of context, such as “Add to basket” instead of “Click here”?
9. Do videos have captions, and can autoplay be stopped?
10. Does the page have a logical heading structure with one H1 and H2s and H3s in the right order?
11. Is the page language set correctly, so the screen reader pronounces Danish as Danish?
12. Do the cookie banner, chat widget and payment window work with a keyboard and a screen reader?

Many people overlook the last point. A cookie banner that traps keyboard focus or cannot be closed without a mouse blocks the entire site for some users. The same applies to third-party payment windows. Choose suppliers who document their own accessibility, and test them in your own flow. We cover the rules for the banner’s content in our guide to cookie banner rules.

Which accessibility issues should you fix first?

If you have received a report with 140 issues, it can feel overwhelming. Prioritise using two questions: does the issue stop someone from completing a purchase or booking, and how many pages does it affect? A missing label in the checkout matters more than a wrong heading order on a blog post from 2019. Many issues also live in shared components such as the header, menu, buttons and form fields, so one fix in a design system solves the problem on a hundred pages at once.

The five issues we see most often

When we review existing websites, the same issues come up again and again. Low contrast in light-grey text and in buttons with white text on pastel colours. Icons without text, such as a basket or a magnifying glass with no name for the screen reader. Forms where the field name only exists as placeholder text and disappears as you type. Dropdown menus and date pickers built as custom components that cannot be used with a keyboard. And pop-ups where focus is not moved into the window, so a screen reader user never notices that anything opened. All five can be solved in design and code without compromising the look.

What does it cost to make a website accessible?

The price depends mostly on how the site is built. A modern solution with a shared component library can often be fixed in days, because the issues are concentrated in a few places. An older WordPress site with a bought theme, ten plugins and a page builder can be expensive to fix, because the code is not yours and every update can reintroduce the issues. There, rebuilding the key templates is often cheaper. The ranges below are typical market prices and should be read as reference points.

We believe accessibility belongs in the design and code from the first sketch, and it costs far less than fixing it afterwards. See what goes into our packages, or have accessibility reviewed as part of a UX audit. If you are facing fixes to an old site, a website redesign can be the most economical route, because you get rid of technical debt at the same time.

How do you build accessibility in from the start?

The most important choices are made in the design phase. The colour palette decides contrast, typography decides readability, and interaction patterns decide whether something works with a keyboard. That is why we work with a design system in which every component is tested once and reused everywhere. In code we use real HTML elements before reaching for custom solutions: a button is a button and a link is a link. It sounds trivial, but it is the source of half the issues we find elsewhere.

What happens if you do not comply with the Accessibility Act?

Sikkerhedsstyrelsen can supervise, request documentation and order issues to be fixed, and the law also allows for sanctions. We do not go into the size of any fines here, because that depends on the case and on enforcement practice, which is still developing. The practical advice is the same either way: show that you are on top of it. A documented test, a prioritised plan and an honest statement put you in a far better position than a site nobody has looked at.

There is also a business side. An accessible site is faster to use, has a better structure for Google and typically converts better on mobile, because clear labels, large tap targets and a logical order help everyone. Many of the requirements overlap with good SEO-friendly structure and with website speed. It is the same craft.

A worked example: a webshop with 25 employees

Take a Danish webshop with 25 employees selling garden furniture to consumers. It is clearly covered. An automated scan reports 140 issues, but most come from six components: product card, filter menu, quantity selector, basket, checkout form and cookie banner. A manual audit of search, filter, add to basket and pay typically costs DKK 15,000–25,000. Fixing the components takes one to two weeks in a modern codebase. The editorial team spends a day on alt text for the 50 best-selling products and on replacing PDF care guides with ordinary pages. Finally, the statement is written with two known gaps and a date for when they will be solved. The total bill lands somewhere between DKK 30,000 and 70,000, and the webshop is easier for every customer to use afterwards.

If you need a new website or webshop anyway, require WCAG 2.1 AA in the requirements specification and ask the supplier to describe how they test. Combine it with the other rules in our guide to GDPR for websites and apps. If you want a concrete figure for what it would cost you, get a fixed price within 24 hours.