test(EYT-141): Tastatur und sichtbaren Fokus auf /planung und /kosten wirklich fahren

[DYAI2025]

Kein Produktionscode, nur der fehlende Nachweis.

Der Befund

shell-smoke.spec.ts prüft den Tab-Zyklus — ausschliesslich auf /. In journey.pwtest.ts kam keyboard null Mal vor:

$ grep -c 'visibleFocus\|keyboard' apps/web/e2e/auth-journey/journey.pwtest.ts
0

/planung und /kosten, die beiden Flächen der Kernreise, hatten damit keinen einzigen Tastaturnachweis; nur die Startseite hatte einen. Das Akzeptanzkriterium nennt „Tastatur, sichtbarer Fokus" ausdrücklich für die tatsächlich implementierten Sprint-6-Flächen.

Das ist dieselbe Lücke wie beim verschachtelten <main> in PR #81 — nur an einer anderen Stelle: der Wächter existierte, hat die Fläche aber nie betreten.

Was jetzt läuft

pruefeTastaturUndFokus hängt an pruefeBarrierefreiheit und läuft damit auf beiden Flächen, mit echter GoTrue-Sitzung und echten Daten aus PostgreSQL.

Die Sichtbarkeitsprüfung (outline mit Breite > 0 oder box-shadow) ist aus shell-smoke.spec.ts wörtlich übernommen, nicht neu formuliert. Zwei Definitionen von „sichtbarer Fokus" wären zwei Wahrheiten, die auseinanderlaufen können — und die schwächere gäbe dann den Ausschlag.

Was bewusst NICHT zugesichert wird

Die DOM-Reihenfolge. shell-smoke vergleicht Tab- gegen DOM-Reihenfolge; auf einer statischen Seite trägt das. Hier stehen Formulare mit Zuständen, die während des Durchtabbens nachladen können — eine Reihenfolgezusicherung wäre flaky und würde als „Fokusfehler" gelesen, obwohl sie ein Timingartefakt ist.

Zugesichert ist, was hier wirklich trägt: jedes erreichte Element zeigt einen sichtbaren Fokus, und es gibt keine Tastaturfalle (ein weiterer Tab verlässt das zuletzt fokussierte Element).

Zwei Vorkehrungen gegen einen vakuösen Nachweis

1. Die Zahl der fokussierbaren Elemente wird vorab gegen 0 geprüft. Ohne das liefe die Schleife auf einer leeren Fläche null Mal und wäre grün, ohne etwas gemessen zu haben.
2. Elemente ohne Indikator werden benannt statt gezählt. „2 Elemente ohne Indikator" zwingt zur Suche; die Liste zeigt sofort, welches Bedienelement gemeint ist.

Gates lokal

tsc --noEmit   → 0
eslint         → 0
prettier       → 0

Die eigentliche Messung ist auth-journey in diesem PR.

🤖 Generated with Claude Code

Summary by Sourcery

Sichere die Tastaturbedienbarkeit und sichtbaren Fokusindikatoren auf den zentralen authentifizierten Flächen ab.

Bug Fixes:

• Erweitere die Barrierefreiheitsprüfungen der angemeldeten Kernflächen /planung und /kosten um den tatsächlichen Nachweis von Tastaturbedienbarkeit, sichtbarem Fokus und dem Fehlen von Tastaturfallen.
• Erkenne native Browser-Fokusringe mit outline-width: auto korrekt, damit die Fokusprüfung keine gültigen Indikatoren als Fehler meldet.

Enhancements:

• Verbessere die Diagnose der Tastaturtests durch die Benennung betroffener Bedienelemente und Schutzprüfungen gegen vakuose oder nicht tatsächlich ausgeführte Messungen.

Tests:

• Verknüpfe den Tastatur- und Fokusnachweis mit den Barrierefreiheitstests der authentifizierten Reise und prüfe alle erreichten interaktiven Elemente.

[sourcery-ai]

Sorry @DYAI2025, you have reached your weekly rate limit of 500000 diff characters.

Please try again later or upgrade to continue using Sourcery

[sourcery-ai]

Reviewer's Guide

Adds a focused Playwright-based keyboard accessibility check to the authenticated journey tests and wires it into the existing accessibility helper, ensuring /planung and /kosten have non‑vacuous coverage for visible focus and keyboard traps using the same definition as shell-smoke.

Sequence diagram for the updated accessibility checks with pruefeTastaturUndFokus

sequenceDiagram
  participant TestRunner
  participant pruefeBarrierefreiheit
  participant pruefeTastaturUndFokus
  participant Page
  participant DOM

  TestRunner->>pruefeBarrierefreiheit: pruefeBarrierefreiheit(seite, flaeche)
  pruefeBarrierefreiheit->>Page: setViewportSize
  pruefeBarrierefreiheit->>Page: goto
  pruefeBarrierefreiheit-->>TestRunner: viewport restored

  pruefeBarrierefreiheit->>pruefeTastaturUndFokus: pruefeTastaturUndFokus(seite, flaeche)

  pruefeTastaturUndFokus->>Page: evaluate(querySelectorAll.length)
  Page->>DOM: querySelectorAll(focusable)
  DOM-->>Page: fokussierbare
  Page-->>pruefeTastaturUndFokus: fokussierbare
  pruefeTastaturUndFokus->>TestRunner: expect(fokussierbare).toBeGreaterThan(0)

  loop Tab cycle over fokussierbare
    pruefeTastaturUndFokus->>Page: keyboard.press("Tab")
    pruefeTastaturUndFokus->>Page: evaluate(activeElement, getComputedStyle)
    Page->>DOM: document.activeElement
    DOM-->>Page: activeElement
    Page-->>pruefeTastaturUndFokus: { id, sichtbarerFokus }
    alt halt ohne sichtbarerFokus
      pruefeTastaturUndFokus->>pruefeTastaturUndFokus: ohneIndikator.push(id)
    end
  end

  pruefeTastaturUndFokus->>TestRunner: expect(ohneIndikator).toEqual([])

  pruefeTastaturUndFokus->>Page: evaluate(activeElement.outerHTML.slice)
  Page-->>pruefeTastaturUndFokus: vorher
  pruefeTastaturUndFokus->>Page: keyboard.press("Tab")
  pruefeTastaturUndFokus->>Page: evaluate(activeElement.outerHTML.slice)
  Page-->>pruefeTastaturUndFokus: nachher
  pruefeTastaturUndFokus->>TestRunner: expect(nachher).not.toBe(vorher)

  pruefeBarrierefreiheit->>Page: AxeBuilder(...).analyze()
  Page-->>pruefeBarrierefreiheit: ergebnis
  pruefeBarrierefreiheit-->>TestRunner: completes accessibility checks

Loading

File-Level Changes

Change	Details	Files
Introduce pruefeTastaturUndFokus helper to assert keyboard operability and visible focus on authenticated pages.	Define a Playwright helper that counts focusable elements via querySelectorAll and fails when none are present. Simulate Tab key presses to traverse the focusable elements and inspect document.activeElement in the browser context. Determine visible focus using the same outline/box-shadow rule as shell-smoke and collect identifiers for elements without indicators. Assert that the list of elements without visible focus is empty, with a descriptive failure message naming offending controls. Add a post-loop check to ensure an additional Tab changes the active element, guarding against keyboard traps.	apps/web/e2e/auth-journey/journey.pwtest.ts
Integrate the new keyboard and focus assertions into the existing pruefeBarrierefreiheit flow for authenticated journey pages.	Invoke pruefeTastaturUndFokus from pruefeBarrierefreiheit after viewport-based Axe runs. Ensure the new checks run with real authenticated sessions and data, alongside existing WCAG Axe checks.	apps/web/e2e/auth-journey/journey.pwtest.ts

---

Tips and commands

Interacting with Sourcery

• Trigger a new review: Comment @sourcery-ai review on the pull request.
• Continue discussions: Reply directly to Sourcery's review comments.
• Generate a GitHub issue from a review comment: Ask Sourcery to create an
  issue from a review comment by replying to it. You can also reply to a
  review comment with @sourcery-ai issue to create an issue from it.
• Generate a pull request title: Write @sourcery-ai anywhere in the pull
  request title to generate a title at any time. You can also comment
  @sourcery-ai title on the pull request to (re-)generate the title at any time.
• Generate a pull request summary: Write @sourcery-ai summary anywhere in
  the pull request body to generate a PR summary at any time exactly where you
  want it. You can also comment @sourcery-ai summary on the pull request to
  (re-)generate the summary at any time.
• Generate reviewer's guide: Comment @sourcery-ai guide on the pull
  request to (re-)generate the reviewer's guide at any time.
• Resolve all Sourcery comments: Comment @sourcery-ai resolve on the
  pull request to resolve all Sourcery comments. Useful if you've already
  addressed all the comments and don't want to see them anymore.
• Dismiss all Sourcery reviews: Comment @sourcery-ai dismiss on the pull
  request to dismiss all existing Sourcery reviews. Especially useful if you
  want to start fresh with a new review - don't forget to comment
  @sourcery-ai review to trigger a new review!

Customizing Your Experience

Access your dashboard to:

• Enable or disable review features such as the Sourcery-generated pull request
  summary, the reviewer's guide, and others.
• Change the review language.
• Add, remove or edit custom review instructions.
• Adjust other review settings.

Getting Help

• Contact our support team for questions or feedback.
• Visit our documentation for detailed guides and information.
• Keep in touch with the Sourcery team by following us on X/Twitter, LinkedIn or GitHub.