Die Zahlen der US-Studie auf dieser Seite sind Version 1 (1. September 2026). Die aktuelle Version 2.1 vom 5. Oktober 2026 nutzt ein anderes Instrument: eine Tastaturbarriere auf 24,6 % der gemessenen Seiten. Version 2.1 und was sich geändert hat →

Methodik: wie wir die Barrierefreiheit kommunaler Websites messen

Version 1.1 · 1. September 2026 · Maksim Galatin & AIfa (Claude, Gemini, Grok) · lizenziert unter CC BY-NC 4.0

Warum eine eigene Methodik nötig war

Automatisierte Messungen der Barrierefreiheit gibt es reichlich. Scanner wie axe-core erzeugen sie: Sie sind günstig, reproduzierbar und messen das Markup einer Seite.

Daten darüber, was geschieht, wenn jemand versucht, den Weg per Tastatur zu gehen, gibt es kaum. Ein Regelsatz prüft das Markup; er versucht nicht, das Ziel zu erreichen. Nötig ist ein Durchlauf, der auf einer echten Seite tatsächlich Tab drückt und beobachtet, wo der Fokus landet.

Wir führen beide Messungen durch und vergleichen sie miteinander. Die Lücke zwischen ihnen ist das Hauptergebnis dieser Arbeit, und sie zeigt sich nur, wenn beide Prüfungen über genau dieselbe Stichprobe laufen.

Teil I. Automatisierte Messung

Was in die Stichprobe kommt

Für die Vereinigten Staaten — das offizielle Register der .gov-Domains, das die CISA führt (cisagov/dotgov-data, Lizenz CC0, täglich aktualisiert). Daraus nehmen wir Organisationen der Typen City und County: 11.659 Einträge in 51 Bundesstaaten und Gebieten.

Das ist ein wichtiger Unterschied zu einem durch Suche zusammengestellten Satz. Auf die Frage „woher haben Sie diese Städte“ gibt es eine Antwort, die sich in einer Minute prüfen lässt: das gesamte offizielle Register, nicht das, was wir zufällig gefunden haben.

Für Europa — kommunale Organisationen aus OpenStreetMap mit den Tags amenity=townhall, office=government und verwandten.

Wie wir prüfen

Ein echter Browser (Chromium über Puppeteer), keine HTTP-Anfrage. Der Grund: Ein großer Teil moderner Websites wird per Skript zusammengesetzt, und die Prüfung des Quell-HTML misst etwas anderes als das, was ein Mensch sieht.

Auf jeder Website: Wir öffnen die Seite und warten auf das Ereignis domcontentloaded; wir führen axe-core aus — einen offenen Regelsatz, abgestimmt auf WCAG 2.1 AA; wir verzeichnen jede ausgelöste Regel, die Zahl der Vorkommen und den DOM-Selektor; wir suchen die Zahlungsseite und prüfen den Weg dorthin.

Was wir zählen und wie

Verstoßdichte = Zahl der ausgelösten Regeln geteilt durch die Zahl der geprüften Seiten. Dichte statt einer absoluten Zahl: Eine große Website hat mehr Seiten, und ein Vergleich nach der Gesamtzahl der Verstöße hieße, Größe zu bestrafen. Die Farbe des Punkts einer Website auf der Karte ist der Anteil ihrer gemessenen Seiten, auf denen ein Mensch das Ziel erreicht hat: 75 % oder mehr ist grün, 50–75 % gelb, unter 50 % rot. Früher färbte eine einzige Seite mit Barriere (etwa ein Veranstaltungskalender) die ganze Website rot; seit dem 1. November 2026 folgt die Farbe derselben Regel wie die Länderrangliste, und der seitenweise Bericht zeigt genau, was kaputt ist.

Was wir NICHT tun — und das ist wichtig

Wir verurteilen keine ganze Website anhand einer Seite, wir zählen Warnungen nicht als Verstöße, und wir ersetzen Messung nicht durch Urteil. Der automatisierte Teil beantwortet nur eine Frage — ob eine Regel ausgelöst hat — und keine andere.

Teil II. Tastaturdurchlauf

Hier beginnt, was kein automatisiertes Audit tut.

Die Aufgabe für den Prüfer

Den Weg eines Menschen gehen, der eine kommunale Steuer oder Geldbuße nur mit der Tastatur bezahlen will. Die Maus wird überhaupt nicht berührt.

Wer prüft

Der Durchlauf wird von einem Software-Agenten in einem echten Chrome-Browser durchgeführt, nicht von einem Menschen am Schreibtisch. Wir sagen das offen, denn wie jede Zahl unten zu lesen ist, hängt von dieser Antwort ab.

Der Agent steuert eine echte Seite so, wie es ein Mensch ohne Maus tut: Er drückt Tab, liest, wohin der Fokus gewandert ist, und hält an, wo es nicht mehr weitergeht. Er zerlegt nicht das Quell-HTML und urteilt nicht nach dem Markup — er durchläuft die lebendige Seite mit all ihren Skripten, Einwilligungsbannern und Pop-ups.

Wie viele Seiten von einer Website genommen werden

Der kommunale Durchlauf nimmt acht Seiten pro Website: Startseite, Zahlung, Kontakte, Sitzungen, Dokumente, Stellen, Dienstleistungen, Neuigkeiten. Denn er misst den WEG ZU EINEM ZIEL — das Erreichen des Formulars zur Steuerzahlung —, und das Ziel liegt auf einer inneren Seite. Der kommerzielle Durchlauf nimmt EINE Seite pro Organisation, die Startseite. Der Grund ist nicht Zeitersparnis, sondern die Beobachtungseinheit: Der Anteil beschreibt Organisationen, und von der einen acht Seiten und von der anderen eine einzige zu nehmen, gäbe großen Websites achtfaches Gewicht — die Zahl würde nicht mehr die Barrierefreiheit beschreiben, sondern die Größe der Website. Zudem hat eine gemischte Menge privater Organisationen kein gemeinsames Ziel, das mit einer Steuerzahlung vergleichbar wäre: Eine Werkstatt hat keine Sitzungsprotokolle, eine Klinik keine Stellenbörse im selben Sinn. Die beiden Datensätze werden nie in einer Tabelle vermischt.

Warum das einem Menschen näher ist als einem gewöhnlichen Scanner. Der Agent zählt keine Tastendrücke — er sucht ein Ziel. Bei jedem Schritt liest er die Beschriftung des Elements, das gerade den Fokus hält, und führt sie durch dieselbe Stufenleiter wie ein Screenreader: zuerst sichtbarer Text, dann aria-label, dann title. Diese Beschriftung und die Linkadresse gleicht er mit dem Zweck der Seite ab: Zahlung, Stellen, Dokumente. So sucht auch ein Mensch — nach Namen, nicht nach Elementnummer. Zweitens: Der Agent prüft, ob SICHTBAR ist, wo er steht. Bei jedem Schritt untersucht er den Umriss des fokussierten Elements, und wenn der Ring per Styling entfernt wurde, verzeichnet er das gesondert — denn der Unterschied zwischen dem Erreichen eines Ziels und dem blinden Erreichen ist für einen Menschen entscheidend und existiert für einen Regelprüfer nicht. Drittens prüft er, ob Formularfelder beschriftet sind, auf die drei Arten, auf die ein Screenreader eine Beschriftung sucht — ein an das Feld gebundenes label, ein umschließendes label, ein aria-label —, und zählt die Seite nur dann als beschriftet, wenn mindestens sieben von zehn Feldern es sind. Viertens bemerkt er Text unter 12 px. Fünftens wartet er 60 ms zwischen den Tastendrücken — er hämmert nicht auf die Seite ein, er lässt sie antworten, wie es ein Mensch tut. Und vor allem hat er drei Ausgänge, nicht zwei: richtig angekommen; angekommen, aber blind oder in unbeschriftete Felder; innerhalb von vierzig Tastendrücken nicht angekommen. Vierzig ist keine technische Grenze, sondern die Grenze der Geduld: Darüber hinaus verlässt ein echter Mensch die Website.

Was uns das bringt. Reproduzierbarkeit: Derselbe Durchlauf kann erneut ausgeführt werden und liefert dasselbe Ergebnis, während man einen lebenden Menschen nicht vor 67.000 Seiten setzen und ihn nicht bitten kann, den Weg einen Monat später zu wiederholen. Und Umfang: Eine Messung dieser Größe wird von Menschenhand schlicht nicht gemacht — genau deshalb gab es solche Daten bisher nicht.

Was uns das NICHT bringt, und wir räumen es ein. Der Agent ersetzt keinen Screenreader-Nutzer und misst nicht, wie verständlich eine Seite ist. Er beantwortet eine Frage — ob das Ziel physisch allein mit der Tastatur erreichbar ist. Wir behaupten nicht, Tests mit blinden Teilnehmenden durchgeführt zu haben: Das haben wir nicht.

Was für jede Website verzeichnet wird

Das letzte Feld ist das entscheidende: Es ermöglicht den Vergleich zweier Messungen desselben Objekts.

Was als Barriere gilt

• Fokus ist unsichtbar (outline: none) — man erkennt nicht, wo man ist
• Fokusfalle — das Element lässt sich per Tastatur nicht verlassen
• Unbeschriftetes Feld — ein Screenreader kann nicht sagen, was einzugeben ist
• Eine Schaltfläche, die keine Schaltfläche ist — ein div mit Handler erhält keinen Fokus
• Ein modaler Dialog, der sich nicht mit Escape schließen lässt

Wie die Stichprobe für den Durchlauf gewählt wird

Geprüft werden beide Gruppen: die Websites, die der automatische Durchgang für barrierefrei hielt, und die, die er ablehnte. Sonst hätten wir eine einseitige Messung, die nur die Fehler zeigt, die uns passen.

Teil III. Was der Vergleich ergibt

Die Hauptgröße dieser Forschung ist die Lücke zwischen Maschine und Durchlauf, und sie wird in beide Richtungen gemessen:

Falsche Beruhigung — die automatische Prüfung sagt „barrierefrei“, der Durchlauf kommt nicht durch.
Falscher Alarm — die automatische Prüfung lehnt die Seite ab, der Durchlauf kommt durch.

US-Studie: Stand vom 1. September 2026 (Version 1; die heutigen weltweiten Summen stehen im Kasten oben auf der Seite)

Einschränkungen, die wir einräumen

1. Der US-Durchlauf ist abgeschlossen — das gesamte CISA-Register wurde durchlaufen, 11.659 Websites von 11.659. Die US-Zahlen sind endgültig; sie ändern sich nur, wenn andere Länder hinzukommen, und das wird offen gesagt.

2. Nicht jeder Eintrag hat einen Screenshot. Wo sich die Seite nicht öffnete, gab es nichts aufzunehmen.

3. Ein Bot-Schutz ist nicht dasselbe wie fehlende Barrierefreiheit. Wir wissen nicht, was dahinter liegt, und verzeichnen ihn nicht als Barriere.

4. Ein Durchlauf ersetzt keinen echten Nutzer. Er beantwortet eine Frage: ob das Ziel physisch allein mit der Tastatur erreichbar ist. Das Ziel UNTERSCHEIDET sich nach Seitentyp, und es gibt acht: ein öffentliches Dokument finden, ein 311-Anliegen einreichen, den Zahlungsschritt erreichen, Ratsprotokolle finden, die Hauptnavigation erreichen, eine Stellenanzeige finden, einen Kontakt finden, eine datierte Veranstaltung finden. Die Gesamtzahlen — 74,6 % haben das Ziel nicht erreicht, 25,4 % schon — umfassen alle acht Aufgabenziele, nicht ein einzelnes. Allein das Zahlungsziel liegt bei 19,0 % erreicht. Die Zahlen in diesem Punkt sind Version 1 des Datensatzes (Schnappschuss vom 1. September 2026, Instrument v4). Version 2 (2. Oktober 2026, Instrument v5): Seiten ohne die benötigte Funktion werden nicht als Barrieren gezählt, und die Barriere unter den gemessenen Seiten beträgt 33,5 % (8.448 von 25.252) oder 33,9 % bei strenger Zählung eines schwachen Fokusrahmens. Details und der Vergleich der Versionen stehen auf /research/data im Block „Version 2 · 2. Oktober 2026“.

5. Die Schwelle von 40 Tab-Drücken ist unsere. Sie ist dadurch begründet, dass der mittlere erfolgreiche Weg drei Drücke lang ist — bleibt aber unsere Wahl, kein Standard. Per Sensitivitätsanalyse getestet: Schwellen von 40, 60 und 100 ergeben IDENTISCHE Zahlen — niemand erreicht ein Ziel jenseits von vierzig Drücken, und das 99. Perzentil erfolgreicher Wege liegt bei 35. Niedrigere Schwellen ändern das Ergebnis: Bei 30 sinkt der Anteil, der das Ziel erreicht, um 0,6 Punkte, bei 20 um 2,1, bei 10 um 5,7. Die Hauptzahl bewegt sich ebenso: 53,8 % bei 40, 55,0 % bei 30, 57,6 % bei 20. Vierzig ist daher Spielraum und keine inhaltliche Modellierungsentscheidung — jede größere Schwelle liefert dieselbe Antwort.

6. Websites, die für den automatischen Durchgang unzugänglich waren, fielen früher ganz aus der Stichprobe. Es sind 787, darunter New York vollständig; 230 dieser Kommunen sind an die Frist vom 26. April 2027 gebunden. Wir erfassen sie gesondert per Durchlauf, in derselben Reihenfolge — von groß nach klein.

7. Manche Seiten wurden zweimal geprüft, und wir haben ermittelt, was das ändert. Der Durchlauf läuft in Runden, und dieselbe Adresse kommt gelegentlich erneut an die Reihe: 348 Einträge von 95.524 — 0,4 % des Protokolls. Wir haben jeden Anteil neu berechnet und für jedes Paar aus Adresse und Seitentyp nur einen Eintrag behalten, den neuesten. Die Hauptzahl hat sich überhaupt nicht bewegt: 74,6 % vorher und nachher; der Anteil, der das Ziel erreicht, 25,4 % so oder so. Ein Unterschied von einem Hundertstel eines Punktes, und wir nennen ihn hier, damit er später nicht erklärt werden muss. Die Zahlen in diesem Punkt sind Version 1 des Datensatzes (Schnappschuss vom 1. September 2026, Instrument v4). Version 2 (2. Oktober 2026, Instrument v5): Seiten ohne die benötigte Funktion werden nicht als Barrieren gezählt, und die Barriere unter den gemessenen Seiten beträgt 33,5 % (8.448 von 25.252) oder 33,9 % bei strenger Zählung eines schwachen Fokusrahmens. Details und der Vergleich der Versionen stehen auf /research/data im Block „Version 2 · 2. Oktober 2026“.

8. Die Beobachtungen sind nicht unabhängig, und das haben wir gemessen. Acht Aufgaben auf einer Website hängen zusammen: Eine schlecht gebaute Website scheitert meist an allen acht. Die Intraklassenkorrelation beträgt 0,263 und der Varianzinflationsfaktor 2,72 — acht Aufgaben ergeben also nicht acht unabhängige Beobachtungen, sondern etwa drei. Die effektive Stichprobengröße beträgt 17.272 statt 47.036 messbarer Einträge. Das dafür korrigierte Konfidenzintervall der Hauptzahl: 52,7 % [51,7; 53,8]. Unkorrigiert läge es bei [53,2; 54,4] — fast halb so breit, und es wäre falsch. Gesondert: Eine Zählung nach Kommune statt nach Seite — eine Stimme pro Website — ergibt 52,7 % gegenüber 53,8 %. Eine Lücke von 1,1 Punkten: Die Schlussfolgerung hängt nicht von der Zähleinheit ab.

Offenheit

• Die Rohdaten werden vollständig veröffentlicht, einschließlich der Einträge, die uns nicht passen
• Der Prüfcode ist offen
• Screenshots der Durchläufe sind beigefügt — einer für jede geprüfte Seite
• Fehler früherer Versionen werden in der Methodik selbst beschrieben, statt nachträglich umgeschrieben zu werden

Wir haben auch uns selbst geprüft

Eine Studie über Barrierefreiheit, deren eigene Websites nicht barrierefrei sind, ist nichts wert. Am 27. August 2026 haben wir alle vier eigenen Websites demselben Verfahren unterzogen wie die kommunalen: per Tastatur, in einem echten Browser, mit Prüfung der Fokussichtbarkeit bei jedem Schritt.

Und das haben wir bei uns selbst gefunden. Unser Code enthält 83 Vorkommen von outline: none — genau die Zeile, die in unserer eigenen Forschung 31 % aller Abbrüche ausmacht. Unschädlich sind sie nur, weil eine globale :focus-visible-Regel sie überschreibt. Genau das ist der Unterschied zwischen „schlecht geschrieben“ und „funktioniert schlecht“, und wir zeigen ihn an uns selbst.

Offenlegung von Interessenkonflikten

Zitierweise

Maksim Galatin & AIfa (Claude, Gemini, Grok). Municipal Website Accessibility: Automated Scan versus Keyboard Traversal. AIfa Works, 2026. CC BY-NC 4.0. aifa.works/research/methodology

Rückmeldung

Einen Fehler in Methodik oder Daten gefunden — schreiben Sie uns: contact@codeofdigitaleternity.com

Die Daten selbst — aifa.works/research/data