EN 301 549 V4.1.1: was sich geändert hat und welche Version weiterhin zählt
Die Norm hinter dem European Accessibility Act hat eine neue Version, veröffentlicht im September 2026. Sie nimmt WCAG 2.2 in den Software-Abschnitt auf. Die Version, auf die das Gesetz verweist, ist allerdings weiterhin V3.2.1 aus dem Jahr 2021. Hier steht der Unterschied, Anforderung für Anforderung, und wofür eine Prüfung einer mobilen App heute einstehen muss.
Auf welche Version das Gesetz verweist
Eine Norm wird zur rechtlichen Bezugsgröße, wenn ihre Fundstelle im Amtsblatt der Europäischen Union veröffentlicht ist. Erst das lässt die Einhaltung der Norm die Vermutung tragen, dass auch das Gesetz eingehalten ist. Für die EN 301 549 ist die zitierte Version V3.2.1 von März 2021, die WCAG 2.1 Stufe AA enthält.
V4.1.1 ist im September 2026 veröffentlicht worden. Zitiert ist sie bis heute nicht, also ändert sie von sich aus keine Pflicht. AccessibleEU, das Zentrum der Kommission selbst, hat am 7. September 2026 gesagt, dass die geltende Bezugsgröße V3.2.1 bleibt, bis die Fundstelle veröffentlicht ist.
Nationale Texte gehen zu einem dynamischen Verweis über statt zu einer festen Version. In Frankreich hat das décret n° 2026-816 vom 24. August 2026 das ältere Dekret so umgeschrieben, dass ein Dienst barrierefrei ist, wenn er den harmonisierten Normen entspricht, deren Fundstellen im Amtsblatt veröffentlicht sind. Ändert sich die Fundstelle, folgt die Pflicht ihr ohne ein weiteres Dekret.
Die praktische Folge für jede Prüfung heute: Ein Bericht, der nur für V4.1.1 einsteht, antwortet nicht auf die Frage, die das Gesetz stellt, und ein Bericht, der nur für V3.2.1 einsteht, lässt WCAG 2.2 aus. Beide Versionen müssen in der Tabelle stehen.
Was Abschnitt 11 hinzugewonnen hat
Abschnitt 11 ist der Software-Teil, der für eine mobile App gilt. In V4.1.1 enthält er die 50 Kriterien der WCAG 2.2 in den Stufen A und AA, die auf Software anwendbar sind, gegenüber WCAG 2.1 in V3.2.1.
Sieben Anforderungen in Abschnitt 11 haben keine Entsprechung in V3.2.1. Fünf kommen aus WCAG 2.2: 11.2.4.11 Focus not obscured (minimum), 11.2.5.7 Dragging movements, 11.2.5.8 Target size (minimum), 11.3.3.7 Redundant entry und 11.3.3.8 Accessible authentication (minimum). Zwei waren in V3.2.1 einfach nicht belegt und sind jetzt Anforderungen: 11.2.4.2, das WCAG 2.4.2 als Non-web software titled übernimmt, und 11.3.2.4 Consistent identification.
Davon ist 11.2.5.8 diejenige, die das Ergebnis der meisten Prüfungen mobiler Apps ändert. Ein Touch-Ziel unter 24 mal 24 war unter WCAG 2.1 eine Empfehlung und ist unter 2.2 ein Verstoß, und zu kleine Ziele sind der Mangel, den unsere eigenen Prüfungen am häufigsten finden.
Ein Kriterium der WCAG 2.2 hat es nicht in den Software-Abschnitt geschafft: 3.2.6 Consistent help. Abschnitt 11.3.2.6 ist nicht belegt, eine App wird hier also nicht daran gemessen.
Was weggefallen ist und was nur verschoben wurde
Parsing ist weg. WCAG 2.2 hat das Kriterium 4.1.1 gestrichen, und damit ist die Anforderung 11.4.1.1.1 aus V3.2.1 entfallen. Wenn ein älterer Bericht eine App an Parsing scheitern lässt, gibt es diesen Befund nicht mehr.
Die Anforderungen an die Dienste für Barrierefreiheit selbst sind neu gefasst. V3.2.1 verlangte von Software, die dokumentierten Barrierefreiheitsdienste der Plattform zu nutzen (11.5.2.3), und von Plattformen, sie bereitzustellen (11.5.2.1, 11.5.2.2). In V4.1.1 ist 11.5.2.3 eine Empfehlung und 11.5.2.2 nicht belegt, während die Pflicht der Plattform einmal in 11.5.2.1 steht.
Die Autorenwerkzeuge sind aus Abschnitt 11 in Abschnitt 5 gewandert: Die fünf Anforderungen 11.8.1 bis 11.8.5 heißen jetzt 5.10.1 bis 5.10.5, mit denselben Titeln.
Dokumentation und Support sind neu geordnet. Aus 12.1.1, 12.1.2, 12.2.2, 12.2.3 und 12.2.4 in V3.2.1 sind 12.1, 12.2 und 12.3 geworden, dazu kommen elektronische Programmführer als 12.4 und 12.5.
Abschnitt 6, für Apps mit Telefonie, ist um betriebliche Szenarien herum neu geschrieben (6.0.2 bis 6.0.9), und seine Anforderungen an Echtzeit-Text sind umnummeriert und umbenannt. Abschnitt 7 sagt jetzt subtitles, wo V3.2.1 captions sagte.
Die Falle sind Nummern, die eine Umnummerierung überlebt haben. In V3.2.1 ist 6.2.3 Interoperability; in V4.1.1 steht dieselbe Nummer für DTMF touch-tone generation during RTT operations. Eine Zuordnungstabelle muss Anforderungen abgleichen, nicht Nummern.
Wofür eine Prüfung heute einstehen muss
Zählt man die Anforderungen, die eine native mobile App erfüllen oder verfehlen kann, steht unser Prüfverfahren für 144 von ihnen ein: die Anforderungen der V4.1.1 aus den Abschnitten 5, 6, 7, 11 und 12 sowie die 19 Anforderungen der V3.2.1, die in V4.1.1 keine identische Entsprechung haben und weiterhin zu der Version gehören, die das Gesetz zitiert.
Jede Anforderung wird von Hand an den Bildschirmen aus dem Bericht geprüft, mit den Screenreadern der Testumgebung, die darin genannt ist. Automatische Prüfungen laufen daneben und zeigen auf die Codezeile, aber sie stehen für einen Teil der Liste ein, nicht für die ganze.
Der Bericht nennt den Abschnitt in beiden Nummerierungen, damit dasselbe Dokument einer Aufsicht antwortet, die V3.2.1 liest, und einem Team, das sich auf V4.1.1 vorbereitet.
Oder lassen Sie den ganzen Build prüfen: Die Store-Prüfung kostet 190 €, 2 Arbeitstage.