Barrierefreiheit

Wie wir für Tastatur-, Screenreader-, Sehbehinderungs- und Low-Tech-Nutzer bauen. Ein ehrlicher, datierter Momentaufnahme.

Wir schreiben diese Seite so, wie der Rest der Website geschrieben ist: was funktioniert, was nicht, und wie man es selbst überprüft. Sie ist datiert, weil Barrierefreiheit ein bewegliches Ziel ist. Wir testen nach jeder Hauptversion erneut.

Formelle Barrierefreiheitserklärung

Angestrebte Norm

WCAG 2.2 AA für die gesamte Erfahrung. AAA-Behandlung bei der Fokusdarstellung (dicke kontrastreiche Ringe, nicht verdeckt) und bei der Formularetikettierung + Fehlerbehebung. Verfolgt anhand der W3C-Empfehlung, nicht einer Paraphrase.

Letztes internes Audit

2026-04-19. Manueller Durchlauf durch unser eigenes Team gegen die Homepage, print-size, den /standards/ Hub + 9 Autoritätsseiten und die 45 Zahlungsschema-Landingpages.

Externes Audit

Beauftragt, Bericht ausstehend. Veröffentlichung bei Eingang unter /accessibility/audit/ mit Behebungshinweisen, Mängel inklusive, kein Rosinenpicken.

Wiederholungsrhythmus

Monatliche Stichprobe + vollständiger manueller Durchlauf nach größeren UI-Änderungen. Automatisierte Prüfungen (Kontrastlinting, WCAG 2.2 Neue-Kriterien-Scan) laufen bei jedem Deployment.

Kontakt + SLA

hello@abundera.ai, wir bestätigen Barrierefreiheitsmeldungen innerhalb von 2 Werktagen, triagieren innerhalb von 5 und behandeln Tastatur-/Screenreader-/kognitive Blocker als Prioritätsprobleme (werden vor Funktionsarbeit ausgeliefert).

WCAG 2.2 AA-Konformität nach Erfolgskriterium

Die neuen Kriterien in Version 2.2, die wir aktiv beobachten. Der Status spiegelt wider, was wir intern verifiziert haben; das externe Audit wird Vorrang haben.

Unterstützung für Bewegung und erzwungene Farben

• prefers-reduced-motion: reduce, Umgebungsschwebungen und Einblendübergänge werden unterdrückt. Funktionale Übergänge bleiben kurz. Verifiziert mit macOS Reduce Motion und Windows "Animationen anzeigen" deaktiviert.
• forced-colors: active (Windows Hoher Kontrast Modus), Fokusringe verwenden die System-Highlight-Farbe; Ränder erben SystemCanvasText. Verifiziert in Edge auf Windows 11 High Contrast.

Bekannte Einschränkungen

• JAWS noch nicht getestet. Die nächste AT-Runde zielt auf JAWS auf Edge auf Windows 11.
• Der Visitenkarten-Designer ist vom Design her mausorientiert für die Drag-to-Position-Vorschau. Jedes Steuerelement hat eine Tastaturalternative, aber die Live-Feedback-Schleife ist noch visuell. Farbeingaben, Preset-Raster und Hex-Felder haben jetzt explizite ARIA-Bindungen (2026-04-19).
• Der externe Auditbericht steht aus. Der selbst bestätigte Status in der obigen Tabelle wird durch die Erkenntnisse des Prüfers ersetzt, wenn der Bericht eintrifft.
• Einige Drittanbieter-Hilfstechnologien (Dragon NaturallySpeaking, Speech-to-Text auf Android) sind nicht in unserer Regressionsmatrix; wir akzeptieren Community-Berichte und beheben pro Ticket.

Barrierefreiheits-Changelog

• 2026-04-19 (PM), TalkBack Live-Region-Doppelauslösung behoben: aria-live="polite" aus dem #qr-preview-Wrapper entfernt; Ankündigungen kommen jetzt nur noch vom Scannbarkeits-role="status"-Badge, einmal pro Generierung. BCD-Modal: Farbwähler erhielten korrekte <label for>-Bindungen (Hintergrund, Text, Akzent, Verlauf); Preset-Raster-Container erhielt role="group" + aria-label. Barrierefreiheitstabellen erhielten <caption> + scope="col"/"row", WCAG 2.2 AA + AT-Matrix werden jetzt korrekt auf VoiceOver, NVDA und TalkBack angekündigt.
• 2026-04-19 (AM), Fokusindikatoren verbessert (3 px + Box-Shadow-Backup). Unterstützung für forced-colors + prefers-reduced-motion hinzugefügt. Zielgrößenaudit: .saved-profile-delete, .type-search-clear, .compat-toggle-btn auf ≥ 28 px erhöht. Überschriftenebenensprung behoben (vCard/MECARD-Unterüberschriften h4 → h3). Formelle WCAG 2.2 AA-Erklärung + AT-Matrix veröffentlicht.
• 2026-04-18, Manueller WCAG 2.2 AA-Basisdurchlauf dokumentiert. Vier-Säulen-Vertrauensstreifen für sauberere Hierarchie reduziert.
• 2026-03-08, Erste /accessibility/-Seite veröffentlicht.

Wozu wir uns verpflichten

• Vollständige Tastaturnavigation. Jedes Generatorsteuerelement, jedes Modal und jeder Exportablauf ist ohne Maus erreichbar.
• Sichtbare Fokusstatus. Fokussierte Eingaben, Schaltflächen und Links zeigen einen klaren Ring. Wir verlassen uns nicht allein auf Farbe.
• Beschriftungen auf jedem Feld. Formulareingaben haben zugehörige <label>-Elemente oder aria-label-Attribute. Platzhaltertext wird niemals als einzige Beschriftung verwendet.
• ARIA-Live-Regionen für die QR-Vorschau und Toasts. Screenreader hören "QR generiert" und Toast-Nachrichten, wenn sie ausgelöst werden, nicht erst wenn der Fokus zu ihnen wechselt.
• Textalternativen für Icon-only-Schaltflächen. aria-label auf jeder SVG-only-Schaltfläche.
• Farb-unabhängige Statusbedeutung. Scannbarkeits-Badges und Kompatibilitätschips verbinden Farbe mit einem Glyphen und einer Textbeschriftung.
• Explizite Exportformatnamen. Download-Schaltflächen sagen "PNG herunterladen", "SVG herunterladen" usw., nicht nur "Herunterladen".
• Große mobile Tippziele. Interaktive Elemente sind mindestens 44 × 44 CSS-Pixel auf groben Zeigern, gemäß WCAG 2.5.8.
• Respekt vor reduzierter Bewegung. Übergänge sind unter prefers-reduced-motion: reduce deaktiviert.

Wo wir noch Mängel haben

• JAWS noch nicht getestet. JAWS-Lizenz erworben, Testslot für die nächste AT-Runde gebucht. Alle anderen Hauptanwendungen (VoiceOver macOS + iOS, NVDA, Narrator, TalkBack) haben die jüngste Regression bestanden.
• Der Visitenkarten-Designer ist designbedingt mauslastig (Drag-to-Position, Canvas-Vorschau). Tastaturalternativen existieren für jedes Steuerelement, aber die Live-Vorschau-Feedback-Schleife ist noch visuell-first. Farbsteuerelemente verwenden jetzt korrekte <label for>-Bindungen + role="group" auf dem Preset-Picker (2026-04-19).
• Komplexe Generatorabläufe (Batch-CSV, mehrstufiger Assistent) könnten eine bessere Skip-Link-Struktur gebrauchen. Geplant.
• Beschreibende Tabellenzusammenfassungen. Barrierefreiheits- + Kompatibilitätstabellen haben jetzt <caption> + scope-Attribute (2026-04-19). Längere zeilenweise Erzählzusammenfassungen für jede Zeile sind noch geplant.

Matrix der Hilfstechnologieunterstützung

Ingenieursartefakt, keine PR-Erklärung. Jede Zeile ist eine echte Browser + AT + Plattform-Kombination, die wir physisch in den Händen gehalten haben. Der Status spiegelt den letzten manuellen Durchlauf wider; Vorbehalte verzeichnen alles, was noch einen vollständigen Durchlauf blockiert.

Release-Rhythmus: Matrix wird gegen jeden größeren UI-Änderung neu ausgeführt. "Bestanden" = kein Blocker; Vorbehalte sind kosmetische oder eng begrenzte Regressionen, die für die nächste Version in der Warteschlange stehen. "Nicht getestet" = wir haben die Kombination noch nicht physisch ausgeführt, wir sagen es, anstatt es auszulassen.

Tastaturkarte

• Tab / Shift+Tab: vorwärts / rückwärts durch fokussierbare Elemente navigieren.
• Enter / Leertaste: Schaltflächen und Schalter aktivieren.
• Pfeiltasten: zwischen Optionen in einer Radiogruppe wechseln (Typauswahl, Vorlagenauswahl, Tab-Leiste).
• Escape: Modals schließen (Visitenkarten-Designer, Preflight, Druckdienste, Bildzuschnitt).
• Pos1 / Ende in einem Überlaufmenü zum ersten / letzten Element springen.

Internes Audit, 2026-04-19

Manueller WCAG 2.2 AA-Durchlauf gegen die Homepage, /print-size/, den neuen /standards/ Hub + 9 Autoritätsseiten und die 45 Zahlungsschema-Landingpages (die vom gemeinsamen Template erben). Was wir verifiziert haben, was wir behoben haben und was offen ist:

Als bestanden verifiziert

• Skip-Link-Ziel existiert, der Skip-Link (href="#generator") verweist auf ein sichtbares Element auf jeder Seitenvariante.
• Fokus-sichtbare Stile, :focus-visible ist global mit einem 2px-Umriss deklariert, plus pro-Eingabe-Überschreibungen mit einem farbigen Rand + Schatten. Bestätigt durch CSS-Audit bei den Zeilen 34 und 88 von site/css/style.c17bfd85.css.
• Alle Formulareingaben haben Beschriftungen, jedes <input> / <select> / <textarea> im Generator hat entweder ein explizites <label for="..."> oder ein umschließendes <label>. Platzhalter als Beschriftung wird nirgendwo verwendet.
• Schaltflächen haben zugängliche Namen, jede <button> hat entweder Textinhalt oder ein aria-label. SVG-only-Schaltflächen (Hamburger, Teilen, Installieren) tragen alle aria-label.
• Dekorative SVGs als versteckt markiert, aria-hidden="true" auf jedem dekorativen Symbol, damit Screenreader sie überspringen, anstatt ihre Geometrie anzukündigen.
• Korrekte ARIA-Rollen, role="radiogroup" auf dem Typauswähler mit role="radio" + aria-checked auf jeder Option; role="tablist" / role="tab" + aria-selected auf den Panel-Tabs.
• Textkontrast, primärer Text ist #f5f5f5 auf #08090a (≈ 17:1, WCAG AAA). Gedämpfter Text #a3a3a3 auf demselben Hintergrund ist ≈ 8:1 (über AAA 7:1).
• Sprachauswähler hat aria-label="Language", obwohl die sichtbare Beschriftung implizit ist.

In diesem Durchlauf behoben

• Überschriftenebenensprung, drei Unterüberschriften in den vCard / MECARD Extra-Felder-Abschnitten waren <h4> unter einem <h2> ohne zwischenliegendes <h3>. Screenreader-Gliederungstools flaggten dies als "übersprungene Ebene." Zu <h3> geändert, damit die Gliederung h1 → h2 → h3 → h3 sauber liest.

Bekannte Einschränkungen

• Vollständiger Axe / NVDA / VoiceOver-Sweep erfordert einen Browser + AT, den wir nicht aus der Build-Pipeline heraus ausführen können. Manueller browserbasierter Durchlauf monatlich geplant.
• Unabhängiges Drittparteienaudit ist beauftragt (siehe Platzhalter /accessibility/audit/). Der Bericht wird bei Eingang veröffentlicht, auch wenn er Erkenntnisse enthält.
• Das "/" Tastaturkürzel für die Befehlspalette ist ein leichtes Kollisionsrisiko auf Seiten mit Suchfeldern. Wir verwenden preventDefault() nur wenn der Fokus außerhalb einer Eingabe ist; dokumentiert, aber noch nicht mit AT auditiert.

Ein Problem melden

Wenn etwas per Tastatur nicht erreichbar, falsch beschriftet oder anderweitig mit Ihrer Konfiguration nicht nutzbar ist, senden Sie eine E-Mail an hello@abundera.ai. Geben Sie Ihren Browser, das Betriebssystem, AT und den spezifischen Ablauf an. Wir behandeln Barrierefreiheitsfehler als Prioritätsprobleme.

Zuletzt überprüft: 2026-04-19. Nächste Überprüfung: nach der nächsten größeren UI-Änderung.