On this page · 10 sections
Summary. The European Accessibility Act, Directive (EU) 2019/882, has applied since 28 June 2025, and EU member states had to transpose it into national law by June 2022. WCAG 2.2 became a W3C Recommendation on 5 October 2023 and adds 9 success criteria over WCAG 2.1, of which 6 sit at Level A or AA. The current European harmonised standard is EN 301 549 V3.2.1, published in March 2021, and ETSI published draft V4.1.0 in November 2025. Here is the part most Indian SaaS companies get wrong: the EAA's covered list runs to 10 product and service categories, and a typical B2B SaaS tool is not on it. You are probably not in legal scope. Your European buyer's procurement questionnaire does not care.
That gap between legal scope and commercial scope is the whole subject of this article. Get it right and accessibility work becomes a targeted, finite project. Get it wrong and you either fail deals you could have won, or you spend a quarter chasing a regulation that never applied to you.
First question: are you actually in scope?
The European Commission publishes the covered list, and it is specific rather than general. The EAA covers computers and operating systems; ATMs, ticketing and check-in machines; smartphones; TV equipment related to digital television services; telephony services and related equipment; access to audio-visual media services; services related to air, bus, rail and waterborne passenger transport; banking services; e-books; and e-commerce.
Read that list against your product. A project management tool sold to European engineering teams is not on it. A payroll platform is not on it. An analytics dashboard is not on it. E-commerce is on it, so if you run a storefront selling into the EU, you are in scope directly. Banking services are on it, so a fintech serving EU consumers is in scope. Everything else needs a specific argument rather than an assumption.
There is a second exclusion worth knowing. Microenterprises providing services, meaning businesses with fewer than 10 employees, are exempt from the Act's obligations, though the Commission encourages them to make products and services accessible anyway. Very few companies reading this will qualify, and it is not a position to build a strategy on.
Enforcement runs through member states rather than Brussels. Each state designates its own authorities, and the Commission runs an expert group of national administrations, market surveillance authorities, civil society organisations and accessibility experts to coordinate application. The practical consequence for a company selling across several countries is that there is no single regulator to satisfy and no single clearance to obtain.
| Rule | Who it binds | What it means for an Indian SaaS vendor |
|---|---|---|
| European Accessibility Act, Directive (EU) 2019/882 | Economic operators placing the 10 listed product and service categories on the EU market | Direct obligation only if you are e-commerce, banking, transport, e-books or the listed hardware categories |
| Web Accessibility Directive, Directive (EU) 2016/2102 | Public sector bodies' websites and mobile applications | No direct obligation, but it is why EU public-sector buyers demand EN 301 549 evidence from suppliers |
| EN 301 549 | The harmonised standard referenced for conformance | The document your buyer's questionnaire will actually name, whichever directive drove it |
| EU AI Act, Article 50(5) | Providers and deployers giving AI transparency notices | From 2 August 2026 your AI disclosures must themselves meet accessibility requirements |
| Rights of Persons with Disabilities Act 2016, section 42 | Appropriate government bodies in India | The domestic duty behind Indian public-sector and government-adjacent procurement |
| Contractual accessibility warranties | Whoever signs the MSA | The real driver for most B2B vendors, and enforceable regardless of statutory scope |
The bottom row is the one that closes deals. Most Indian SaaS companies meet accessibility as a contract clause and a security-questionnaire sibling, not as a regulator's letter.
The question that matters more than scope
Procurement teams do not run a legal scope analysis on their suppliers. They send a questionnaire. That questionnaire asks for a conformance statement against WCAG at a stated level, often an accessibility statement URL, and increasingly an audit report with a date on it. If your answer is "the EAA does not apply to us", you have answered a question nobody asked and the deal stalls in review.
This is why we tell clients to treat accessibility as a sales-enablement artefact first and a compliance artefact second. The work is the same. The framing determines whether it gets funded.
EN 301 549 and where WCAG sits inside it
EN 301 549, "Accessibility requirements for ICT products and services", is the European standard that defines what ICT products and services must do to be usable by people with disabilities. The current published version is V3.2.1, dated March 2021. It supports Directive (EU) 2016/2102, the Web Accessibility Directive, and has done so since August 2021 under Commission Implementing Decision (EU) 2021/1339.
Two structural facts matter when you read it. First, EN 301 549 is broader than WCAG: it organises testable criteria across clauses 5 to 13 covering hardware, software, documentation and support services, with conformance procedures in clause 14. WCAG covers web content; EN 301 549 covers the product around it. If you ship a desktop client, a mobile app and a support portal, WCAG conformance on the marketing site answers a fraction of the standard.
Second, the version question is live. ETSI published draft EN 301 549 V4.1.0 in November 2025. Until a new version is cited in the Official Journal, V3.2.1 remains the published harmonised version. That creates a practical planning question: do you certify against the standard as it stands, or build to WCAG 2.2 now so the next version does not reopen the work?
Our answer to clients is to build to WCAG 2.2 Level AA regardless. The incremental cost over 2.1 is small, the six new A and AA criteria are cheap to satisfy at design time and expensive to retrofit, and no buyer has ever rejected a supplier for exceeding the asked-for level.
The 6 WCAG 2.2 criteria that create new work
WCAG 2.2 adds nine success criteria over WCAG 2.1 and removes one: 4.1.1 Parsing is obsolete and removed from 2.2. Of the nine additions, three sit at Level AAA, which almost no commercial programme targets. That leaves six at Level A or AA. These are the ones that will appear in an audit against a 2.2 baseline.
| New criterion in WCAG 2.2 | Level | What it means in your codebase |
|---|---|---|
| 2.4.11 Focus Not Obscured (Minimum) | AA | Sticky headers, sticky footers and cookie bars must not entirely hide the focused component |
| 2.5.7 Dragging Movements | AA | Every drag interaction needs a single-pointer alternative unless dragging is essential; kanban boards and sliders are the usual offenders |
| 2.5.8 Target Size (Minimum) | AA | Pointer targets at least 24 by 24 CSS pixels, or spaced so 24-pixel circles centred on them do not intersect, with inline and essential exceptions |
| 3.2.6 Consistent Help | A | If a help mechanism repeats across pages, it must keep the same relative order in the page |
| 3.3.7 Redundant Entry | A | Do not ask for the same information twice in one process; auto-populate it or let the user select it |
| 3.3.8 Accessible Authentication (Minimum) | AA | No cognitive function test in login unless an alternative or mechanism exists; supporting password-manager paste satisfies it |
Three of these predict where a real audit will find failures in a modern SaaS product. Dragging Movements catches drag-and-drop boards and reorderable lists, which are now standard in project tools. Target Size catches dense data tables with icon-only row actions. Accessible Authentication catches login flows that block paste on the password field, which teams often add deliberately as a security measure and which the criterion treats as a barrier. That last one is a one-line fix and a genuinely useful conversation with your security team.
The three AAA additions, for the record, are 2.4.12 Focus Not Obscured (Enhanced), 2.4.13 Focus Appearance, and 3.3.9 Accessible Authentication (Enhanced). 2.4.13 is worth reading even if you are not targeting AAA, because it gives a concrete definition of an adequate focus indicator: an area at least as large as a 2 CSS pixel thick perimeter of the component, with a contrast ratio of at least 3:1 between focused and unfocused states. Designers asking "how visible does focus need to be" now have a number.
What an audit that survives procurement contains
A buyer's reviewer is checking whether your report is evidence or marketing. The difference is visible in about thirty seconds.
An audit worth paying for states its scope as a list of URLs, screens and user journeys, not "the application". It names the standard and version, EN 301 549 V3.2.1 or WCAG 2.2 Level AA, rather than "accessibility guidelines". It names the assistive technology and browser pairings tested, because a screen-reader result is meaningless without them. It separates automated findings from manual findings, since automated tooling reliably detects only a minority of issues and a report that is entirely automated output tells a reviewer you did not do the work. It records each failure against a specific success criterion number. And it dates itself.
The other half is the accessibility statement. It should describe conformance honestly, list known issues, give a feedback mechanism, and say what is planned. A statement that claims full conformance with no known issues reads as untested to anyone experienced, because every real product of any size has open items.
| Approach | What you actually get | Where it fails |
|---|---|---|
| Automated scanner only | Fast, cheap, catches contrast, missing alt text, form labels, landmark structure | Misses keyboard traps, focus order, screen-reader semantics and every one of the six new WCAG 2.2 A and AA criteria in part |
| Overlay or accessibility widget | A visible badge and a fast answer to a questionnaire | Does not change the underlying markup; experienced reviewers and disability organisations treat it as a red flag rather than evidence |
| Manual audit against WCAG 2.2 AA | Criterion-level findings with reproduction steps and assistive technology pairings | Costs real time; produces a backlog somebody then has to fund |
| Audit plus remediation plus regression tests | Fixed product, plus automated checks that stop regressions returning | Requires engineering capacity, not just a report |
| Design-system-level remediation | Fixes propagate to every screen using the component | Slower to start; needs a real design system rather than a component folder |
The last row is where the economics change. If your focus rings, target sizes and form patterns live in a shared component library, a single fix closes the same finding across 200 screens. If they were hand-rolled per screen, you pay for each one. This is the honest reason accessibility remediation costs vary so widely between two apparently similar products, and it is worth knowing before you scope a budget.
The real cost is almost never the audit. It is the backlog the audit creates.
How we approach it
eCorpIT runs this as four phases, and we will tell you at the end of the first one if the rest is unnecessary.
Scope determination. We check your product against the EAA's covered categories, the directives your buyers actually cite, and your existing contractual commitments. The output is a short memo saying whether you have a legal obligation, a commercial one, or both. Some clients stop here, correctly.
Baseline audit. Manual testing against WCAG 2.2 Level AA, mapped to EN 301 549 clauses where a buyer needs that mapping, on an agreed list of journeys rather than a vague "the app". Findings carry criterion numbers, reproduction steps, tested browser and assistive technology pairings, and severity.
Remediation. Fixes land in the design system first where one exists, because that is where they multiply. We work inside your repositories and your review process, alongside the team that will maintain the result.
Regression protection. Automated accessibility checks in CI catch the mechanical regressions, paired with a short manual checklist for the things tooling cannot see. Without this step, the next release reopens findings you already paid to close, which is the most common way accessibility budgets get spent twice.
We design applications aligned with EN 301 549 and WCAG 2.2 requirements, and we write accessibility statements that describe your actual conformance position. We do not claim to certify anyone, because no consultancy can: conformance is a property of your product, evidenced by testing, not a badge a vendor issues.
Teams building a new product rather than retrofitting one should fold this into the build, which is what we do on SaaS MVP development engagements and custom web application builds. Regression protection usually lands alongside broader QA and test automation work. For the regulatory background on the EAA itself, our earlier analysis of the European Accessibility Act and WCAG 2.2 audit path for Indian SaaS goes deeper on the directive.
India-specific considerations
Indian companies have a domestic duty that predates the European one and is frequently overlooked. The Rights of Persons with Disabilities Act 2016 addresses access to information and communication technology, with section 42 placing obligations on appropriate government bodies to ensure ICT is accessible to persons with disabilities.
For teams selling to Indian government and public-sector buyers, the operative document is GIGW, the Guidelines for Indian Government Websites, now at version 3.0, issued by the National Informatics Centre under the Ministry of Electronics and Information Technology. GIGW 3.0 aligns with WCAG 2.1 Level AA and covers quality, accessibility, cybersecurity and lifecycle management for government websites and apps.
The planning consequence is straightforward. A team building to WCAG 2.2 Level AA for European buyers already exceeds the WCAG 2.1 Level AA baseline that GIGW 3.0 references, since the 2.0 and 2.1 criteria carry into 2.2 essentially unchanged apart from the removal of 4.1.1 Parsing. One programme, two markets. Sequencing it the other way, building to 2.1 for India and then upgrading for Europe, means paying for the same regression testing twice.
One further overlap is arriving. From 2 August 2026, Article 50(5) of the EU AI Act requires that AI transparency notices conform to applicable accessibility requirements. If your product ships an AI feature with a disclosure banner, that banner is now in both workstreams, as our guide to Article 50 machine-readable AI content marking sets out.
FAQ
How eCorpIT can help
eCorpIT is a Gurugram-based technology consultancy, founded in 2021, CMMI Level 5 and MSME certified, with senior-led engineering teams building web and mobile products for clients in India, Europe and the United States. We run scope determination, manual WCAG 2.2 Level AA audits mapped to EN 301 549, design-system-level remediation inside your repositories, and CI regression checks that stop findings reopening. We will tell you after the scope memo if you do not need the rest. If a European buyer has sent you an accessibility questionnaire and you are not sure what an honest answer looks like, talk to our team.
References
- European Accessibility Act (EAA), European Commission — covered products and services, implementation and the expert group.
- Directive (EU) 2019/882 on the accessibility requirements for products and services — the European Accessibility Act itself.
- The EAA comes into effect in June 2025, AccessibleEU — the 28 June 2025 application date and the microenterprise exemption.
- A new era for inclusion begins: the EAA enters into force, AccessibleEU — status at entry into application.
- What's New in WCAG 2.2, W3C Web Accessibility Initiative — the nine new success criteria, their levels, and the removal of 4.1.1 Parsing.
- Web Content Accessibility Guidelines (WCAG) 2.2, W3C Recommendation — the normative text of the success criteria.
- EN 301 549 V3.2.1 (2021-03), ETSI — the published harmonised European standard for ICT accessibility.
- Draft EN 301 549 V4.1.0 (2025-11), ETSI — the draft revision published in November 2025.
- EN 301 549 V3, the harmonised European Standard for ICT accessibility, ETSI — scope, clause structure and the link to Directive (EU) 2016/2102.
- Web Accessibility Directive: standards and harmonisation, European Commission — the public sector directive that drives much supplier questioning.
- Guidelines for Indian Government Websites (GIGW) 3.0 — features and roadmap for the Indian government web and app guidance.
- GIGW 3.0, DBIM Toolkit — the guidelines document issued under MeitY.
- Article 50: Transparency Obligations for Providers and Deployers of Certain AI Systems — Article 50(5) and its accessibility requirement, applying from 2 August 2026.
Last updated 20 July 2026.
