Managing EAA compliance for one app and one platform is workable when the scope is treated as two separate digital assets with their own audit, remediation, and documentation tracks. Each asset needs a WCAG 2.1 AA audit, a prioritized remediation plan, validation of fixes, and an accessibility statement that reflects the current state. The European Accessibility Act points to EN 301 549, which incorporates WCAG 2.1 AA as the technical standard for digital products. Two assets means two audit reports, two remediation cycles, and two statements, coordinated under one program.
| Item | Detail |
|---|---|
| Standard | EN 301 549, which references WCAG 2.1 AA |
| Assets in scope | One mobile app and one web platform, audited separately |
| Audit type | Fully (manual) audit per asset, scans flag approximately 25% of issues |
| Outputs | Two audit reports, two remediation cycles, two accessibility statements |
| Ongoing work | Re-evaluation after major releases, monitoring of new content |
What does the EAA actually require for an app and a platform?
The EAA requires that covered digital products and services meet accessibility requirements aligned with EN 301 549. For most teams shipping a consumer app and a web platform, that maps to WCAG 2.1 AA across both interfaces. The functional requirements cover perceivability, operability, understandability, and resilience for users with disabilities.
An app and a platform are treated as separate assets because the user environments differ. A native mobile app uses platform accessibility APIs, screen readers like VoiceOver and TalkBack, and gesture-based interaction. A web platform runs in a browser with different assistive technology behaviors. Each needs its own evaluation against the relevant criteria.
Step 1: Define scope for each asset
Scope is the foundation. For the app, scope covers the screens, flows, and components a real user touches: onboarding, core tasks, settings, account management, and any in-app purchase or transactional flows. For the platform, scope covers the templates, key authenticated pages, the dashboard, and any embedded components that serve unique functions.
Document the scope in writing before any audit work begins. Page or screen counts drive pricing, timeline, and the structure of the audit report. Ambiguous scope produces ambiguous results.
Step 2: Conduct a (manual) audit on each asset
A (manual) audit is the only way to determine WCAG conformance. Automated scans flag approximately 25% of issues and cannot evaluate context, meaning, or interaction patterns. An auditor reviews each screen and template against WCAG 2.1 AA, identifies issues, and produces a report with severity, location, and remediation guidance.
Two assets means two reports. Keep them separate. The app report references mobile-specific criteria and platform behaviors. The web platform report references browser-based interaction. Combining them creates confusion during remediation.
Step 3: Prioritize and remediate issues
Once both reports are delivered, prioritization determines what gets fixed first. Risk Factor or User Impact prioritization formulas help teams sequence work by severity, frequency, and the criticality of the affected user flow. High-impact issues on core flows take precedence over low-impact issues on secondary screens.
Remediation runs as two parallel tracks. Mobile developers address app issues. Web developers address platform issues. A shared tracker keeps both teams visible to leadership without merging the technical work.
Step 4: Validate the fixes
After developers complete remediation, an auditor validates each fix against the original report. Validation confirms that the issue is resolved and that no regressions were introduced. This step is what moves an organization from “we made changes” to “we can document conformance.”
Validation is not a re-audit. It checks the specific issues identified earlier. A re-audit happens later, after significant product changes or on a regular cadence.
Step 5: Publish accessibility statements and documentation
The EAA expects organizations to publish accessibility information about their products. Each asset gets its own accessibility statement reflecting the current state of conformance, known issues, and contact information for accessibility feedback. The app statement lives in the app store listing or in-app help. The platform statement lives on the website.
Internal documentation matters too. Audit reports, remediation logs, and validation records form the evidence trail if a regulator or a customer requests proof of conformance work.
How do you keep both assets compliant over time?
EAA compliance is not a one-time project. Apps ship updates. Platforms add features. New content goes live. Each release introduces the possibility of new issues.
Teams that stay ahead build accessibility into their release process: design reviews catch issues before development, developer training reduces the number of issues introduced, and a re-evaluation cadence (often annual or after major releases) keeps documentation current. Accessible.org and the Accessibility Tracker Platform support this kind of ongoing work by giving teams a place to track issues, validate fixes, and maintain conformance records across multiple assets.
What if the app and platform share a backend?
Shared backends do not change the audit approach. Accessibility is evaluated at the user interface layer. Two interfaces means two audits, even if the data and business logic are common.
Do you need separate accessibility statements for each asset?
Yes. Each asset has its own conformance state, its own known issues, and its own user environment. One statement covering both creates ambiguity and weakens the documentation. Two clear statements is the cleaner path.
How long does the full process take for one app and one platform?
Timelines vary by scope. Audits typically run a few weeks per asset. Remediation depends on developer capacity and the number of issues identified. Validation is faster than the original audit. A realistic full cycle, from kickoff to published statements, often runs three to six months when both assets are in active development.
Can the same auditor cover both the app and the platform?
One auditing team can cover both, which keeps reporting consistent and reduces coordination overhead. The auditors assigned to each asset should have direct experience with that environment: native mobile for the app, browser-based for the platform.
One app and one platform is a manageable EAA scope when the work is sequenced cleanly: audit, prioritize, remediate, validate, document. Treat each asset on its own track and the program stays clear from kickoff to published statement.
Contact Accessible.org to scope EAA compliance work for your app and platform: Contact Accessible.org.
