EU Accessibility Act: What developers need to know in 2025

Building accessible websites and apps isn’t just about doing the right thing—it’s now a legal requirement. The EU Accessibility Act (EAA) ensures that digital products and services are usable by people with disabilities, but its benefits extend far beyond that. Features like good color contrast, keyboard navigation, and structured content improve usability for everyone, including users on mobile devices or slow internet connections.

But why does this matter right now? Because the deadline for compliance—June 28, 2025—is fast approaching. After this date, businesses that fail to meet accessibility standards could face penalties. That means developers play a critical role in ensuring digital products meet these new legal requirements.

So, who exactly needs to comply, and what do you need to know to get ready? Let’s break it down.

Who has to be compliant?

If you run a personal blog about your holidays and don’t make any money from it, you’re exempt from EAA compliance (at least for that blog). But if you’re a business operating in the EU, you likely need to comply. Yes, even non-EU businesses! 

Business and services covered:

• Manufacturers of products (e.g., computing devices, self-service terminals, e-readers)
• Importers bringing these products into the EU
• Distributors making them available on the EU market
• Service providers offering e-commerce, banking, telephony, or certain transport/media services

That covers most companies—but there are some exceptions.

Exceptions and microenterprises: 

If you’re part of a microenterprise offering services, you might be off the hook for some (but not all) obligations. A microenterprise is defined as one that:

• Employs fewer than 10 people, and
• Has an annual turnover or balance sheet under €2 million

However, manufacturers of products—regardless of size—must still comply.

There’s also a “disproportionate burden” clause for companies that can’t meet the requirements due to financial or technical limitations. But proving this involves paperwork, so most businesses should just focus on making their products accessible.

What must be compliant, and when?

The EAA focuses on digital accessibility. As a developer, here are the key areas to keep in mind:

• Websites and web apps – e-commerce sites, SaaS platforms, and public sector websites (some of which were already covered by previous directives).
• Mobile apps – must be designed and tested with accessibility in mind.
• Software platforms – if your software has a user interface and is offered to EU customers, it likely falls under the directive.

This means most software needs to be accessible—not just on computers and phones, but also on ticket machines, e-readers, and self-service terminals.

However, internal company tools are generally not covered, since the EAA targets consumer-facing offerings. That said, employment and anti-discrimination laws may still require accessibility in internal software.

Compliance Deadlines

The main deadline for compliance is June 28, 2025. After this, non-compliance could lead to penalties.

There are a few exceptions. For example, non-accessible self-service terminals can still be used for up to 20 years—but if they break, they must be replaced with an accessible version.

Now that we know who, what, and when, let’s dive into how to ensure accessibility.

Understanding accessibility standards and guidelines

The EAA doesn’t specify exactly how to achieve accessibility, and each EU country can introduce specific rules. However, the Web Content Accessibility Guidelines (WCAG) are widely recognized as the go-to standard.

The four WCAG principles (POUR)

WCAG is built on four key principles—often referred to as POUR—which ensure that digital content is usable for all.

• Perceivable – Users must be able to perceive content (e.g., alt text for images, captions for videos).
• Operable – Users must be able to interact with your site using keyboards, screen readers, or other assistive technologies.
• Understandable – Content should be clear, consistent, and easy to navigate.
• Robust – Code should follow standards so assistive tech can interpret it correctly.

WCAG conformance levels

• Level A – Basic accessibility (failing this means some users can’t use the site).
• Level AA – Addresses major barriers (the standard most websites aim for).
• Level AAA – Highest accessibility (not always achievable for complex applications).

How can you make your website or app accessible?

Understanding accessibility principles is one thing, but implementing them is another. Let’s break down the key areas where accessibility improvements can make a difference.

Text Alternatives for Non-text Content

Any images that are not merely for decoration will need a non-text alternative. An example of this is the alt attribute for HTML image elements. Also videos need to have an alternative as text description for people who cannot visually perceive the video. At the same time, we need to keep in mind hearing impairments as well. Videos need captions for this group of users. These text alternatives help for the P of POUR, perceivable. This way, the content is perceivable to a much larger group.

Keyboard Accessibility 

There’s a group of users that cannot work with a mouse. For example, if you’re blind or have some impairment on your hands, it can be challenging to work with the mouse. When we speak about this group of users who rely on the keyboard for operating the website, we are talking about the O of POUR: operable (and a little about the P too). This requires some work and optimizations of the developer creating the UI. Elements will have to be focusable with the keyboard, and follow a logical flow. It’s also helpful if users that use the keyboard can quickly navigate to the main content.

Navigable and Consistent Content 

A big part of operable and understandable design is having your site or app flow in a way that makes sense to users. And by that I mean all users, including those using a keyboard or screen reader. Users rely on predictable layouts to orient themselves. If they’re constantly guessing where the “Next” button or the “Cart” link is, that’s not a fun way to keep them mentally challenged. That’s a terrible user experience, even more so for folks using assistive tech that already have to spend more time finding everything on your page.

So in practice here are some examples of what that means:

• Headings and sections should follow a sequence that matches the visual layout. For example, <h1> for your main title, <h2> for section headings, and so on.
• Provide a “Skip to main content” link for keyboard users to bypass repetitive navigation or menus.
• If you have a navigation bar, keep it in the same place on every page. Don’t randomly shuffle the menu items.
• Headers, footers, and sidebars should stay in the same position across the entire site or app.
• Fonts, colors, and button styles should be uniform across all sections so people don’t feel disoriented.

Descriptive Errors

Nothing is more frustrating than an error message like “Something went wrong” with no hint on how to fix it. Under U (or Understandable), WCAG encourages the following for the error messages:

• Add descriptive error messages. So, for example, “Your password must be at least 8 characters long” instead of “Invalid password.”
• Show the error message near the relevant field, not just at the top or bottom of the form.
• Work with different accessible mechanism. If you highlight the error field in red, also include text that a screen reader can pick up, like aria-describedby="error-password-length".

This helps all users, but also users with visual or cognitive impairments that rely even more so on clear instructions and feedback. Good error handling helps them correct mistakes quickly and prevents them from having to redo or re-navigate a page.

Scalable Text 

We often focus on images and forget about text. But some users have low vision or need bigger letters for better readability. The guidelines say your layout should handle scaling up to 200% (and ideally 400%) without losing functionality. Here are some ways that we can achieve that:

• Work with relative units instead of fixed units. For example on websites, use em, rem, or percentages in CSS instead of fixed pixel units.
• Especially avoid fixed heights on your page. If your layout is locked to a specific height, text might overflow or get cut off at higher zoom levels. That’s terrible for the user experience when you zoom in!

This is very important for users who rely on magnification software or just use the browser’s zoom. All users need to read your content comfortably. If text overlaps or the page breaks, it’s a major accessibility barrier.

Responsive Design for Accessibility Across Devices

If your site works great on a desktop but is a nightmare on an iPhone, you’re excluding a whole group of potential users. Inclusive design means inclusive for all device types.

It’s not just about mobile-friendly layouts in the general sense. Responsive design also helps people who rely on touch or use their device in landscape mode. This ties into both the Operable and Robust aspects of the POUR principles.

• You want to make sure the website has adaptive layouts. Make sure your content (both text and non-text) rearranges gracefully across various screen sizes and orientations.
• Have spacious touch targets. On mobile, buttons and links need enough space so users don’t tap the wrong element by mistake.

Sufficient Color Contrast

If people literally can’t read your text because it blends into the background, that’s a direct accessibility fail. High contrast also helps with glare on mobile devices in bright sunlight. For example, for normal text this should be 4.5:1. Here is an example of sufficient and insufficient contrast :

You can check the contrast on different websites, for example https://coolors.co/contrast-checker/. You can see that the contrast for large text such as headers and small text such as paragraphs differs. Personally, I’m sad that this color combination fails, but I can see why at the same time:

ARIA (Accessible Rich Internet Applications)

The main thing on web pages is to use semantic HTML. This means using the meaningful specific elements, such as <button>, <nav>, <header>. Instead of nicely formatted divs with a class that says what it’s for. If you have semantic HTML, ARIA attributes can help screen readers and similar tools further to understand interactive elements. For example:

With aria-label, you’re telling the screen reader, “This button closes the modal window,” rather than just showing an emoji red cross that leaves the user guessing to some extent. The ARIA labels can be used for a lot more, such as specifying roles, states, and properties on elements so assistive technologies can interpret them correctly. Here are a few common cases where ARIA shines:

1. If you build a custom dropdown or a toggle switch that isn’t a native HTML element, you can add attributes like role="switch" or role="listbox" to help users know what it’s supposed to do.
2. For instance, aria-expanded="true" (or "false") indicates whether a dropdown is open or closed. It’s invaluable for screen readers, which otherwise wouldn’t know when content is toggled.
3. Use aria-live="polite" (or "assertive") for dynamically updated content. For example, showing the user “1 new message arrived” on a chat app without them having to navigate away from their current position and accidentally stumbling upon it.

Thanks to ARIA, we have a richer, more descriptive experience for users relying on assistive technology.

What are the technical considerations for accessibility compliance?

Accessibility should be part of your entire development process—not an afterthought.

• Shift left: Incorporate accessibility from the design phase—don’t add it as an afterthought.
• Test for accessibility:
  • Use automated tools (axe-core, Lighthouse, WAVE).
  • Perform manual testing (screen readers, keyboard navigation).
• Backend developers should provide clear error messages instead of generic “Something went wrong” errors.

Why accessibility compliance matters for developers

Accessibility compliance isn’t just about following the law—it’s about creating better digital experiences for everyone. By incorporating accessibility into your development process, you’ll improve usability, expand your audience, and future-proof your work.

If you’re not sure where to start, an accessibility audit is a great first step. Tools like Lighthouse, Wave, or axe-core can help you identify key issues quickly. From there, focus on fixing the most critical barriers and integrating accessibility into your workflow—automating where possible and testing manually when needed.

Need more guidance? Here are some official EU directives and learning resources to help you navigate compliance and best practices.

• EU Directives: See EUR-Lex for the legal texts.
• The W3 WCAG 2 Overview
• Pluralsight Path - Developing Websites for Accessibility 
• Specific Pluralsight Courses:
  • Foundations of Accessible Web Design 
  • Meeting Web Accessibility Guidelines (Section 508/ WCAG 2.1)

Happy accessible coding!