Kurze Antwort: Das Präsidialrundschreiben Nr. 2025/10 (Cumhurbaşkanlığı Genelgesi) zur digitalen Barrierefreiheit in der Türkei verlangt, dass Diensteanbieter, die im Sinne des türkischen E-Commerce-Gesetzes Nr. 6563 elektronischen Handel betreiben, ihre Websites und mobilen Apps bis Juni 2027 an die „Kontrol Listesi – A Seviyesi“ (Checkliste für Stufe A) des Ministeriums für Familie und Soziale Dienste und an die WCAG 2.2 anpassen. Die Checkliste übersetzt die 31 Erfolgskriterien der Stufe A aus WCAG 2.2 in 126 Fragen; jede Webseite und jeder App-Bildschirm wird einzeln bewertet. Die Durchführungsrichtlinie (Yönerge) sieht eine Prüfkommission aus mindestens drei Personen und eine dreistufige Prüfung aus automatisierten Tests, manuellen Tests und Nutzertests mit Menschen mit Behinderungen vor. Ein direktes Bußgeld enthält das Rundschreiben nicht; die Überwachungsergebnisse werden jedoch öffentlich bekanntgegeben, und nicht barrierefreie digitale Dienste können Gegenstand einer Diskriminierungsbeschwerde bei der TİHEK werden, der türkischen Menschenrechts- und Gleichstellungsinstitution.
Dieser Leitfaden richtet sich an Inhaberinnen und Inhaber, E-Commerce-Verantwortliche sowie IT- und Produktverantwortliche von Onlinehändlern, die in der Türkei einen eigenen Webshop oder eine eigene iOS-/Android-App betreiben – ob als türkisches Unternehmen oder als Unternehmen aus der DACH-Region, das mit türkischen Partnern arbeitet oder in die Türkei verkauft. Einrichtungen der ersten Welle, deren Frist bereits im Juni 2026 abgelaufen ist, können dieselben Schritte nutzen. Wer zugleich an Verbraucher in Deutschland verkauft, findet im Abschnitt zu den Sanktionen den Bezug zum deutschen Barrierefreiheitsstärkungsgesetz (BFSG). Die Angaben haben wir nicht aus Nachrichtenzusammenfassungen übernommen, sondern direkt aus den Texten des Rundschreibens, der Checkliste, des Logo-Leitfadens und der Durchführungsrichtlinie, aus den einschlägigen Gesetzen sowie aus Quellen der TİHEK und des W3C zusammengetragen. Dieser Beitrag ist keine Rechtsberatung und gibt den Stand vom 31. Oktober 2026 wieder.
Was regelt das Rundschreiben zur Barrierefreiheit in der Türkei? Vier offizielle Dokumente in einer Tabelle
Rechtsgrundlage ist das türkische Gesetz Nr. 5378 über Menschen mit Behinderungen (Engelliler Hakkında Kanun):
„Es wird sichergestellt, dass Informationsdienste sowie Informations- und Kommunikationstechnologie für Menschen mit Behinderungen barrierefrei zugänglich sind.“ (Gesetz Nr. 5378, Art. 7; unsere Übersetzung)
Die Einzelheiten regeln vier Dokumente:
| Dokument | Was regelt es? | Bedeutung für den E-Commerce |
|---|---|---|
| Rundschreiben 2025/10 (Amtsblatt Resmî Gazete, 21. Juni 2025) | Geltungsbereich und Fristen; Überwachungs-, Beratungs- und Prüfkommissionen; Logo-Nutzungsrecht für 2 Jahre | Frist 2 Jahre: Juni 2027 |
| Durchführungsrichtlinie über Verfahren und Grundsätze (Uygulama Usul ve Esasları Hakkında Yönerge; ohne Angabe des Genehmigungsdatums) | Kommissionen, Prüfmethode, Ausnahmen, Logoverfahren | Kommission aus mindestens 3 Personen, dreistufiger Test |
| Kontrol Listesi – A Seviyesi (Checkliste Stufe A, V2.2.30.01, Ankara 2026) | 31 Erfolgskriterien der Stufe A aus WCAG 2.2, 126 Fragen | Jede Seite und jeder App-Bildschirm wird einzeln bewertet |
| Leitfaden zur Verwendung des Barrierefreiheitslogos (Erişilebilirlik Logosu Kullanım Kılavuzu, geändert am 14.04.2026) | Verwendung des Logos auf Websites und in mobilen Apps | Nur auf Websites und in Apps, denen das Recht erteilt wurde |
Zwei Punkte werden häufig verwechselt:
- Das Rundschreiben 2026/1 ist kein Plan für das Web. Der Überwachungs- und Kontrollplan in diesem Rundschreiben vom 21. Januar 2026 erfasst nur Gebäude, Freiflächen und öffentliche Verkehrsmittel. Den für Web und Mobile vorgesehenen Überwachungsplan (İzleme Planı) konnten wir Stand 31. Oktober 2026 auf den Seiten der EYHGM zu Barrierefreiheit und Rechtsvorschriften nicht finden (die EYHGM ist die für Menschen mit Behinderungen und ältere Menschen zuständige Generaldirektion des Ministeriums). Für die Aussage „Die Kontrollen im E-Commerce haben begonnen“ ist es zu früh.
- Ein türkischer WCAG-2.2-Leitfaden ist offenbar noch nicht veröffentlicht. Der im Rundschreiben angekündigte Leitfaden fehlt auf der Barrierefreiheitsseite des Ministeriums, und das W3C führt die autorisierte türkische Übersetzung als „geplant“ (Absichtserklärung vom 5. Mai 2026). Legen Sie den englischen WCAG-2.2-Text des W3C zugrunde.
Hinweis zur Durchführungsrichtlinie: Das Ministerium führt die Richtlinie auf der Seite „Yönergeler“ (Richtlinien) der EYHGM; am 31. Oktober 2026 war der dortige Dokumentlink leer, der PDF-Text ist auf der Website des Ministeriums jedoch abrufbar. Der Text enthält kein Genehmigungsdatum; nach Art. 19 tritt er mit dem Tag der Genehmigung in Kraft. Die folgenden Angaben zur Durchführungsrichtlinie beruhen auf diesem Text; behalten Sie mögliche Aktualisierungen des Ministeriums im Blick.
Barrierefreiheit in der Türkei: Wer ist im E-Commerce verpflichtet, und drohen Sanktionen?
Geltungsbereich: alle mit eigener Website oder App
Das Rundschreiben nennt Diensteanbieter (hizmet sağlayıcı), die im Sinne des Gesetzes Nr. 6563 zur Regulierung des elektronischen Handels E-Commerce betreiben; eine Größenschwelle oder eine Ausnahme für Kleinstunternehmen sieht es nicht vor. Nach dem Gesetz Nr. 6563 ist Diensteanbieter jede natürliche oder juristische Person, die E-Commerce betreibt; als E-Commerce-Umgebung gelten Website, mobile Website und mobile App. Eine Marke mit eigenem Shop oder eigener App fällt damit eindeutig in den Geltungsbereich. Zwei Konstellationen sind unklar:
- Händler, die nur über Marktplätze verkaufen: Das Gesetz Nr. 6563 zählt auch Marktplatzhändler zu den „elektronik ticaret hizmet sağlayıcı“ (Anbieter von E-Commerce-Diensten); die Verkaufsumgebung gehört jedoch dem Marktplatz, und wie sich die Pflicht auf den Händler auswirkt, ist nicht geregelt.
- Einzelunternehmen (şahıs şirketi): Die Durchführungsrichtlinie definiert die Kommission über „Institutionen, Einrichtungen und juristische Personen“ sowie über „mindestens drei Beschäftigte“.
Holen Sie zu diesen Fragen eine Auskunft des Ministeriums oder Ihrer Rechtsberatung ein. Für Einrichtungen der ersten Welle wie Banken, private Krankenhäuser, private Bildungseinrichtungen und Personenbeförderungsunternehmen ist die einjährige Frist bereits im Juni 2026 abgelaufen.
Sanktionen: kein Bußgeld im Rundschreiben – das Risiko liegt woanders
- Rundschreiben und Durchführungsrichtlinie sehen kein Verwaltungsbußgeld vor. Die Überwachungsergebnisse gibt jedoch die Ministerin oder der Minister öffentlich bekannt.
- Die Bußgelder des Gesetzes Nr. 5378 betreffen nicht das Web. Die Bußgelder im Übergangsartikel 3 (Geçici Madde 3) knüpfen an Gebäude, Freiflächen und öffentlichen Verkehr an. Der in manchen Ratgebern genannte Betrag von „5.000–25.000 TL pro Feststellung“ (TL = türkische Lira) ist in dieser Vorschrift für Gemeinden und öffentliche Einrichtungen vorgesehen; für natürliche Personen und juristische Personen des Privatrechts nennt der Gesetzestext einen nominalen Betrag von 1.000–5.000 TL pro Feststellung.
- Der Weg über die TİHEK ist ein konkretes Risiko. Das Gesetz Nr. 6701, die Rechtsgrundlage der TİHEK, verbietet Diskriminierung aufgrund einer Behinderung, wertet das Unterlassen angemessener Vorkehrungen als Diskriminierung und erfasst auch natürliche Personen und juristische Personen des Privatrechts, die „vergleichbare Dienstleistungen“ anbieten. Das Verwaltungsbußgeld nach Art. 25 Abs. 1 liegt 2026 bei 17.052–256.357 TL; das Entscheidungsgremium der TİHEK (Kurul) kann das Bußgeld einmalig in eine Verwarnung umwandeln. In ihrer Entscheidung Nr. 2024/403 stellte die TİHEK einen Verstoß fest, weil Bereiche im Online- und Mobile-Banking einer Bank mit einem Screenreader nicht lesbar waren.
- Wenn Sie an Verbraucher in Deutschland verkaufen: BFSG. Das Barrierefreiheitsstärkungsgesetz (BFSG) setzt den European Accessibility Act (Richtlinie (EU) 2019/882) in Deutschland um und erfasst Dienstleistungen im elektronischen Geschäftsverkehr, die nach dem 28. Juni 2025 für Verbraucher erbracht werden; wer eine nicht konforme Dienstleistung anbietet, riskiert ein Bußgeld von bis zu 100.000 Euro. Ausgenommen sind Kleinstunternehmen, die Dienstleistungen erbringen (weniger als 10 Beschäftigte und höchstens 2 Mio. Euro Jahresumsatz oder Jahresbilanzsumme) – eine solche Ausnahme kennt das türkische Rundschreiben nicht. Wer in beiden Märkten verkauft, sollte die beiden Regelwerke deshalb getrennt prüfen.
Wie lesen Sie die Checkliste zur Barrierefreiheit (Stufe A)?
Die Checkliste des Ministeriums aus dem Jahr 2026 (V2.2.30.01) übersetzt die 31 Erfolgskriterien, die sich auf die vier Prinzipien von WCAG 2.2 verteilen, in 126 nummerierte Fragen. Es gibt drei Fragetypen (Fragenummern geben wir im Folgenden mit „F“ an):
- ★ (64 Fragen): Pflichtbedingung. Die Antwort „Nein“ bedeutet Korrekturbedarf.
- ★★ (3 Fragen): Zustand, der nicht vorliegen darf. Die Antwort „Ja“ bedeutet Korrekturbedarf: Informationen werden nur über Farbe vermittelt (F52), Blitze überschreiten die Grenzwerte (F81), der Kontext ändert sich, sobald eine Komponente lediglich den Fokus erhält (F106).
- Ohne Stern (59 Fragen): Filterfragen. Eine solche Frage klärt etwa, ob die Seite ein CAPTCHA enthält; je nach Antwort geht es im passenden Abschnitt weiter.
Die entscheidende Regel: Die Fragen werden für jede Webseite und jeden App-Bildschirm gesondert beantwortet. In einem Shop mit Tausenden Produktseiten bedeutet das, die Seitenvorlagen (Templates) einzeln abzuarbeiten: Startseite, Kategorie, Produktdetailseite, Warenkorb, Checkout-Schritte, Registrierung und Kundenkonto sowie Aktionsseiten. Eine Korrektur in einem Template wirkt sich auf alle Seiten aus, die es verwenden; wie die Seiten bei der Überwachung stichprobenartig ausgewählt werden, wird laut Durchführungsrichtlinie die Überwachungskommission (İzleme Komisyonu) festlegen.
Die Liste deckt nur Stufe A ab; Farbkontrast (1.4.3), sichtbarer Fokus (2.4.7) und die Größe von Touch-Zielen (2.5.8) sind AA-Kriterien und gehören deshalb nicht zum gesetzlichen Minimum. Wir empfehlen trotzdem, sie von Anfang an im Designsystem zu verankern: In der WebAIM-Analyse 2026 ist geringer Kontrast der häufigste Fehler und findet sich auf 83,9 % der Startseiten. Da die Liste nicht zu kommerziellen Zwecken vervielfältigt werden darf, geben wir die Fragen nicht wieder, sondern erklären ihre Logik; die aktuelle Fassung laden Sie bitte auf der Website des Ministeriums herunter.
Was verlangt die Durchführungsrichtlinie? Kommission, Tests, Ausnahmen und Logo
Prüfkommission: mindestens drei Personen aus dem eigenen Personal
Nach Art. 13 der Durchführungsrichtlinie bildet jede Einrichtung und jede juristische Person, die überwacht wird, eine Prüfkommission (İnceleme Komisyonu) aus mindestens drei Beschäftigten, von denen mindestens eine Person in der Web-/Mobile-Abteilung arbeitet; der in manchen Ratgebern zu lesende Tipp, ein „Kernteam aus zwei Personen“ genüge, widerspricht dieser Vorschrift. In dem Jahr, in dem Sie in den Überwachungsplan aufgenommen werden, erstellt die Kommission einen Prüfbericht (İnceleme Raporu) im Format dieses Plans und schickt ihn an das Sekretariat bei der EYHGM; außerdem verfolgt sie die Korrekturen und erstellt für die Verlängerung des Logos einen aktualisierten Bericht.
Wie läuft ein Barrierefreiheitstest ab? Drei Stufen
- Automatisierter Test: mit Werkzeugen, die auf der W3C-Website gelistet sind. Die Liste des W3C umfasst Stand 31. Oktober 2026 insgesamt 119 Werkzeuge; sie lässt sich nach Android und iOS filtern, und auch WAVE und axe DevTools sind darin enthalten (das W3C befürwortet keine bestimmten Produkte).
- Manueller Test: Formulare, Bedienelemente der Oberfläche, Dialogfenster, Bestätigungen von Dateneingaben, Fehlermeldungen, Rückmeldungen, Tastaturbedienung sowie Nicht-Text-Inhalte wie Fotos, Videos, CAPTCHAs und Audio.
- Nutzertest mit Menschen mit Behinderungen: mit blinden und sehbehinderten Menschen (Screenreader-Nutzende und Menschen mit geringem Sehvermögen), hörbehinderten Menschen (gehörlos und schwerhörig) und Menschen mit körperlichen (orthopädischen) Behinderungen, die Maus und Tastatur nur eingeschränkt nutzen können. Empfohlen werden außerdem Tests mit Menschen mit kognitiven Beeinträchtigungen, im Autismus-Spektrum, mit spezifischen Lernstörungen und mit Farbenblindheit.
Warum reicht ein Barrierefreiheits-Plug-in (Overlay) nicht aus?
Die Checkliste verlangt, dass die Verknüpfung von Beschriftungen (Labels) mit Formularfeldern und die Überschriftenhierarchie im Code „programmatisch“ festgelegt sind und dass das Fokusmanagement korrekt umgesetzt ist. Ein nachträglich eingebundenes Widget versucht, das im Browser auf Basis von Vermutungen nachzubessern, kann bei jeder Template-Änderung brechen und erreicht native iOS-/Android-Bildschirme überhaupt nicht. Keines der vier Dokumente enthält eine Bestimmung, die ein Plug-in als Konformitätsnachweis gelten lässt; nach der Durchführungsrichtlinie sind manuelle Tests und Nutzertests mit Menschen mit Behinderungen in jedem Fall erforderlich.
Kennen Sie auch die Grenzen automatisierter Tests: Laut der Analyse WebAIM Million 2026 enthalten 95,9 % der Startseiten der eine Million populärsten Websites automatisch erkannte WCAG-Fehler; im Schnitt sind es 56,1 Fehler pro Seite, auf türkischsprachigen Seiten 66,2 und in der Kategorie Shopping 71,0. Eine Tastaturfalle oder ein nichtssagender Alternativtext fällt dagegen meist erst beim Test durch Menschen auf. Automatische Prüfungen in der CI/CD-Pipeline helfen zu verhindern, dass behobene Fehler mit neuen Releases zurückkehren.
Ausnahmen: Was fällt nicht unter die Pflicht?
- Inhalte, die dynamisch und automatisch aus anderen Quellen eingebunden werden: Die Durchführungsrichtlinie nennt als Beispiele dynamisch eingeblendete Werbung und Kundenbewertungen. Ausgenommen ist nur der Inhalt selbst – nicht Ihr Bewertungsformular und nicht Ihre Rating-Komponente.
- Online-Karten, sofern die für die Navigation wesentlichen Informationen barrierefrei bereitgestellt werden.
- Live-Übertragungen; eine Aufzeichnung, die auf der Website vorgehalten wird, muss jedoch innerhalb von 14 Tagen barrierefrei gemacht werden.
- Video- und Audioaufnahmen, die vor dem Rundschreiben aufgezeichnet wurden, sowie Archivinhalte, die innerhalb eines Jahres nach Inkrafttreten des Rundschreibens nicht aktualisiert werden und für Verwaltungsverfahren nicht erforderlich sind. Für neue Produktvideos gelten die Fragen zu Untertiteln, Transkript und Audiodeskription (F17–25).
Eine Übersetzung in die Türkische Gebärdensprache (Türk İşaret Dili, TİD) ist für Video- und Audioinhalte nicht vorgeschrieben; wird sie angeboten, muss die Dolmetscherin oder der Dolmetscher in der TİD-Eignungsprüfung (TİD Yeterlilik Sınavı) mindestens 70 Punkte erreicht haben.
Wie erhalten Sie das Barrierefreiheitslogo?
Das Logo dürfen Sie nicht eigenmächtig einbinden. Das Nutzungsrecht kann bei der EYHGM beantragt werden; die Überwachungskommission vergibt es für 2 Jahre, und zwar gesondert für barrierefreie Websites und für die barrierefreie App auf jedem mobilen Betriebssystem. Für die Verlängerung ist ein aktueller Prüfbericht nötig, der dem geltenden Überwachungsplan entspricht. Laut dem am 14. April 2026 aktualisierten Leitfaden darf das Logo nur auf Websites und in Apps verwendet werden, denen das Recht erteilt wurde; ein Klick darauf muss zur Verifizierungsseite auf der offiziellen Website der EYHGM führen, und zur Erzielung kommerzieller Vorteile darf es nicht genutzt werden.
Vom Schaufenster bis zur Kasse: die häufigsten Stolpersteine in Onlineshops
Typische Shop-Komponenten und die zugehörigen Fragen der Checkliste (Nummerierung nach V2.2.30.01):
| Komponente | Fragen | Was ist zu tun? |
|---|---|---|
| Menü und wiederkehrende Blöcke | F36–37, F65–66, F82–83 | Verwenden Sie <nav>; Untermenüs, die sich per Maus öffnen, müssen sich auch per Tastatur öffnen lassen; ergänzen Sie einen Link „Zum Hauptinhalt springen“. |
| Slider und laufendes Aktionsband | F75–78 | Pause-Schaltfläche für automatische Bewegungen, die länger als 5 Sekunden dauern. |
| Produktbilder | F1–5 | Aussagekräftiges alt für informationstragende Bilder, alt="" für dekorative Bilder. |
| Farb- und Größenauswahl | F16, F51–53 | Kennzeichnen Sie den ausgewählten oder ausverkauften Zustand zusätzlich zur Farbe mit Text; geben Sie jedem Farbfeld einen zugänglichen Namen („Marineblau“). |
| Filter | F40–41, F107–108 | Gruppieren Sie Optionen mit <fieldset> und <legend>; lädt eine Auswahl die Seite automatisch neu, kündigen Sie das vorher an oder setzen Sie eine Schaltfläche „Anwenden“ ein. |
| Warenkorb +/− und Icon-Buttons | F15–16, F124–126 | Zugängliche Namen wie „Menge erhöhen“ oder „In den Warenkorb“; der Mengenwert muss programmatisch aktuell bleiben. |
| Schnellansicht, Cookie-Banner, Pop-up | F61–64, F69–70 | Modales Fenster mit role="dialog"; der Fokus wechselt ins Fenster, Escape schließt es, und nach dem Schließen kehrt der Fokus zur auslösenden Schaltfläche oder an eine sinnvolle Stelle zurück. |
| Zeitlimit für Sitzung und Warenkorb | F73–74 | Zeitlimit abschalten, auf mindestens das Zehnfache verlängern oder mindestens 20 Sekunden vor Ablauf warnen und mit einer einfachen Aktion mindestens 10-mal verlängern lassen. |
| Formulare | F38–39, F111–120 | Platzhaltertext ersetzt kein Label; verknüpfen Sie Fehlertexte mit dem Feld; ein Sternchen ohne Erklärung oder nur ein roter Rahmen genügt nicht. |
| Liefer- und Rechnungsadresse | F121–122 | Option „Rechnungsadresse entspricht der Lieferadresse“ und autocomplete-Attribute. |
| CAPTCHA | F10–12 | Text, der den Zweck erklärt, und eine Alternative, die nicht auf einem einzigen Sinn beruht; ein rein visuelles oder rein akustisches CAPTCHA genügt nicht. |
| Live-Support, FAQ, Chatbot | F109–110 | Hilfe-Link auf jeder Seite an derselben, vorhersehbaren Stelle. |
Dass ein Screenreader die Meldung „In den Warenkorb gelegt“ ansagt (WCAG 4.1.3), ist ein AA-Kriterium und nicht Teil der Liste; wir empfehlen es dennoch als Standard.
Zahlungsschritt und 3-D Secure
Der 3-D-Secure-Bildschirm ist meist eine Seite der Bank oder des Zahlungsdienstleisters; seinen Inhalt können Sie nicht ändern. Auf die Ausnahme der Durchführungsrichtlinie für automatisch eingebundene Inhalte sollten Sie sich nicht verlassen: Die Richtlinie nennt dafür Beispiele wie Werbung und Kundenbewertungen, und der Kaufprozess passt unseres Erachtens nicht zu dieser Beschreibung. Sichern Sie den Teil ab, den Sie selbst in der Hand haben:
- Geben Sie dem iframe mit den Zahlungsfeldern oder dem 3DS-Bildschirm einen aussagekräftigen
title; setzen Sie den Fokus beim Öffnen dorthin und nach dem Schließen auf die Ergebnismeldung. - Testen Sie die Erfolgs- und Fehlerseiten nach der Rückkehr aus 3DS mit einem Screenreader; bei einem Fehler sollten die eingegebenen Daten erhalten bleiben.
- Fordern Sie von Ihrem Zahlungsdienstleister schriftliche Angaben zur Barrierefreiheit von Zahlungsformular und 3DS-Bildschirm an, und machen Sie diese bei der Vertragsverlängerung zum Kriterium.
Details zur Integration finden Sie in unserem Leitfaden zur Integration eines virtuellen POS (sanal POS) mit 3DS.
Barrierefreie mobile Apps: Entsprechungen in iOS, Android und React Native
Die Checkliste nennt in ihren Beispielen Plattform-APIs beim Namen; auch Ihre iOS- und Android-App wird mit denselben Fragen Bildschirm für Bildschirm bewertet. Häufig genutzte Entsprechungen:
| Anforderung (Frage) | Android | iOS | React Native |
|---|---|---|---|
| Zugänglicher Name (F3, F16) | contentDescription | accessibilityLabel | accessibilityLabel |
| Dekoratives Element ausblenden (F5) | importantForAccessibility="no" | isAccessibilityElement = false | aria-hidden={true} |
| Überschrift (F28) | accessibilityHeading="true" | accessibilityTraits = .header | accessibilityRole="header" |
| Listeninformation (F30) | CollectionInfo | accessibilityContainerType | role="list" |
| Modal und Fokus (F62, F70) | accessibilityPaneTitle | accessibilityViewIsModal | accessibilityViewIsModal (nur iOS) |
| Aktion statt Wischen und Ziehen (F68, F96) | AccessibilityAction | accessibilityCustomActions | accessibilityActions |
| Automatisches Ausfüllen (F122) | autofillHints | textContentType | autoComplete |
In der React-Native-Spalte weichen wir an zwei Stellen von den Beispielen der Liste ab. „list“ gehört nicht zu den Werten von accessibilityRole; die Listenrolle wird mit role="list" festgelegt. accessible={false} wiederum schaltet unter Android nur die Fokussierbarkeit (focusable) ab; um ein dekoratives Element auf beiden Plattformen vor dem Screenreader zu verbergen, verwendet man aria-hidden. Flutter kommt in der Liste nicht vor; dort werden dieselben Informationen über die Eigenschaften label, header, excludeSemantics und customSemanticsActions des Semantics-Widgets bereitgestellt. Ergänzen Sie außerdem für Aktionen, die nur per Wischgeste möglich sind, etwa das Entfernen aus dem Warenkorb, eine Schaltflächen-Alternative (F95–96) und für bewegungsgesteuerte Funktionen wie „Schütteln zum Rückgängigmachen“ eine Alternative und eine Möglichkeit zum Abschalten (F101–103); verknüpfen Sie Fehlermeldungen mit dem betreffenden Feld (unter Android mit setError). Da das Logo-Recht für jedes mobile Betriebssystem gesondert vergeben wird, planen Sie iOS und Android wie getrennte Produkte; bezeichnen Sie eine App erst dann als „barrierefrei“, wenn sie mit VoiceOver und TalkBack getestet wurde. Unseren Ansatz für die native Entwicklung beschreiben wir auf unserer Seite zur Mobile-App-Entwicklung.
In 7 Monaten bis Juni 2027: der Fahrplan Schritt für Schritt
Eine realistische Reihenfolge für ein Team, das im November 2026 startet:
- November 2026, Organisation und Bestandsaufnahme: Bilden Sie die Prüfkommission (mindestens 3 Personen, eine davon aus der Web-/Mobile-Abteilung). Listen Sie Web-Templates und App-Bildschirme auf; markieren Sie Drittanbieter-Komponenten wie Zahlung, Cookie-Banner und Live-Support gesondert.
- Dezember 2026, Ausgangsmessung: automatisierter Scan mit Werkzeugen aus der W3C-Liste, danach die Checkliste Template für Template. Überführen Sie die Befunde in eine Aufgabenliste und ziehen Sie dabei die ★★-Punkte und den Checkout-Prozess vor.
- Januar–März 2027, Korrekturen an Komponenten: Korrigieren Sie Buttons, Formularfelder, Modals, Menüs, Slider und Filter im Designsystem; binden Sie die automatisierten Tests in die CI-Pipeline ein.
- März–April 2027, Zahlung und App: Zahlung und Rückkehr aus 3DS, Cookie-Banner und Widgets von Drittanbietern; Korrekturen in iOS und Android.
- April–Mai 2027, manuelle Tests und Nutzertests mit Menschen mit Behinderungen: Tests mit Tastatur, VoiceOver und TalkBack; Testsitzungen mit Nutzerinnen und Nutzern aus den in der Durchführungsrichtlinie genannten Gruppen; Entwurf des Prüfberichts.
- Juni 2027 und danach: Sobald der Überwachungsplan für Web und Mobile veröffentlicht ist, passen Sie den Bericht an dessen Format an, prüfen einen Antrag auf das Logo und führen bei jedem Release Regressionstests durch.
Entscheidungspunkt: Wenn Sie ein fertiges Theme nutzen, hängt ein Teil der Korrekturen von Ihrem Theme- und Plug-in-Anbieter ab. Lassen Sie sich vom Anbieter einen schriftlichen Zeitplan für die Barrierefreiheit geben; bekommen Sie keinen, bringen Sie vor März 2027 einen Theme-Wechsel oder eine maßgeschneiderte Website auf den Tisch. Bei einer maßgeschneiderten Lösung werden Korrekturen in gemeinsamen Komponenten vorgenommen und wirken sich auf alle Seiten aus, die diese Komponente nutzen.
Wie unterstützt Partnerfy Sie dabei?
Wir lösen Barrierefreiheit an der Quelle, nicht mit einem Plug-in. Zuerst erfassen wir Ihre Templates und App-Bildschirme und scannen sie mit Werkzeugen aus der W3C-Liste; danach testen wir manuell mit Tastatur, VoiceOver und TalkBack. Die Befunde beheben wir in den Komponenten Ihres Designsystems und im nativen iOS-, Android- oder React-Native-Code und binden automatisierte Prüfungen in Ihre CI-Pipeline ein. Für die Nutzertests mit Menschen mit Behinderungen bereiten wir die Szenarien vor, unterstützen Sie dabei, diese Tests mit Vereinen und Organisationen aus dem Bereich zu planen, und erstellen die technische Dokumentation für den Bericht Ihrer Prüfkommission; die Mitgliedschaft in der Kommission und die rechtliche Bewertung bleiben bei Ihnen. Wenn Sie eine erste Einschätzung Ihrer E-Commerce-Infrastruktur wünschen, schreiben Sie uns.
Quellen
- Resmî Gazete (türkisches Amtsblatt): Rundschreiben 2025/10 (21.06.2025, Ausgabe 32933)
- Ministerium für Familie und Soziale Dienste: Kontrol Listesi – A Seviyesi (V2.2.30.01)
- EYHGM: Seite „Yönergeler“ (Richtlinien) und Durchführungsrichtlinie über Verfahren und Grundsätze (PDF)
- EYHGM: Leitfaden zur Logoverwendung, Rundschreiben 2026/1 und Seite zur Barrierefreiheit
- Türkische Gesetzesdatenbank (mevzuat.gov.tr): Gesetze Nr. 5378, Nr. 6701 und Nr. 6563
- TİHEK: Verwaltungsbußgelder 2026 und Pressemitteilung zum Rundschreiben 2025/10
- W3C: WCAG 2.2 und WCAG-Übersetzungen
- W3C: Web Accessibility Evaluation Tools List
- WebAIM: The WebAIM Million (2026)
- BFSG: § 1, § 2, § 3 und § 37
- React Native: Accessibility und Flutter: Semantics-Klasse