What Is the European Accessibility Act – And Does It Apply to Your SaaS?

The safest practical rule for a growing SaaS: if you have EU customers, if your product will grow beyond microenterprise thresholds, or if you are building toward a B2C or B2B2C use case, designing for WCAG 2.1 AA from the start is significantly cheaper than retrofitting accessibility later. Studies consistently show that fixing accessibility in production code costs 3–5x more than building it in at the design and development stage.

What Does EAA Compliance Actually Require?

EAA compliance means your digital product must conform to EN 301 549, which incorporates WCAG 2.1 Level AA. WCAG, the Web Content Accessibility Guidelines, is built around four principles known as POUR:

1. Perceivable – Information and interface components must be presentable to users in ways they can perceive. This includes providing text alternatives for images, captions for video, sufficient colour contrast, and content that doesn’t rely on a single sensory channel.
2. Operable – All interface functionality must be operable without requiring interaction that users cannot perform. This means full keyboard navigability, no content that causes seizures, enough time for users to read and use content.
3. Understandable – Content and interface operation must be understandable. This means readable text, predictable page behaviour, and clear error identification and correction support.
4. Robust – Content must be robust enough to be reliably interpreted by assistive technologies, including screen readers. This means clean, semantic HTML and ARIA attributes used correctly.

Practical requirements for a SaaS product:

• All images have descriptive alt text
• All interactive elements (buttons, forms, links) are keyboard-accessible
• Colour contrast ratios meet WCAG minimums (4.5:1 for normal text, 3:1 for large text)
• Screen readers can parse all interface elements correctly
• Form fields have visible labels and clear error messages
• Video content has captions or transcripts
• No content relies on colour alone to convey information
• Focus indicators are visible for keyboard navigation
• An accessibility statement is published on the product or website

Beyond the product itself, the EAA also requires a publicly accessible accessibility statement describing the product’s conformance level, known limitations, and a contact for accessibility-related feedback.

What Are the Penalties for Non-Compliance?

Penalties are determined by each EU member state individually, but the EAA requires them to be effective, proportionate, and dissuasive. Enforcement can include financial fines, withdrawal of non-compliant products from the EU market, or bans on offering services in the EU.

Examples of country-level penalties:

Beyond fines, there is a significant procurement consequence: EU government and enterprise institutions are increasingly requiring a VPAT (Voluntary Product Accessibility Template), a formal document of WCAG conformance, as a condition of procurement. Without a VPAT, your SaaS may be disqualified from EU public sector contracts regardless of your product quality.

When Did the EAA Come Into Force – And What About Existing Products?

The EAA became enforceable on 28 June 2025. This is the date from which new products and services must comply. Products already on the market before that date have a transitional period and must comply by 28 June 2030, or at their next major update, whichever comes first.

For most SaaS products under active development, where new features ship regularly, the 2030 grace period is largely academic. Any significant update after June 2025 triggers compliance requirements for the updated components.

Timeline:

• 2019 – EAA adopted as EU Directive
• 2022 – Member states transpose EAA into national law
• 28 June 2025 – EAA comes into force; new products and services must comply
• 28 June 2030 – Deadline for legacy products already on market before June 2025

What Should SaaS Founders Do Now?

If your SaaS is in scope under the EAA, whether you’re building a new product or have an existing one, the most practical starting point is understanding where you stand against WCAG 2.1 AA today.

Immediate steps:

1. Determine your scope – Is your product consumer-facing? Are you above microenterprise thresholds? Do you have EU customers or plan to?
2. Run an accessibility audit – Test your current product against WCAG 2.1 AA criteria. Manual testing with assistive technologies is more reliable than automated scanners alone.
3. Prioritise critical paths – Focus first on core user workflows: onboarding, login, main dashboard, and checkout or key conversion flows.
4. Build in, don’t bolt on – If you are at the design stage, accessibility requirements are far cheaper to implement in Figma than in production code. Design decisions, contrast ratios, component structure, focus states, set the accessibility baseline for everything built from them.
5. Publish an accessibility statement – Even a basic statement of current conformance level and a remediation roadmap reduces enforcement risk significantly.
6. Produce a VPAT when ready – Required for EU government and enterprise procurement.

If you are building a new SaaS MVP, working with a product team that understands accessibility requirements from the design phase is the most cost-effective path to EAA compliance.

Conclusion

The European Accessibility Act is in force. It applies to any SaaS product with EU customers, regardless of where the company is based. The technical standard is WCAG 2.1 AA via EN 301 549. The practical implication is clear: if you are building a product that will be used in the EU, accessibility is a compliance requirement, not a nice-to-have. Building it in from the design stage is 3–5x cheaper than fixing it in production. For SaaS founders at the pre-seed and seed stage, the right time to address EAA compliance is now — before the codebase grows and the retrofit cost compounds.

→ Book a strategy call with Inity Agency to discuss EAA compliance for your SaaS product.