Barrierefreiheit

Erklärung zur Barrierefreiheit

Wir möchten, dass diese Website für alle nutzbar ist — unabhängig von Endgerät, Hilfstechnologie oder Beeinträchtigung. Diese Seite beschreibt, was wir bereits umgesetzt haben und wie Sie uns erreichen, wenn Sie auf eine Barriere stoßen.

Standards

Diese Website wird nach den Web Content Accessibility Guidelines (WCAG) 2.2 Stufe AA als Zielvorgabe entwickelt, erfüllt WCAG 2.1 Stufe AA und orientiert sich an den Anforderungen des Barrierefreiheitsstärkungsgesetzes (BFSG) sowie der EU-Richtlinie über die Barrierefreiheit (EAA).

Geltungsbereich

Diese Erklärung bezieht sich auf die Website cordata.tech — Marketingseiten, Blog und Kontaktformular. Die Beratungsdienste von Cordata werden im Rahmen von B2B-Verträgen erbracht und fallen weitgehend außerhalb des Anwendungsbereichs des BFSG, das primär für Verbraucher-E-Commerce, Banken, Verkehr und Telekommunikation gilt. Wir orientieren uns dennoch freiwillig an dessen Grundsätzen — Barrierefreiheit ist gutes Engineering.

Was wir umgesetzt haben

Ausreichender Farbkontrast für Fließ- und Sekundärtext in hellem und dunklem Theme; semantische HTML-Landmarken (main, nav, footer) und ein Sprunglink zum Hauptinhalt; sichtbare Tastatur-Fokusindikatoren für alle interaktiven Elemente; Formularfelder mit zugeordneten Labels und Autocomplete-Hinweisen; dekorative Symbole und Emojis sind als solche für Screenreader gekennzeichnet; fremdsprachige Eigennamen (z. B. ungarische Rechtsbegriffe im Impressum) sind mit dem korrekten lang-Attribut ausgezeichnet, damit die Sprachausgabe natürlich bleibt; vollständige Unterstützung für prefers-reduced-motion — alle nicht-essenziellen Animationen werden auf Wunsch des Betriebssystems deaktiviert.

Prüfmethode

Die Prüfung erfolgt fortlaufend und wird von uns selbst durchgeführt; was sich automatisieren lässt, ist automatisiert, damit es nicht übersprungen werden kann. Der Farbkontrast wird bei jedem Build gemessen: Ein Browser ohne Oberfläche öffnet jede Seite im hellen und im dunklen Design, liest für jeden Text die Farbe aus, die nach Auflösung aller Stilregeln tatsächlich dargestellt wird, und bricht den Build ab, sobald ein Wert unter dem für seine Schriftgröße geltenden Schwellenwert nach WCAG 2.1 AA liegt. Das Layout wird auf dieselbe Weise geprüft, bei 320, 375 und 390 Pixeln Breite — der schmalsten von WCAG geforderten Breite und den beiden häufigsten Telefonbreiten: Der Build bricht ab, sobald horizontal gescrollt werden muss, ein Menü-Bedienelement fehlt oder ein solches kleiner als 44 mal 44 Pixel ist. Der Build bricht ebenfalls ab, wenn eine englische Passage ohne lang-Attribut in deutschem Fließtext auftaucht. Der übrige Teil erfolgt manuell: Lighthouse und axe DevTools auf geänderten Seiten, Tastaturnavigation für interaktive Elemente sowie stichprobenartige Screenreader-Kontrollen mit macOS VoiceOver. Eine externe Barrierefreiheitsprüfung haben wir bislang nicht beauftragt.

Kompatibilität

Die Website wird gegen aktuelle Versionen von Chrome, Firefox und Safari auf macOS sowie Chrome und Safari auf Mobilgeräten getestet. Zusätzlich wird bei jedem Build jede Seite in Telefonbreite gerendert, sodass das Layout in den Größen geprüft wird, in denen es tatsächlich gelesen wird, und nicht nur am Schreibtisch. Screenreader-Stichproben erfolgen mit VoiceOver unter macOS und iOS. Wenn Sie Probleme mit einem Browser oder einer Hilfstechnologie feststellen, die wir nicht getestet haben, melden Sie es uns bitte.

Bekannte Einschränkungen

Eine externe Barrierefreiheitsprüfung haben wir bislang nicht beauftragt. Sollten Sie Inhalte finden, die WCAG 2.1 AA nicht erfüllen — etwa ein fehlendes Label, zu geringen Kontrast oder eine nicht per Tastatur erreichbare Funktion — betrachten wir das als Mangel, nicht als Feature-Wunsch. Eine frühere Fassung dieser Erklärung führte eine Lücke nach WCAG 3.1.2 (Language of Parts) auf, weil englische Fachbegriffe innerhalb deutscher Seiten kein lang-Attribut tragen. Bei erneuter Prüfung war das zu viel des Guten: Das Kriterium nimmt Eigennamen und Fachbegriffe ausdrücklich aus, und genau darum handelt es sich. Echte englische Passagen in deutschem Fließtext — etwa ein wörtliches Zitat aus einer Hersteller-Dokumentation — tragen lang="en", und eine Prüfung in unserer Build-Pipeline bricht das Deployment ab, falls doch einmal eine ohne auftaucht.

Kontakt

Wenn Sie eine Barriere auf dieser Website feststellen, schreiben Sie uns bitte eine E-Mail. Wir bemühen uns, Meldungen innerhalb von fünf Werktagen zu bestätigen und in angemessener Zeit zu beheben oder einen Workaround zu dokumentieren.

[email protected]

Stand: 14. September 2026