Das Präsidialrundschreiben und die Ministeriums-Checkliste.

Das türkische Präsidialrundschreiben vom 24. Juni 2025 nimmt für die Websites und mobilen Anwendungen öffentlicher Einrichtungen WCAG 2.2 Stufe A als Referenz.

Diese Seite erklärt, was das Rundschreiben sagt und was es praktisch bedeutet. Eine Warnung vorweg: Nichts hiervon ist Rechtsberatung. Der Umfang Ihrer Verpflichtung hängt vom Status Ihrer Einrichtung und Ihren Verträgen ab; eine verbindliche Antwort verlangt juristischen Rat. Das Folgende ist der technische Rahmen.

Was das Rundschreiben sagt

Das Rundschreiben setzte die Barrierefreiheit der Websites und mobilen Anwendungen öffentlicher Einrichtungen auf die Tagesordnung und verwies als technische Referenz auf WCAG 2.2, als Konformitätsstufe auf A. Also kein abstraktes „es soll barrierefrei sein“, sondern ein Verweis auf einen internationalen Standard und eine bestimmte Stufe dieses Standards.

Dieser Verweis zählt, weil er Messbarkeit bringt. „Eine barrierefreie Website“ ist ein strittiger Begriff; „eine Website, die die 31 Erfolgskriterien der Stufe A von WCAG 2.2 erfüllt“ ist es nicht — sie erfüllt sie oder nicht, und jedes Kriterium lässt sich einzeln prüfen.

Die Ministeriums-Checkliste: 31 Kriterien, 126 Fragen

Nach dem Rundschreiben veröffentlichte das Ministerium für Familie und Soziale Dienste eine Bewertungs-Checkliste. Sie nimmt die 31 Erfolgskriterien der Stufe A von WCAG 2.2 und entfaltet sie in 126 Bewertungsfragen, gruppiert unter den vier Prinzipien: wahrnehmbar, bedienbar, verständlich, robust.

Die Entfaltung von 31 auf 126 ist kein Zufall. Ein Erfolgskriterium deckt meist mehrere Situationen ab — das Kriterium „Nicht-Text-Inhalte“ etwa betrifft Bilder, Icons, Diagramme, CAPTCHAs und dekorative Elemente je für sich. Indem die Checkliste diese Situationen in einzelne Fragen übersetzt, nimmt sie der Prüfung die Subjektivität.

Der eigentliche Wert der Liste ist nicht ihr Umfang, sondern dass sie die Debatte beendet.

Praktisch heißt das für ein Team vor einer Ausschreibung oder Prüfung: Die Vorbereitung besteht nicht im Auslegen des WCAG-Textes, sondern darin, auf jede der 126 Fragen eine belegbare Antwort zu erzeugen. Die Antworten sollten nicht „ja/nein“ lauten, sondern „auf diesem Bildschirm, auf diese Weise erfüllt“.

Wen es bindet, wen es betrifft

Das Rundschreiben bindet direkt die öffentlichen Einrichtungen. Aber seine Wirkung endet dort nicht — und das ist der Punkt, den die meisten Teams in der Privatwirtschaft übersehen.

1. Öffentliche Einrichtung — direkt im Geltungsbereich. Website und mobile Anwendung.
2. Zulieferer, der Software oder Websites an die öffentliche Hand verkauft — über den Vertrag indirekt im Geltungsbereich. Das gelieferte Produkt muss die Verpflichtung des Käufers erfüllen.
3. Agentur in einer öffentlichen Ausschreibung — sollte in der Leistungsbeschreibung eine Barrierefreiheitsklausel erwarten.
4. Privatunternehmen mit Firmenkunden — das Rundschreiben bindet es nicht, aber die Lieferantenprüfungen des Käufers können es.
5. KMU und private Websites — nicht im Geltungsbereich. Eine indirekte Wirkung bleibt möglich, wenn ein Kunde dem EU-Barrierefreiheitsgesetz unterliegt.

Die richtige Frage lautet also womöglich nicht „bindet mich dieses Rundschreiben“, sondern „bindet es meinen Kunden“. Als Zulieferer barrierefrei zu liefern bringt den Kunden durch die Prüfung — und das wird zunehmend ein Verkaufsargument.

Genügt Stufe A

Das Rundschreiben nimmt Stufe A als Referenz. Aber A ist die Basis: Es umfasst die Kriterien, ohne die Inhalte für manche Nutzer völlig unzugänglich sind. Für ein brauchbares Erlebnis genügt es im Allgemeinen nicht.

Ein konkretes Beispiel: Das Kontrastverhältnis kommt auf Stufe A gar nicht vor. 1.4.3 „Kontrast (Minimum)“ liegt auf AA. Eine nur auf A zielende Website könnte ihren Fließtext mit 2:1 Kontrast gegen den Grund veröffentlichen und technisch als konform gelten — doch dieser Text ist für jemanden mit geringer Sehschärfe unlesbar, und auf dem Telefon in der Sonne für alle.

Dasselbe gilt für den Fokusindikator: 2.4.7 „Fokus sichtbar“ liegt auf AA. Stufe A verlangt Tastaturzugang, aber nicht die Sichtbarkeit des Fokus — eine Website, die sich per Tastatur bedienen lässt, ohne dass Sie je sehen, wo Sie sind, kann A-konform sein.

Der praktische Rat lautet deshalb: Auch wenn dem Rundschreiben A genügt, setzen Sie das Ziel auf AA. Der Aufstieg zu AA besteht in den meisten Projekten aus einer Kontrastkorrektur und einem Fokusring — Arbeit von wenigen Tagen. Seit 2026 gilt AA ohnehin als De-facto-Standard für die öffentliche Hand und größere Unternehmen.

Vorbereitung: eine praktische Reihenfolge

Für ein Team, das sich auf eine Prüfung vorbereitet, gibt es vier Dinge, bevor die Checkliste Frage für Frage abgeschritten wird. Sie schließen einen großen Teil der Fragen gesammelt.

1. Eine Tastaturtour — die Website ohne Maus von Anfang bis Ende benutzen. Die meisten Fragen des Prinzips Bedienbarkeit werden hier beantwortet.
2. Semantische Bereinigung — Überschriftenhierarchie, Landmarkenstruktur, Formularetiketten. Die Basis der Prinzipien Robustheit und Verständlichkeit.
3. Ein Alternativtext-Inventar — der Status jedes Bildes muss entschieden werden: informativ oder dekorativ. Das dekorative erhält einen LEEREN Alternativtext, keine Auslassung.
4. Eine Beweisakte — für jede Frage kein Bildschirmfoto, sondern eine wiederholbare Messung. Wird die Prüfung erneuert, muss derselbe Beleg reproduzierbar sein.

Der letzte Punkt wird am häufigsten übersprungen und kostet am meisten. Eine einmalige Barrierefreiheitskorrektur zerfällt lautlos in den nächsten drei Deployments. Ist der Beleg an eine reproduzierbare Messung gebunden — einen automatischen Test, ein Prüfskript — zeigt sich der Zerfall sofort. Ist er es nicht, wird er bei der nächsten Prüfung neu entdeckt.

Was die 126 Fragen unter den vier Prinzipien fragen

Die Checkliste verteilt ihre Fragen auf die vier Prinzipien, und die Verteilung zeigt, wo die Prüfung ihr Gewicht legt. Sie zu kennen hilft, die Vorbereitungszeit richtig zu verteilen.

1. Wahrnehmbar — Alternativen für Nicht-Text-Inhalte, Transkripte für Audio und Video, Information nicht allein durch Farbe oder Form, skalierbarer Text.
2. Bedienbar — jede Funktion per Tastatur, keine Fokusfallen, einstellbare Zeitlimits, kein anfallauslösendes Blinken, aussagekräftige Seitentitel.
3. Verständlich — die Seitensprache deklariert, Fokus ohne unerwartete Kontextwechsel, Fehler benannt, Formularfelder etikettiert.
4. Robust — Markup für Hilfstechnologien interpretierbar, Bedienelemente melden das Tripel Name-Rolle-Wert korrekt.

Ein Punkt verdient Beachtung: Keines dieser Prinzipien trägt die Überschrift „visuelles Design“. Stufe A ist eine fast vollständig strukturelle und semantische Prüfung — sie schaut, ob das HTML richtig geschrieben ist. Die visuellen Posten (Kontrast, Fokussichtbarkeit) beginnen auf AA.

Die in Prüfungen am häufigsten durchgefallenen Klauseln

Die wiederkehrenden Fehler auf türkischen öffentlichen Websites und in Unternehmensprojekten ähneln einander. Vier erklären den Großteil der Liste, und alle vier sind billig zu beheben.

Formularetiketten. Texte, die visuell wie Etiketten wirken, aber programmatisch nicht ans Feld gebunden sind, sind der häufigste Fehler. Der Screenreader sagt „Eingabefeld“ und kann nicht sagen, welches. Die Lösung ist, das Etikett-Element ans Feld zu binden; Platzhaltertext ersetzt kein Etikett.

Bildalternativen. Fehler an beiden Enden: das informative Bild ohne Alternative, und das dekorative Bild mit Dateinamen oder einem sinnleeren Text wie „Bild“ etikettiert. Die richtige Alternative des dekorativen Bildes ist LEER — so überspringt es der Screenreader.

Überschriftenhierarchie. Nach visueller Größe gewählte Überschriftenebenen (h4 verwenden, damit es klein aussieht) brechen die Dokumentstruktur. Der Screenreader-Nutzer navigiert die Seite nach Überschriften; eine kaputte Hierarchie zerstört sein Inhaltsverzeichnis.

Seitensprache. Eine fehlende oder falsche Sprachangabe am Wurzelelement lässt den Screenreader den Text falsch aussprechen. Türkischer Inhalt, von einer englischen Sprachausgabe gelesen, ergibt für den Hörer etwas Unverständliches. Eine einzeilige Korrektur, eine große Wirkung.

Das Verhältnis zum European Accessibility Act

Das Rundschreiben in der Türkei steht nicht allein; es ist Teil eines internationalen Trends. Der European Accessibility Act bringt Barrierefreiheitspflichten für Unternehmen, die Produkte oder Dienste auf dem EU-Markt anbieten, und seine technische Referenz ist wieder die AA-Stufe der WCAG.

Das trägt direkte Bedeutung für türkische Unternehmen mit Export oder EU-Kunden: Auch wo das Rundschreiben sie nicht bindet, sind ihre Kunden gebunden, und die Pflicht fließt die Lieferkette hinab in die Verträge. Wenn ein Hersteller, der eine mehrsprachige B2B-Website baut, sich um Barrierefreiheit kümmert, ist der Grund nicht Wohltätigkeit — es ist Marktzugang.

Die praktische Folge: AA als Basis zu nehmen erfüllt das Rundschreiben in der Türkei mit Reserve und zugleich die Erwartung auf EU-Seite. Auf einen Standard hinzuarbeiten statt zwei getrennte Konformitätsprojekte zu führen ist auf lange Sicht deutlich günstiger.

Konformität ist stetig, nicht einmalig

Das Teuerste an Barrierefreiheitsprüfungen ist nicht die Korrektur selbst, sondern ihr Zerfall. Eine einmalige Verbesserung wird in den nächsten drei Deployments lautlos zurückgenommen: Eine neue Komponente entfernt den Fokusring, eine neue Farbe senkt den Kontrast, ein neues Bild kommt ohne Alternative.

Die einzige echte Lösung ist, Barrierefreiheitsentscheidungen an den Code zu binden statt an menschliche Aufmerksamkeit. Werden die Kontrastverhältnisse in der Palettendatei berechnet und an einen Test gebunden, kann das falsche Farbpaar nicht ins Deployment. Ist der Fokusring ein Token, lässt er sich nicht vergessen. Ist der Alternativtext ein Pflichtfeld, kann er nicht leer bleiben.

Die Prüfung zu bestehen dauert einen Tag; bestanden zu bleiben verlangt ein System.

Die konkrete Form dieses Ansatzes: Jede Barrierefreiheitsentscheidung bekommt einen Wächter, und der Wächter läuft bei jedem Deployment. Taucht ein Fehler auf, zeigt er sich in diesem Deployment, nicht bei der nächsten Prüfung — und die Behebung dauert Minuten, nicht Tage.