cerez.io Barrierefreiheitserklärung
Wir betreiben unsere eigene Website mit unserem eigenen Produkt. Diese Erklärung wurde nach den Standards EAA Article 13 + EN 301 549 + WCAG 2.2 AA erstellt, einschließlich unserer Mängel.
1. Konformitätsstatus
cerez.io WCAG 2.2 AA standardına göre şu an KISMİ UYUM durumundadır. Hedefimiz WCAG 2.2 AA TAM UYUM seviyesine ulaşmaktır.
"Teilweise konform" bedeutet: Der Großteil der Website (Navigation, Hauptinhalt, Formulare, Dokumentation) erfüllt die Barrierefreiheitskriterien; jedoch sind die in Abschnitt 2 unten aufgeführten Mängel noch nicht behoben. Die WCAG 2.2 AAA-Stufe ist nicht unser Ziel; auch die WCAG-Dokumentation selbst stellt fest, dass diese Stufe für die meisten Inhaltstypen nicht anwendbar ist.
| Standard | Zielstufe | Aktueller Status |
|---|---|---|
| WCAG 2.2 | Level AA | Teilweise konform |
| EN 301 549 v3.2.1 | Artikel 9 (Web) | Teilweise konform |
| EAA (Direktif 2019/882) | Article 13 | Erklärung veröffentlicht |
| Gesetz Nr. 5378 + KAİK | Vollständige Konformität | Teilweise konform |
2. Festgestellte Mängel (Ehrliche Liste)
Die folgenden Punkte sind tatsächliche Lücken, die durch manuelle Tests und automatisierte Werkzeuge (Lighthouse Accessibility, axe DevTools, Navigation nur per Tastatur) ermittelt wurden. Für jeden Punkt ist ein Zieldatum zur Behebung festgelegt. Im September 2026 behobene Punkte wurden aus dieser Liste entfernt; was getan wurde, ist unten gesondert aufgeführt.
Die Dropdown-Menüs "Produkte" und "Lösungen" im Header funktionieren mit der Maus einwandfrei; sie wurden jedoch nicht vollständig keyboard-only (Tab, Enter, Pfeiltasten, Escape) getestet. ARIA aria-expanded, aria-haspopup und Fokusverwaltung werden überprüft.
Bei einigen modalen Fenstern können die Attribute aria-modal="true" und role="dialog" fehlen. Wird ein Modal geschlossen, sollte der Fokus zum auslösenden Element zurückkehren, das es geöffnet hat; dieses Verhalten wird über alle Modals hinweg standardisiert.
Derzeit gibt es auf der Website keine Videoinhalte. Für demnächst hinzukommende Tutorial-Videos werden Untertitel (Closed Captions), Audiodeskription für sehbehinderte Nutzer und ein Transkript verpflichtend sein. Die WCAG-Kriterien 1.2.2, 1.2.3 und 1.2.5 werden angewendet.
Richtlinie: CC und Transkript werden vor der Veröffentlichung bereit sein
Die semantischen Elemente <nav>, <main>, <aside>, <footer> werden nicht auf allen Seiten konsistent verwendet. Auf einigen Seiten wurde ein div bevorzugt. Alle Seitenvorlagen werden überprüft und auf semantische HTML5-Elemente umgestellt.
Im September 2026 behobene Lücken
Die unten aufgeführten Punkte aus der Erklärung vom 31. Mai 2026 wurden behoben und durch Messung überprüft.
Am Anfang jeder Seite gibt es einen Link Zum Inhalt springen, der bei Tastaturfokus sichtbar wird und zum Hauptinhaltsbereich (main) führt.
Die zuvor mit 3,8 bis 4,3 angegebenen Bereiche wurden neu gemessen: Footer-Links 6,96:1, Footer-Überschriften 14,48:1, sekundärer grauer Text 4,83:1, Fließtext 7,65:1. Alle liegen über dem für WCAG AA erforderlichen Schwellenwert von 4,5:1.
Überprüft: 10. September 2026
Alle Felder in den Kontakt-, Registrierungs- und Anmeldeformularen sind mit einem expliziten <label for="..."> verknüpft. Das versteckte Spam-Fallenfeld im Newsletter-Formular hat zusätzlich ein aria-label erhalten, damit Screenreader einen Namen dafür ansagen.
Das Attribut alt wurde für Inhaltsbilder ergänzt, dekorative Bilder sind mit einem bewusst leeren alt="" gekennzeichnet. Zusätzlich wurden übersprungene Überschriftenebenen (etwa h5 nach h1) korrigiert, Datentabellen um caption ergänzt und externe Links, die in einem neuen Tab öffnen, mit einem Hinweis für Screenreader versehen.
3. Getestete Umgebungen
Diese Erklärung basiert auf Tests, die in den folgenden Umgebungen durchgeführt wurden. Der Umfang ist nicht vollständig; wir erweitern ihn weiter.
| Unterstützende Technologie | Plattform | Status |
|---|---|---|
| NVDA (Türkisch) | Firefox / Windows | Getestet |
| VoiceOver | Safari / macOS | Teilweise getestet |
| JAWS | Chrome / Edge / Windows | Geplant |
| TalkBack | Chrome / Android | Geplant |
| Keyboard-only-Navigation | Tab, Enter, Esc, Pfeiltasten | Getestet |
| Chrome DevTools Lighthouse | Accessibility-Audit | Wird kontinuierlich ausgeführt |
| axe DevTools (Deque) | Chrome-Erweiterung | Wird kontinuierlich ausgeführt |
4. Feedback und Kontakt
Wenn Sie ein Problem mit der Barrierefreiheit haben, eine Funktion nicht funktioniert oder eine Inkompatibilität mit Ihrer unterstützenden Technologie besteht, melden Sie sich bitte:
| Kanal | Kontakt |
|---|---|
| Spezielle Barrierefreiheits-Hotline | erisim@cerez.io |
| Allgemeiner Support | destek@cerez.io |
| Telefon | +90 540 059 40 40, Montag-Freitag 09:00-18:00 |
| +90 540 059 40 40 | |
| Kontaktformular | cerez.io/iletisim |
- Wir antworten innerhalb von 7 Tagen auf Ihre Anfrage.
- Wir verpflichten uns, das Problem innerhalb von 30 Tagen zu beheben (7 Tage bei kritischen, den Zugang blockierenden Problemen).
- Dauert die Behebung aus einem nachvollziehbaren Grund länger, informieren wir Sie und nennen ein neues Zieldatum.
5. Rechtsgrundlage
Diese Erklärung wurde im Rahmen der folgenden nationalen und internationalen Rechtsvorschriften erstellt:
- EAA (European Accessibility Act, Richtlinie 2019/882). In den EU-Mitgliedstaaten ab dem 28. Juni 2025 in Kraft. cerez.io fällt in den Geltungsbereich, da es Kundendienstleistungen für den EU-Markt anbietet.
- EN 301 549 v3.2.1. Der europäische harmonisierte Standard und das technische Pendant der EAA. Artikel 9 (Webinhalte), Artikel 10 (Nicht-Web-Dokumente) und Artikel 11 (Software) sind die relevanten Abschnitte.
- WCAG 2.2 (W3C). Web Content Accessibility Guidelines: Level A, AA und AAA. Unser Ziel ist Level AA.
- Gesetz Nr. 6701 über die Menschenrechts- und Gleichstellungsinstitution der Türkei. Verbot der Diskriminierung aufgrund einer Behinderung.
- Gesetz Nr. 5378 über Menschen mit Behinderungen. Das Recht von Menschen mit Behinderungen auf Zugang zu Informations- und Kommunikationsdiensten.
- Präsidialerlass Nr. 2019/12: Barrierefreiheit öffentlicher Webseiten und mobiler Anwendungen (KAİK). Verpflichtend für öffentliche Einrichtungen; eine Best-Practice-Referenz für die Privatwirtschaft.
- Section 508 (USA). Verpflichtend für Lieferanten, die mit Bundesbehörden Geschäfte machen. cerez.io Diese Konformität wird als Referenz für US-Kunden herangezogen.
6. Durchsetzungsverfahren (Beschwerderecht)
Wenn Sie mit unserer Antwort auf die bei uns eingereichte Barrierefreiheitsanfrage nicht zufrieden sind oder Ihre Anfrage unbeantwortet bleibt, haben Sie das Recht, bei den folgenden Institutionen Beschwerde einzulegen:
| Institution | Zuständigkeitsbereich |
|---|---|
| Behindertenföderation der Türkei | NGO-Unterstützung und Nachverfolgung: engelliler.gen.tr |
| KAİK (Einheit zur Überwachung und Prüfung der öffentlichen Barrierefreiheit) | Barrierefreiheitsprüfung öffentlicher Websites (ein Beratungsmechanismus für die Privatwirtschaft) |
| Menschenrechts- und Gleichstellungsinstitution der Türkei (TİHEK) | Diskriminierungsbeschwerden gemäß Gesetz Nr. 6701: tihek.gov.tr |
| Ombudsmann-Institution | Beschwerden gegen Verwaltungshandlungen: ombudsman.gov.tr |
| Ministerium für Familie und Soziales, Generaldirektion für Dienste für Menschen mit Behinderungen und ältere Menschen | Prüfung gemäß Gesetz Nr. 5378 |
7. Erstellung der Erklärung
| Methode | Manuelle Tests (Tastatur, NVDA, VoiceOver) + automatisierte Tools (Lighthouse, axe DevTools) + interne Team-Code-Review |
| Datum der Erstveröffentlichung | 31. Mai 2026 |
| Letzte Aktualisierung | 31. Mai 2026 |
| Nächste geplante Überprüfung | Alle 6 Monate |
| Unabhängiges Drittaudit | In Planung |
| Sprache der Erklärung | Türkisch (offiziell); englische und deutsche Übersetzungen folgen in Kürze |
8. Transparenzhinweis
Jede neu festgestellte Lücke wird noch am selben Tag hier veröffentlicht; nichts wird verschwiegen. Ist eine Behebung abgeschlossen, bleibt sie mit der Markierung "behoben" bestehen, damit der Verlauf nachvollziehbar bleibt.
Barrierefreiheit ist kein Ziel, sondern ein Prozess der kontinuierlichen Verbesserung. Es ist das Beispiel, das das Team hinter dem Produkt, das wir unseren Kundinnen und Kunden verkaufen, auf der eigenen Website geben sollte.
Auch Ihre eigene Website braucht eine EAA-Erklärung
EAA Article 13 schreibt für jeden digitalen Dienst eine Barrierefreiheitserklärung vor. Beginnen Sie Ihre eigene Erklärung mit dem Erklärungsgenerator und prüfen Sie sie vor der Veröffentlichung.