The European Accessibility Act (EAA) treats software updates as part of the product itself. If a covered product or service receives an update after June 28, 2025, that update must meet the same accessibility requirements as the base product. There is no carve-out for incremental releases, patches, or feature additions. A non-conformant update can pull a previously conforming product back into noncompliance.
The rule is simple in concept and detailed in application. What follows is how it actually works.
| Update Type | EAA Treatment |
|---|---|
| Bug fix or security patch | Must not introduce new accessibility issues. No new conformance documentation required. |
| Minor feature addition | New functionality must meet EN 301 549 requirements at release. |
| Major version or redesign | Treated as a substantial change. Full accessibility evaluation expected. |
| UI or workflow overhaul | Triggers re-evaluation of affected user flows against EN 301 549. |
| Third-party component update | Responsibility stays with the product owner, not the component vendor. |
What the EAA Says About Updates
The EAA applies to products and services placed on the EU market after June 28, 2025. For software, the obligation does not end at first release. The regulation expects covered products to remain accessible across their lifecycle, which means every update inherits the same accessibility requirements as the base release.
The technical standard behind the EAA is EN 301 549, which maps closely to WCAG 2.1 AA for web and software interfaces. When an update changes UI, content, or interaction patterns, those changes are evaluated against EN 301 549 the same way the original release was.
Do Small Patches Need Accessibility Review?
Yes, but the scope of review scales with the scope of the update. A security patch that does not touch the user interface does not require a fresh audit. It does require that no new accessibility issues are introduced during the patch.
Feature additions are different. A new form field, a new modal, a new navigation element, any of these introduce new code paths that must meet EN 301 549. The team shipping the update is responsible for confirming the new code conforms before release, not after.
When an Update Counts as a Substantial Change
A substantial change is the point where an update stops being incremental and starts being a new product release in practical terms. UI overhauls, workflow redesigns, and major version upgrades all qualify. So do platform migrations and rewrites of core components.
When a substantial change occurs, the accessibility work resets. Previous conformance documentation does not carry over to the redesigned areas. A fresh evaluation against EN 301 549 is needed for the affected parts of the product.
Third-Party Components and Dependencies
Software products use third-party libraries, frameworks, and components. The EAA holds the product owner responsible for the accessibility of the final product, not the upstream vendor. If a third-party component update introduces an accessibility issue, the product owner must address it.
This is why ongoing accessibility evaluation matters. A dependency update can quietly regress a previously conformant product. Without periodic re-evaluation, the regression goes undetected until a user reports it or an enforcement action begins.
Documentation Expectations
The EAA requires manufacturers to maintain technical documentation that demonstrates conformance. For software, this includes audit reports, remediation records, and any accessibility statements published with the product. When a substantial update ships, the documentation should reflect the current state of the product, not the state at first release.
Keeping documentation current is less about paperwork and more about creating a defensible record. If an enforcement body or customer asks how the product meets EN 301 549, the answer should be a current audit report, not a two-year-old document tied to a different version of the software.
Practical Workflow for Update Releases
Teams shipping covered software typically build accessibility evaluation into the release cycle. New features are reviewed against EN 301 549 before merge. Major releases trigger a thorough audit of changed areas. Documentation updates accompany the release notes.
This is not a separate process layered on top of development. It is part of how the team works. Accessibility evaluation at release time is faster and cheaper than retrofitting after a customer complaint or enforcement letter.
Frequently Asked Questions
Does every software update need a new accessibility audit under the EAA?
No. The scope of evaluation matches the scope of the update. Bug fixes that do not change the interface do not need a fresh audit. Feature additions and substantial changes do require evaluation of the changed areas against EN 301 549.
What happens if a software update breaks accessibility on a previously conforming product?
The product is no longer conforming. The manufacturer is responsible for identifying the regression and remediating it. This applies even if the regression came from a third-party component update.
How does the EAA define a substantial change to software?
The regulation does not provide a single definition, but the practical line is whether the update materially changes how users interact with the product. UI redesigns, major version upgrades, workflow overhauls, and platform migrations all qualify.
Do internal-only software tools fall under EAA software update rules?
The EAA covers products and services offered to consumers in the EU market. Internal enterprise tools generally fall outside its scope, though related employment and procurement laws may still apply depending on the jurisdiction.
Should accessibility documentation be updated with every release?
For minor releases, no. For substantial changes, yes. The documentation should reflect the current product, especially when audit reports or accessibility statements are referenced by buyers, regulators, or partners.
The takeaway is that software is not finished at first release, and neither is its accessibility obligation. Each update is a chance to maintain conformance or to lose it.
For help mapping EAA requirements to your release process, Contact Kris.