Ein Prüfbericht nach WCAG beantwortet die Frage, ob eine Schaltfläche einen zugänglichen Namen hat. Er beantwortet nicht die Frage, ob jemand sie findet. Zwischen diesen beiden Sätzen liegen Befunde, die später teuer werden können: die Suche, die technisch sauber ausgezeichnet ist und trotzdem aufgegeben wird; die Bestellstrecke, die jedes Erfolgskriterium erfüllt und an einer Stelle abreißt, an die im Entwurf niemand gedacht hat. Sichtbar werden solche Stellen erst, wenn jemand die Seite benutzt, der sie benutzen muss - mit Sprachausgabe, mit starker Vergrößerung, mit der Tastatur allein. Ein Nutzertest mit Betroffenen ersetzt das WCAG-Audit nicht; er beantwortet die Frage, die das Audit offenlässt. Dieser Beitrag beschreibt den organisatorischen Ablauf einer solchen Runde: Rekrutierung, Einwilligung, Aufgabenskript, Protokoll, Einordnung - und die vier Fehler, die eine Runde wertlos machen.
Das Wichtigste in Kürze
- Automatische Prüfwerkzeuge decken einen Teil der Kriterien ab, alles Übrige verlangt eine menschliche Beurteilung (W3C). Ein Nutzertest schließt genau diese Lücke, statt den Prüflauf zu wiederholen.
- Eine Bewertung mit Betroffenen findet Nutzungsprobleme, die eine reine Konformitätsprüfung nicht findet (W3C) - und umgekehrt. Erst beide Wege zusammen ergeben ein Bild.
- Kleine Runden liefern belastbare Beobachtungen, aber keine statistische Aussagekraft (W3C). Das Ergebnis ist eine Fehlerliste mit Belegen, keine Quote und kein Notendurchschnitt.
- Die Technik der Teilnehmenden gehört zum Aufbau: 71,6 Prozent der Befragten nutzen mehr als einen Screenreader am Rechner (WebAIM). Wer die Wahl vorgibt, misst eine andere Nutzung als die echte.
- Aufzeichnungen einer Sitzung berühren Gesundheitsdaten. Zulässig sind sie nur mit ausdrücklicher Einwilligung für festgelegte Zwecke (Art. 9 Absatz 2 Buchstabe a DSGVO), und der Abbruch bleibt jederzeit möglich (W3C).
- Testbefunde gehören in denselben Maßnahmenplan wie die Auditbefunde. Bei zwei getrennten Listen bleibt leicht eine davon liegen.
Was ein Prüfwerkzeug nicht sehen kann
Die Grenze ist nicht umstritten, sie steht in der Anleitung des W3C zur Auswahl von Prüfwerkzeugen: Werkzeuge können nicht alle Aspekte der Barrierefreiheit automatisch prüfen, für den Rest ist eine menschliche Beurteilung nötig (W3C). Das ist kein Einwand gegen die Werkzeuge. Ein Prüflauf findet in Minuten, wofür eine Person Stunden braucht - fehlende Alternativtexte, zu geringe Kontraste, unbeschriftete Formularfelder, doppelt vergebene Kennungen. Was er nicht kann, ist bewerten: ob ein vorhandener Alternativtext den Zweck des Bildes trifft, ob die Reihenfolge der Überschriften einer nachvollziehbaren Gliederung folgt, ob eine Fehlermeldung verstanden wird und ob der Weg durch eine Bestellstrecke mit Sprachausgabe in vertretbarer Zeit endet. Genau diese Fragen entscheiden darüber, ob eine Seite benutzbar ist.
Die zweite Grenze liegt in der Fragestellung. Eine Konformitätsprüfung fragt nach Regeln, ein Nutzertest fragt nach Aufgaben. Das W3C beschreibt den Unterschied in seiner Anleitung zur Einbindung von Nutzern so, dass eine Bewertung mit Menschen mit Behinderungen und mit älteren Nutzern Nutzungsprobleme aufdeckt, die eine Konformitätsprüfung allein nicht findet (W3C). Umgekehrt gilt dasselbe: Eine Testrunde findet keine fehlende Sprachauszeichnung im Quelltext und kein Kontrastverhältnis knapp unter dem Schwellenwert. Wer beide Wege als Alternative behandelt, wählt zwischen zwei unvollständigen Bildern. Welche Methode was leistet, steht in unserem Überblick zu Methoden und Prüfansätzen; dieser Beitrag beschreibt den Teil, der sich nicht automatisieren lässt.
Drei Fragen, die kein Prüflauf beantwortet
Wen Sie einladen - und wen nicht
Zum Jahresende 2023 lebten in Deutschland rund 7,9 Millionen Menschen mit einer schweren Behinderung (Statistisches Bundesamt). Für eine Testrunde ist diese Zahl nur der Hintergrund, entscheidend ist die Zusammensetzung. Eine Runde, in der alle Teilnehmenden blind sind und dasselbe Programm benutzen, beschreibt eine Nutzungsart und nicht die Nutzung. Besetzt wird deshalb entlang der Zugangswege: Sprachausgabe am Rechner, Sprachausgabe am Mobilgerät, starke Vergrößerung, Bedienung ausschließlich mit der Tastatur, Bedienung über Sprache oder Schalter, dazu Teilnehmende mit Lese- oder Konzentrationsschwierigkeiten. Wir stellen solche Runden im Rahmen eines begleiteten Screenreader-Tests zusammen. Eingeladen wird sinnvollerweise über Verbände, Selbsthilfeorganisationen und Hochschulgruppen, nicht über einen Aufruf auf der eigenen Website.
Der zweite Zuschnitt ist der Erfahrungsgrad. Das W3C empfiehlt für frühe Phasen Teilnehmende mit vergleichsweise hoher Erfahrung, weil sie ihre eigene Technik sicher bedienen und die Beobachtung nicht von Bedienfehlern am Hilfsmittel überlagert wird (W3C). Diese Empfehlung hat eine Kehrseite, die in die Auswertung gehört: Wer eine Sprachausgabe seit Jahren benutzt, kennt Umwege, die eine ungeübte Person nicht kennt. In der zehnten Screenreader-Umfrage von WebAIM mit 1539 gültigen Antworten zeigt sich der Unterschied deutlich: 78 Prozent der Befragten mit fortgeschrittener Erfahrung suchen auf einer langen Seite zuerst über die Überschriften, bei Anfängern sind es 47 Prozent (WebAIM). Eine Runde nur aus geübten Personen misst deshalb die bestmögliche Nutzung, nicht die alltägliche.
| Zugangsweg | Was diese Besetzung sichtbar macht | Worauf bei der Auswahl zu achten ist |
|---|---|---|
| Sprachausgabe am Rechner | Struktur, Namen von Bedienelementen, Vorlesereihenfolge | eigenes Programm und eigene Einstellungen mitbringen lassen |
| Sprachausgabe am Mobilgerät | Wischgesten, eingeblendete Tastatur, Zielgrößen | eigenes Gerät statt eines Testgeräts der Agentur |
| Starke Vergrößerung | Ausschnittwechsel, Umbrüche, klebende Leisten | Vergrößerungsfaktor und Farbumkehr vorher abfragen |
| Bedienung nur mit Tastatur | Fokusreihenfolge, sichtbarer Fokus, Tastenfallen | auch Teilnehmende ohne Sehbehinderung einladen |
| Sprache oder Schalter | Beschriftungen, die zum sichtbaren Text passen | längere Sitzungsdauer und mehr Pausen einplanen |
| Lesen und Verstehen | Formulierungen, Fehlermeldungen, Fachbegriffe | Aufgaben vorlesen, statt sie schriftlich vorzulegen |
Drei Gruppen gehören nicht in eine Testrunde, auch wenn sie leicht verfügbar sind. Erstens die eigenen Mitarbeitenden: Sie kennen den Aufbau des Angebots und finden Wege, die ein Fremder nicht findet. Zweitens Kolleginnen und Kollegen mit verbundenen Augen. Eine Simulation erzeugt Mitgefühl, aber keine Befunde - wer eine Sprachausgabe zum ersten Mal hört, scheitert an der Software und nicht an der Seite. Drittens Personen, die nur Auskunft geben sollen, ohne die Seite zu benutzen. Für geschlossene Bereiche gilt zusätzlich das, was wir zu Kundenportalen hinter der Anmeldung beschrieben haben: Testzugänge mit echten Rechten und passende Testdaten stehen vor dem Termin, sonst besteht die halbe Sitzung aus Warten.
Einwilligung, Aufzeichnung, Aufwandsentschädigung
Eine Testsitzung erzeugt personenbezogene Daten, und zwar in einer besonders geschützten Kategorie. Aus einer Aufnahme geht hervor, dass die Person eine Behinderung hat und welche; das sind Gesundheitsdaten. Ihre Verarbeitung ist zunächst untersagt und wird erst zulässig, wenn die betroffene Person für einen oder mehrere festgelegte Zwecke ausdrücklich eingewilligt hat (Art. 9 Absatz 2 Buchstabe a DSGVO). Praktisch heißt das: Die Einwilligung nennt den Zweck, also die Auswertung dieser Testrunde, den Umfang der Aufnahme, also Bildschirm und Ton ohne Gesicht, die Speicherdauer und den Kreis der Personen, die die Aufnahme sehen dürfen. Eine pauschale Unterschrift unter „Aufzeichnung zu Forschungszwecken“ erfüllt das nicht, weil der Zweck darin nicht festgelegt ist.
Dazu kommen die Punkte, die das W3C unter Forschungsethik führt: Die Teilnehmenden werden darüber informiert, dass sie jederzeit abbrechen können, und ihre Zeit wird angemessen vergütet (W3C). Die Aufwandsentschädigung ist kein Trinkgeld, sondern die Bedingung dafür, dass eine Runde überhaupt zustande kommt und nicht nur aus Menschen besteht, die ohnehin beruflich mit Barrierefreiheit zu tun haben. Sie wird vor der Einladung festgelegt statt hinterher verhandelt, sie ist für alle Teilnehmenden gleich, und sie wird auch dann gezahlt, wenn eine Sitzung nach wenigen Minuten abgebrochen wird. Wer die Entschädigung an ein vollständiges Skript knüpft, erzeugt genau den Druck, der Abbrüche verhindert - und Abbrüche sind Befunde.
Eigenes Gerät
Die Teilnehmenden arbeiten an ihrer eigenen Technik und mit ihren Einstellungen: Sprechgeschwindigkeit, Stimme, Vergrößerungsfaktor, Farbumkehr. Ein bereitgestelltes Testgerät misst vor allem die Einarbeitung in ein fremdes System.
Eigener Screenreader
71,6 Prozent der Befragten nutzen mehr als ein Programm am Rechner (WebAIM). Welches im Test läuft, entscheidet die Person und nicht das Skript, sonst steht im Protokoll eine Umgewöhnung statt einer Barriere.
Braillezeile einplanen
Eine Braille-Ausgabe nutzen 38 Prozent der Befragten (WebAIM). Wer sie verwendet, liest anders: Abkürzungen, Tabellen und lange Linktexte wirken auf der Zeile anders als in der Sprachausgabe.
Mobil getrennt prüfen
91,3 Prozent der Befragten nutzen einen Screenreader auch auf dem Mobilgerät (WebAIM). Die mobile Sitzung ist ein eigener Termin mit eigenen Aufgaben und kein Anhängsel an die Sitzung am Rechner.
Aufnahme im Umfang begrenzen
Aufgezeichnet werden Bildschirm und Ton, nicht das Gesicht. Was nicht gebraucht wird, wird nicht aufgenommen; das verkürzt die Einwilligung, die Speicherfrist und die spätere Diskussion über Freigaben.
Fernsitzung vorbereiten
Eine Sitzung aus der Wohnung der Teilnehmenden spart Anfahrt und hält die gewohnte Technik im Spiel. Die Bildschirmfreigabe muss dafür mit dem Hilfsmittel zusammenarbeiten, und das wird vorher geprüft, nicht im Termin.
Vor dem ersten echten Termin steht ein Pilotlauf. Er prüft nicht die Seite, sondern das Skript: Reicht die eingeplante Zeit? Sind die Aufgaben verständlich, wenn sie vorgelesen werden? Läuft die Bildschirmfreigabe zusammen mit der Sprachausgabe? Ein Pilotlauf mit einer Person aus dem eigenen Haus, die das Angebot nicht kennt, deckt die organisatorischen Pannen auf, bevor sie eine echte Sitzung kosten. Der Pilot ersetzt keinen Teilnehmer und liefert keine Befunde über die Seite; er sorgt dafür, dass die erste echte Sitzung nicht die Generalprobe ist.
Der teuerste Fehler steht vor der Sitzung
Das Aufgabenskript: Auftrag statt Meinungsfrage
Ein Nutzertest steht und fällt mit der Formulierung der Aufgaben. „Wie gefällt Ihnen die Navigation?“ erzeugt eine Meinung. „Bitte finden Sie heraus, bis wann eine Bestellung storniert werden kann“ erzeugt eine Beobachtung. Die Aufgabe beschreibt ein Ziel, nie einen Weg. Sobald der Text den Weg verrät - „Öffnen Sie den Bereich Service und wählen Sie Rücksendungen“ -, prüft die Runde nur noch, ob die Teilnehmenden zuhören können. Besonders anfällig sind Aufgaben rund um Formulare, weil die Bezeichnung eines Feldes im Aufgabentext bereits die halbe Lösung ist; wie Beschriftungen und Fehlermeldungen dabei wirken, steht in unserem Beitrag zu barrierefreien Formularen.
Die Reihenfolge folgt der Nutzung und nicht der Seitenstruktur. Eine Runde beginnt mit einer einfachen Aufgabe, die sicher gelingt, damit die Teilnehmenden ankommen. Danach kommen die Strecken, die im Audit auffällig waren, und erst am Ende die Aufgaben, die vermutlich scheitern - ein früher Abbruch verdirbt sonst den Rest der Sitzung. Für Strecken, die ohne Maus zu Ende gehen müssen, lohnt ein Blick in die Tastaturbedienung, bevor das Skript entsteht: Was schon am Schreibtisch an der Fokusreihenfolge auffällt, braucht keine Testrunde, sondern eine Korrektur.
- Jede Aufgabe nennt ein Ergebnis, das die Person erkennen kann - eine Zahl, ein Datum, eine abgeschlossene Bestellung - und niemals „schauen Sie sich einmal um“
- Kein Begriff aus der Beschriftung der Oberfläche steht im Aufgabentext, sonst wird aus der Suche eine Worterkennung
- Eine Aufgabe je Karte, vorgelesen und zusätzlich als Textdatei, damit sie mit der eigenen Ausgabe noch einmal gelesen werden kann
- Eine Zeitgrenze je Aufgabe wird vorher festgelegt, aber nicht mitgeteilt; sie beendet die Aufgabe, nicht die Sitzung
- Keine Aufgabe verlangt eine echte Zahlung, eine Anmeldung mit privaten Zugangsdaten oder eine echte Stornierung
- Anmeldung und Zugangsschutz stehen als eigene Aufgabe im Skript, weil dort die häufigsten Abbrüche entstehen - siehe barrierefreie Authentifizierung
- Mindestens eine Aufgabe führt absichtlich über einen Fehler, etwa ein falsches Format oder ein leeres Pflichtfeld, weil Fehlerwege selten geprüft werden
- Die letzte Aufgabe bleibt offen: „Was würden Sie als Nächstes tun?“ - dort entstehen die Hinweise, die kein Skript vorsieht
Das Skript enthält außerdem, was die Moderation sagt, wenn jemand nicht weiterkommt. Ohne diesen Teil entsteht der häufigste Fehler einer Runde: Die Moderation hilft mit. Ein Hinweis wie „Der Filter ist oben rechts“ beendet die Beobachtung und ersetzt sie durch eine Vorführung. Vereinbart wird deshalb eine feste Staffel - erst schweigen, dann „Was hören oder sehen Sie gerade?“, dann „Was würden Sie jetzt versuchen?“, und erst danach der Abbruch der Aufgabe. Wer hilft, bevor die Staffel durch ist, hat die Aufgabe nicht gemessen, sondern gerettet.
Protokollieren, ohne zu deuten
Im Protokoll steht, was geschehen ist, nicht warum. „Teilnehmerin bewegt sich mit der Überschriftentaste durch die Seite, landet bei der vierten Überschrift, geht zurück, öffnet die Suche“ ist eine Beobachtung. „Teilnehmerin findet die Navigation unübersichtlich“ ist bereits eine Deutung und in der Auswertung wertlos, weil sich nicht mehr feststellen lässt, worauf sie beruht. Diese Trennung ist der Grund, warum eine Runde zwei Rollen braucht: Die Moderation spricht, das Protokoll schreibt mit. Eine Person allein erledigt beides schlecht. Welche Ausgabe dabei läuft, gehört ebenfalls ins Protokoll - Programm, Fassung, Browser; die technische Seite dazu steht in der Screenreader-Optimierung.
Die Angabe der Technik ist wichtig, weil sie das Ergebnis verschiebt. 71,6 Prozent der Befragten nutzen mehr als ein Programm am Rechner, und die beiden meistgenutzten liegen nah beieinander: 65,6 Prozent der Befragten nutzen NVDA, 60,5 Prozent JAWS (WebAIM). Ein Befund, der nur in einem Programm auftritt, bleibt ein Befund - er wird aber anders eingeordnet als einer, den alle Teilnehmenden zeigen. Ohne die Angabe im Protokoll lässt sich das im Nachhinein nicht mehr unterscheiden, und die Diskussion mit der Entwicklung beginnt bei null.
Ein zweiter Punkt betrifft die Uhr. Zeiten werden mitgeschrieben, aber nicht als Kennzahl ausgewiesen. Das W3C weist ausdrücklich darauf hin, dass sich die Erhebung bei Barrierefreiheitstests auf das Verstehen der Fehler richtet und nicht auf Bearbeitungszeit oder Zufriedenheit, und dass dabei üblicherweise mit lautem Denken und starker Beteiligung der Moderation gearbeitet wird (W3C). Wer laut denkt, ist langsamer. Eine Zeitangabe aus einer solchen Sitzung ist ein Hinweis auf eine Hürde, kein Messwert und erst recht kein Vergleichswert zwischen zwei Teilnehmenden.
Vier Fehler, die eine Runde wertlos machen
Präferenz oder Barriere?
Nicht jede Beobachtung ist ein Mangel. Eine Teilnehmerin, die konsequent über Überschriften navigiert, während eine andere die Bereichsmarken benutzt, zeigt zwei Gewohnheiten und keinen Fehler. Die Umfragedaten stützen das: 31,7 Prozent der Befragten nutzen Bereichsmarken immer oder häufig, wenn sie vorhanden sind, aber nur 3,7 Prozent benutzen sie als bevorzugten Weg, um auf einer langen Seite etwas zu finden (WebAIM). Wer aus einer einzelnen Sitzung eine Regel ableitet, baut das Angebot auf eine Gewohnheit um. Das W3C warnt an zwei Stellen davor: Die Rückmeldung einer Person mit Behinderung gilt nicht für alle Menschen mit Behinderung, und Ergebnisse aus wenigen Sitzungen lassen sich nicht verallgemeinern (W3C).
- Scheitert die Aufgabe, oder dauert sie nur länger? Ein Abbruch ist eine Barriere, ein Umweg ist zunächst eine Beobachtung
- Tritt die Stelle bei mehreren Teilnehmenden auf, oder nur bei einer Person mit einer bestimmten Einstellung?
- Lässt sich die Stelle einem Erfolgskriterium zuordnen? Dann ist sie ein Prüfbefund und gehört ohnehin behoben
- Liegt die Ursache in der Seite, im Hilfsmittel oder in dessen Bedienung? Nur der erste Fall ist Ihr Befund
- Wäre die Stelle auch ohne Hilfsmittel ein Problem? Dann betrifft sie alle Besucher und ist ein allgemeiner Nutzungsmangel
Die vierte Frage ist die schwerste. Das W3C beschreibt Barrierefreiheit als Zusammenspiel mehrerer Bestandteile - Inhalt, Browser, Hilfsmittel und die Kenntnis des Hilfsmittels -, und ein beobachtetes Problem kann in jedem dieser Bestandteile liegen. Im Termin hilft eine einfache Gegenprobe: dieselbe Aufgabenart auf einer vergleichbaren, funktionierenden Seite. Gelingt sie dort, liegt es an Ihrem Angebot. Scheitert sie auch dort, steht ein Hinweis im Protokoll und kein Befund im Plan. Diese Gegenprobe ist im Termin schnell gemacht und erspart später eine lange Debatte darüber, ob eine Stelle überhaupt in Ihrer Verantwortung liegt.
| Beobachtung im Termin | Einordnung | Wohin sie gehört |
|---|---|---|
| Sprachausgabe sagt „Schaltfläche“ ohne Namen | Prüfbefund, Erfolgskriterium betroffen | Maßnahmenplan, hohe Priorität |
| Fehlermeldung wird nicht angesagt | Prüfbefund mit unmittelbarer Nutzungsfolge | Maßnahmenplan, hohe Priorität |
| Weg zum Ziel dauert ein Vielfaches | Nutzungshürde ohne Regelverstoß | Maßnahmenplan, mittlere Priorität |
| Teilnehmerin benutzt Bereichsmarken nie | Gewohnheit, kein Mangel | Notiz für die Auswertung |
| Ausgabe liest ein Datum als Ziffernfolge | Verhalten des Hilfsmittels | Hinweis, kein Befund |
| Aufgabe scheitert an einem Fachwort | Verständlichkeit des Textes | Redaktion statt Entwicklung |
Die Zuordnung entscheidet über die spätere Diskussion. Ein Befund mit Verweis auf ein Erfolgskriterium wird selten bestritten. Eine Nutzungshürde ohne Regelverstoß braucht die Beobachtung als Beleg: Aufgabe, Teilnehmerprofil, Stelle, Ausgang. Beides gehört in denselben Bericht, aber in getrennte Spalten. Scheitert eine Aufgabe an Fachwörtern statt an Technik, ist der Adressat die Redaktion; wie sich Texte dafür einrichten lassen, steht in einfacher Sprache im Web. Und wenn eine Runde zeigt, dass eine eingekaufte Einblendung die Hürde erzeugt, lohnt der Blick auf Overlays, bevor eine weitere Schicht darüber gelegt wird.
Vom Testprotokoll in den Maßnahmenplan
Am Ende stehen zwei Listen, und sie dürfen nicht zwei Listen bleiben. Die Befunde aus dem Audit sind nach Erfolgskriterien sortiert, die Befunde aus dem Test nach Aufgaben. Zusammengeführt werden sie über die Stelle in der Oberfläche: Welche Komponente, welche Seite, welcher Schritt in der Strecke? Das Vorgehen dafür haben wir im Beitrag zum Maßnahmenplan beschrieben; für Testbefunde kommt eine Spalte hinzu, in der die Beobachtung steht, auf der die Priorität beruht. Ohne diese Spalte wird aus einem Befund im nächsten Quartal eine Behauptung, die niemand mehr belegen kann.
Die Priorität eines Testbefunds ergibt sich aus drei Angaben: Wie viele Teilnehmende sind an der Stelle gescheitert, wie zentral ist die Strecke, und gibt es einen zumutbaren Umweg? Eine Stelle, an der alle scheitern und die auf dem Weg zur Bestellung liegt, steht oben - unabhängig davon, ob ein Erfolgskriterium verletzt ist. Damit die Runde kein Einzelfall bleibt, gehört der nächste Termin in dieselbe Planung wie die technische Nachprüfung; welche Ereignisse eine Nachprüfung auslösen, steht im Prüfrhythmus nach dem Go-live. Laufende Messungen im BFSG-Monitoring zeigen dazwischen, wann sich etwas verschoben hat.
Ein Testprotokoll, in dem keine einzige Aufgabe scheitert, beweist nicht die Barrierefreiheit des Angebots, sondern die Nachsicht der Aufgabenstellung.
Bleibt die Frage nach dem Aufwand. Eine Runde kostet Vorbereitung, Termine, Aufwandsentschädigung und Auswertung - und sie liefert Befunde, die kein Prüflauf liefert. Wer den Aufwand klein halten möchte, testet früher: an einem Klickmuster statt am fertigen Bau, an einer Strecke statt am ganzen Angebot. Das W3C hält informelle Bewertungen während der Entwicklung für wirksamer als eine einzige förmliche Untersuchung am Projektende (W3C). Und wer die Beobachtung im eigenen Team wiederholbar machen möchte, findet den Einstieg in unseren Schulungen.
Quellen und Studien
Verwandte Artikel
Screenreader-Optimierung: Website vorlesbar machen
Screenreader-Optimierung für Websites: ARIA-Landmarks, Rollen, Live-Regionen, semantisches HTML und Tests mit Screenreadern auf Windows, macOS und dem Telefon.
Barrierefreie Bewerbung: Karriereseite ohne Hürden
Bewerbungsstrecken fallen nicht unter das BFSG, sondern unter AGG und SGB IX. Wo Upload, Pflichtfelder und Sitzungsende Bewerbungen kosten und was dann hilft.
Barrierefreie Kundenportale: Login-Bereiche richtig prüfen
Automatische Scans enden an der Anmeldemaske. Wie ein WCAG-Audit den geschützten Bereich mitprüft: Prüfumfang, Testkonten, Sitzungsablauf, Screenreader.