How to Write an Accessibility Statement for Your SaaS (EAA Required)

The European Accessibility Act became enforceable on 28 June 2025. One of its requirements, one that France applied an additional annual penalty specifically for missing, is an accessibility statement. For many SaaS founders, this is the compliance item they know the least about: what it is, what it must contain, where it must be published, and what happens if it is wrong. An accessibility statement is not a privacy policy with a different subject matter. It is a public declaration about the specific accessibility status of your product, and in several EU member states, publishing an inaccurate one increases your legal liability rather than reducing it. This post explains exactly what an EAA-compliant accessibility statement requires, what it cannot say, and how to approach writing one for a SaaS product.

What an Accessibility Statement Is

An accessibility statement is a public declaration about the accessibility status of your digital product, your website, your SaaS application, your mobile app, or any combination of these. It is not a general commitment to inclusivity (though it can include that). It is a specific, factual document about:

• What standard are you conforming to (EN 301 549 / WCAG 2.1 Level AA)
• How well you are conforming to it (fully, partially, or not)
• What is not accessible and why
• How users can get help or report issues
• When the statement was prepared, and how the assessment was conducted

An accessibility statement is distinct from an internal accessibility policy (a governance document for your team) and from a VPAT, Voluntary Product Accessibility Template, which is a detailed technical conformance report primarily used for US government procurement and enterprise sales.

Who Needs One

Under the EAA, any business providing digital services to EU consumers, such as e-commerce platforms, SaaS applications, banking services, transportation ticketing, and telecommunications, must publish an accessibility statement. This applies regardless of where the business is headquartered. A US-based SaaS company serving EU users needs a statement.

The EAA microenterprise exemption (fewer than 10 employees AND under €2 million annual turnover) provides limited relief for service requirements — but microenterprises still need to meet the underlying accessibility requirements for products, and the exemption does not apply to businesses headquartered outside the EU.

For SaaS products: if you have EU users or EU customers, you need a statement. If you have EU users or EU customers and you are pursuing enterprise sales to EU companies, you need a statement that your procurement contacts can reference.

The 5 Required Sections

Based on the official EU model accessibility statement format (per Implementing Decision (EU) 2018/1523) and EAA Annex V requirements, an EAA-compliant accessibility statement must contain five core sections.

Section 1: Compliance Status

The statement must declare one of three compliance statuses:

• Fully compliant – the product meets all WCAG 2.1 Level AA requirements (or EN 301 549) with no exceptions
• Partially compliant – the product meets most requirements but has known gaps; these must be identified
• Not compliant – the product does not currently meet the required standard

This is the section most commonly handled incorrectly. Many organisations publish “we are fully compliant” statements based on a single automated scan — without disclosing that automated tools catch only 30–40% of WCAG violations, and that the remaining 60–70% would require manual testing to find. Publishing a false full compliance claim significantly increases legal exposure if a user or regulator subsequently finds issues.

The safest and most defensible approach for most SaaS products is partially compliant with a documented list of known issues, a timeline for remediation, and clear contact information for users who encounter barriers. This demonstrates transparency and good faith.

Section 2: Non-Accessible Content

If the product is partially compliant, the statement must identify what is not accessible. This section should document:

• Specific known accessibility failures (e.g., “Some data visualisations do not have adequate text alternatives” or “The third-party embedded calendar widget does not support full keyboard navigation”)
• The reason for each gap: either genuine non-compliance (we are working to fix this), disproportionate burden (fixing this would impose disproportionate cost relative to the benefit), or out-of-scope content (third-party content we do not control)
• Expected remediation timelines where applicable

Important legal note on disproportionate burden: This is a specific legal claim under Article 14 of the EAA, it requires a documented economic assessment sent to the relevant national market surveillance authority. It is not a catch-all excuse for not fixing accessibility issues. Use it sparingly and with proper documentation.

Section 3: Assessment Method

The statement must explain how the accessibility assessment was conducted:

• Self-evaluation – the organisation assessed its own product using WCAG criteria
• Automated testing – tools such as Axe, WAVE, or Lighthouse were used (note: these detect 30–40% of issues)
• External audit – a third-party accessibility specialist conducted the assessment
• Combination – automated testing plus manual review plus assistive technology testing

The more rigorous the assessment method, the more defensible the compliance claim. An external audit using WCAG 2.1 manual testing criteria and assistive technology (screen readers, including NVDA and JAWS, keyboard-only navigation) provides the strongest foundation for any compliance claim.

The statement must also include the date of the most recent assessment, and should be updated whenever significant product changes occur that could affect accessibility status.

Section 4: Contact and Feedback Mechanism

The statement must provide a working mechanism for users to:

• Report accessibility barriers they encounter
• Request accessible alternatives for content that is not accessible
• Seek assistance when the product prevents them from completing a task

This must be a genuine, monitored contact point, not a generic contact form that no one checks. A dedicated email address (e.g., accessibility@yourcompany.com) that is monitored and receives responses within a defined timeframe is the most common approach. The response commitment should be documented in the statement.

Section 5: Enforcement Procedure

Under the EAA, users who are not satisfied with the response to their accessibility complaint must be directed to the relevant national enforcement authority. The statement must include information about this escalation pathway.

For businesses operating in multiple EU member states, this means either referencing the enforcement authority in each country where the product is available or including a general reference to EU enforcement mechanisms with guidance on finding the relevant national authority.

What Not to Write: The Common Mistakes

Claiming full compliance without evidence. An automated scan that shows no errors does not mean WCAG compliance, it means no automated errors were detected. Full compliance requires manual testing including keyboard navigation testing, screen reader testing, and cognitive accessibility review. Claiming full compliance without this evidence is misleading.

Vague language that commits to nothing. “We are committed to making our website accessible” is a sentiment, not a statement. The EAA requires specific, factual information about compliance status. Vague language provides no protection.

Listing third-party content as a blanket excuse. While third-party content that you do not control is generally out of scope, embedding inaccessible third-party components into your core product workflow is not automatically exempt. If a third-party login widget, payment form, or data visualisation library is part of your core product, its accessibility is your responsibility.

Not updating it. An accessibility statement with a preparation date from 18 months ago, unchanged despite significant product updates, is evidence of inadequate accessibility governance. Enforcement authorities look for statements that are actively maintained.

A Practical Template Structure

The following structure covers the five required sections for a SaaS product:

Accessibility Statement for [Product Name]

Prepared: [Month Year] | Last reviewed: [Month Year]

[Your company name] is committed to ensuring digital accessibility for people with disabilities. We are continually working to improve the accessibility of [Product Name] and to provide an inclusive experience for all users.

Conformance status

[Product Name] is [fully compliant / partially compliant / not compliant] with [EN 301 549 v3.2.1 / WCAG 2.1 Level AA]. [If partially compliant:] Known areas of non-conformance are listed below.

Non-accessible content (include only if partially or non-compliant)

The following content is not fully accessible for the reasons listed:

• [Description of issue and affected content] — [Reason: non-compliance / disproportionate burden / third-party content outside scope] — [Planned fix date if applicable]

Assessment approach

[Company name] assessed the accessibility of [Product Name] using the following methods: [self-evaluation / automated testing with [tool names] / external audit by [auditor name] / combination of automated and manual testing including assistive technology testing]. The assessment was completed on [date].

Feedback and contact

We welcome feedback on the accessibility of [Product Name]. If you encounter accessibility barriers, or if you require content in an accessible alternative format, please contact:

Email: [accessibility@yourcompany.com]

Response time: We aim to respond within [X] working days.

Enforcement procedure

If you are not satisfied with our response to your accessibility complaint, you may contact the relevant national enforcement authority in your country. For a list of national enforcement authorities, see [link to EU resource].

Where to Publish It

The accessibility statement must appear on your website or product in a prominent, easily accessible location. Best practice is:

• A dedicated page at a predictable URL (e.g., yourproduct.com/accessibility)
• A link in the footer of your marketing site
• A link accessible from within the product itself
• Referenced in your privacy policy and terms of service

France specifically penalises inaccessible accessibility statements, the statement page itself must meet WCAG 2.1 Level AA requirements. Use sufficient colour contrast, proper heading structure, and keyboard-navigable links.

How Often to Update It

The statement must be updated:

• At least annually
• Whenever significant accessibility work is completed that changes the compliance status
• Whenever significant new features are released that introduce new accessibility considerations
• Whenever the assessment is re-run

A stale accessibility statement, particularly one that claims a compliance status that has since changed, is evidence of inadequate governance and increases legal risk.

Conclusion

An accessibility statement is not a checkbox. It is a legal document that declares your product’s accessibility status, documents its limitations honestly, and provides users with a genuine mechanism to get help. Getting it right means being specific about what is and is not accessible, being honest about the assessment method used, and providing a working contact mechanism that is actually monitored. Getting it wrong, particularly by claiming full compliance without adequate evidence, increases your legal exposure under the EAA rather than reducing it.

→ Need help auditing your product’s accessibility status before writing your statement? Inity conducts WCAG 2.1 AA audits that give you the factual foundation for an accurate, defensible accessibility statement. Book a call.