Die WCAG 2.2 AA Checkliste für Shopify-Stores

WCAG 2.2 AA ist die Version und Stufe, auf die sich mittlerweile fast alle Gesetze zur Barrierefreiheit beziehen, und das Ziel, das wir für jeden Shopify-Store empfehlen. Dies ist eine praktische Checkliste: die wichtigsten Erfolgskriterien, gegliedert nach den vier POUR-Prinzipien, und jeweils dort zugeordnet, wo das Problem tatsächlich in einem Shopify-Theme auftritt.

Einmal nach WCAG 2.2 AA umsetzen, und du erfüllst gleichzeitig die älteren Regelwerke. WCAG 2.2 ist ein Superset von 2.1 – wer diese erfüllt, erfüllt also auch den US-ADA-Vergleichsstandard, die europäische EN 301 549 (WCAG 2.1 AA) sowie die britischen, kanadischen und australischen Vorschriften. Ein einziger Arbeitsgang deckt sie alle ab.

Das Wichtigste in Kürze

• WCAG 2.2 AA ist der aktuelle rechtliche Maßstab. Die Erfüllung davon deckt auch WCAG 2.1 AA und alle darauf aufbauenden Regelungen ab.
• Konformität mit Stufe AA bedeutet, dass jedes Erfolgskriterium der Stufe A und jedes der Stufe AA erfüllt wird. AAA-Kriterien sind nicht erforderlich.
• WCAG 2.2 hat gegenüber 2.1 neun Erfolgskriterien hinzugefügt und eines entfernt (4.1.1 Parsing). Sechs der neun liegen auf Stufe A oder AA.
• Automatisierte Scanner erkennen nur etwa 30 bis 40 % der Kriterien. Ein manueller Test mit der Tastatur und ein Screenreader-Test sind erforderlich, um den Rest abzudecken.
• Jeder echte Fix ist eine Änderung am Theme-Code (Liquid, CSS, JavaScript) und kein Widget, das einfach darübergelegt wird.

Warum du uns vertrauen kannst

Jacques hat über 15 Jahre Entwicklungserfahrung und hat vielen Shopify-Marken geholfen, barrierefreie, schnelle Storefronts zu launchen. Wir sind seit über vier Jahren im Shopify-Umfeld tätig und haben Fudge entwickelt, einen KI-Store-Builder und Editor mit einer Bewertung von 4.9 im Shopify App Store. Fudge findet Probleme bei der Barrierefreiheit in deinem Theme und behebt sie im nativen Code. Die unten stehenden Kriteriennummern und -stufen stammen direkt aus der offiziellen W3C WCAG 2.2-Empfehlung, nicht aus dem Gedächtnis.

Diese Checkliste ist die praktische Ergänzung zu unserem umfassenderen Shopify ADA- und WCAG-Compliance-Guide. Wenn du eher das rechtliche Gesamtbild als die Kriterien suchst, fange dort an.

---

So liest du diese Checkliste

Die WCAG haben drei Konformitätsstufen: A (Minimum), AA (das Ziel) und AAA (die höchste). Um WCAG 2.2 AA zu erreichen, musst du jedes Level A-Kriterium und jedes Level AA-Kriterium erfüllen. AAA-Kriterien sind eher erstrebenswerte Ziele und nicht Teil des gesetzlichen Standards; wir erwähnen sie daher, machen sie aber nicht zur Voraussetzung.

Die Richtlinien sind unter vier Prinzipien gruppiert, bekannt unter dem Akronym POUR:

• Wahrnehmbar (Perceivable). Nutzer können die Inhalte über einen ihrer Sinne wahrnehmen.
• Bedienbar (Operable). Nutzer können jedes Kontrollelement bedienen.
• Verständlich (Understandable). Inhalt und Verhalten sind vorhersehbar.
• Robust. Assistive Technologien können das Markup interpretieren.

Jeder der folgenden Abschnitte listet die Kriterien auf, die in einem Shopify-Store am ehesten brechen können – mit der exakten Nummer des Erfolgskriteriums, seinem Level und der Stelle im Theme, an der du es beheben musst.

Was ist neu in WCAG 2.2

WCAG 2.2 wurde im Oktober 2023 zur W3C Recommendation und ist die aktuelle Version.¹ Es hat alles aus 2.1 übernommen und neun neue Erfolgskriterien hinzugefügt, während eines entfernt wurde. Es ist wichtig sicherzugehen, auf welchem Level diese Kriterien verortet sind, da nur die Ergänzungen der Level A und AA dein Compliance-Ziel beeinflussen.²

Erfolgskriterium (Success criterion)	Level	In deinem AA-Ziel?
2.4.11 Focus Not Obscured (Minimum)	AA	Ja
2.4.12 Focus Not Obscured (Enhanced)	AAA	Nein
2.4.13 Focus Appearance	AAA	Nein
2.5.7 Dragging Movements	AA	Ja
2.5.8 Target Size (Minimum)	AA	Ja
3.2.6 Consistent Help	A	Ja
3.3.7 Redundant Entry	A	Ja
3.3.8 Accessible Authentication (Minimum)	AA	Ja
3.3.9 Accessible Authentication (Enhanced)	AAA	Nein

Zwei Punkte, die man sich gut merken sollte: 2.4.13 Focus Appearance ist Level AAA, nicht AA – es ist also für die AA-Konformität nicht erforderlich, auch wenn es sich um den Fokus dreht. Zudem wurde 4.1.1 Parsing in WCAG 2.2 gestrichen: Es ist nun obsolet, da moderne Browser fehlerhaftes Markup (das dieses Kriterium adressierte) mittlerweile selbst problemlos handhaben können. Du musst es also nicht mehr testen.²

Die sechs neuen A- und AA-Kriterien sind diejenigen, die du zu deinem bestehenden 2.1-Review hinzufügen solltest. Wir heben sie in den POUR-Abschnitten weiter unten nochmal hervor.

Wahrnehmbar (Perceivable)

Alles, was ein Shopper braucht, um die Seite zu verstehen, muss für die Augen, das Gehör oder für assistive Technologien verfügbar sein.

Textalternativen und Medien

• 1.1.1 Nicht-Text-Inhalt (A). Jedes aussagekräftige Bild benötigt eine Textalternative. In Shopify ist dies das alt-Feld bei Produktbildern, Kategoriebildern und allen Bildern, die über einen Abschnitt oder den Theme-Editor hinzugefügt werden. Dekorative Bilder sollten ein leeres alt="" haben, damit Screenreader sie überspringen. Bedienelemente, die nur aus Icons bestehen (Warenkorb, Suche, Burger-Menü), benötigen ebenfalls einen barrierefreien Namen, was sich mit den unten genannten Bedienbarkeits-Kriterien überschneidet.
• 1.2.2 Untertitel (aufgezeichnet) (A) und 1.2.5 Audiodeskription (aufgezeichnet) (AA). Wenn du Produktvideos oder ein Lifestyle-Reel einbindest, stelle Untertitel bereit und biete eine Audiodeskription oder Textalternative an, wenn visuelle Elemente Informationen vermitteln, die nicht im Audio enthalten sind.

Speziell für Produktbilder zeigt dir unser kostenloser Shopify Catalog Data Audit die Abdeckung von Alt-Texten in deinem gesamten Katalog, sodass du sehen kannst, wie groß die Lücke bei 1.1.1 ist, bevor du anfängst zu schreiben.

Farbe und Kontrast

• 1.4.1 Use of Color (A). Verlasse dich niemals allein auf die Farbe, um Bedeutung zu vermitteln. Ein Sale-Preis, der nur in Rot angezeigt oder ein Formularfehler, der nur durch einen roten Rahmen markiert wird, fällt durch. Nutze Text, ein Icon oder eine Unterstreichung zusätzlich.
• 1.4.3 Contrast (Minimum) (AA). Normaler Text benötigt ein Kontrastverhältnis von mindestens 4.5:1 im Vergleich zu seinem Hintergrund; großer Text (etwa 24px, oder 18.66px fettgedruckt) braucht 3:1. Dies ist der allerhäufigste Fehler bei Shopify und resultiert fast immer aus Brand-Farben, die für den Body-Text, Button-Labels oder Placeholder-Text verwendet werden. Du kannst dies relativ leicht in den Farbeinstellungen des Themes oder im CSS beheben.
• 1.4.11 Non-text Contrast (AA). UI-Komponenten (Interface components) und aussagekräftige Grafiken benötigen ebenfalls einen 3:1 Kontrast. Denke an hellgraue Rahmen bei Inputs, einen reinen Outline-Button für den “Add to cart” oder einen Focus Ring, den man kaum erkennen kann.

Anpassung des Layouts

• 1.4.4 Resize Text (AA). Text muss lesbar bleiben und darf nicht verschwinden, wenn auf 200% reingezoomt wird. Vermeide Container mit festen Pixel-Höhen (fixed pixel heights), die den Text beim Vergrößern abschneiden.
• 1.4.10 Reflow (AA). Bei einer Viewport-Breite von 320 CSS-Pixeln (was etwa einem 400%-Zoom entspricht) muss der Inhalt vollständig in eine Spalte umbrechen (Reflow), ohne dass horizontales Scrollen nötig ist. Sticky Header, breite Tabellen und mehrspaltige (Multi-Column) Sections verursachen hier bei Shopify-Themes oft Probleme.
• 1.4.12 Text Spacing (AA) und 1.4.13 Content on Hover or Focus (AA). Content muss dem Erhöhen von Zeilen- und Buchstabenabständen standhalten, und jedes Hover- oder Focus-Popover (wie ein Mega-Menü, oder ein Size-Guide Tooltip) muss manuell versteckbar, bei gedrückter Maus persistent und bedienbar bleiben.
• 1.3.5 Identify Input Purpose (AA). Felder, in die User bereits bekannte Daten eintragen können (wie Name, E-Mail-Adresse oder Lieferanschrift beim Checkout oder Formulare im Kundenkonto) sollten unbedingt das richtige autocomplete-Attribut aufweisen. So können Browser und Assistive Tech sie automatisch ausfüllen.

Bedienbar (Operable)

Jedes Menü, jeder Drawer und jeder Button muss auch über die Tastatur und per Touch funktionieren, nicht nur mit der Maus.

Tastaturzugriff (Keyboard access)

• 2.1.1 Keyboard (A) und 2.1.2 No Keyboard Trap (A). Alles, was per Maus bedient werden kann, muss auch mit der Tastatur steuerbar sein und der Fokus darf nie steckenbleiben. Bei Shopify sind die üblichen Fehlerquellen oft custom Mega-Menüs, Cart Drawers, Quick-View-Modals und Bildergalerien, die mit JavaScript gebaut wurden, welches die Tastatureingaben ignoriert. Ein Shopper, der Tab und Enter benutzt, muss in der Lage sein, den Cart Drawer zu öffnen, hindurchzunavigieren, und ihn wieder zu schließen.
• 2.4.1 Bypass Blocks (A). Biete einen Skip-Link an, damit Tastaturnutzer den Header überspringen und direkt zum Main Content springen können. Dawn und die meisten Themes aus dem Shopify Theme-Store bringen diesen standardmäßig mit; stark gecustomizete Themes lassen ihn hin und wieder verlieren.

Sichtbarkeit des Fokus

• 2.4.7 Focus Visible (AA). Das Element, das aktuell den Tastaturfokus hat, muss einen sichtbaren Indikator besitzen. Ein ziemlich häufiger Theme-Fehler ist ein global gesetztes outline: none in der CSS, das den Focus Ring auf der gesamten Webseite versteckt. Entferne dies oder ersetze es durch einen sichtbaren Custom-Stil.
• 2.4.11 Focus Not Obscured (Minimum) (AA). Neu in 2.2. Wenn ein Element in den Fokus gerät, darf es nicht komplett durch anderen Content verdeckt werden. Sticky Header, Cookie Banner und Floating Chat Buttons sind oftmals die Schuldigen: Sie können beim Runter-Tabben das im Fokus stehende Feld verdecken.

Pointer, Touch und Zielgröße

• 2.5.7 Dragging Movements (AA). Neu in 2.2. Jede Aktion, die ein Drag-Ereignis auslöst, muss durch eine Alternative ohne Dragging (Single-Pointer) bedienbar sein. Hat dein Theme etwas wie einen bildbasierten “Slide to confirm”-Regler oder einen Image Slider, füge Tap- oder Klick-Steuerungen (wie Buttons oder Pfeile) als Alternative hinzu.
• 2.5.8 Target Size (Minimum) (AA). Neu in 2.2. Touch-Ziele (Touch targets, also klickbare Elemente) müssen mindestens 24x24 CSS-Pixel groß sein oder genügend Abstand zu anderen Elementen aufweisen. Enge Mobile-Menüs, kleine Quantity Steppers, eng beieinander liegende Varianten-Swatches und winzige Social Icons im Footer sind typische Shopify-Fehler.
• 2.5.3 Label in Name (A). Ein Control-Element muss in seinem Accessible Name mindestens seinen sichtbaren Label-Text enthalten, damit Voice-Control Nutzer (z.B. Sprach-Assistenten) den Button wirklich bedienen können, indem sie “Add to cart” aussprechen.

Verständlich (Understandable)

Shopper sollten einfach vorhersehen können, was ein Bedienelement macht, und sie sollten sich von versehentlichen Klicks problemlos erholen können.

Sprache und Vorhersehbarkeit

• 3.1.1 Language of Page (A). Setze das lang-Attribut für die Seite (z.B. <html lang="en"> oder "de"), damit Screenreader bei der Aussprache nicht durcheinanderkommen. 3.1.2 Language of Parts (AA) hilft den Tools wie Screenreadern dabei, Zitate und Abschnitte in einer fremden Sprache richtig vorzulesen – besonders wichtig für mehrsprachige Stores.
• 3.2.3 Consistent Navigation (AA) und 3.2.4 Consistent Identification (AA). Halte Header, Menü und wiederkehrende Icons konsistent an der gleichen Stelle und benenne sie auf allen Seiten durchgängig identisch. Ein Cart-Icon, das mal “Cart” und mal “Bag” heißt, scheitert in diesem Punkt.
• 3.2.6 Consistent Help (A). Neu in 2.2. Wenn du Support (einen Kontakt-Link, Chat, oder das FAQ) auf deiner Website bereitstellst, sollte dieser auf auf allen Unterseiten immer leicht und an der gewohnten Position zu finden sein.

Formulare, Labels und Fehler

• 3.3.2 Labels or Instructions (A). Jedes Formulareingabefeld braucht ein programmatisches <label>. Ein Placeholder-Text ist kein Label. Dies betrifft extrem oft das Newsletter Signup, Kontaktformulare, Suchfelder oder Variant/Quantity-Selectoren zahlreicher Themes. Ein visuell verstecktes <label>, das nur für Screenreader bereitgestellt wird, reicht hier oftmals völlig aus.
• 3.3.1 Error Identification (A) und 3.3.3 Error Suggestion (AA). Schlägt eine Formularausfüllung fehl, hebe den Text für dieses konkrete Feld fehlerhaft hervor und schlage vor, wie der User den Eintrag korrekt formatieren kann. Achte darauf, Fehler nicht mit Farbe allein zu signalisieren.
• 3.3.7 Redundant Entry (A). Neu in 2.2. Zwinge einen Shopper nicht dazu, doppelte Informationen (die er im selben Durchlauf bereits gemacht hat) erneut ins Formular einzugeben. Wenn eine „Rechnungsadresse entspricht Lieferadresse“-Checkbox angeboten wird, löst das den Check im Checkout-Flow super.
• 3.3.8 Accessible Authentication (Minimum) (AA). Neu in 2.2. Verlange für einen Login niemals einen alleinigen kognitiven Test (etwa ein Puzzle zu lösen oder Zeichen eines Bildes abzutippen), an dem es für Assistive-User am Ende scheitert. Verlangt dein Login einen CAPTCHA, erstelle dringend eine Alternative wie E-Mail Magic Links oder Support für normale Passwort-Manager.

Robust

Das HTML-Markup deiner Seite muss sauber strukturiert und vor allen Dingen für eine fehlerfreie Interpretation der Assistive Technologies formatiert sein.

• 4.1.2 Name, Role, Value (A). Hast du eigene interaktive Komponenten, benenne Rollen und Status-Codes klar. Ein <div>, das via CSS als Button umgebaut wurde, benötigt ein role="button", eine Keyboard-Navigation und einen Accessible Name. Ein Akkordeon braucht bspw. einen sauberen Zustand als aria-expanded. Wann immer möglich: Vermeide Custom-Umbauten und nutze echte, native Elemente (<button>, <a>, <select>).
• 4.1.3 Status Messages (AA). Meldungen, die bei Updates ohne Wechsel des Fokus auftauchen – wie etwa „Added to cart“ oder „Only 2 left“ – sollten via ARIA Live Region angesagt werden, damit Screenreader sie mit aufnehmen können.
• Bitte beachte: Das Kriterium 4.1.1 Parsing wurde in WCAG 2.2 gestrichen. Doppelte IDs bei id-Attributen oder Probleme durch die Markup-Nesting-Struktur zählen daher nicht mehr als ein Fail für dieses spezielle Kriterium (auch wenn sie andere Kriterien trotzdem brechen können!).

Die Checkliste im Überblick

Nutze dies als schnelle Übersicht. Jede Zeile steht für ein Kriterium, seinen Level und die Shopify-Stelle, an der es in der Regel zu Problemen führt. Die Zeilen, die mit Neu in 2.2 markiert sind, solltest du in deine bestehenden WCAG 2.1-Reviews übernehmen.

Kriterium	Level	Typische Shopify Fehlerquellen
1.1.1 Non-text Content	A	Fehlendes alt bei Produkt- & Section-Bildern; unbeschriftete Button-Icons
1.4.1 Use of Color	A	Sale-Preise oder Formular-Fehler, die nur durch Farbe dargestellt werden
1.4.3 Contrast (Minimum)	AA	Brand-Farben bei Body Text, Buttons, Placeholders liegen unter 4.5:1
1.4.10 Reflow	AA	Horizontales Scrollen bei 320px; Sticky Headers und breite Tabellen
1.4.11 Non-text Contrast	AA	Sehr helle Input Border, Outline Buttons, schwache Focus Rings
2.1.1 Keyboard	A	Mega-Menüs, Cart Drawers, Quick-View-Modals nicht per Tastatur bedienbar
2.4.1 Bypass Blocks	A	Fehlende “Skip-to-Content”-Links bei stark modifizierten Themes
2.4.7 Focus Visible	AA	Globales outline: none blendet die Focus Ringe aus
2.4.11 Focus Not Obscured (Min) Neu in 2.2	AA	Sticky Header oder Chat-Widget überlagert das eigentlich angewählte (Fokus) Element
2.5.7 Dragging Movements Neu in 2.2	AA	Reine Drag-Slider ohne alternierende Buttons, Taps oder Pfeile
2.5.8 Target Size (Minimum) Neu in 2.2	AA	Zu dichte Touchpoints: Steppers, Swatches, Footer-Icons unter 24px
3.1.1 Language of Page	A	Fehlerhafte oder fehlende lang-Attribute in modifizierten Themes
3.2.6 Consistent Help Neu in 2.2	A	Support oder Kontakt-Links unterschiedlich und inkonsequent auf verschiedenen Seiten platziert
3.3.2 Labels or Instructions	A	Newsletter, Search, Kontakt-Formulare oder Variants Field haben kein <label>
3.3.7 Redundant Entry Neu in 2.2	A	Nutzer müssen bereits hinterlegte Daten zur Rechnung nochmal eingeben, statt diese direkt übernehmen zu können
3.3.8 Accessible Authentication (Min) Neu in 2.2	AA	Nur-CAPTCHA Login ohne barrierefreie Option oder Hilfestellung
4.1.2 Name, Role, Value	A	<div> Buttons oder Accordions ohne Roles oder Statusangaben
4.1.3 Status Messages	AA	„Added to Cart” Meldungen, die von Screenreadern nicht erfasst und vorgelesen werden

Automatisierte Tools bringen dich nur ein Stück weit

Ein Scanner ist ein guter Startpunkt und der schnellste Weg, um Kontrastprobleme, fehlende Alt-Texte oder fehlende Labels ausfindig zu machen. Letztlich deckt das automatisierte Tooling aber nur rund 30 bis 40% aller WCAG Erfolgskriterien ab. Eine Maschine bewertet dir eben nicht, ob ein Text (oder Alt-Text) Sinn ergibt, ob die Abfolge des Tastatur-Paging gut funktioniert oder wie gut der Kunde mit einem Screenreader tatsächlich durch den Checkout-Prozess kommt.

Also erfordert ein echter Audit zwei Ebenen:

1. Automatisierter Scan. Lasse ein kostenloses Tool (wie axe DevTools, WAVE, oder die Google Lighthouse Erweiterung) einmal über deine zentralen Templates (Startseite, Produkte, Collections, Cart und Text-/Contentseiten) drüberlaufen.
2. Manuelle Tests. Klick dich manuell durch: vom Produkt über den Cart Drawer bis in den final abgeschlossenen Checkout – ausschließlich bedient über die Tastatur (Tab, Shift + Tab, und Enter). Wiederhole genau dies im Anschluss gemeinsam mit der Audioausgabe (Mac VoiceOver oder dem kostenlos für Windows verfügbaren Tool NVDA). Zu guter Letzt stellst du mal auf 200% Zoom und probierst im Bereich des Reflow (bis etwa 320px) sicherzustellen, ob sich nichts überschneidet.

Eine Schritt-für-Schritt Anleitung, zu welchen Accessibility Fehlern das in der Praxis häufig führt und wie man diese löst, findest du in unserem Guide zur Behebung typischer Shopify Accessibility Failures.

Wie du gefundene Fehler richtig behebst

Jeder dauerhafte Fix auf dieser Checkliste ist eine waschechte Änderung an deinem Theme-Code. Und hier stoßen Overlays stark an ihre Grenzen. Eine Extra-Layer-Codeanpassung, ein sogenanntes Overlay-Widget, das einfach von dritt-Gewerben über einen Theme gepflanzt wird, behebt den Code-Fail nicht im Kern! Es kann keine alt-Tags sinnvoll verändern, kein <label> dem Suchfeld zuführen oder Zielstrukturen auf Tastatur-Eingaben für deine Store-Drawer anlegen. Die drübergestülpte Optik tarnt einfach fehlerhaftes HTML. Aus genau dem Grund hat die FTC bereits große Anbieter bestraft, und Seitenbetreiber wurden verklagt, weil sie mit drübergestülpten Codezeilen agierten, statt den echten und relevanten Core (das HTML Theme) sauber aufzusetzen. Genaures und die Aufbereitung dieses Problems haben wir dir detailiert hier zusammengestellt: Warum Accessibility Overlays scheitern. Und auch generelle plattform-gegebene Fragen und Shopify Core Begebenheiten erörtern wir hier auf dem Blog in Ist Shopify ADA compliant?

Die allermeisten Problemlösungen geschehen im Code durch konkrete Anpassungen von Liquid, CSS und JavaScript:

• Füge überall auf der Seite beschreibende und sinnhafte alt-Tags ein (und kennzeichne dekorative und bedeutungsleere Slider-/Dekorationen schlicht mit einem leeren alt="").
• Statte Icon-only-Buttons mit einem Accessible Name aus.
• Setze jedem Formular-Feld (Input) ein <label>-Equivalent davor.
• Treibe Kontraste für Texte und UI-Components im Design auf die Ratios von 4.5:1 und 3:1 an.
• Re-integriere sichtbare Fokus-Zustände (Focus States) und organisiere eine logische Tastenzuweisungs-Struktur (Tab Order).
• Vergrößere enge Touch-Targets auf minimum 24px (Breite & Höhe) und sorge für gute Drag-and-Drop Alternativen.
• Wähle pro „Region“ oder Unterseite der Sub-Markets konsequent ein valides lang-Attribut in der Sprache, in welcher der Kunde die Website gerade besteuert.

Hier helfen dir zumeist AI Store Builder weiter. Fudge checkt dein live aufgesetztes System (Theme) aktiv ab, weist dir genau im fehlerhaften Code und dem passenden Kriterium nach der WCAG aus, was harkt. Der Fix wird von der KI passgenau ausgearbeitet und repariert direkt dein Native Liquid, CSS oder Java. Keine unruhig geladenen externen Scripts. Kein drübergestülptes Layer. Fudge repariert genau deinen Store-Level Code so sauber, wie auch der Entwickler ihn lösen würde. Die KI und Fudge eignet sich übrigens auch spitze, um zum Beispiel unkompliziert strukturierte Daten zu ergänzen oder generelles Anpassungen und Store Editing optimal abzuarbeiten.

Das Modell, das wir empfehlen (und nach dem wir auch Fudge gebaut haben) gleicht immer drei Grund-Steps nach Priorität ab: Zeige auf, wo Handlungsbedarf geboten ist. Behebe das Fundament am Quellcode! – und tracke für die Zukunft, dass zukünftiger Content nicht langsam von der Barrierefreiheit wegdriftet. Solltest du auch Store-Umsätze auf dem europäischen Festland anvisieren, kommst du übrigens direkt auf doppelte Erfüllung: Die von Europa erzwungenen Auflagen im European Accessibility Act, die sich in der Vergangenheit am Standard der WCAG 2.1 AA orientierten, deckst du hiermit gleichzeitig optimal ab!

---

FAQ

Footnotes

1. Web Content Accessibility Guidelines (WCAG) 2.2, W3C Recommendation, wurde im Oktober 2023 zur Empfehlung, w3.org/TR/WCAG22. Kontrastwerte aus 1.4.3 und 1.4.11; Zielgröße aus 2.5.8; Umbruch (Reflow) aus 1.4.10. ↩

2. W3C Web Accessibility Initiative, “What’s New in WCAG 2.2”: neun neue Erfolgskriterien (2.4.11, 2.4.12, 2.4.13, 2.5.7, 2.5.8, 3.2.6, 3.3.7, 3.3.8, 3.3.9) und die Entfernung von 4.1.1 Parsing, w3.org/WAI/standards-guidelines/wcag/new-in-22. ↩ ↩²