Barrierefreiheitszertifikat – Startseite
Kostenlos prüfen Menü

Kanal · Web-Apps

Web-Apps, die auch ohne Maus funktionieren

In einer Web-App ändert sich der Inhalt, ohne dass die Seite neu lädt. Genau da gehen Fokus und Ansagen verloren. Wir prüfen, ob Tastatur- und Screenreader-Nutzer mitkommen.

Kostenlos prüfenAudit anfragen
Eine Frau steht in der Abendsonne auf der Straße und schaut aufmerksam auf das Smartphone in ihren Händen.

Warum Web-Apps eine eigene Prüfung brauchen

Eine klassische Website lädt bei jedem Klick neu. Der Screenreader beginnt oben, der Titel ändert sich. In einer Single-Page-App passiert das nicht von selbst. Darum muss die App selbst dafür sorgen, dass Fokus, Titel und Ansagen stimmen.

Dazu kommen eigene Bedienelemente: Kombinationsfelder, Reiter, Baumansichten, Dialoge. Jedes braucht die richtige Rolle, einen Namen und eine Tastaturbedienung.

Unser Scanner sieht nur, was ohne Anmeldung erreichbar ist. Den eingeloggten Bereich prüft im Audit ein Mensch, mit einem Testzugang und im vorher vereinbarten Umfang. Das Zertifikat nennt genau diese Version.

Worauf wir in Web-Apps achten

Fokusführung

Wohin springt der Fokus nach dem Öffnen und Schließen eines Dialogs, nach dem Löschen eines Eintrags, nach einem Seitenwechsel?

Dialoge und Seitenleisten

Modale Dialoge müssen den Fokus halten und mit Escape schließen. Was dahinter liegt, darf nicht erreichbar sein.

Dynamische Inhalte

Nachladende Listen, Live-Suche, Benachrichtigungen. Was sich ändert, muss angesagt werden, aber ohne Dauerbeschallung.

Eigene Komponenten

Auswahllisten, Reiter, Schalter und Menüs müssen sich verhalten wie ihre Vorbilder im Browser.

Tabellen und Diagramme

Daten brauchen eine Textalternative oder Tabelle. Sortierung und Filter müssen mit Tastatur gehen.

Die wichtigsten Kriterien für Web-Apps

  • 4.1.2Name, Rolle, Wert

    Jede eigene Komponente braucht Name, Rolle und Zustand, etwa „aufgeklappt“ oder „ausgewählt“.

  • 4.1.3Statusmeldungen

    Statusmeldungen müssen ohne Fokuswechsel angesagt werden, zum Beispiel über eine Live-Region.

  • 2.4.3Fokus-Reihenfolge

    Die Fokus-Reihenfolge muss dem Ablauf folgen, auch nach dynamischen Änderungen.

  • 2.1.2Keine Tastaturfalle

    Keine Tastaturfalle: Aus jedem Widget muss man mit der Tastatur wieder herauskommen.

  • 2.4.11Fokus nicht verdeckt (Minimum)

    Neu in WCAG 2.2: Feste Leisten dürfen den Fokus nicht komplett verdecken.

  • 3.2.2Bei Eingabe

    Eine Auswahl darf nicht ungefragt die Ansicht wechseln oder ein Formular absenden.

So prüfen wir Ihre Web-App

  1. Umfang vereinbaren

    Ansichten, Rollen, Nutzerwege und Versionsnummer. Bis 15 Seiten und ein Nutzerweg ab 1.490 Euro, bis 40 Seiten und drei Wege für 2.990 Euro, größere Apps auf Anfrage.

  2. Testzugang

    Ein Testkonto mit Beispieldaten, idealerweise in einer Testumgebung.

  3. Prüfung von Hand

    Alle 55 Kriterien, Tastatur, Zoom und Screenreader (NVDA oder VoiceOver).

  4. Bericht und Nachprüfung

    Befunde mit Fundstelle. Nach der Korrektur prüfen wir die durchgefallenen Kriterien erneut.

Häufige Fragen

Wir nutzen ein UI-Framework mit barrierefreien Komponenten. Reicht das?

Es hilft. Entscheidend ist, wie Sie die Komponenten zusammensetzen: Beschriftungen, Fokusführung nach Aktionen und eigene Erweiterungen. Das prüfen wir im Zusammenspiel.

Kann der Scanner unseren Login-Bereich prüfen?

Nein. Der Scanner meldet sich nirgends an und schickt keine Formulare ab. Den eingeloggten Bereich prüft ein Mensch im Audit.

Was passiert mit dem Zertifikat beim nächsten Release?

Es gilt für die geprüfte Version. Kleinere Änderungen an öffentlichen Seiten überwacht das Monitoring. Große Änderungen im eingeloggten Bereich brauchen eine neue Prüfung.

Passend dazu