Teilweise, und die ehrliche Antwort hat drei Teile. Sie ist NICHT WCAG-zertifiziert und wurde nicht von Dritten geprüft: keine Seite dieser Website wird etwas anderes behaupten. Mehrere Grundlagen sind dennoch bauartbedingt vorhanden, weil die Oberfläche von einem deterministischen Programm geschrieben und nicht jedes Mal neu gezeichnet wird — sichtbarer Tastaturfokus, reduzierte Bewegung auf Systemwunsch, echte Formulare, keine nativen Dialogfenster. Bei jeder Generierung wird der Barrierefreiheitsbaum jedes Bildschirms erfasst und in einem Bericht veröffentlicht. Was fehlt, wird unten benannt statt verschwiegen. Und da der Code Ihnen gehört, ist eine Korrektur gewöhnliche Arbeit und kein Ticket bei einem Anbieter.
Was bauartbedingt gesichert ist, weil ein Programm die Oberfläche schreibt
Der Unterschied liegt darin, wer den Stift führt. Die Oberfläche wird nicht bei jeder Generierung von einem Modell gezeichnet: ein deterministischer Builder erzeugt sie aus einer gemeinsamen Komponentenbibliothek. Eine einmal gesetzte Garantie gilt daher für jeden Bildschirm jeder Anwendung, statt von der Eingebung des Tages abzuhängen. Das ist die nützlichste Eigenschaft dieser Architektur für die Barrierefreiheit, und sie ist kein Slogan: sie lässt sich Bildschirm für Bildschirm prüfen.
Konkret: jedes interaktive Element nimmt den Tastaturfokus an und zeigt einen sichtbaren Ring aus der Farbwelt der Anwendung — nicht den Standardring des Browsers, der auf farbigem Grund verschwindet — und derselbe Ring erscheint nicht beim Mausklick, wo er nichts beiträgt. Wer im System reduzierte Bewegung einstellt, erhält Übergänge von vernachlässigbarer Dauer. Eingabedialoge sind echte Formulare: die Eingabetaste bestätigt, das erste Feld erhält beim Öffnen den Fokus, und die Hauptschaltfläche ist eine Absendeschaltfläche.
Keine nativen Dialogfenster, und warum das eine gute Nachricht ist
Eine hier erzeugte Anwendung verwendet niemals das native Bestätigungsfenster des Browsers. Das Löschen einer Zeile geschieht in zwei Schritten innerhalb der Seite: ein erster Klick schärft die Aktion, ein zweiter bestätigt sie, und dazwischen kann man abbrechen. Dasselbe gilt für das Deaktivieren eines Kontos.
Diese Entscheidung fiel nicht wegen der Barrierefreiheit — sie kam aus einem Automatisierungsproblem und einer Frage der visuellen Sprache — doch ihre Folge ist real und gehört gesagt. Ein natives Fenster verlässt das Dokument, unterbricht den Lesefluss und wird je nach Browser und Hilfsmittel unterschiedlich angekündigt. Eine Bestätigung innerhalb der Seite bleibt in der Tabulatorreihenfolge, liest sich wie der Rest des Bildschirms und lässt Raum zum Zurücktreten, ohne eine modale Frage beantworten zu müssen.
Was bei jeder Generierung GEMESSEN wird — und was die Messung nicht verspricht
Vor der Auslieferung wird jede Anwendung in einem echten Browser geöffnet und Bildschirm für Bildschirm durchlaufen. Dabei wird nicht das Bild geprüft, sondern der Barrierefreiheitsbaum: die Struktur, die ein Screenreader durchläuft. Erfasst werden Schaltflächen, Links und Felder ohne zugänglichen Namen, übersprungene Überschriftenebenen, Bilder ohne Beschreibung sowie identische Beschriftungen, die außerhalb einer Liste wiederholt werden. Ein „ד zum Schließen gilt als unbenannt, weil ein Screenreader es als „Multiplikationszeichen“ vorliest.
Hier liegt der Punkt der Ehrlichkeit, und er ist entscheidend: es ist ein BERICHT, kein Tor. Es gibt weder Schwellenwert noch Urteil noch Blockade — ein Bildschirm mit unbenannten Bedienelementen wird bei der Auslieferung nicht zurückgehalten. Die Messung sagt also, was man über die Anwendung weiß; sie verspricht kein Konformitätsniveau. Eine Abdeckungszahl, die etwas anderes behauptete, wäre genau die Art von Versprechen, die diese Seite verweigert.
Was NICHT getan ist, und was Sie damit tun können
Drei Lücken, benannt. Eingabedialoge fangen den Fokus nicht ein: die Tabulatortaste kann einen offenen Dialog verlassen, obwohl sie darin kreisen sollte. Es ist keine Live-Region gesetzt: ein erfolgreiches Speichern, ein Fehler, eine aktualisierte Liste sind auf dem Bildschirm sichtbar, werden aber niemandem angekündigt. Und es gibt weder eine WCAG-Zertifizierung noch eine unabhängige Prüfung — wenn Sie also einer gesetzlichen Pflicht unterliegen, entbindet diese Anwendung Sie nicht davon und behauptet es auch nicht.
Was Sie damit tun können, unterscheidet diese Lage gerade von geschlossener Software. Der Code gehört Ihnen, er ist als Archiv oder in einem Repository abrufbar, und es ist ein gewöhnliches Next.js-Projekt: den Fokus in einem Dialog einzufangen oder eine Live-Region zu ergänzen sind klar umrissene, bezifferbare Frontend-Arbeiten, die jeder Dienstleister ausführen kann. Bei einem klassischen Anbieter ist derselbe Mangel ein Ticket, dessen Priorität und Termin Sie nicht steuern. Unterliegen Sie einer Regelung zur Barrierefreiheit, planen Sie Ihre Prüfung: sie ist ohnehin Pflicht, und hier sind ihre Ergebnisse umsetzbar.