Fokusführung bei Menüs, Dialogen und Formularen

Fokus folgt der nächsten sinnvollen Handlung

Fokusführung entscheidet, wo eine Person nach einer Veränderung weiterarbeiten kann. Ein aufgeklappter Bereich, ein geöffnetes Fenster oder eine fehlerhafte Eingabe verändern den Zusammenhang. Dabei muss nicht jede Änderung den Fokus verschieben. Entscheidend ist, ob die aktuelle Position die nächste sinnvolle Handlung weiterhin ermöglicht. Diese Entscheidung wird für jeden Übergang ausdrücklich getroffen und anschließend mit der Tastatur geprüft.

Unser eigener fiktiver Entwurf verbindet drei kleine Aufgaben: Bereiche einer Navigation öffnen, einen gespeicherten Entwurf entfernen und zwei Eingaben prüfen. Es werden keine Nachrichten verschickt und keine echten Kundendaten gelöscht. Gerade diese kleine überschaubare Oberfläche erlaubt es, die verschiedenen Rückkehrwege vollständig zu untersuchen. Der vollständige HTML-, CSS- und JavaScript-Code steht im Beitrag und wurde tatsächlich im Browser ausgeführt.

Die wichtigste Frage lautet nach jedem Schritt: Wo kann ich jetzt sinnvoll weitermachen? Nach einem bloßen Aufklappen bleibt die auslösende Schaltfläche passend. Nach dem Öffnen eines modalen Dialogs liegt die Aufgabe dagegen im Dialog. Nach dem Löschen kann der frühere Auslöser fehlen. Ein einziges pauschales Muster für alle drei Fälle würde wichtige Unterschiede verdecken.

Drei Zustände vor dem ersten JavaScript benennen

Beschreiben Sie zunächst die sichtbaren Inhalte und die möglichen Handlungen. Die Navigation ist geöffnet oder geschlossen. Der Löschdialog ist offen oder geschlossen und bezieht sich auf genau einen Entwurf. Das Formular besitzt gültige oder zu korrigierende Eingaben. Diese Zustände sind fachlich verständlich und lassen sich ohne einen konkreten Selektor besprechen. Die technische Umsetzung soll diese Beschreibung abbilden.

Für jeden Zustandswechsel werden Auslöser, Ergebnis und Fokusziel notiert. Beim Dialog kommt ein Rückkehrziel hinzu. Ist es nach einer erfolgreichen Änderung noch vorhanden? Wenn nicht, braucht es eine vorher bestimmte Alternative. Diese Frage gehört zur Gestaltung des Ablaufs und wird nicht erst beim Reparieren einer JavaScript-Ausnahme gestellt. Die Entfernung einer Karte ist dafür ein besonders anschaulicher Fall.

Die tatsächliche Reihenfolge im HTML bildet die normale Tabulatorfolge. Es gibt keine positiven tabindex-Werte zur künstlichen Nummerierung. Nur die Entwurfsüberschrift und die Fehlerübersicht erhalten minus eins als gezielt erreichbare Zwischenziele. Dadurch können sie bei Bedarf Fokus erhalten, ohne bei jedem gewöhnlichen Durchgang einen zusätzlichen Tastaturschritt zu verlangen.

Eine aufklappbare Navigation behält den Zusammenhang

Die Schaltfläche Bereiche öffnet zwei gewöhnliche Navigationslinks. Ihr aria-expanded-Wert und die tatsächliche Sichtbarkeit werden gemeinsam geändert. Beim Öffnen bleibt der Fokus auf der Schaltfläche. Der nächste Tabulatorschritt erreicht den ersten Link. Das Aufklappen löst damit keinen überraschenden Sprung aus und die Person kann den neuen Inhalt in der erwarteten Reihenfolge betreten.

Escape innerhalb des offenen Bereichs schließt ihn und setzt den Fokus auf den Auslöser zurück. Verlässt die Person die Navigation mit Tab, schließt der Bereich ebenfalls. Dieser zweite Vorgang verschiebt den Fokus jedoch ausdrücklich nicht zurück. Sonst würde der gerade erreichte nächste Arbeitsschritt wieder entzogen. Gleiche Sichtbarkeit nach dem Schließen bedeutet also nicht in jedem Fall dieselbe Fokusbewegung.

Die Links bleiben normale Links. Wir erklären die Navigation nicht mit einer menu-Rolle zu einem komplexen Anwendungsmenü. Eine gewöhnliche Bereichsnavigation benötigt hier keinen zusätzlichen Pfeiltastenvertrag. Das passende native Element hält Bedienung und Erwartung zusammen. Das WAI-Beispiel zur aufklappbaren Navigation erläutert diese Unterscheidung; unser eigener kleiner Entwurf nutzt sie für seine konkrete Aufgabe.

WAI APG: Disclosure Navigation

Den unverstärkten Grundzustand sinnvoll erhalten

Im ursprünglichen HTML sind beide Navigationslinks sichtbar und die zusätzliche Öffnungsschaltfläche ist verborgen. Erst wenn die passende Skriptfunktion läuft, werden der Auslöser eingeblendet und die Links eingeklappt. Ohne JavaScript bleiben die Ziele deshalb unmittelbar erreichbar. Die Darstellung behauptet keine vorhandene Interaktion, deren Verhalten tatsächlich noch fehlt. Diese Reihenfolge lässt sich im Browser ohne Skriptausführung gesondert prüfen.

Die Löschaktionen sind ebenfalls zunächst verborgen. Die fiktiven Entwürfe bleiben lesbar und verschwinden nicht nur deshalb, weil eine optionale Erweiterung ausfällt. Das Formular behält zunächst seine native Pflichtfeldprüfung. Erst die eigene Fehlerübersicht aktiviert den bewusst selbst verwalteten Prüfablauf. Die unterschiedlichen Grundzustände sind Bestandteil des Entwurfs und werden nicht aus einem zufällig erfolgreichen Skriptstart abgeleitet.

Diese kleine Absicherung ist kein vollständiger Ersatz für einen produktiven Ablauf mit Serverantwort. Eine reale Anfrage braucht ihren tatsächlichen Versandweg und passende Rückmeldungen. Unser Beispiel prüft lediglich Eingaben im Browser. Die sichtbare Bestätigung bezeichnet deshalb genau diesen erreichten Zustand. Sie behauptet weder eine zugestellte Nachricht noch eine bereits durch einen Mitarbeiter bearbeitete Anfrage.

HTML als vollständigen Zusammenhang lesen

Der folgende Code enthält die gesamte kleine Aufgabenfläche. Sichtbare Überschriften benennen die Bereiche. Jede Eingabe hat ein zugeordnetes Label. Der Dialog erhält seinen Namen aus seiner Überschrift und besitzt zwei ausdrücklich benannte Aktionen. Die Fehlerübersicht enthält normale Links zu den betroffenen Eingaben. Diese Struktur bleibt auch ohne die konkrete rote Gestaltung verständlich.

Die Entwurfsüberschrift ist das Rückkehrziel, wenn nach dem Löschen keine Karte mehr vorhanden ist. Sie ist kein zusätzlicher regulärer Tabulatorstopp. Die Fehlerübersicht wird erst nach einer gescheiterten Prüfung sichtbar und gezielt erreicht. Beide Ziele sind an tatsächliche Zustandswechsel gebunden. Sie werden nicht zur allgemeinen Dekoration sämtlicher Überschriften mit Fokusattributen verwendet.

<header><nav aria-label="Hauptnavigation">
  <button id="nav-toggle" type="button" aria-expanded="false" aria-controls="nav-links" hidden>Bereiche</button>
  <div id="nav-links"><a href="#drafts">Entwürfe</a><a href="#contact">Anfrage prüfen</a></div>
</nav></header>
<main>
  <h1>Fokus am nächsten Arbeitsschritt</h1>
  <section id="drafts"><h2 id="draft-title" tabindex="-1">Gespeicherte Entwürfe</h2>
    <article class="draft"><h3>Wartung</h3><button class="remove-draft" type="button" hidden>Entwurf Wartung löschen</button></article>
    <article class="draft"><h3>Relaunch</h3><button class="remove-draft" type="button" hidden>Entwurf Relaunch löschen</button></article>
  </section>
  <section id="contact"><h2>Anfrage prüfen</h2>
    <p>Eigener fiktiver Eingabeentwurf. Die Prüfung versendet keine Nachricht.</p>
    <div id="error-summary" tabindex="-1" aria-labelledby="error-title" hidden>
      <h3 id="error-title">Bitte prüfen Sie die Angaben</h3><ul></ul>
    </div>
    <form id="enquiry">
      <label for="enquiry-name">Name</label>
      <input id="enquiry-name" name="name" required autocomplete="name">
      <p id="name-error" hidden></p>
      <label for="enquiry-email">E-Mail-Adresse</label>
      <p id="email-help">An diese Adresse soll die Rückantwort möglich sein.</p>
      <input id="enquiry-email" name="email" type="email" required autocomplete="email" aria-describedby="email-help">
      <p id="email-error" hidden></p>
      <button type="submit">Eingaben prüfen</button>
    </form>
    <p id="form-status" role="status"></p>
  </section>
</main>
<dialog id="remove-dialog" aria-labelledby="remove-title">
  <form method="dialog"><h2 id="remove-title">Diesen Beispielentwurf löschen?</h2>
    <p>Es wird nur eine Karte in diesem fiktiven Entwurf entfernt.</p>
    <button id="remove-cancel" value="cancel" autofocus>Abbrechen</button>
    <button id="remove-confirm" value="confirm">Entwurf löschen</button>
  </form>
</dialog>

Den Dialog mit einer sicheren nächsten Handlung öffnen

Unser Löschdialog beginnt auf Abbrechen. Die Person kann den Zusammenhang prüfen und muss die Entfernung bewusst wählen. Das ist eine Entscheidung für diese kurze Aufgabe mit zwei Aktionen. Ein anderer Dialog mit längeren Erläuterungen oder einer Bearbeitungsmaske kann ein anderes Anfangsziel benötigen. Die Anfangsposition soll das Verstehen und Handeln unterstützen statt überall mechanisch das erste beliebige Feld zu aktivieren.

showModal öffnet den nativen Dialog modal. Die außerhalb liegenden Inhalte gehören währenddessen nicht zum normalen Bedienweg. Für die beiden festen Aktionen ergänzt der Entwurf einen kleinen lokalen Tabulatorzyklus. Rückwärts von Abbrechen führt er zu Entwurf löschen, vorwärts von dort wieder zu Abbrechen. Escape bleibt als nativer Abbruch nutzbar. Der Handler betrifft ausschließlich dieses Dialogelement.

Die zwei festen Randziele sind eine bewusste Begrenzung. Sobald weitere Eingaben, verschachtelte Bereiche oder bedingt sichtbare Aktionen hinzukommen, muss diese Logik neu geprüft werden. Der gezeigte Zyklus ist kein universeller Fokusmanager. Bei einer größeren Komponentenbibliothek werden Anfangsziel, aktuelle erreichbare Elemente, Verschachtelung und Rückkehr als eigene gepflegte Funktion entwickelt und mit den tatsächlich unterstützten Umgebungen abgenommen.

WAI APG: Modal Dialog

Nach Abbruch zum vorhandenen Auslöser zurückkehren

Beim Öffnen merkt sich der Entwurf die auslösende Schaltfläche und die betroffene Karte. Nach Abbrechen oder Escape ist diese Schaltfläche weiterhin vorhanden. Sie erhält wieder Fokus. Die Person steht damit genau dort, wo die unterbrochene Aufgabe begann. Ein Rücksprung an den Dokumentanfang oder zum ersten Navigationslink würde zusätzliche Arbeit erzeugen und die Beziehung zwischen Aktion und Objekt verwischen.

Vor jedem Öffnen wird der Rückgabewert des Dialogs geleert. Nur der ausdrücklich bestätigte Wert confirm entfernt eine Karte. Diese Trennung ist beim wiederholten Verwenden entscheidend: Eine frühere Bestätigung darf nicht als neue Bestätigung gelten, wenn der nächste Dialog abgebrochen wird. Unsere Prüfung führt deshalb zuerst eine Entfernung aus und bricht anschließend den nächsten Löschversuch ab.

Ein gespeicherter Verweis allein garantiert noch kein gültiges Rückkehrziel. Die Eigenschaft isConnected zeigt hier, ob der alte Auslöser weiterhin im Dokument vorhanden ist. Erst dann wird er tatsächlich verwendet. Eine produktive Oberfläche mit zusätzlichen Sichtbarkeits- oder Berechtigungszuständen müsste außerdem prüfen, ob das Ziel weiterhin sinnvoll erreichbar ist. Unser kleiner Entwurf besitzt diese zusätzlichen Zustände nicht.

Nach dem Löschen eine konkrete Alternative anbieten

Nach erfolgreichem Löschen ist die frühere Schaltfläche zusammen mit ihrer Karte entfernt. Ein Fokusaufruf auf diesen alten Knoten würde keine sinnvolle Fortsetzung liefern. Deshalb wählt der Entwurf die nächste noch vorhandene Löschaktion. Nach der ersten Entfernung bleibt nur der Relaunch-Entwurf übrig. Genau seine Aktion wird im tatsächlich ausgeführten Tastaturweg zum neuen Ziel.

Wird auch die letzte Karte entfernt, gibt es keine weitere Löschaktion. Nun erhält die Überschrift Gespeicherte Entwürfe den Fokus. Der nächste normale Tabulatorschritt führt zum folgenden Formular. Die leere Sammlung bleibt dadurch als verständlicher Abschnitt bestehen. In einem realen Produkt könnte ergänzend eine Aktion zum Anlegen eines neuen Entwurfs das fachlich passendere Ziel sein.

Die Auswahl einer Alternative ist eine Produktentscheidung. In einer sortierten langen Liste könnte der folgende oder vorherige Eintrag sinnvoll sein. Bei einer abgeschlossenen Aufgabe kann eine übergeordnete Übersicht passen. Entscheidend ist ein nachvollziehbarer Weg für den konkreten Inhalt. Eine allgemeine Regel, nach jeder Entfernung immer denselben zufälligen ersten Button zu fokussieren, wäre dafür zu ungenau.

Fokusdarstellung und kleine Ansichten gemeinsam gestalten

Das CSS gibt fokussierten Elementen einen deutlichen Rahmen mit Abstand. In der dunklen Darstellung wird die Farbe angepasst. Diese Anzeige gehört zu denselben Elementen, deren Interaktion geprüft wird. Die Erklärgrafik verwendet die tatsächlichen Browserbilder. Der Fokusrahmen wurde nicht nachträglich eingezeichnet. So lässt sich die sichtbare Wirkung der eigenen Regeln direkt mit dem gezeigten Code verbinden.

Der Dialog begrenzt seine Breite auf den verfügbaren Raum und darf bei Bedarf vertikal rollen. Die Prüfung betrachtet 320, 390 und 1440 Pixel Breite in heller und dunkler Darstellung. Sie untersucht die Position des geöffneten Dialogs sowie des fokussierten Abbruchs. Zusätzliche überlagernde Banner besitzt dieser Entwurf nicht. In einer echten Einbindung müssen solche vorhandenen Ebenen gesondert berücksichtigt werden.

* { box-sizing: border-box; }
body { margin: 0; color: #202326; background: #f8f3ea; font: 1rem/1.5 system-ui,sans-serif; }
header, main { max-width: 58rem; margin: auto; padding: 1.5rem; }
header { border-bottom: 3px solid #cf0711; }
nav a { display: inline-block; padding: .6rem; color: #a50710; }
button { font: inherit; padding: .75rem 1rem; margin: .4rem 0; border: 2px solid #202326;
  border-radius: .3rem; color: white; background: #202326; cursor: pointer; }
:focus-visible { outline: 4px solid #cf0711; outline-offset: 4px; }
.draft { border: 1px solid #777; padding: 1rem; margin: 1rem 0; border-radius: .3rem; }
section { margin-bottom: 2.5rem; }
label { display: block; font-weight: 700; margin-top: 1rem; }
input { display: block; max-width: 100%; width: 30rem; padding: .7rem; font: inherit; border: 2px solid #777; }
#error-summary { border: 3px solid #a50710; padding: 1rem; margin-bottom: 1.5rem; }
#error-summary a { color: #a50710; }
[aria-invalid="true"] { border-color: #a50710; }
dialog { width: min(34rem,calc(100% - 2rem)); max-height: calc(100% - 2rem); overflow: auto;
  color: #202326; background: #f8f3ea; padding: 2rem; border: 2px solid #202326; border-radius: .5rem; }
dialog::backdrop { background: rgb(0 0 0 / .6); }
@media (prefers-color-scheme: dark) {
  body, dialog { background: #202326; color: #f8f3ea; }
  button { color: #202326; background: #f8f3ea; border-color: #f8f3ea; }
  nav a, #error-summary a { color: #ffb2ab; }
  :focus-visible { outline-color: #ff8a80; }
  input { color: #202326; background: #fffaf0; }
}

Formularfehler als erreichbare Arbeitsliste darstellen

Nach dem Prüfen leerer Pflichtangaben erscheint eine kurze Übersicht mit zwei Links. Der Fokus wird auf diese Übersicht gesetzt. Von dort führt der nächste Tabulatorschritt zum ersten Fehlerlink und Enter zur betroffenen Eingabe. Die Person muss weder die gesamte Seite nach roten Stellen absuchen noch erraten, welches Feld gemeint ist. Die Meldung nennt die erforderliche Korrektur.

Die Eingaben erhalten aria-invalid und eine Verknüpfung zu ihrer jeweiligen Meldung. Der E-Mail-Hinweis bleibt zusätzlich erhalten. Ein Fehler ersetzt also nicht versehentlich die vorherige Erklärung. Bei jeder erneuten Prüfung werden alte Markierungen und alte Listenpunkte entfernt und aus dem aktuellen Ergebnis neu aufgebaut. Die Inhalte werden über textContent gesetzt und nicht als ungeprüftes HTML eingefügt.

Die Entscheidung für eine fokussierte Übersicht gehört zu diesem Ablauf nach einer ausdrücklichen Prüfaktion. Während des Tippens wird der Fokus nicht fortwährend auf Fehlermeldungen gezogen. Eine solche Unterbrechung würde die Korrektur erschweren. Für andere Formulare können ergänzende Rückmeldungen sinnvoll sein, doch ihre Zeitpunkte und Ankündigungen müssen zum tatsächlichen Arbeitsprozess passen.

WAI: Form Notifications

Korrekturen bewahren und Erfolg präzise benennen

Nach Eingabe eines Namens und einer unvollständigen E-Mail-Adresse bleibt nur noch der E-Mail-Fehler übrig. Der bereits richtige Name bleibt erhalten und seine ungültige Markierung verschwindet. Die Übersicht führt jetzt direkt zum verbleibenden Problem. Dieser zweite Durchlauf ist aussagekräftiger als ein einzelner Test mit vollständig leerem Formular, weil er den Übergang zwischen mehreren Fehlerzuständen belegt.

Nach der korrekten E-Mail-Adresse verschwindet die Übersicht. Der Fokus bleibt auf Eingaben prüfen. Ein Statusbereich enthält die Aussage, dass die Eingaben für die weitere Prüfung vorbereitet sind. Dieser Text beschreibt nur die tatsächliche Browserprüfung. Es gibt keinen Netzwerkversand. Der Code bietet damit einen nachvollziehbaren Baustein für Eingabeführung und behauptet keinen vollständigen Kontaktprozess.

In einer produktiven Anwendung bleiben serverseitige Validierung und tatsächliche Fehlerantworten maßgeblich. Auch nach einer Serverantwort müssen gültige Angaben erhalten bleiben und betroffene Felder verständlich erreichbar sein. Vertrauliche Daten gehören dabei nicht unbedacht in eine URL oder Fehlermeldung. Die Fokusstrategie wird mit dem realen Daten- und Versandablauf verbunden, statt dessen erfolgreiche Verarbeitung aus einem grünen Status abzuleiten.

Den vollständigen JavaScript-Übergang nachvollziehen

Der folgende Code hält Navigation, Dialog und Formular als getrennte kleine Abläufe zusammen. Die Navigation unterscheidet Schließen mit Rückkehr und Schließen beim Weitergehen. Der Dialog unterscheidet vorhandenen Auslöser und gelöschten Auslöser. Das Formular unterscheidet Fehlerübersicht und erfolgreich beendete Browserprüfung. Diese Unterschiede erklären die jeweiligen Fokusaufrufe und machen spätere Änderungen überprüfbar.

Ein globaler Handler, der nach jeder Aktion pauschal das erste Element fokussiert, wird nicht benötigt. Ebenso wenig wird die normale Tabulatortaste auf der ganzen Seite abgefangen. Nur die beiden Dialogränder erhalten ihre eng begrenzte Ergänzung. Die übrige Reihenfolge bleibt beim Browser. Damit lässt sich ein Fehler im Übergang einem kleinen überschaubaren Abschnitt zuordnen und gezielt korrigieren.

const navButton = document.querySelector('#nav-toggle');
const navLinks = document.querySelector('#nav-links');
function closeNavigation(restoreFocus) {
  navLinks.hidden = true;
  navButton.setAttribute('aria-expanded', 'false');
  if (restoreFocus) navButton.focus();
}
navButton.hidden = false;
navLinks.hidden = true;
navButton.addEventListener('click', () => {
  const open = navButton.getAttribute('aria-expanded') === 'true';
  navLinks.hidden = open;
  navButton.setAttribute('aria-expanded', String(!open));
});
document.querySelector('nav').addEventListener('keydown', event => {
  if (event.key === 'Escape' && !navLinks.hidden) {
    event.preventDefault(); closeNavigation(true);
  }
});
document.querySelector('nav').addEventListener('focusout', event => {
  if (!event.currentTarget.contains(event.relatedTarget)) closeNavigation(false);
});

const dialog = document.querySelector('#remove-dialog');
const cancelButton = document.querySelector('#remove-cancel');
const confirmButton = document.querySelector('#remove-confirm');
let opener = null, pendingCard = null;
for (const button of document.querySelectorAll('.remove-draft')) {
  button.hidden = typeof dialog.showModal !== 'function';
  button.addEventListener('click', () => {
    opener = button; pendingCard = button.closest('.draft');
    dialog.returnValue = ''; dialog.showModal();
  });
}
dialog.addEventListener('keydown', event => {
  if (event.key !== 'Tab') return;
  if (event.shiftKey && document.activeElement === cancelButton) {
    event.preventDefault(); confirmButton.focus();
  } else if (!event.shiftKey && document.activeElement === confirmButton) {
    event.preventDefault(); cancelButton.focus();
  }
});
dialog.addEventListener('close', () => {
  if (dialog.returnValue === 'confirm') pendingCard?.remove();
  const destination = opener?.isConnected ? opener
    : document.querySelector('.remove-draft') || document.querySelector('#draft-title');
  destination.focus();
  opener = null; pendingCard = null;
});

const form = document.querySelector('#enquiry');
const summary = document.querySelector('#error-summary');
form.noValidate = true;
form.addEventListener('submit', event => {
  event.preventDefault();
  const name = form.elements.name, email = form.elements.email;
  const errors = [];
  if (!name.value.trim()) errors.push({field:name, errorId:'name-error', text:'Bitte geben Sie einen Namen an.'});
  if (email.validity.valueMissing || email.validity.typeMismatch)
    errors.push({field:email, errorId:'email-error', text:'Bitte geben Sie eine E-Mail-Adresse an.'});
  for (const field of [name,email]) {
    field.removeAttribute('aria-invalid');
    if (field === email) field.setAttribute('aria-describedby','email-help');
    else field.removeAttribute('aria-describedby');
  }
  for (const id of ['name-error','email-error']) document.getElementById(id).hidden = true;
  const list = summary.querySelector('ul'); list.replaceChildren();
  for (const error of errors) {
    error.field.setAttribute('aria-invalid','true');
    error.field.setAttribute('aria-describedby', (error.field === email ? 'email-help ' : '') + error.errorId);
    const text = document.getElementById(error.errorId);
    text.textContent = error.text; text.hidden = false;
    const li = document.createElement('li'), link = document.createElement('a');
    link.href = '#' + error.field.id; link.textContent = error.text;
    li.append(link); list.append(li);
  }
  summary.hidden = errors.length === 0;
  document.querySelector('#form-status').textContent = errors.length ? ''
    : 'Die Eingaben sind für die weitere Prüfung vorbereitet.';
  if (errors.length) summary.focus();
});

96 ausgeführte Prüfungen als begrenzten Nachweis lesen

Der eigene Entwurf wurde mit 96 Prüfungen in Desktop-Edge ausgeführt. Dazu gehören Öffnen und Verlassen der Navigation, Escape, Dialoganfang, beide Tabulatorränder, Abbruch, erste Entfernung, zweite Entfernung und das alternative Fokusziel bei leerer Sammlung. Der wiederholte Dialog nach einer früheren Bestätigung ist ausdrücklich enthalten. Die Prüfung beobachtet jeweils das tatsächliche aktive Element.

Für das Formular wurden zwei Fehler, die Korrektur eines Fehlers und anschließend gültige Angaben durchgespielt. Fehlerlinks, erhaltene Werte, aktualisierte Beschreibungen und der Verbleib auf der Prüfaktion wurden kontrolliert. Beide Farbdarstellungen und mehrere Breiten gehören ebenfalls dazu. Ohne JavaScript bleiben die Navigationsziele sichtbar, die optionalen Aktionen verborgen und die native Formularprüfung aktiv.

Diese Fälle belegen das Verhalten des gezeigten Entwurfs. Sie sind keine vollständige Prüfung aller Browser, Bildschirmleseprogramme, Vergrößerungen und produktiven Einbindungen. Die Abbildungen zeigen echte Zustände derselben Quellen. Für die konkrete Veröffentlichung gehören zusätzliche manuelle Aufgabenwege und die vorgesehenen Hilfstechniken in die Abnahme. Ein erfolgreicher automatisierter Lauf ersetzt diese eigene Betrachtung nicht.

Fokus ist weder Auswahl noch gespeicherter Zustand

Ein sichtbarer Fokus zeigt die aktuell bedienbare Position. Er bedeutet nicht automatisch, dass ein Entwurf ausgewählt, ein Formular abgesendet oder eine Änderung gespeichert wurde. Diese Unterschiede müssen auch sprachlich erkennbar bleiben. Im Beispiel trägt der Dialog seine Entscheidung über den Rückgabewert. Das Formular bestätigt seine eigene Prüfung über einen getrennten Status. Die Fokusposition allein dient für keine dieser fachlichen Aussagen als Beweis.

Auch das bloße Scrollen zu einer Stelle ersetzt die Tastaturposition nicht. Eine Person kann einen Fehler sehen und trotzdem beim nächsten Tabulatorschritt an einer ganz anderen Stelle landen. Deshalb kontrollieren unsere Abläufe das tatsächlich aktive Element. Für den eigenen Bestand lohnt sich derselbe Vergleich zwischen sichtbarem Ausschnitt, aktuellem Fokus und fachlichem Zustand. Erst wenn alle drei zusammenpassen, ist die nächste Handlung verständlich erreichbar. Eine spätere Animation darf diese Verbindung nicht wieder verdecken oder die Bedienung verzögern.

Eine hilfreiche Abnahme für das eigene Team schreiben

Formulieren Sie die erwarteten Übergänge in der Sprache der Aufgabe. Zum Beispiel: Entwurf öffnen, Entfernung abbrechen und beim selben Entwurf weiterarbeiten. Oder: Letzten Entwurf entfernen und den leeren Bereich verstehen. Solche Sätze sind für Gestaltung, Entwicklung und fachliche Prüfung gemeinsam nachvollziehbar. Technische Selektoren ergänzen den Nachweis, müssen aber nicht die einzige verständliche Beschreibung bleiben.

Notieren Sie bei einem Fehler den Ausgangszustand, die ausgelöste Handlung und die tatsächlich verlorene Position. Die Aussage Fokus falsch ist schwerer zu bearbeiten als die Beobachtung, dass nach dem Löschen der letzten Karte der nächste Tabulatorschritt unerwartet im Kopfbereich beginnt. Eine konkrete Beschreibung macht die Folge für die Nutzer sichtbar und führt schneller zur passenden Korrektur.

Nach einer Änderung werden die betroffenen Wege erneut ausgeführt. Ein weiterer Dialogbutton, eine neue Validierung oder eine andere mobile Navigation können bisherige Annahmen verändern. Fokusführung bleibt deshalb Teil der Pflege interaktiver Komponenten. Die entscheidende Qualitätsfrage bleibt dieselbe: Kann die Person nach Öffnen, Abbrechen, Korrigieren und Bestätigen ohne Orientierungsverlust an ihrer eigentlichen Aufgabe weiterarbeiten?

Übergänge im Überblick

Checkliste für die eigene Umsetzung

• Für jeden Übergang Zustand, Auslöser und Fortsetzung beschreiben.
• Normale Dokumentreihenfolge statt positiver Tabulatornummern verwenden.
• Sichtbarkeit und aria-expanded gemeinsam aktualisieren.
• Beim Weitergehen keinen unerwünschten Rücksprung auslösen.
• Dialoganfang und Abbruch bewusst festlegen.
• Gelöschte Auslöser durch fachlich passende Ziele ersetzen.
• Alte Dialogrückgaben vor erneutem Öffnen leeren.
• Fehlerlinks, Beschreibungen und erhaltene Werte nach Korrektur prüfen.
• Fokus mit Tastatur, kleinen Ansichten und beiden Darstellungen kontrollieren.
• Realen Versand und serverseitige Fehler mit demselben Aufgabenweg abnehmen.

Quellen und Prüfstand

Primärquellen am 09.11.2026 geprüft. Eigener fiktiver Entwurf mit 96 tatsächlich ausgeführten Edge-Prüfungen. Die Browserprüfung ersetzt weder eine vollständige Hilfstechnikprüfung noch eine rechtliche Bewertung der gesamten Webseite.

• WAI APG: Disclosure Navigation
• WAI APG: Modal Dialog
• WAI: User Notification
• WCAG: Focus Order
• MDN: HTMLElement.focus
• MDN: inert