DIE KURZE ANTWORT
Beginnen Sie mit einer echten Aufgabe: eine Leistung finden und eine Anfrage vorbereiten. Versuchen Sie den Weg ohne Maus. Achten Sie darauf, ob Bedienelemente erreichbar sind, der Fokus sichtbar bleibt und Formulare verständlich reagieren. Das liefert konkrete Hinweise für Verbesserungen. Es ist eine erste praktische Sichtung und noch kein vollständiger Nachweis der Barrierefreiheit.
Eine Aufgabe ist aussagekräftiger als ein kurzer Rundgang
Für einen sinnvollen Versuch wählen Sie eine typische Besuchersituation. Ein Interessent möchte beispielsweise eine bestimmte Leistung finden, Rückfragen klären und die Kontaktmöglichkeit erreichen. Notieren Sie vorher, woran ein erfolgreicher Abschluss erkennbar ist. So schauen Sie nicht nur, ob einzelne Tasten etwas auslösen, sondern ob der gesamte Weg verständlich bleibt.
Starten Sie mit der öffentlichen Website und arbeiten Sie mit Beispieldaten. In einem Produktivformular würde ich keine Testanfrage absenden, ohne den Betreiber vorher einzubeziehen. Für die spätere technische Abnahme ist eine geeignete Testumgebung besser: Dort lassen sich auch Fehler und Übertragungen kontrolliert ausprobieren.
Navigation ohne Maus ausprobieren
Mit Tab wechseln Sie typischerweise zwischen Bedienelementen, mit Umschalt und Tab in die Gegenrichtung. Links und Schaltflächen lassen sich je nach Element mit Eingabe oder Leertaste bedienen. Die genaue Steuerung hängt von der Komponente ab. Entscheidend ist, dass sich ihre Funktion grundsätzlich über eine Tastaturschnittstelle ausführen lässt.
Prüfen Sie besonders Menüs, Dialoge und eingebundene Elemente. Der Fokus darf dort nicht so hängen bleiben, dass der weitere Weg nur noch per Maus erreichbar ist. Notieren Sie die betroffene Seite, den Auslöser und den letzten erreichbaren Schritt. Eine nachvollziehbare Fehlerbeschreibung spart bei der Korrektur viel Sucharbeit.
Understanding WCAG 2.2: Keyboard, SC 2.1.1 · Understanding WCAG 2.2: No Keyboard Trap, SC 2.1.2Erkennen, wo Sie gerade sind
Eine Tastaturbedienung wird anstrengend, wenn Sie den aktiven Bereich suchen müssen. Achten Sie auf eine gut erkennbare Markierung. Feststehende Kopfzeilen, Cookie-Dialoge oder Kontaktleisten dürfen die fokussierte Komponente nicht vollständig verdecken. Die W3C-Erläuterung zu WCAG 2.2 beschreibt dieses Problem ausdrücklich.
Schauen Sie dabei nicht nur auf die Startseite. Lange Leistungsseiten und ausgeklappte Untermenüs können andere Situationen erzeugen. Vergrößern Sie die Darstellung zusätzlich und prüfen Sie erneut, ob die Orientierung erhalten bleibt. Für den Bericht würde ich konkrete Beobachtungen festhalten, anstatt allein „Navigation funktioniert“ anzukreuzen.
Understanding WCAG 2.2: Focus Not Obscured (Minimum), SC 2.4.11Formularfelder brauchen verständliche Hinweise
Besucher sollten vor einer Eingabe erkennen, welche Information erwartet wird. Sichtbare Beschriftungen und passende Hinweise sind dafür hilfreicher als ein Beispieltext, der beim Tippen verschwindet. Pflichtangaben und erwartete Formate sollten verständlich sein. Ein Datum, eine Telefonnummer oder ein längeres Anliegen benötigen unterschiedliche Unterstützung.
Für die technische Prüfung kommt hinzu, ob eine Beschriftung dem richtigen Feld zugeordnet ist und assistierende Software sie verstehen kann. Das lässt sich nicht allein aus dem Aussehen beurteilen. Ich würde zunächst die sichtbare Verständlichkeit verbessern und anschließend Zuordnung und Bedienung gezielt testen. Zusätzliche Eingaben sollten einen klaren Zweck haben.
Understanding WCAG 2.2: Labels or Instructions, SC 3.3.2Fehler sollen weiterhelfen
Wenn eine Eingabe nicht verarbeitet werden kann, muss der Besucher den Fehler erkennen und zuordnen können. Eine rote Umrandung allein erklärt wenig. Besser ist eine verständliche Nachricht am betroffenen Feld oder eine gut auffindbare Fehlerübersicht. Die W3C-Kriterien verlangen bei automatisch erkannten Eingabefehlern eine textliche Beschreibung.
Prüfen Sie leere Pflichtfelder und ein bewusst unpassendes Format. Bleiben andere Eingaben erhalten? Ist klar, was als Nächstes zu tun ist? Nach einer Korrektur sollte der Weg fortgesetzt werden können. Auch eine erfolgreiche Übermittlung verdient eine eindeutige Rückmeldung; ein still verschwundenes Formular lässt Besucher unnötig zweifeln.
Understanding WCAG 2.2: Error Identification, SC 3.3.1Aus Beobachtungen einen umsetzbaren Plan machen
Eine kurze Liste mit URL, Handlung und beobachtetem Hindernis ist bereits eine gute Grundlage. Ich würde zuerst Fehler bearbeiten, die eine wichtige Aufgabe vollständig blockieren. Anschließend folgen weitere Verbesserungen und eine erneute Prüfung derselben Schritte. Den Umfang einer weitergehenden Untersuchung vereinbare ich gesondert mit Ihnen.