The EAA's compliance deadline for European Union member states was June 28, 2025, which means any team shipping to EU markets in 2026 is already past the grace period, not ahead of it. For a product team, the difference between "accessible" and "non-compliant" is a build checklist executed during development, not a remediation sprint added after a regulator or a user complaint forces the issue.
TL;DR
WCAG 2.1 added mobile-specific success criteria (1.3.4 Orientation, 2.5.1 Pointer Gestures, 2.5.4 Motion Actuation, 2.5.5 Target Size) that desktop-first teams routinely miss.
The EAA compliance deadline of June 28, 2025 already applies to apps serving EU users; this is enforcement territory in 2026, not future planning.
Enforcement is real and financial: a French court ordered Carrefour to fix its website and app accessibility within six months or face daily fines, and Germany's accessibility law allows fines of up to €100,000 for non-compliant digital services such as banking platforms that don't support screen readers.
WCAG 2.1 vs 2.2 is not a rewrite; 2.2 adds criteria on top of 2.1 rather than replacing it, so a 2.1-compliant app needs a gap check, not a redo.
Accessibility testing works best as checkpoints inside the sprint (design review, component build, pre-release QA), not a single pre-launch audit.
About the Author: 724SOFTWARE is a Vietnam-based engineering company that has delivered mobile apps into regulated and high-traffic environments, including a live mobile banking app, a derivatives trading platform across iOS, Android, Web, and Desktop, and a fan-engagement app with 500,000+ downloads under concurrent voting-traffic spikes. Building for EU and Australian clients means accessibility compliance is a standard line item in the build process, not a specialty add-on.
What Does WCAG 2.1 Actually Require for Mobile Apps?
WCAG 2.1 is the Web Content Accessibility Guidelines version that extended the original web-focused criteria to cover mobile interaction patterns directly. Before 2.1, teams building native apps had to interpret desktop-oriented guidelines and guess how they applied to touchscreens. WCAG 2.1 added success criteria written specifically for mobile:
1.3.4 Orientation: the app must work in both portrait and landscape unless a specific orientation is essential (a check-deposit camera view, for example).
2.5.1 Pointer Gestures: any function that uses a multi-point or path-based gesture (pinch-to-zoom, swipe-to-dismiss) needs a single-tap alternative.
2.5.4 Motion Actuation: features triggered by shaking or tilting the device need an on-screen control alternative, because not every user can perform or control that motion.
2.5.5 Target Size: interactive elements need a minimum touch target size so users with motor impairments or limited dexterity can hit the right control reliably.
These four criteria are the ones that surprise mobile-first teams, because they look like UX polish items rather than compliance requirements. They are both. A pinch-to-zoom gesture without a tap alternative is a usability gap for a user with limited hand mobility and a WCAG failure in the same line of code.
How Is WCAG 2.2 Different From 2.1, and Does It Replace It?
WCAG 2.1 vs 2.2 is a common point of confusion because the numbering suggests a replacement, when it is actually additive. WCAG 2.2 keeps every success criterion from 2.1 and adds new ones on top, largely around focus visibility, drag-and-drop alternatives, and further refinement of target size requirements. A team that built to 2.1 Level AA does not need to rebuild; it needs a gap analysis against the new 2.2 criteria and targeted fixes where they apply.
For a Vietnam engineering team building for clients in Australia or the EU, the practical takeaway is to build to 2.1 AA as the floor and track 2.2 as the direction regulators and procurement teams are already moving. Government and enterprise RFPs increasingly reference 2.2 by name, so treating it as "future work" rather than current scope is a planning risk, not a compliance one yet.
What Does the European Accessibility Act Require, and Who Does It Apply To?
The European Accessibility Act (EAA) requires digital products and services, including e-commerce platforms, banking apps, and consumer mobile apps, to be accessible to users with disabilities, using standards aligned with WCAG. The mandatory compliance deadline across EU member states was June 28, 2025, which means this is a live enforcement requirement in 2026, not an upcoming one. Foreign companies selling into the EU market, including SaaS vendors headquartered outside Europe, must meet these requirements before their product reaches EU users.
This matters beyond companies with an EU office. A fintech app built in Australia or the US but sold to EU customers falls under EAA scope the moment EU users can access it. The Act doesn't check where the company is incorporated; it checks where the product is used. Teams building for Western European buyers, including the Netherlands, Germany, and Finland, need to treat EAA compliance as a launch gate for any product with EU market reach, not a regional afterthought handled by a local office.
What Happens If a Mobile App Isn't Accessible? Is Enforcement Actually Happening?
Enforcement is documented and financial, not theoretical. A French court ordered Carrefour to fix its website and mobile app accessibility within six months or face daily fines. In Germany, the national accessibility law implementing the EAA allows for fines of up to €100,000 for non-compliant digital services, a penalty that would apply to failures like an online banking platform that doesn't support screen readers. These aren't warning letters; they're court orders and statutory penalties attached to specific, identifiable failures: a missing accessible alternative, a screen reader that couldn't parse the interface.
The pattern across both cases is the same: the failure was structural, not cosmetic. Carrefour's issue wasn't a missing alt-text tag here and there; it was systemic enough that a court set a hard deadline. A screen-reader failure on a banking platform means blind and low-vision users could not complete core banking tasks at all. These are the kinds of gaps that WCAG's success criteria, built into development from the start, are designed to catch before a regulator does.
How Should Accessibility Testing Fit Into the Mobile Development Lifecycle?
Accessibility testing works best distributed across the build, not concentrated in one pre-launch audit. A single end-of-project accessibility sweep tends to surface structural issues, like a navigation pattern that relies entirely on gesture, at the point where fixing them means reworking a shipped component. The more effective approach is three checkpoints:
Design review: color contrast ratios, touch target sizing, and orientation support get checked against WCAG criteria before a single screen is built.
Component-level build: screen reader labels, focus order, and gesture alternatives get verified as each component is developed, using automated accessibility testing services alongside manual screen-reader testing (VoiceOver on iOS, TalkBack on Android).
Pre-release QA: a full pass against WCAG 2.1 AA (or 2.2 where applicable) and, for EU-facing products, EAA-specific checks, run as a release gate alongside functional and security testing.
Automation testing and security testing are built into the delivery pipeline as standard QA stages, not optional add-ons requested late. Mobile app accessibility testing fits the same model: the cost of a gesture-only interaction pattern discovered in week 2 of design is a design change; discovered in week 10 of a shipped app, it's a re-architecture.
Frequently Asked Questions
Does WCAG apply to native mobile apps, or only websites?
WCAG 2.1 explicitly extends to native mobile apps through mobile-specific success criteria like Pointer Gestures and Target Size, alongside the general guidelines that originated for web content.
What's the real difference between WCAG 2.1 and 2.2 for a team already compliant with 2.1?
WCAG 2.2 adds criteria on top of 2.1 rather than replacing them, so a 2.1 AA-compliant app needs a gap check against the new criteria, not a rebuild.
Does the EAA apply to a company with no office in the EU?
Yes. The EAA applies based on where the product is accessed by users, not where the company is incorporated, so any mobile app with EU users falls under its requirements.
Is ADA mobile app compliance the same as WCAG compliance?
ADA compliance for mobile apps in the US is generally assessed against WCAG success criteria in practice, though the ADA itself doesn't name a specific technical standard the way the EAA does.
Can accessibility testing be automated, or does it need manual testing too?
Automated accessibility testing services catch a meaningful share of issues (contrast ratios, missing labels) efficiently, but gesture alternatives, screen reader flow, and real usability still need manual testing with assistive technology.
Does a Vietnam IT company have the expertise to build EAA and WCAG-compliant apps for EU clients?
Accessibility compliance is a development standard, not a geography-dependent skill; a Vietnam IT company building for Fintech and Healthcare clients applies the same WCAG and EAA checklists as any team building for those sectors.
What's the cost of fixing accessibility gaps after launch versus building them in?
Exact remediation costs vary by the scope of the gap and the platform, but structural fixes (like replacing a gesture-only interaction with a tap alternative) are consistently more expensive post-launch because they touch shipped components and require regression testing across the existing user base.
About 724SOFTWARE
724SOFTWARE is a Vietnam-based engineering company delivering mobile app development for clients in Australia, Singapore, the UK, and across SEA/APAC, with a growing presence serving the Netherlands, Germany, and Finland. The team has built regulated, high-traffic mobile products where compliance requirements including accessibility, security, and data protection are part of the standard build process. 724SOFTWARE is aligned with ISO 9001 and ISO 27001:2022 standards and is GDPR compliant, and operates a follow-the-sun delivery model with under 10-minute incident response for clients working across time zones. Teams scale from 1 to 50+ pre-vetted engineers within 2 to 4 weeks, giving clients a dedicated team or embedded staff augmentation model without rebuilding a hiring pipeline from scratch.
If your mobile app needs to meet WCAG 2.1 (or 2.2) and EAA requirements before it reaches EU or Australian users, contact 724SOFTWARE at https://724software.com.vn to discuss what accessibility testing looks like inside your existing development timeline.
