Run One Accessibility Audit That Satisfies EN 301 549 v4.1.1 and Turkey's 2025/10 Circular

Run One Accessibility Audit That Satisfies EN 301 549 v4.1.1 and Turkey's 2025/10 Circular

ETSI published EN 301 549 V4.1.1 on 2 September 2026, after formal adoption on 24 August 2026. It moves the European ICT accessibility standard from WCAG 2.1 to WCAG 2.2, adds six success criteria, voids one, and reworks the user-preference clauses. It is not yet cited in the Official Journal, so the legally referenced version is still V3.2.1. At the same time, Turkish e-commerce service providers covered by Presidential Circular 2025/10 have until roughly June 2027 to pass a WCAG 2.2 Level A checklist. If you run audits for organisations that sell in both markets, you now have three moving baselines and one test budget. This is the seven-step process we use to re-baseline an existing audit without discarding the evidence you already paid for.

What changed in V4.1.1, and what did not

Six WCAG 2.2 criteria enter clauses 9 (web), 10 (non-web documents) and 11 (non-web software); they are listed with test methods in step 2 below. SC 4.1.1 Parsing is marked void, matching its removal from WCAG 2.2. New user-preference subsections appear at 9.7, 10.7 and 11.7. Clause 6 real-time text requirements are substantially extended. Annex ZB and clause A.2 map requirements to the European Accessibility Act for the first time.

What did not change: the legal position. V4.1.1 has no effect until the Commission cites it in the Official Journal. Deque expects that citation around the end of November 2026, but that is a forecast, not a published date. Until it happens, V3.2.1 (WCAG 2.1 AA) remains the reference.

Correct the record on "EN 301 549 means EAA compliance"

The claim is repeated constantly by vendors and it is not currently supportable. V3.2.1 was harmonised on 12 August 2021 under the Web Accessibility Directive (2016/2102), by Implementing Decision 32021D1339. Article 15 of the EAA grants presumption of conformity only to standards cited in the Official Journal in support of Directive 2019/882, and none has been cited there yet. The standard's own foreword points at the 2016 Directive.

Practical consequence: in EAA scope your audit is evidence, not a shield. Map findings to Annex I directly and keep dated records. Under the Web Accessibility Directive the presumption is real, and V3.2.1 is what confers it.

The three baselines you are actually measured against

InstrumentWho it coversTechnical referenceLevelPresumption of conformity?
Web Accessibility Directive (EU) 2016/2102EU public sector bodiesEN 301 549 V3.2.1WCAG 2.1 AAYes, cited in the OJ
European Accessibility Act (EU) 2019/882E-commerce, banking, transport, e-books, telecoms sold into the EUNo harmonised standard cited yetAnnex I requirementsNo
Türkiye Circular 2025/10 (RG 21 June 2025, no. 32933)Public bodies, municipalities, banks, private hospitals, Group A travel agencies, larger telecoms, e-commerce providers under Law 6563Ministry checklist, 31 principles / 122 questions, aligned to WCAG 2.2Level AAccessibility Logo, valid 2 years

Note the asymmetry a Turkish retailer selling into Germany faces: Level A on a national checklist, Level AA on the EU technical reference, and an EU legal test that is neither. Test to the union, not the intersection.

Step 1. Freeze your V3.2.1 evidence before you touch the script

Snapshot the current audit as a dated, versioned artefact: clause list, test date, tool versions, page sample, pass/fail per criterion. You will need it if a regulator asks what you knew and when. Do not edit it in place; everything from here is a new baseline sitting beside the old one.

Step 2. Add the six new criteria to your test script

Each of these is cheap to test and expensive to fix late, because most failures live in the design system rather than in individual pages.

CriterionLevelHow we test itPass thresholdMost common failure
2.4.11 Focus Not Obscured (Min)AATab through every template at 320px and 1280px, with sticky elements presentFocused element never entirely hiddenSticky header or cookie bar covering the focused field
2.5.7 Dragging MovementsAAAttempt every drag interaction with single clicks or taps onlyEvery drag has a non-drag pathImage gallery carousels, range sliders, map pins
2.5.8 Target Size (Min)AAMeasure interactive targets in devtools24 x 24 CSS px, or qualifying spacing exceptionIcon-only buttons, quantity steppers, close buttons
3.2.6 Consistent HelpACompare help entry points across five templatesSame relative order on every page that offers helpChat widget floats to a different corner per template
3.3.7 Redundant EntryAComplete a full checkout and count re-typed fieldsNo re-entry unless essentialBilling address retyped after shipping address
3.3.8 Accessible Authentication (Min)AAAttempt login and OTP flows with a password manager and paste enabledNo cognitive function test without an alternativePaste blocked on OTP fields, image puzzle CAPTCHA

Fix order: 2.5.8 and 2.4.11 first, since they are component-level and one change clears hundreds of instances. Then 3.3.8, because it blocks the whole funnel for affected users. 3.2.6 and 3.3.7 are flow decisions that need a product owner in the room.

Step 3. Retire 4.1.1 Parsing findings without deleting them

Mark existing 4.1.1 findings as superseded, with the date and the reason, rather than removing them. Two reasons. Clients still on WCAG 2.0 or 2.1 contracts are still tested against it. And duplicate IDs or unclosed elements that you logged under 4.1.1 usually still cause real failures under 1.3.1, 4.1.2 or name-role-value checks. Re-file the defect, do not drop it.

Step 4. Test the user-preference clauses

Clauses 9.7, 10.7 and 11.7 ask whether your interface respects settings the user already expressed at browser or platform level. Five checks: browser default font size at 200% and text scales; reduced motion and animations stop; forced dark mode and contrast holds; custom text or background colour and content stays readable; increased letter and word spacing and nothing clips. Each is a five-minute test, and each routinely fails on sites that pass every other AA criterion.

Step 5. Map findings to EAA Annex I, not only to clause numbers

With no cited harmonised standard for the EAA, a report organised purely by clause number does not answer what a market surveillance authority will ask. Add a column to the findings register: which Annex I requirement the finding bears on, and what evidence shows it is met. Dull work, and the part that holds up.

Step 6. Score the Turkish Level A checklist separately

Do not assume WCAG 2.2 AA conformance clears the Ministry checklist. It is a separate instrument of 31 principles and 122 questions, administered by a monitoring commission chaired by the Ministry of Family and Social Services, with a two-year Accessibility Logo as the reward and public disclosure as the sanction. Score it as its own pass, and record which question each piece of evidence answers.

Step 7. Rewrite the accessibility statement and set a review date

Name the version tested (V3.2.1 today, V4.1.1 once cited), the date, the sample, known non-conformances with target dates, and a feedback channel. Set a review for the month after the expected OJ citation; if the citation slips, the review still happens and you re-date the statement.

Worked example: a travel booking flow

A Group A online travel agency sells to Turkish and EU customers. Step 2 finds 24 x 24 failures on date-picker day cells and passenger-count steppers, a drag-only price slider, and paste blocked on the SMS code field. Step 4 finds the date picker collapses at 200% text. Step 5 files all of it against Annex I. Step 6 shows the Level A checklist passes the slider (an AA criterion) but fails the date picker on labelling. Result: one design-system ticket, one auth ticket, one component rebuild — three tickets instead of forty page-level defects. [INTERNAL DATA NEEDED: Switas median count of AA failures cleared per design-system component change, from the 2026 audit set]

Where this breaks down

  • Timing risk. The OJ citation date for V4.1.1 is a forecast. If it slips past your audit window you will have tested to a standard that is not yet the legal reference. That is a defensible position, but say so in the report.
  • Deadline precision. The 2025/10 periods summarised here come from secondary legal summaries; the Resmî Gazete text is the controlling document and should be read before you put a date in a client contract.
  • Not a certification. Nothing here produces a legally binding declaration, only defensible evidence.
  • Clause 6 is out of scope. If your client ships real-time text, voice or video calling, the extended clause 6 requirements need a specialist pass that this playbook does not cover.
  • Tooling covers little of this. Of the six new criteria, only target size is reliably machine-detectable. The rest are manual.
  • Transposition varies. Enforcement bodies, penalties and reporting formats differ by member state; check the market you actually sell into.

Frequently asked questions

Marked for FAQPage schema.

Should we test to V3.2.1 or V4.1.1 right now?
Both. V3.2.1 is the cited reference under the Web Accessibility Directive; V4.1.1 is where you will be measured within months. The six extra criteria cost a fraction of a full audit.

Does conforming to EN 301 549 make us compliant with the European Accessibility Act?
Not automatically. No harmonised standard has yet been cited in the Official Journal for Directive 2019/882, so there is no presumption of conformity. Conformance is strong evidence, not a legal shield.

We are outside the EU. Does the EAA apply?
It applies to products and services placed on the EU market, not to where the company sits. A Turkish retailer shipping to EU consumers is in scope.

Is there a microenterprise exemption?
Service providers under 10 employees and EUR 2 million turnover are exempted from the service requirements. Verify against Article 4 and your national transposition before relying on it.

Does Turkey's circular require Level AA?
The Ministry checklist is scored at Level A, aligned to WCAG 2.2. If you also sell into the EU you need AA regardless, so plan to AA and report Level A separately.

What happens if we miss the Turkish deadline?
The mechanism is an Accessibility Logo for compliant organisations and public disclosure for the rest. Reputational rather than financial, which for consumer brands is not necessarily milder.

Can an overlay close these six criteria?
No. Target size, dragging alternatives and authentication are structural. An overlay cannot change a component's hit area or remove a cognitive function test from a login.

How long does a re-baseline take?
For one e-commerce template set, budget two to four days of testing plus remediation. The variable is how centralised the design system is, not the page count.

Run the re-baseline

Run steps 1 to 7 on your own checkout and login flows; those two journeys carry most of the six new criteria. If you would rather have it done and documented against Annex I and the Turkish checklist in one pass, our accessibility practice at wcag.switas.com runs exactly this audit.

Sources


Çağdaş Polat
Written by

Çağdaş Polat

Çağdaş Polat is Co-Founder of Switas, where he leads technology and growth consulting for brands across e-commerce, travel, healthcare, and the public sector. A computer science graduate who moved from software development into senior marketing, product, and strategy roles over the past decade, he now advises companies on CRO, analytics, and building growth systems that hold up under measurement.


Related Articles

Switas As Seen On

Magnify: Scaling Influencer Marketing with Engin Yurtdakul

Check Out Our Microsoft Clarity Case Study

We highlighted Microsoft Clarity as a product built with practical, real-world use cases in mind by real product people who understand the challenges companies like Switas face. Features such as rage clicks and JavaScript error tracking proved invaluable in identifying user frustrations and technical issues, enabling targeted improvements that directly impacted user experience and conversion rates.