Since 28 June 2025, the European Accessibility Act (EAA) applies across the entire European Union. This directive imposes accessibility requirements on digital products and services, including professional software. For companies using ERP systems daily, the question is no longer theoretical: business interfaces (order entry, invoice validation, dashboards) must be accessible to people with disabilities.
Approximately 87 million people in the EU live with some form of disability—nearly one in four adults according to Eurostat. The challenge extends beyond regulatory compliance: an accessible ERP benefits all users through improved ergonomics, keyboard navigation, and readability.
This article details the regulatory framework, major vendors’ preparedness levels, and provides a practical methodology for auditing and improving your ERP’s accessibility.
What is the European Accessibility Act and Why It Concerns ERP Systems
Directive 2019/882 Overview
The European Accessibility Act (Directive 2019/882) was adopted on 17 April 2019. It harmonises accessibility requirements for digital products and services across the EU. The scope is broad: e-commerce, banking services, transportation, digital books, and “electronically provided services” in general.
The directive excludes microenterprises (fewer than 10 employees with turnover or balance sheet below €2 million) and includes a disproportionate burden clause for cases where compliance would entail manifestly excessive costs relative to the expected benefit.
Key date: obligations apply to new products and services from 28 June 2025. Products already on the market benefit from a transition period until 28 June 2030, provided they undergo no substantial modifications.
National Transposition: Timeline and Country Differences
Each member state has transposed the directive into national law before the deadline of 28 June 2022:
| Country | National Law | Technical Standard | Oversight Body |
|---|---|---|---|
| France | Law 2023-171 of 9 March 2023 | RGAA 4.1 (WCAG 2.1 AA based) | ARCOM |
| Germany | BFSG (Barrierefreiheitsstärkungsgesetz) | EN 301 549 / WCAG 2.1 AA | Marktüberwachungsbehörde (regional authorities) |
| Italy | D.Lgs. 82/2022 | EN 301 549 | AgID |
| Spain | Real Decreto 193/2023 | EN 301 549 / UNE-EN 301549 | Ministerio de Asuntos Económicos |
| Netherlands | Wet implementatie EU-richtlijn toegankelijkheid | EN 301 549 | Nederlandse Voedsel- en Warenautoriteit |
The common European technical standard is EN 301 549, which incorporates WCAG 2.1 Level AA success criteria. Some countries (France, Germany) add national specifications.
Is ERP a “Digital Service” Under the EAA?
The directive targets “electronically provided services” for consumers. An internal ERP (back-office) used exclusively by employees doesn’t directly fall under the EAA as a “consumer service.”
However, three situations make ERP accessibility legally relevant:
- Customer and supplier portals: an online ordering portal, supplier extranet, or browser-accessible customer service falls under EAA scope
- Employer obligations: European and national employment law (in France, Law 2005-102) already requires reasonable accommodations for disabled employees, including digital work tools
- Public procurement: EU Directive 2014/24/EU on public procurement requires accessibility criteria in specifications, directly affecting ERP systems deployed in public or semi-public sectors
In practice, even for strictly internal ERP systems, accessibility becomes a de facto requirement for any company employing people with disabilities or responding to public tenders.
WCAG 2.2 Level AA: The Applicable Technical Standard
Four Principles Applied to ERP Systems
The WCAG 2.2 (Web Content Accessibility Guidelines) standard from W3C is organised around four principles, each with specific implications for ERP systems:
- Perceivable: information must be presentable in forms users can perceive. In ERP systems, this means sufficient contrast in data entry forms, text alternatives for reporting graphics, indicators not based solely on colour (e.g., an “overdue” status cannot be signalled only in red)
- Operable: the interface must be navigable and usable without a mouse. ERP dashboards, data grids, and approval workflows must be fully operable via keyboard. Session timeouts must be sufficient or configurable
- Understandable: forms must have explicit labels, error messages must be clear and contextual, and navigation must be consistent across modules
- Robust: HTML/ARIA code must be properly structured to work with assistive technologies (screen readers, magnification software, switches)
Practical Examples in ERP Systems
Keyboard navigation in dashboards. Users must be able to navigate between dashboard widgets (revenue, pending orders, alerts) using Tab and arrow keys, without getting trapped in a component (concept of “focus trap”).
Contrast in data entry forms. The minimum contrast ratio required by WCAG AA is 4.5:1 for text and 3:1 for interface elements (field borders, actionable icons). ERP themes with light grey backgrounds and medium grey text are frequently non-compliant.
Screen reader support in workflows. When a user approves an invoice in an approval workflow, the status change must be announced to screen readers via ARIA live regions. An “Approve” button without accessible labelling will be invisible to NVDA or JAWS.
Current State: Where ERP Vendors Stand
SAP: Fiori Leading, SAP GUI Lagging
SAP is the most advanced vendor in ERP accessibility. The SAP Fiori interface is designed according to WCAG principles and includes keyboard navigation, screen reader support, and contrast ratio compliance. SAP publishes Accessibility Conformance Reports (ACR) based on VPAT format for its cloud products.
The SAPUI5 library targets WCAG 2.2 compliance, with specific work on new criteria (drag-and-drop alternatives, redundant input minimisation).
The problem: companies still using SAP GUI (classic Windows interface) or legacy ABAP transactions don’t benefit from these advances. SAP GUI accessibility is structurally limited by its technical architecture. For companies migrating to S/4HANA, this is an additional argument favouring the switch to Fiori.
Oracle: Documented Compliance, Variable Experience
Oracle publishes VPAT/ACR reports for all its cloud products, including Oracle Cloud ERP. Declared compliance covers EN 301 549 and WCAG 2.1. In practice, user feedback indicates gaps between documented compliance and actual experience, particularly in reporting modules and configuration interfaces.
Oracle nonetheless benefits from structured accessibility governance and a dedicated programme (Oracle Accessibility Programme) that integrates accessibility testing into the development cycle.
Odoo, Sage, Dynamics 365: Uneven Maturity
Microsoft Dynamics 365 benefits from Microsoft’s massive investment in accessibility. The web interface generally respects WCAG standards, and Microsoft publishes Conformance Statements. However, custom Power Apps modules require separate auditing.
Sage hasn’t published as visible an accessibility programme as SAP or Oracle. Sage interfaces vary significantly across products (Sage 100, Sage X3, Sage Intacct) and technological generations. Recent cloud versions are generally better positioned than legacy thick clients.
Odoo is a special case. Odoo’s web framework has progressed on accessibility in recent versions, but the vast ecosystem of community modules (over 40,000 on the Odoo App Store) is subject to no accessibility controls. A third-party module adding a custom entry screen can break the entire system’s accessibility.
The Trap of Accessibility-Breaking Customisations
This is the blind spot of most ERP projects. Even if the vendor delivers a compliant product, customisations made during deployment (custom screens, ABAP reports, Crystal Reports views, integrated Power BI dashboards, community modules) are almost never audited for accessibility.
A “theoretically compliant” ERP can become non-compliant in production if internal development teams or system integrators haven’t integrated accessibility requirements into their processes.
Auditing Your ERP’s Accessibility: Methodology
Automated Audit Tools
Automated tools quickly detect the most common issues:
- axe DevTools (Deque Systems browser extension): detects WCAG violations in web interfaces, ideal for cloud ERP or web portals
- Lighthouse (integrated into Chrome DevTools): provides an accessibility score and identifies critical elements (contrast, missing labels, heading structure)
- WAVE (Web Accessibility Evaluation Tool): visual tool overlaying errors and alerts directly on the page
These tools cover approximately 30-40% of WCAG criteria. They don’t replace manual auditing but help prioritise fixes.
Essential Manual Testing
Automated tests cannot evaluate a disabled user’s actual experience. The following manual tests are essential:
- Complete keyboard navigation: navigate each critical screen (order entry, invoice validation, stock inquiry) using only Tab, Enter, Escape, and arrow keys. Verify focus is visible and tab order is logical
- Screen reader testing: test with NVDA (free, Windows) or JAWS (commercial, Windows) the main user journeys. Verify field labels, error messages, and status changes are properly announced
- 200% magnification: enlarge the interface to 200% and verify no information is truncated or inaccessible (reflow)
- High contrast mode: activate the operating system’s high contrast mode and verify the interface remains usable
Evaluation Grid: 10 Critical Points in ERP Systems
- All form fields have associated HTML labels (
<label for="...">) - Input error messages identify the concerned field and error nature
- Contrast ratio meets 4.5:1 for text and 3:1 for interface components
- Keyboard navigation covers all screens without “focus traps”
- Data tables use
<th>,scope, and<caption>for structure - Charts and visual indicators have text or tabular alternatives
- Context changes (popups, tabs, redirects) are announced to assistive technologies
- Session timeouts are configurable or warned 20 seconds before expiration
- Heading structure (
h1toh6) is hierarchical and consistent per page - The site/application passes axe DevTools tests with zero critical violations
Action Plan: Making Your ERP Compliant in 5 Steps
1. Inventory Used Interfaces
List all ERP interfaces exposed to users: internal back-office, customer portal (B2B e-commerce, order tracking), supplier portal, mobile application. Each interface potentially has different obligations depending on whether it serves consumers (EAA) or employees (employment law).
2. Prioritise Critical Screens
Focus effort on high-impact journeys: order entry, invoice validation, stock inquiry, management reporting. An exhaustive audit of hundreds of screens is unrealistic initially. Target the 20 most-used screens and external portals as priorities.
3. Working with Vendor vs Internal Fixes
For standard products, engage the vendor. Request their VPAT/ACR reports, accessibility roadmap, and planned fixes. For customisations, responsibility lies with you: integrate WCAG AA criteria into development specifications and integrator requirements.
4. Train Internal UX/Development Teams
Accessibility cannot be treated as an afterthought. Train internal developers and key users on web accessibility fundamentals: semantic HTML structure, ARIA attributes, keyboard testing. An investment of 2-3 training days per developer suffices to cover the basics. Change management is an essential lever, as detailed in our practical ERP change management guide.
5. Document Accessibility Declaration
In France, publishing an accessibility declaration is mandatory for public services and will extend to the private sector via the EAA. This declaration must indicate the compliance level achieved, identified non-conformities, and contact means for users experiencing difficulties. A multi-year accessibility improvement scheme reinforces the approach’s credibility.
Penalties and Risks for Non-Compliance
Fines by Country
Penalties vary according to national transpositions:
- France: ARCOM can impose fines up to €50,000 per violation (ordinance of 6 September 2023). Non-compliance with additional obligations (accessibility declaration, multi-year scheme) is punishable by €25,000
- Germany: BFSG provides for fines from €10,000 to €100,000 depending on severity, with graduated procedure (notice, hearing, then penalty)
- Italy: proportional administrative fines, with possibility of market withdrawal for non-compliant products
- Spain: penalties of €10,001 to €100,000 for serious infractions
Beyond fines, competitors and consumer associations can initiate cease-and-desist actions in several member states.
Reputational Risk and Public Procurement Exclusion
Direct financial risk (fines) is often less than indirect risk. A company whose customer portal isn’t accessible faces de facto exclusion from public tenders, where accessibility criteria are now integrated into specifications. Reputational risk is also real: disability associations and specialist media regularly publish rankings and reports.
Accessibility as Software Quality Lever
Accessibility isn’t just a regulatory constraint. WCAG principles, applied to ERP systems, improve all users’ experience: faster keyboard navigation, clearer error messages, better dashboard readability. For an ageing workforce, these improvements directly impact productivity.
Initial audit costs vary from €5,000 to €20,000 depending on ERP complexity and screen count. Remediation costs depend on customisation volume. These investments should be compared to potential fines and, crucially, to lasting software quality improvements.
To go further, consult our ERP user acceptance testing checklist (integrate accessibility criteria into your UAT) and our ERP GDPR compliance guide (regulatory compliance logic is similar: inventory, audit, action plan, documentation).
For adoption hypothesis validation, start with a 3-month POC on one target process (procurement, accounting, CRM). Typical budget: €15-30K. Result: Go/No-Go decision with concrete figures, not spreadsheets of commercial promises.
