# Anmeldung und Klickpfade beschreiben

Wie Sie Anmeldung und Klickpfade als Schritte festlegen, Entwürfe freigeben und mit einem KI-Assistenten arbeiten; Selektoren, Tasten, Fehlergründe.

**Kurz gesagt**

- Anmeldungen und Klickpfade sind Schrittfolgen aus acht Aktionen, geprüft beim Speichern und noch einmal im Scanner.
- Beides setzt eine bestätigte Domain und ein eigenes Testkonto voraus; der Scanner bleibt auf Ihrer Domain.
- Läuft die Anmeldung über einen anderen Dienst, tragen Sie dessen Host ausdrücklich ein und bestätigen das.
- Was ein KI-Assistent oder die API anlegt, ist ein Entwurf und läuft erst, wenn eine Person ihn freigibt.

Dieser Artikel beschreibt vollständig, wie Sie im Reiter „Prüfung“ einer Website eine Anmeldung und Klickpfade festlegen. Er ist für Entwicklerinnen und Entwickler geschrieben. Ein KI-Assistent bekommt ihn als Anleitung, wenn er Klickpfade für Sie entwirft ([Anmeldung und Klickpfade beschreiben](https://barrierepruefung.de/hilfe/anmeldung-und-klickpfade#ki-assistent)). Die Grundlagen stehen in [Regelmäßig prüfen, Login-Bereiche und Klickpfade](https://barrierepruefung.de/hilfe/regelmaessig-pruefen#login).

## Voraussetzung: bestätigte Domain

Ohne bestätigte Domain lässt sich weder ein Zugang noch ein Klickpfad speichern, beide Formulare sind dann gesperrt. Das ist die Grenze zwischen einem Prüfwerkzeug und einem Werkzeug, das jemand gegen fremde Anwendungen richten könnte. Fällt die Bestätigung später weg, laufen Zugänge und Klickpfade nicht mehr.

Auch beim Speichern gilt: Alles, was ein Schritt erreichen darf, liegt auf Ihrer Domain (mit allen Subdomains). Die einzige Ausnahme sind die Anmeldedienste, die Sie ausdrücklich eintragen ([Anmeldung und Klickpfade beschreiben](https://barrierepruefung.de/hilfe/anmeldung-und-klickpfade#anmeldedienste)).

## Das Testkonto

Legen Sie ein eigenes Konto nur für die Prüfung an, mit den geringsten Rechten, die der Bereich zum Ansehen braucht. Nie Ihr eigenes Konto, nie eines mit Administrationsrechten. Die Zugangsdaten werden verschlüsselt gespeichert, nur während einer Prüfung entschlüsselt und in Bildern und Protokollen maskiert.

Besser noch: Prüfen Sie gegen eine Staging-Umgebung, damit nichts in Produktion geschehen kann.

Mit einem Formular oder Ablauf meldet sich eine Prüfung einmal an, nicht für jede Seite neu: Die weiteren Seiten übernehmen die Sitzung. Sie liegt nur im Arbeitsspeicher des Scanners, wird nach 15 Minuten ohne Zugriff, spätestens nach 2 Stunden nicht mehr benutzt und danach gelöscht, sobald der Scanner das nächste Mal aufräumt: im Leerlauf binnen Sekunden, sonst nach der gerade laufenden Seite. Das schont das Anmeldelimit Ihrer Anwendung. Läuft die Sitzung unterwegs ab, meldet sich die Prüfung neu an und prüft dieselbe Seite noch einmal; hält Ihre Anwendung die Anmeldung nur im `sessionStorage`, meldet sie sich je Seite an. Im Zugriffsprotokoll des Zugangs steht weiter ein Eintrag je Seite, denn die Zugangsdaten werden für jede Seite bereitgestellt.

## Zwei Zugangsarten

Im Abschnitt „Zugang hinterlegen“ wählen Sie unter „Art des Zugangs“:

- **„Einfaches Anmeldeformular“:** Benutzername, Passwort und Absenden liegen auf einer Seite. Sie geben die Adresse der Anmeldeseite und drei Selektoren an. Die Adresse muss auf Ihrer Domain liegen.
- **„Mehrstufige Anmeldung oder externer Anmeldedienst“:** Alles, was nicht auf eine Seite passt: erst eine Methode wählen, dann Benutzername und Passwort auf getrennten Seiten, ein Einmalcode, eine Weiterleitung zu einem Anmeldedienst. Sie beschreiben den Ablauf als Schrittfolge ([Anmeldung und Klickpfade beschreiben](https://barrierepruefung.de/hilfe/anmeldung-und-klickpfade#ablauf)).

In beiden Fällen ist ein „Erfolgsmerkmal“ Pflicht: ein Selektor, der nur angemeldet sichtbar wird. Ohne ihn würde der Scanner womöglich die Anmeldeseite statt Ihres Bereichs prüfen. Der Scanner prüft nach jeder Seite, ob er noch angemeldet ist. Steht das Merkmal nicht auf der geprüften Seite selbst, ruft er einmal die Seite nach der Anmeldung zusätzlich auf; ein Merkmal, das auf jeder Seite steht, spart diese Anfrage.

## Die Schrittsprache

Ein Klickpfad und eine mehrstufige Anmeldung sind eine JSON-Liste von Schritten. Jeder Schritt hat eine `action` und die Felder, die sie braucht. Es gibt genau acht Aktionen, kein freies JavaScript:

| Aktion | Felder | Wirkung |
| --- | --- | --- |
| `goto` | `url` | Öffnet eine Adresse auf Ihrer Domain. Relative Adressen wie `/warenkorb` gelten gegen die Adresse, unter der die Website tatsächlich liegt. |
| `click` | `selector` | Klickt das Element. |
| `fill` | `selector`, `value` | Trägt Text ein. |
| `select` | `selector`, `value` | Wählt eine Option einer Auswahlliste. |
| `press` | `key` | Drückt eine Taste ([Anmeldung und Klickpfade beschreiben](https://barrierepruefung.de/hilfe/anmeldung-und-klickpfade#tasten)), optional mit `selector`. |
| `wait_for` | `selector` | Wartet, bis das Element sichtbar ist. |
| `assert_visible` | `selector` | Wartet kurz und schlägt fehl, wenn das Element dann nicht sichtbar ist. Ein Klickpfad läuft in jeder Bildschirmbreite der Prüfung, das Element muss also auch schmal sichtbar sein. |
| `scroll` | – | Scrollt, damit nachgeladene Inhalte erscheinen. |

Ein Klickpfad darf höchstens 30 Schritte haben, eine mehrstufige Anmeldung höchstens 15. Bei einem Klickpfad wird nach jedem Schritt geprüft: Der Weg ist das Prüfobjekt, nicht nur das Ziel.

Ein Klickpfad:

```json
[
  {"action": "goto", "url": "/produkt/beispiel"},
  {"action": "click", "selector": "role=button[name=\"In den Warenkorb\"]"},
  {"action": "wait_for", "selector": "[data-test=warenkorb]"},
  {"action": "press", "key": "Tab"},
  {"action": "select", "selector": "#lieferart", "value": "Abholung"},
  {"action": "fill", "selector": "#plz", "value": "30159"},
  {"action": "scroll"},
  {"action": "assert_visible", "selector": "[data-test=zusammenfassung]"}
]
```

## Selektoren

Erlaubt sind drei Arten:

- **CSS**, etwa `#email`, `[data-test=konto]`, `form.login button`.
- **`role=…`**, etwa `role=button[name="Anmelden"]`: Das Element wird nach seiner Rolle und seinem zugänglichen Namen gefunden, so wie es auch ein Screenreader erlebt.
- **`text=…`**, etwa `text=Zur Kasse`: Das Element wird nach seinem sichtbaren Text gefunden.

Bevorzugen Sie `role=…`: Es übersteht Umbauten, bei denen sich Klassen und Aufbau ändern, und ein Element, das sich so nicht mehr finden lässt, ist meist auch für Menschen mit Hilfstechnik ein Problem.

Abgewiesen werden alle anderen Selektor-Arten, also `xpath=…`, `id=…` und `internal:…`, außerdem Selektoren, die mit `//` oder `..` beginnen (Playwright liest sie als XPath), und verkettete Selektoren mit `>>`. Der Grund: Jeder Klick wird an genau dem Element geprüft, das er bedient ([Anmeldung und Klickpfade beschreiben](https://barrierepruefung.de/hilfe/anmeldung-und-klickpfade#nie-geklickt)), und das gelingt nur zuverlässig, wenn der Selektor eindeutig lesbar ist.

## Tasten

Die Aktion `press` kennt nur diese Tasten: `Tab`, `Shift+Tab`, `Escape`, `Enter`, `Space`, `ArrowUp`, `ArrowDown`, `ArrowLeft`, `ArrowRight`, `Home`, `End`, `PageUp` und `PageDown`. Alles andere wird beim Speichern abgewiesen.

`Enter` und `Space` zählen wie ein Klick: Das Zielelement wird geprüft, und liegt es in einem Formular, zusätzlich dessen Absendeknopf. Ein Enter im Formular ist ein Absenden ohne Klick.

## Platzhalter für Zugangsdaten

Zugangsdaten stehen nie im Text der Schritte, sondern als Platzhalter, und zwar nur im Feld `value` einer `fill`-Aktion:

- `{{ zugang.benutzername }}`
- `{{ zugang.passwort }}`
- `{{ zugang.einmalcode }}`: nur, wenn Sie das Geheimnis für den Einmalcode hinterlegt haben. Der Code selbst wird für jede Prüfung neu erzeugt.

Benutzername und Passwort müssen je mindestens einmal vorkommen, sonst ist es kein Anmeldeablauf. Der Scanner setzt die Werte erst unmittelbar vor dem Eintragen ein; in Fehlermeldungen kommen sie nie vor.

Jeder Platzhalter geht nur in ein Feld, das für ihn gemacht ist. Der Scanner prüft das am Feld selbst, bevor er etwas einträgt:

- `{{ zugang.passwort }}` nur in ein Passwortfeld (`input type="password"`).
- `{{ zugang.einmalcode }}` nur in ein Feld mit `autocomplete="one-time-code"` oder `inputmode="numeric"` oder in ein Passwortfeld.
- `{{ zugang.benutzername }}` nur in ein einzeiliges Eingabefeld vom Typ Text, E-Mail oder Telefon.

Nie in einen mehrzeiligen Textbereich (`textarea`) oder einen editierbaren Bereich. Passt das Feld nicht, wird nichts eingetragen, und die Anmeldung scheitert mit `zugangsdaten_feld_unzulaessig`. So kann kein Schritt Ihr Passwort oder einen Einmalcode in ein Kommentar- oder Suchfeld schreiben und absenden, wo sie danach auf Ihrer Seite zu lesen wären. Der Benutzername ist die Ausnahme: Er darf in jedes einzeilige Textfeld, kann dort also stehen und auf Bildern oder im ARIA-Baum des Probelaufs sichtbar werden.

## Mehrstufige Anmeldung

Im Formular „Mehrstufige Anmeldung oder externer Anmeldedienst“ tragen Sie Bezeichnung, Benutzername, Passwort, optional das „Geheimnis für den Einmalcode (optional)“, die „Schritte der Anmeldung“ und das „Erfolgsmerkmal“ ein. Für den Ablauf gilt zusätzlich:

- Höchstens 15 Schritte.
- Der **erste Schritt ist ein `goto` auf Ihre Domain.** Der Scanner beginnt immer bei Ihnen. Später ist ein `goto` nur auf Ihre Domain erlaubt.
- Ein `stop_before` gibt es nicht: Eine Anmeldung löst keine Bestellung aus.
- Nach dem letzten Schritt muss der Scanner wieder auf Ihrer Domain stehen **und** das Erfolgsmerkmal sehen.

Ein Ablauf für eine Anwendung mit eigener Anmeldung in zwei Stufen:

```json
[
  {"action": "goto", "url": "/"},
  {"action": "click", "selector": "role=link[name=\"Anmelden\"]"},
  {"action": "fill", "selector": "#benutzername", "value": "{{ zugang.benutzername }}"},
  {"action": "click", "selector": "role=button[name=\"Weiter\"]"},
  {"action": "fill", "selector": "#passwort", "value": "{{ zugang.passwort }}"},
  {"action": "click", "selector": "role=button[name=\"Anmelden\"]"}
]
```

Als „Erfolgsmerkmal“ dient etwa `[data-test=konto]`.

## Externe Anmeldedienste

Leitet Ihre Anwendung zum Anmelden auf einen anderen Host weiter, tragen Sie diesen unter „Anmeldedienste (optional)“ ein, einen Host je Zeile, zum Beispiel `anmeldung.beispiel-dienst.de`. Dazu gehört ein Kästchen, mit dem Sie bestätigen, dass diese Anmeldedienste zu Ihrer Anwendung gehören und das Konto ein von Ihnen eingerichteter Testzugang ist. Wer das wann bestätigt hat, wird festgehalten.

Die Regeln dahinter:

- Höchstens 3 Hosts, jeder genau so, wie er im Browser steht. Keine Platzhalter wie `*`, keine IP-Adressen, und kein Host Ihrer eigenen Domain (dort braucht es keine Zulassung).
- Der Anmeldedienst wird **nur durch eine Navigation aus Ihrem Ablauf** erreicht, etwa einen Klick oder eine Weiterleitung, nie durch ein `goto`.
- Er gilt **nur während der Anmeldung.** Danach, in Klickpfaden und bei der Prüfung der Seiten, ist nur Ihre Domain erlaubt.
- Ändern Sie die Liste, bestätigen Sie neu. Ohne Bestätigung gelten die eingetragenen Hosts nicht.

Ein Ablauf über einen Anmeldedienst:

```json
[
  {"action": "goto", "url": "/"},
  {"action": "click", "selector": "role=button[name=\"Mit Servicekonto anmelden\"]"},
  {"action": "wait_for", "selector": "#benutzer"},
  {"action": "fill", "selector": "#benutzer", "value": "{{ zugang.benutzername }}"},
  {"action": "fill", "selector": "#kennwort", "value": "{{ zugang.passwort }}"},
  {"action": "click", "selector": "role=button[name=\"Anmelden\"]"}
]
```

Der Klick auf „Mit Servicekonto anmelden“ führt zu `anmeldung.beispiel-dienst.de`, dort werden die Daten eingetragen, danach geht es zurück zu Ihrer Anwendung. Dieser Host steht in der Liste der Anmeldedienste.

### Wird die Anmeldeseite mitgeprüft?

Für Nutzerinnen und Nutzer gehört die Anmeldung zu Ihrem Angebot. Ist der Host eines Anmeldedienstes in **derselben Organisation** als Website bestätigt, prüfen wir seine Anmeldeseite mit: einmal je Prüfung, beim Ankommen und bevor etwas eingetragen ist, ohne Zustandsentdeckung. Diese Prüfung meldet sich nicht an: Sie trägt nie ein Passwort oder einen Einmalcode ein. Steht ein solcher Schritt in Ihrem Ablauf vor der Anmeldeseite, endet sie dort mit `anmeldeseite_nicht_erreicht`. Die Befunde stehen im Bericht unter „Anmeldung über {Host}“ und zählen zur Konformität wie jede andere Seite. Ob die Bestätigung gilt, wird bei jeder Prüfung neu entschieden.

Ist der Host nicht bestätigt, wird die Seite nicht geprüft. Die Übersicht sagt dann, dass die Anmeldung über diesen Host lief und nicht geprüft wurde, und rät, ihn als Website zu bestätigen. Seiten der Anmeldung auf Ihrer eigenen Domain, etwa die Auswahl der Methode, gehören zur gewöhnlichen Seitenauswahl.

## Was nie geklickt wird

Es wird nie bestellt, bezahlt, gelöscht oder abgemeldet. Diese Regeln lassen sich nicht abschalten:

- Vor jeder Bedienung wird das **tatsächlich bediente Element** geprüft: sein Text, sein `aria-label`, `title`, `name`, Wert und `data-testid`. Enthält eine davon Wörter wie *löschen, kündigen, bestellen, kaufen, bezahlen, abmelden, delete, submit order, checkout*, wird nicht geklickt. Auch ein Icon-Knopf ohne Text fällt so auf.
- Mitgeprüft wird das Steuerelement, in dem das Element liegt: Trifft Ihr Selektor das Symbol oder einen Teil der Beschriftung in einem Knopf „Konto löschen“, gilt die Beschriftung des Knopfs. Bei einem Label zählt auch das Feld oder der Knopf, den es auslöst.
- Bedient wird genau das geprüfte Element. Wird es zwischen Prüfung und Klick ausgetauscht oder wechselt die Seite, scheitert der Schritt, statt ein anderes Element zu bedienen.
- Das gilt für `click`, für `Enter` und `Space` (samt Absendeknopf des Formulars) und für die gewählte Option bei `select`.
- Der Scanner wartet kurz auf ein Element, das noch nachgeladen wird. Erscheint es bei `click`, `press` mit Selektor oder `select` nicht, gilt es nicht als sicher: Der Schritt scheitert nach dieser Wartezeit mit `klick_abgelehnt:nicht_gefunden`.
- Einzige Ausnahme: *absenden* und *abschicken* sind **während der Anmeldung** erlaubt, weil das Absenden des Anmeldeformulars ihr Zweck ist. Alles andere gilt auch dort.
- Zur Laufzeit bleibt der Scanner auf Ihrer Domain. Führt ein Klick, eine Weiterleitung oder eine Taste auf eine andere Website, endet der Pfad sofort, nichts von der fremden Seite geht ins Ergebnis.

## Abbrechen vor

Berührt ein Klickpfad eine Bestellung oder Zahlung, ist „Abbrechen vor“ Pflicht: der Selektor der Schaltfläche, die die Handlung auslösen würde. Der Pfad endet garantiert davor.

Als Berührung gilt, wenn irgendwo in den Schritten (Adresse, Selektor, Wert oder Taste) einer dieser Wortteile vorkommt, gleich in welcher Schreibweise: bestell, kaufen, checkout, kasse, zahlung, bezahlen, order, payment, purchase, abschicken, absenden. Ohne „Abbrechen vor“ lässt sich ein solcher Klickpfad nicht speichern.

## Entwürfe und Freigabe

Was Sie im Reiter „Prüfung“ speichern, läuft ab der nächsten Prüfung: Speichern ist dort zugleich Freigeben. Was über die API oder einen KI-Assistenten entsteht, ist dagegen immer ein **Entwurf**. Er steht neben den laufenden Schritten und läuft in keiner Prüfung, bis eine Person ihn freigibt. Das gilt für neue Klickpfade, für die Änderung eines vorhandenen Klickpfads und für die Schritte einer mehrstufigen Anmeldung.

Jeder Klickpfad nennt seinen Status als Wort:

- **„Entwurf, läuft noch nicht“:** Der Pfad existiert nur als Entwurf.
- **„Freigegeben, läuft in Prüfungen“:** Die freigegebenen Schritte laufen in jeder Prüfung.
- **„Freigegeben, neuer Entwurf wartet auf Freigabe“:** Es laufen weiter die bisherigen Schritte; daneben liegt ein Entwurf.

Unter einem Entwurf steht, was er ändert, Schritt für Schritt als Text: „unverändert“, „geändert“ (mit vorher und jetzt), „neu“ und „entfällt“. Verglichen wird je Position; ein eingefügter Schritt erscheint deshalb als Reihe geänderter Schritte. Dazu steht, wann und auf welchem Weg der Entwurf entstand, etwa „über die API, Token „Editor Lena“, verantwortlich: …“, und wie der letzte Probelauf genau dieses Entwurfs ausging. Gab es keinen, steht dort „Noch nicht ausprobiert“. Freigeben lässt sich der Entwurf trotzdem; der Hinweis sagt Ihnen nur, was Sie freigeben.

Mit „Freigeben“ werden die Schritte des Entwurfs zu den laufenden Schritten, mit „Verwerfen“ wird nur der Entwurf gelöscht. Freigeben darf jedes Mitglied, das Klickpfade bearbeiten darf. Bei der Freigabe gilt:

- Der Entwurf wird **erneut geprüft**, mit den Regeln von heute. Ist die Domain nicht mehr bestätigt oder ist ein Schritt inzwischen ungültig, wird die Freigabe mit einer Meldung abgewiesen, und die laufenden Schritte bleiben.
- Freigegeben wird **genau der Entwurf, den Sie gesehen haben.** Hat ihn ein Assistent ersetzt, während die Seite offen war, wird die Freigabe abgewiesen; die Seite zeigt dann den neuen Entwurf.
- Die Freigabe der Schritte einer mehrstufigen Anmeldung hebt eine Pause auf ([Anmeldung und Klickpfade beschreiben](https://barrierepruefung.de/hilfe/anmeldung-und-klickpfade#pause)): Ein neuer Ablauf ist ein neuer Versuch. Ausgenommen ist ein Zugang, dessen Anmeldeseite außerhalb Ihrer Domain liegt.

## Mit einem KI-Assistenten arbeiten

Ein KI-Assistent in Ihrem Editor kann Klickpfade für Sie entwerfen und ausprobieren. Er spricht dafür mit dem MCP-Server des Dienstes; wer keinen Assistenten nutzt, erreicht dasselbe über die API ([Klickpfade über die API bearbeiten](https://barrierepruefung.de/hilfe/api-klickpfade)). Der Assistent sieht nur die Website, an die sein Token gebunden ist, und alles, was er speichert, ist ein Entwurf ([Anmeldung und Klickpfade beschreiben](https://barrierepruefung.de/hilfe/anmeldung-und-klickpfade#freigabe)).

### Token anlegen und Recht erteilen

1. Öffnen Sie bei der Website den Reiter „Einbindung“. Ihn sehen nur „Inhaberin oder Inhaber“ und „Administration“.
2. Vergeben Sie eine Bezeichnung, an der Sie das Token später erkennen, etwa „Editor Lena“, und wählen Sie „Token erzeugen“. Das Token wird nur einmal angezeigt.
3. Wählen Sie beim neuen Token „Klickpfade bearbeiten erlauben“. Erst dann darf es Klickpfade lesen, entwerfen und ausprobieren.

Wer das Recht erteilt, steht als verantwortliche Person an jedem Entwurf, der über dieses Token entsteht. Verliert sie ihre Rolle, erlischt das Recht: Der Assistent kann dann weiter lesen, aber nichts mehr entwerfen oder ausprobieren, bis eine andere Person das Recht neu erteilt.

### Den Assistenten einrichten

Die Adresse des MCP-Servers ist `https://barrierepruefung.de/mcp`. Das Token geht als Kopfzeile `Authorization: Bearer …` mit. Tragen Sie das Token nie in eine Datei ein, die mit Ihrem Code committet wird.

**GitHub Copilot in VS Code:** Legen Sie im Projekt die Datei `.vscode/mcp.json` an. Die `inputs`-Abfrage fragt das Token beim ersten Start ab, VS Code speichert es sicher für die nächsten Starts, und die Datei selbst enthält es nicht:

```jsonc
{
  "inputs": [
    {
      "type": "promptString",
      "id": "a11y-token",
      "description": "Token für Klickpfade",
      "password": true
    }
  ],
  "servers": {
    "a11y": {
      "type": "http",
      "url": "https://barrierepruefung.de/mcp",
      "headers": {
        "Authorization": "Bearer ${input:a11y-token}"
      }
    }
  }
}
```

**GitHub Copilot in JetBrains:** Öffnen Sie im Copilot-Chat im Agent-Modus über das Werkzeugsymbol die MCP-Einstellungen; es öffnet sich die Datei `mcp.json`. Dort steht die Kopfzeile unter `requestInit.headers`:

```jsonc
{
  "servers": {
    "a11y": {
      "url": "https://barrierepruefung.de/mcp",
      "requestInit": {
        "headers": {
          "Authorization": "Bearer IHR_TOKEN"
        }
      }
    }
  }
}
```

**GitHub Copilot in Visual Studio:** Tragen Sie den Server in die Datei `%USERPROFILE%\.mcp.json` für Ihr Benutzerkonto ein, nicht in die `.mcp.json` der Projektmappe, die oft mit eingecheckt wird. Der Aufbau ist derselbe, `servers` mit `url`. Wie Visual Studio eine eigene Kopfzeile wie `Authorization` erwartet, beschreibt Microsoft nicht; die Doku nennt für entfernte Server nur die Anmeldung über OAuth. Bitte in der Doku des Herstellers prüfen, ob `headers` oder `requestInit.headers` gilt.

**Claude Code:** Ein Befehl im Terminal. Ohne Angabe gilt der Eintrag nur für Sie in diesem Projekt und landet nicht im Repository:

```text
claude mcp add --transport http a11y https://barrierepruefung.de/mcp --header "Authorization: Bearer IHR_TOKEN"
```

**Cursor:** Tragen Sie den Server in die globale Datei `~/.cursor/mcp.json` ein, nicht in die `.cursor/mcp.json` des Projekts:

```jsonc
{
  "mcpServers": {
    "a11y": {
      "url": "https://barrierepruefung.de/mcp",
      "headers": {
        "Authorization": "Bearer IHR_TOKEN"
      }
    }
  }
}
```

Nicht geprüft ist der Cloud-Coding-Agent von GitHub Copilot, der in GitHub selbst arbeitet: Ob er einem entfernten MCP-Server eine solche Kopfzeile mitgeben kann, wissen wir nicht. Die Varianten in VS Code, Visual Studio und JetBrains sind davon nicht betroffen.

### Was der Assistent darf

Der Server bietet diese Werkzeuge an:

| Werkzeug | Was es tut |
| --- | --- |
| `website` | Host, Prüfbereich, Bestätigung der Domain und Grenze der Klickpfade |
| `klickpfade_auflisten` | Klickpfade mit Status, laufenden Schritten und Entwurf |
| `klickpfad_pruefen` | prüft Schritte, ohne zu speichern, mit Fehlercode je Schritt |
| `klickpfad_entwurf_speichern` | speichert einen neuen Klickpfad oder den Entwurf eines vorhandenen |
| `anmeldeablauf_entwurf_speichern` | schlägt die Schritte einer mehrstufigen Anmeldung vor |
| `probelauf_starten` | probiert einen Entwurf, einen freigegebenen Pfad oder ungespeicherte Schritte aus |
| `probelauf_ergebnis` | je Schritt, ob er ging und wohin er führte, mit Bild und ARIA-Schnappschuss |

Dazu gibt es den Prompt `klickpfad_anleitung` (dieser Artikel) und die Schemata `schema://klickpfad` und `schema://anmeldeablauf`.

Ein Probelauf geht den Pfad einmal im Browser, prüft aber nichts auf Barrierefreiheit. Er hält sich an dieselben Regeln wie eine Prüfung: nur Ihre Domain, nie bestellen, bezahlen, löschen oder abmelden ([Anmeldung und Klickpfade beschreiben](https://barrierepruefung.de/hilfe/anmeldung-und-klickpfade#nie-geklickt)). Beim ersten Schritt, der scheitert, endet er. Von einer Seite außerhalb Ihrer Domain gibt es weder Bild noch Schnappschuss, nur ihre Herkunft. Auf den Bildern sind Passwort-, E-Mail- und Telefonfelder maskiert, dazu Felder, deren Name oder Autovervollständigung auf Passwort, Token, Geheimnis oder Kartennummer hinweist. Was in anderen Feldern steht, ist zu sehen.

Der Assistent darf **nicht**:

- einen Entwurf freigeben. Das tut immer eine Person im Reiter „Prüfung“.
- Zugangsdaten sehen oder setzen: weder Benutzername, Passwort noch das Geheimnis für den Einmalcode, auch keine Anmeldedienste und keine Bestätigung dafür. In seinen Schritten stehen nur Platzhalter. Passwort und Einmalcode trägt der Scanner nur in dafür gemachte Felder ein ([Anmeldung und Klickpfade beschreiben](https://barrierepruefung.de/hilfe/anmeldung-und-klickpfade#platzhalter)), sodass sie nicht in einem Kommentarfeld landen; den Benutzernamen trägt er in jedes einzeilige Textfeld ein, er kann also auf Bildern oder im ARIA-Baum des Probelaufs auftauchen.
- einen Zugang anlegen oder löschen, einen Klickpfad löschen oder eine Prüfung starten.
- eine andere Website erreichen als die seines Tokens.

### Grenzen der Probeläufe

- Je Website laufen höchstens 20 Probeläufe je Stunde, davon höchstens 5 mit Anmeldung.
- Es läuft immer nur ein Probelauf je Website. Ein zweiter wird abgewiesen, nicht eingereiht.
- Scheitert die Anmeldung in einem Probelauf, sind Probeläufe mit Anmeldung für 30 Minuten gesperrt. Das schützt Ihr Testkonto vor einer Sperre durch den Anmeldedienst. Ein Probelauf zählt dagegen nicht zur Pause des Zugangs.
- Ergebnis und Bilder eines Probelaufs werden nach 24 Stunden gelöscht. Danach steht am Entwurf wieder „Noch nicht ausprobiert“.
- `probelauf_ergebnis` wartet bis zu 25 Sekunden auf das Ende des Probelaufs.
- Probeläufe gibt es nur in einem Plan mit Klickpfaden und nur mit bestätigter Domain.

## Wenn ein Klickpfad scheitert

Jeder Klickpfad hat im Reiter „Prüfung“ eine Karte mit seinem Stand aus dem letzten abgeschlossenen Lauf: erfolgreich, gescheitert oder „nicht geprüft“. Gescheitert heißt: Ein Schritt ließ sich nicht ausführen, und der Scanner hat gemessen, warum. Die Karte nennt den Schritt, die Breite und den Grund in einem Satz, dazu was Sie tun können; der Selektor und die Messwerte stehen unter „Technische Angabe“. Sie zeigt außerdem, ob der Pfad seit dem Lauf geändert wurde („im nächsten Lauf neu geprüft“). Mit „Zum Lauf“ öffnen Sie den Lauf, mit „Probelauf starten“ probieren Sie den Pfad sofort aus.

Gemessen wird nur an einem Schritt, der gescheitert ist, in der Seite, die der Scanner schon geladen hat: kurz, ohne die Seite neu zu laden und ohne weitere Anfrage an Ihre Website. Zahlen und Wahrheitswerte (Treffer, sichtbar, bedienbar, abgelöst, Seite gewechselt) und höchstens ein Pfad ohne Query kommen in den Befund, nie ein eingegebener Wert und nie eine Meldung des Browsers.

| Code | Was gemessen wurde | Was tun |
| --- | --- | --- |
| `element_fehlt` | Der Selektor trifft auf der Seite kein Element. Auch ein Klick, der nach der Wartezeit nichts fand (`klick_abgelehnt:nicht_gefunden`), steht meist so da. | Selektor auf der Seite prüfen, die der Schritt erreicht, am besten als `role=…` oder `text=…`. Erscheint das Element später, vorher mit `wait_for` warten. |
| `element_versteckt` | Der Selektor trifft ein Element, es ist aber nicht sichtbar. | Ein Element wählen, das in dieser Breite sichtbar ist, oder es mit einem vorherigen Schritt sichtbar machen, etwa durch Öffnen des Bereichs. |
| `erster_treffer_versteckt` | Der Selektor trifft mehrere Elemente, das erste ist nicht sichtbar. | Den Selektor einschränken oder `:visible` ergänzen. |
| `element_deaktiviert` | Das Element ist sichtbar, aber deaktiviert. | Vorher erledigen, was die Seite verlangt (etwa ein Pflichtfeld), oder mit `wait_for` warten, bis es bedienbar ist. |
| `element_abgeloest` | Die Seite hat das Element während des Schritts durch ein neues ersetzt. | Vorher mit `wait_for` auf ein Element warten, das erst erscheint, wenn die Seite fertig ist. |
| `zeitueberschreitung` | Der Schritt wurde in der Wartezeit nicht fertig. | Mit `wait_for` auf ein Element warten, das zeigt, dass die Seite geladen ist, und prüfen, ob der Schritt für das Testkonto möglich ist. |
| `adresse_nicht_erreichbar` | Die Adresse des Schritts war nicht erreichbar. | Prüfen, ob sie für das Testkonto erreichbar ist und nicht auf eine Fehlerseite führt. |
| `pfad_verlassen` | Der Pfad führte auf eine andere Website. | Den Pfad so ändern, dass er auf Ihrer Domain bleibt. |
| `klick_abgelehnt` | Der Klick wurde nicht ausgeführt, weil die Beschriftung des Elements oder des Knopfs, in dem es liegt, ein Muster enthält, das nie geklickt wird (`klick_abgelehnt:destruktives_muster:` und das Wort), oder aus einem anderen genannten Grund. | `stop_before` vor dem Schritt setzen ([Anmeldung und Klickpfade beschreiben](https://barrierepruefung.de/hilfe/anmeldung-und-klickpfade#stop-before)) oder einen anderen Selektor wählen. |
| `selektor_nicht_erlaubt` | Der Selektor ist weder CSS noch `role=…` oder `text=…`. | Umschreiben ([Anmeldung und Klickpfade beschreiben](https://barrierepruefung.de/hilfe/anmeldung-und-klickpfade#selektoren)). |
| `taste_nicht_erlaubt` | Die Taste steht nicht in der Liste. | Eine erlaubte Taste wählen ([Anmeldung und Klickpfade beschreiben](https://barrierepruefung.de/hilfe/anmeldung-und-klickpfade#tasten)). |

Ein Probelauf geht jede Breite des Prüfprofils nacheinander durch und endet beim ersten Scheitern. Er zählt als ein Probelauf, nicht als einer je Breite. Die Anmeldung geschieht einmal je Geräteklasse; Desktop und die schmale Breite teilen sich eine. Das Ergebnis nennt jeden Schritt je Breite mit Bild und, wenn er scheiterte, mit dem Befund. So sehen Sie, ob ein Pfad nur in der Breite scheitert, in der ein Menü hinter einem Knopf liegt.

**Nicht geprüft ist nicht gescheitert.** „nicht geprüft“ steht, wenn der Scanner den Pfad nicht bis zu einem Schritt bringen konnte, etwa wegen einer gescheiterten Anmeldung (Bremse, [Anmeldung und Klickpfade beschreiben](https://barrierepruefung.de/hilfe/anmeldung-und-klickpfade#pause)), einer Drosselung durch Ihre Website, einer abgelaufenen Frist, eines aufgebrauchten Budgets oder eines Fehlers des Proxys. Am Pfad liegt dann nichts; die Karte nennt den Grund, und mit der Ursache beseitigt, wird er im nächsten Lauf geprüft. Bei einem Grund, den wir nicht benennen können, steht „aus einem technischen Grund“. Was sich aus den Gründen ableitet, steht unter [Anmeldung und Klickpfade beschreiben](https://barrierepruefung.de/hilfe/anmeldung-und-klickpfade#fehlergruende).

**So beheben Sie einen Pfad.** Die Oberfläche bearbeitet vorhandene Klickpfade nicht Schritt für Schritt. „Korrigierten Klickpfad anlegen“ führt zum Formular „Klickpfad anlegen“: Legen Sie dort den korrigierten Pfad neu an und löschen Sie den alten („Klickpfad löschen“). Oder lassen Sie einen KI-Assistenten oder die API einen Entwurf zum vorhandenen Pfad schreiben ([Anmeldung und Klickpfade beschreiben](https://barrierepruefung.de/hilfe/anmeldung-und-klickpfade#ki-assistent), [Klickpfade über die API bearbeiten](https://barrierepruefung.de/hilfe/api-klickpfade)) und geben ihn im Reiter „Prüfung“ frei. Probieren Sie ihn vor der Freigabe mit einem Probelauf aus; der Entwurf zeigt, wie dieser Probelauf ausging.

## Fehlergründe

Scheitert etwas, nennt die Prüfung einen Grund. Er steht bei der Seite oder im Lauf:

| Grund | Was er bedeutet | Was tun |
| --- | --- | --- |
| Anmeldung gescheitert (`auth_failed`) | Das Erfolgsmerkmal wurde nicht sichtbar. | Zugangsdaten und Testkonto prüfen, Erfolgsmerkmal prüfen. |
| `anmeldung_dns:…` | Ihre Website ruft bei der Anmeldung eine Adresse auf, deren Name sich nicht auflösen lässt; die Adresse steht hinter dem Doppelpunkt. Die Zugangsdaten wurden nicht geprüft. | Einen eigenen A- oder CNAME-Eintrag für diese Adresse anlegen. Ein Platzhalter-Eintrag (`*`) greift nicht mehr, sobald es für einen Namen darüber eigene Einträge gibt. |
| `ziel_drosselt` | Die Schnittstelle Ihrer Website hat das Testkonto gedrosselt (HTTP 429, oder 503 mit der Kopfzeile `Retry-After`; ein 503 ohne sie gilt nicht als Drosselung). Wir warten die genannte Zeit, höchstens 120 Sekunden, ohne Angabe 60, und prüfen danach langsamer weiter: Nach jeder Seite warten wir 10 Sekunden, je Drosselung doppelt so lang, höchstens 60. Der Lauf endet mit diesem Grund nach 3 Drosselungen in Folge ohne fertige Seite oder nach 12 im ganzen Lauf. Antwortet die Anmeldeseite selbst oder das Absenden des Formulars mit 429 oder 503, endet der Lauf sofort, ohne zu warten. In beiden Fällen gilt die Anmeldung nicht als gescheitert, der Zugang wird nicht pausiert. | Das Limit Ihrer eigenen API für das Testkonto oder unsere Adresse lockern, dann den Lauf neu starten. |
| `kein_erfolgsindikator` | Es gibt kein Erfolgsmerkmal, oder es fand sich nicht. | Einen Selektor angeben, der nur angemeldet erscheint. |
| `anmeldung_schritt_fehlgeschlagen` | Ein Schritt der Anmeldung ließ sich nicht ausführen; die Schrittnummer steht dabei. | Selektor des Schritts prüfen, am besten als `role=…`. |
| `zugangsdaten_feld_unzulaessig` | Ein Schritt wollte Zugangsdaten in ein Feld eintragen, das nicht dafür gemacht ist; eingetragen wurde nichts. | Den Platzhalter in das richtige Feld setzen ([Anmeldung und Klickpfade beschreiben](https://barrierepruefung.de/hilfe/anmeldung-und-klickpfade#platzhalter)). |
| `anmeldung_fremder_host` | Die Anmeldung führte auf einen Host, der nicht in der Liste steht. | Den Host unter „Anmeldedienste (optional)“ eintragen und bestätigen, falls er zu Ihrer Anwendung gehört. |
| `anmeldung_nicht_zurueck` | Nach dem letzten Schritt stand der Scanner nicht wieder auf Ihrer Domain. | Fehlende Schritte ergänzen (Rückkehr abwarten, `wait_for`). |
| `anmeldung_verloren` | Während der Prüfung landete eine Seite wieder auf dem Anmeldedienst, oder das Erfolgsmerkmal war nach der Messung auch auf der Seite nach der Anmeldung nicht mehr zu sehen (Sitzung auf Ihrer eigenen Domain verworfen). Die Anmeldung ging verloren. | Sitzungsdauer des Testkontos prüfen. |
| `nachweis_nicht_moeglich` | Nach der Messung ließ sich nicht prüfen, ob die Anmeldung noch stand: Die Seite nach der Anmeldung war nicht erreichbar oder antwortete mit einem Serverfehler. Die Seite gilt als nicht geprüft, ihr Ergebnis wird verworfen. Die Anmeldung gilt nicht als gescheitert, die übrigen Seiten laufen weiter. | Wenn es sich häuft: die Erreichbarkeit der Seite nach der Anmeldung prüfen. |
| `frist_abgelaufen` | Die Seite wurde nicht geprüft, weil die Frist des Laufs abgelaufen ist, etwa nach langen Abständen wegen einer Drosselung. Die Seite selbst ist nicht das Problem. | Das Limit Ihrer eigenen API für das Testkonto lockern oder weniger Seiten prüfen. |
| `anmeldung_fehlgeschlagen` | Eine frühere Seite desselben Laufs ist bei der Anmeldung gescheitert; weitere Versuche wurden nicht unternommen. | Ursache der ersten Meldung beheben. |
| `anmeldung_ohne_grenze` | Die Anmeldung wurde nicht versucht, weil der Auftrag keine Grenze für erlaubte Hosts trug. Das kommt nur während einer Aktualisierung vor. | Prüfung später erneut starten. |
| `pfad_verlassen` | Ein Klickpfad führte auf eine andere Website. | Pfad so ändern, dass er auf Ihrer Domain bleibt. |
| `selektor_nicht_erlaubt` | Der Selektor ist kein CSS, `role=…` oder `text=…`. | Selektor umschreiben ([Anmeldung und Klickpfade beschreiben](https://barrierepruefung.de/hilfe/anmeldung-und-klickpfade#selektoren)). |
| `taste_nicht_erlaubt` | Die Taste steht nicht in der Liste. | Eine der erlaubten Tasten wählen. |
| `klick_abgelehnt:…` | Das Element wurde nicht bedient: nach der Wartezeit nicht gefunden (`nicht_gefunden`; in der Rückmeldung zum Klickpfad steht das meist als `element_fehlt`, [Anmeldung und Klickpfade beschreiben](https://barrierepruefung.de/hilfe/anmeldung-und-klickpfade#klickpfad-scheitert)) oder mit einem Muster, das nie geklickt wird (`destruktives_muster:` und das Wort), am Element selbst oder am Knopf, in dem es liegt. | Selektor prüfen; bei einem Bestellweg `stop_before` setzen. |
| Anmeldeseite nicht erreicht (`anmeldeseite_nicht_erreicht`) | Die Prüfung der Anmeldeseite kam auf keinen bestätigten Anmeldedienst. | Ablauf und Liste der Anmeldedienste prüfen. |
| Anmeldeseite wechselte während der Messung (`anmeldeseite_navigiert`) | Die Seite wurde teilweise geprüft, weil sie selbst weiterleitete. | Kein Fehler Ihrer Anmeldung, die Anmeldung wird deshalb nicht gebremst. |
| Anmeldeseite nicht mehr prüfbar (`anmeldeseite_nicht_pruefbar`) | Die Bestätigung des Anmeldehosts ist weggefallen. | Den Host wieder als Website bestätigen. |
| `anmeldeseite_gebremst` | Die Anmeldeseite wurde nicht geprüft, weil die Anmeldung in diesem Lauf schon gescheitert war. | Ursache der Anmeldung beheben, die Anmeldeseite wird dann wieder geprüft. |

## Pause nach Fehlschlägen

Eine gescheiterte Anmeldung kostet einen Versuch je Prüfung, nicht einen je Seite: Nach dem ersten Fehlschlag werden die übrigen Seiten desselben Laufs nicht mehr versucht (Grund `anmeldung_fehlgeschlagen`), auch die Prüfung der Anmeldeseite nicht (`anmeldeseite_gebremst`). Für diese Seiten werden die Zugangsdaten nicht einmal entschlüsselt. Das schützt das Testkonto, denn manche Anwendungen sperren es nach wenigen Fehlversuchen, und für einen Dritten sähe das aus wie ein Angriff auf Zugangsdaten. Scheitert die Anmeldung erst mitten im Lauf, ist der Lauf „teilweise abgeschlossen“; der Überblick und die E-Mail nennen dann den Grund, und die übrigen Seiten gelten als nicht geprüft.

Scheitert die Anmeldung 3 Läufe in Folge, wird der Zugang pausiert. Am Zugang steht dann der Grund; nach der Korrektur („Zugang wieder aktivieren“) geht es weiter. Ein Zugang, der wegen einer Anmeldeadresse außerhalb Ihrer Domain abgeschaltet wurde, hat diesen Knopf nicht: Er lässt sich erst nach dem Löschen und Neuanlegen mit einer Adresse auf Ihrer Domain wieder nutzen.

Wie viele Zugänge und Klickpfade Ihr Plan erlaubt, steht in [Regelmäßig prüfen, Login-Bereiche und Klickpfade](https://barrierepruefung.de/hilfe/regelmaessig-pruefen#klickpfade).

---

Zuletzt gegen das Produkt geprüft: 2026-11-03 · https://barrierepruefung.de/hilfe/anmeldung-und-klickpfade