Eine Webseite vollständig mit der Tastatur bedienen
Eine echte kleine Aufgabe ohne Maus durchführen und ihre Zustandswechsel vollständig prüfen.
Die vollständige Aufgabe zählt, nicht nur ein Tabulatorschritt
Eine mit der Tastatur bedienbare Webseite lässt Menschen ihre tatsächliche Aufgabe ohne Maus erledigen. Sie müssen die nötigen Elemente erreichen, den aktuellen Fokus erkennen, Aktionen auslösen und vorübergehend geöffnete Bereiche wieder verlassen können. Ein einmal sichtbarer Rahmen um einen Link belegt diesen vollständigen Ablauf noch nicht. Die Prüfung folgt deshalb der Aufgabe einschließlich Auswahl, Bestätigung, Abbruch und Rückkehr.
Unser eigenes Beispiel ist eine kleine fiktive Leistungsübersicht. Zwei Angebote sind sichtbar und ein optionaler Dialog kann nach Webseiten oder Software filtern. Die Daten sind erfunden. Wir entwickeln den tatsächlichen HTML-, CSS- und JavaScript-Entwurf und führen die Tastaturwege im Browser aus. So entsteht ein überschaubarer überprüfbarer Ablauf statt einer allgemeinen Behauptung, jede Komponente einer gesamten produktiven Webseite sei bereits abgenommen.
Der Einstieg ist einfach: Legen Sie die Maus beiseite und beschreiben Sie den gewünschten Weg. Im Beispiel soll eine Person den Hauptinhalt erreichen, den Bereich wählen, die Auswahl übernehmen und anschließend eine passende Leistung öffnen. Danach folgt derselbe Weg mit Abbruch. Erst wenn diese Varianten funktionieren, betrachten wir weitere Ansichten, Schriftgrößen und unterstützende Technologien.
Eine verständliche Reihenfolge aus dem Dokument entwickeln
Die Fokusfolge soll zur inhaltlichen Reihenfolge passen. Unser Beispiel beginnt mit einem Sprunglink, danach folgen die Hauptnavigation und im Inhalt die Filteraktion sowie die sichtbaren Leistungslinks. Die Reihenfolge entsteht aus dem HTML. Wir verwenden keine positiven tabindex-Werte, um eine abweichende künstliche Nummerierung zu erzwingen. Eine spätere Änderung am Layout würde solche Sonderreihenfolgen sonst leicht unverständlich machen.
Ein tabindex von minus eins hat hier eine andere Aufgabe. Der Hauptbereich kann nach dem Sprunglink gezielt Fokus erhalten, ohne als zusätzlicher gewöhnlicher Tabulatorschritt zwischen die Aktionen zu geraten. Die Dialogüberschrift wird beim Öffnen ebenfalls gezielt fokussiert. Diese beiden bewussten Ziele unterstützen die Orientierung. Sie sind keine Einladung, jede Überschrift und jeden Absatz in die reguläre Tastaturfolge aufzunehmen.
Prüfen Sie die reale Seite einschließlich Kopfbereich, eingeblendeter Leisten und Fußbereich. Ein isolierter Baustein kann eine gute Folge besitzen, während die Einbindung denselben Bereich zweimal erreichbar macht oder einen anderen Weg verdeckt. Eine responsive Umordnung verdient besondere Aufmerksamkeit: Die sichtbare Abfolge und die Tastaturfolge dürfen nicht ohne nachvollziehbaren Grund weit auseinanderlaufen. Die Gestaltung und das Dokument werden gemeinsam beurteilt.
Native Bedienelemente für ihre Aufgabe nutzen
Ein Link führt zu einem Ziel. Ein Button löst eine Aktion aus. Unser Filteröffner ist deshalb ein button mit type="button" und kein mit Klicklogik versehenes div. Die Auswahl im Dialog verwendet echte Radiobuttons. Diese Elemente bringen passende Grundfunktionen mit, die wir nicht vollständig nachbauen müssen. Trotzdem gehört ihr tatsächliches Verhalten im fertigen Zusammenhang in die Prüfung.
Enter aktiviert im Beispiel Links und die Filteraktion. Die Leertaste kann den fokussierten Button ebenfalls auslösen. Innerhalb der Radiogruppe wechseln die Pfeiltasten die Auswahl. Ein Test, der ausschließlich immer wieder Tab drückt, würde diese Teile des Ablaufs übersehen. Die konkrete Interaktion richtet sich nach dem Element. Einheitlichkeit bedeutet hier passende Konventionen statt derselben Taste für jede beliebige Aufgabe.
Wenn eine eigene komplexe Komponente notwendig ist, braucht sie einen ausdrücklich beschriebenen Tastaturvertrag. Dazu gehören Einstieg, Bewegung, Aktivierung und Ausstieg. ARIA-Rollen allein liefern diese Bedienlogik nicht automatisch. Für unseren überschaubaren Filter gibt es keinen Grund, eine Radiogruppe aus frei gestalteten Containerflächen neu zu erfinden. Die gestalterische Anpassung kann auf der vorhandenen Struktur aufbauen.
Fokus sichtbar und erreichbar halten
Unsere CSS-Regel für :focus-visible zeichnet einen deutlichen Rahmen mit Abstand zum Element. In der dunklen Darstellung wird eine hellere rote Variante verwendet. Der Rahmen soll die aktuelle Position zeigen und nicht nur eine dekorative Zustandsänderung sein. Wir entfernen die Browseranzeige nicht ersatzlos. Ob die gewählte Anzeige im konkreten Umfeld erkennbar bleibt, wird tatsächlich betrachtet.
Ein vorhandener Rahmen hilft wenig, wenn ein feststehender Kopfbereich, ein Cookiebereich oder eine andere Ebene das Element verdeckt. Deshalb prüfen wir nicht nur einen berechneten CSS-Wert. Im Beispiel wird zusätzlich die sichtbare Position des fokussierten Dialogtitels bei mehreren Breiten untersucht. Eine vollständige produktive Prüfung muss auch alle tatsächlich vorhandenen überlagernden Bereiche und ihre Wechselwirkungen berücksichtigen.
Die WCAG unterscheiden sichtbaren Fokus und die Frage, ob ein fokussiertes Element verdeckt wird. Für die Gestaltung nehmen wir eine praktisch hilfreiche klare Sichtbarkeit des gesamten wichtigen Elements als Ziel. Die konkreten Mindestanforderungen und ihre Bewertung werden dadurch nicht zu einer pauschalen Konformitätsbescheinigung. Unser Nachweis bleibt an den gezeigten Entwurf und die beschriebenen Fälle gebunden.
W3C: Focus Visible · Focus Not Obscured
Den Hauptinhalt ohne lange Umwege erreichen
Ein Sprunglink kann wiederkehrende Navigation überspringen. Im Beispiel heißt er Zum Inhalt und wird beim ersten Tabulatorschritt sichtbar. Seine Aktivierung setzt den Fokus auf den Hauptbereich. Anschließend führt der nächste Tabulatorschritt zur Filteraktion im Inhalt. Genau dieser tatsächliche Ablauf wird geprüft. Ein Link, der lediglich optisch scrollt und die Tastaturposition nicht sinnvoll verändert, würde die Aufgabe nur teilweise erfüllen.
Der Sprunglink erhält eine eigene klare Fläche, damit er vor der übrigen Gestaltung lesbar ist. Im Normalzustand liegt er außerhalb des sichtbaren oberen Bereichs und erscheint bei Fokus. Diese Technik darf keinen wichtigen Inhaltslink dauerhaft verstecken. Sie ist für den gezielt vorgesehenen zusätzlichen Einstieg gedacht. Die konkrete Position wird mit den vorhandenen Kopfbereichen und kleinen Ansichten abgestimmt.
Für eine große Anwendung können weitere Sprungziele sinnvoll sein, etwa eine Ergebnisliste oder eine zentrale Werkzeugleiste. Jedes zusätzliche Ziel muss verständlich benannt und fachlich nützlich sein. Unser kleines Beispiel benötigt nur den Hauptinhalt. Eine lange Sammlung technischer Sprungpunkte würde die Orientierung nicht automatisch verbessern und könnte den einfachen Einstieg unnötig kompliziert machen.
Den vollständigen HTML-Ablauf betrachten
Der folgende Entwurf enthält Navigation, Hauptinhalt, zwei Leistungsangebote und den Filterdialog. Die Filteraktion ist zunächst hidden und wird nur für die passende Skriptfunktion sichtbar. Ohne JavaScript bleiben beide Angebote und ihre normalen Links lesbar. Es gibt keine falsche Erfolgsmeldung und keinen unbedienbaren versprochenen Filter im unverstärkten Grundzustand. Die Beispieldaten werden ausdrücklich als fiktiv bezeichnet.
Der Dialog trägt einen Namen aus seiner sichtbaren Überschrift. Sein Formular nutzt die native Dialogmethode und besitzt klar bezeichnete Aktionen. Anwenden steht vor Abbrechen in der Dokumentreihenfolge. Die Radiogruppe hat einen gemeinsamen Gruppentitel und einzelne sichtbare Labels. Diese Struktur macht die Frage und die möglichen Antworten auch unabhängig vom farbigen Layout nachvollziehbar.
<a class="skip" href="#main">Zum Inhalt</a>
<header><nav aria-label="Hauptnavigation">
<a href="#services">Leistungen</a><a href="#contact">Kontakt</a>
</nav></header>
<main id="main" tabindex="-1">
<h1>Passende Leistung finden</h1>
<p>Eigener fiktiver Entwurf für die Tastaturprüfung.</p>
<button id="open-filter" type="button" hidden>Bereich filtern</button>
<p id="result-status" role="status">2 Leistungen</p>
<section id="services" aria-label="Leistungen">
<article data-kind="web"><h2>Webseitenwartung</h2>
<p>Prüfen und dokumentieren.</p><a href="#maintenance-info">Wartung ansehen</a></article>
<article data-kind="software"><h2>Schnittstellen</h2>
<p>Datenwege verständlich verbinden.</p><a href="#interface-info">Schnittstellen ansehen</a></article>
</section>
<section id="maintenance-info"><h2>Wartung im Überblick</h2><p>Fiktive Leistungsinformation.</p></section>
<section id="interface-info"><h2>Schnittstellen im Überblick</h2><p>Fiktive Leistungsinformation.</p></section>
<section id="contact"><h2>Kontakt</h2><a href="#main">Zur Übersicht</a></section>
</main>
<dialog id="filter-dialog" aria-labelledby="filter-title">
<form method="dialog">
<h2 id="filter-title" tabindex="-1" autofocus>Bereich auswählen</h2>
<fieldset><legend>Welche Leistungen möchten Sie sehen?</legend>
<label><input type="radio" name="kind" value="all" checked> Alle Bereiche</label>
<label><input type="radio" name="kind" value="web"> Webseiten</label>
<label><input type="radio" name="kind" value="software"> Software</label>
</fieldset>
<div class="actions"><button id="apply-filter" value="apply">Anwenden</button>
<button id="cancel-filter" value="cancel">Abbrechen</button></div>
</form>
</dialog>Einen modalen Dialog bewusst betreten und verlassen
Beim Öffnen erhält die Dialogüberschrift den Anfangsfokus. Dadurch wird der neue Zusammenhang sichtbar, bevor die Person zur Auswahl weitergeht. Während der Dialog modal geöffnet ist, bleibt die übrige Seite für die normale Interaktion zurückgestellt. Ein nächster Tabulatorschritt erreicht die gewählte Radiooption. Die Pfeiltasten wechseln dort die Auswahl. Anwenden übernimmt sie und schließt den Dialog.
Escape und Abbrechen schließen ohne Übernahme der gerade veränderten Auswahl. Danach soll die Person bei der auslösenden Filteraktion weiterarbeiten können. Diese Rückkehr ist wichtig, weil sie den vorübergehenden Dialog in die eigentliche Aufgabe einordnet. Ein Fokus am Dokumentanfang oder an einem inzwischen verborgenen Ergebnis würde nach dem Schließen unnötige Orientierung verlangen. Unsere Browserprüfung betrachtet die tatsächliche aktive Position.
Ein modal begrenzter Fokusweg ist nicht dasselbe wie eine unauflösbare Tastaturfalle. Der Dialog besitzt verständliche erreichbare Wege zum Schließen. Die Bedienung bleibt innerhalb der aktuellen Aufgabe zusammen und kann sie auf übliche Weise verlassen. Das WAI-Dialogmuster beschreibt diesen Zusammenhang. Ein vollständiger Einsatz muss zusätzlich mit den vorgesehenen Browser- und Hilfstechnikkombinationen geprüft werden.
Die Fokusdarstellung zusammen mit dem Layout entwickeln
Das folgende CSS liefert die Gestaltung für den gezeigten Entwurf. Der Dialog begrenzt seine Breite auf den verfügbaren Platz und erhält bei Bedarf eine eigene vertikale Bewegung. Die Aktionsgruppe darf umbrechen. Die Regel für :focus-visible bleibt auch dann erhalten, wenn sich die Anordnung verändert. Ein Fokusindikator ist Teil der Komponente und sollte nicht erst am Ende zufällig über das übrige Layout gelegt werden.
Die lichte und dunkle Variante verwenden dieselben Abstände und Interaktionen. Nur die passenden Farben ändern sich. Ein Test der dunklen Variante darf deshalb nicht auf die bloße Existenz einer Medienabfrage reduziert werden. Wir führen denselben Tastaturweg tatsächlich in beiden Darstellungen aus. Die eigene Prüfung untersucht schmale Ansichten und große Bildschirmbreite, ohne daraus eine automatische Aussage über sämtliche denkbaren Gerätekonfigurationen abzuleiten.
* { box-sizing: border-box; }
body { margin: 0; font: 1rem/1.6 system-ui, sans-serif; color: #202326; background: #f8f3ea; }
header, main { max-width: 58rem; margin: auto; padding: 1.5rem; }
nav { display: flex; flex-wrap: wrap; gap: 1.5rem; }
a { color: #a60710; text-decoration-thickness: .1em; text-underline-offset: .2em; }
button { font: inherit; border: 2px solid #202326; border-radius: .3rem; padding: .7rem 1rem;
color: white; background: #202326; cursor: pointer; }
:focus-visible { outline: 4px solid #ce0711; outline-offset: 4px; }
.skip { position: absolute; top: .5rem; left: .5rem; transform: translateY(-160%);
background: white; padding: .6rem 1rem; z-index: 2; }
.skip:focus { transform: none; }
article { padding: 1rem; margin: 1rem 0; border: 1px solid #777; border-radius: .4rem; }
dialog { width: min(32rem, calc(100% - 2rem)); max-height: calc(100% - 2rem);
overflow: auto; border: 2px solid #202326; border-radius: .5rem; padding: 2rem;
background: #f8f3ea; color: #202326; }
dialog::backdrop { background: rgb(0 0 0 / .6); }
fieldset { padding: 1rem; }
label { display: block; padding: .5rem; }
.actions { display: flex; gap: 1rem; flex-wrap: wrap; margin-top: 1.5rem; }
@media (prefers-color-scheme: dark) {
body, dialog { color: #f8f3ea; background: #202326; }
a { color: #ffb3ad; } button { color: #202326; background: #f8f3ea; border-color: #f8f3ea; }
:focus-visible { outline-color: #ff8a80; } .skip { color: #202326; }
}Abbruch und Übernahme als getrennte Zustände behandeln
Der JavaScript-Baustein hält die tatsächlich übernommene Auswahl getrennt von der gerade im Dialog bearbeiteten Auswahl. Beim Öffnen wird der bisher gültige Wert wieder eingesetzt. Dadurch kann ein Abbruch keinen ungespeicherten Zwischenstand zum nächsten Standard machen. Beim Schließen wird nur der eindeutige Rückgabewert apply als Übernahme behandelt. Die vorhandenen Ergebniselemente bleiben dieselben und werden passend sichtbar oder verborgen.
Ein wichtiger Randfall betrifft wiederholtes Öffnen. Nach einer früheren Übernahme darf Escape beim nächsten Mal nicht versehentlich erneut einen alten Rückgabewert als neue Bestätigung auswerten. Deshalb wird returnValue vor jedem Öffnen geleert. Die Testfolge übernimmt zuerst eine Auswahl und bricht danach eine andere ab. Dieser Fall ist aussagekräftiger als ein einzelner erfolgreicher erster Dialogaufruf.
Die Ergebnisanzahl wird nach einer tatsächlichen Übernahme aktualisiert. Das Statusfeld ist als Statusbereich ausgezeichnet. Ob und wie eine Hilfstechnik diese Änderung im konkreten Zusammenhang ankündigt, wird zusätzlich in ihrer realen Umgebung geprüft. Die bloße Rollenangabe ersetzt keinen solchen Test. Unser automatisierter Nachweis bestätigt hier den tatsächlichen Text und die sichtbar verbleibenden Angebote.
const opener = document.querySelector('#open-filter');
const dialog = document.querySelector('#filter-dialog');
const form = dialog.querySelector('form');
let committedKind = 'all';
opener.hidden = typeof dialog.showModal !== 'function';
opener.addEventListener('click', () => {
for (const radio of form.elements.kind) radio.checked = radio.value === committedKind;
dialog.returnValue = '';
dialog.showModal();
});
dialog.addEventListener('close', () => {
if (dialog.returnValue !== 'apply') return;
committedKind = new FormData(form).get('kind');
let visible = 0;
for (const card of document.querySelectorAll('#services article')) {
card.hidden = committedKind !== 'all' && card.dataset.kind !== committedKind;
if (!card.hidden) visible++;
}
document.querySelector('#result-status').textContent =
visible === 1 ? '1 Leistung' : visible + ' Leistungen';
});
dialog.addEventListener('keydown', event => {
if (event.key !== 'Tab') return;
const first = form.querySelector('input[name="kind"]:checked');
const last = form.querySelector('#cancel-filter');
if (!first || !last) return;
if (event.shiftKey && (document.activeElement === first
|| document.activeElement.id === 'filter-title')) {
event.preventDefault();
last.focus();
} else if (!event.shiftKey && document.activeElement === last) {
event.preventDefault();
first.focus();
}
});
Den kleinen Fokuszyklus nachvollziehbar ergänzen
Die gezeigte Komponente ergänzt an den Rändern des modalen Dialogs einen lokalen Tabulatorzyklus. Er verwendet die aktuell gewählte Radiooption und die letzte Abbruchaktion. Rückwärts vom ersten Ziel oder von der Anfangsüberschrift führt er zum letzten Ziel. Vorwärts von dort geht er zurück zur Radioauswahl. Das ist eine eng auf diese feste kleine Komponente begrenzte Ergänzung und kein globaler Tastaturhandler für die ganze Webseite.
Der tatsächliche Browserlauf zeigte ohne diese Ergänzung einen zusätzlichen Weg über den Browserrahmen. Für den hier gewählten klar begrenzten Dialog wurde der lokale Zyklus bewusst ergänzt und anschließend geprüft. Escape bleibt nativ nutzbar. Die übrige normale Bewegung zwischen den eigenen Bedienelementen wird nicht neu erfunden. Diese Entscheidung wird dokumentiert, statt ein gewünschtes Verhalten allein aus einer Rollenangabe abzuleiten.
Wenn die Komponente später weitere Eingaben oder dynamisch verborgene Aktionen erhält, muss der Zyklus erneut betrachtet werden. Eine festgelegte erste und letzte Aktion ist nur solange passend, wie die Struktur dazu stimmt. Für größere allgemeine Dialogsysteme kann eine gepflegte etablierte Implementierung sinnvoll sein. Unser Beispiel behauptet nicht, mit wenigen Zeilen jedes beliebige interaktive Fenster zuverlässig zu verwalten.
Die 76 ausgeführten Prüfungen richtig einordnen
Der Entwurf wurde in Desktop-Edge mit 76 Prüfungen ausgeführt. Dazu gehören Sprunglink, Hauptfokus, Öffnen mit Enter und Leertaste, Radioauswahl mit Pfeiltasten, Übernahme, Escape, Abbruchaktion und Rückkehr zum Auslöser. Die kritische Folge Übernehmen, erneut öffnen und Abbrechen wurde gesondert geprüft. Ein abgebrochener Wechsel zu Software verändert den bereits übernommenen Webseitenfilter nicht.
Dieselben Abläufe wurden in heller und dunkler Darstellung untersucht. Die Seitenbreite bleibt bei 320, 390 und 1440 Pixeln kontrolliert. Der fokussierte Dialogtitel liegt sichtbar im Fenster. Ohne JavaScript bleiben beide Leistungsangebote vorhanden und die Filteraktion verborgen. Diese Fälle bilden einen konkreten Interaktionsnachweis. Sie sind keine vollständige Prüfung aller Hilfstechniken und keine rechtliche Freigabe einer gesamten Webseite.
Die Abbildung zeigt zwei tatsächlich erzeugte Browseransichten desselben Codes. Links ist die Filteraktion per Tastatur erreicht, rechts wurde der Dialog per Enter geöffnet. Der rote Rahmen gehört zur echten CSS-Fokusdarstellung und wurde nicht nachträglich als Beweis eingezeichnet. Die Bildaufgabe besteht darin, Position und Übergang anschaulich zu machen. Der vollständige Tastaturweg wird durch die ausgeführten Interaktionen belegt.
Weitere typische Problemstellen gezielt suchen
Ein- und ausgeblendete Menüs verdienen dieselbe Aufmerksamkeit wie unser Dialog. Kann eine Person den Auslöser erreichen, den geöffneten Bereich bedienen und danach verständlich weitergehen? Werden verborgene Links versehentlich noch fokussierbar gehalten? Ein visuell geschlossenes Menü ist kein sauberer Zustand, wenn Tab weiterhin in seine unsichtbaren Elemente führt. Diese Fälle gehören in die Prüfung der konkreten Navigation.
Auch automatisch veränderte Ergebnislisten können Fokus verlieren lassen. Wird ein gesamter Bereich ersetzt, verschwindet möglicherweise das gerade aktive Element. Unser kleiner Filter behält die vorhandenen Elemente bei und schließt mit Fokus am unveränderten Auslöser. Ein umfangreicheres Suchsystem braucht dafür eine ausdrückliche Strategie. Die gewünschte neue Position wird aus der Aufgabe abgeleitet und nicht nach jeder Aktualisierung beliebig an den Seitenanfang gesetzt.
Bei Formularfehlern muss die Person das Problem und den Korrekturweg finden. Eine optisch auffällige Meldung weit entfernt vom Feld kann für eine reine Tastaturnutzung unpraktisch sein. Auch hier sind Beschriftung, Beschreibung und sinnvoller Fokus zusammen zu planen. Ein Tastaturtest bleibt deshalb nicht auf Navigationslinks beschränkt, sondern begleitet die tatsächlichen Eingabe-, Korrektur- und Abschlusswege.
Eine redaktionell verständliche Abnahme dokumentieren
Notieren Sie Aufgaben als lesbare Schritte mit erwarteten Ergebnissen. „Filter mit Enter öffnen, Webseiten wählen, mit Anwenden übernehmen und zum passenden Angebot weitergehen“ ist für Fachpersonen verständlicher als eine Sammlung interner Selektoren. Die technische Prüfung darf diese Selektoren zusätzlich nutzen. Beide Ebenen beschreiben denselben Vorgang und machen spätere Abweichungen nachvollziehbar.
Eine zweite Person führt die Schritte ohne Maus aus und beschreibt, wo sie Orientierung verliert. Ergänzend werden die tatsächlich eingesetzten Hilfstechniken geprüft. Der Befund nennt den betroffenen Zustand, die Auswirkung und den vorgesehenen Rückweg. Ein pauschales Etikett wie barrierefrei oder unbrauchbar hilft bei einer konkreten Korrektur weniger als die genaue Stelle, an der eine Aufgabe scheitert.
Nach einer Änderung wird der betroffene Weg erneut geprüft. Ein neues Feld im Dialog, eine klebende Leiste oder eine andere mobile Navigation kann bereits bestehende Annahmen verändern. Der Fokusweg gehört deshalb zur Wartung einer interaktiven Komponente. Die fertige Aufgabe bleibt der Maßstab: erreichen, verstehen, bedienen und ohne ungewollten Verlust der Position sinnvoll weiterarbeiten.
Den Aufwand an der Wirkung ausrichten
Für eine kleine Leistungsübersicht ist ein einfacher nativer Aufbau häufig ausreichend. Unser Beispiel benötigt keine eigene universelle Tastaturbibliothek und keine positive Nummerierung aller Links. Der größte Nutzen entsteht durch eindeutige Elemente, sichtbaren Fokus und sauber behandelte Zustandswechsel. Diese Grundlagen werden vor aufwendigeren gestalterischen Erweiterungen geprüft, weil sie direkt darüber entscheiden, ob eine Person den Vorgang erledigen kann.
Die verwendeten Standardsquellen helfen bei der Einordnung einzelner Anforderungen. Sie ersetzen nicht die konkrete Beobachtung des eigenen Produkts. Umgekehrt ersetzt eine einzelne erfolgreiche Browserprobe nicht jede Anforderung eines umfassenden Prüfverfahrens. Eine ehrliche Abnahme verbindet klare Kriterien mit realen Interaktionen und benennt den geprüften Umfang. So bleibt das Ergebnis für Redaktion, Gestaltung und Entwicklung tatsächlich nutzbar.
Tastaturbedienung ist damit ein Bestandteil guter Produktarbeit. Sie macht die Reihenfolge und den Zustand eines Ablaufs sichtbar und deckt oft unklare Bedienentscheidungen auf. Der gezeigte Entwurf demonstriert einen vollständigen kleinen Weg mit Bestätigung und Abbruch. Ein größerer Bestand wird mit derselben Sorgfalt auf seine eigenen Aufgaben geprüft, statt die erfolgreiche Einzelkomponente ungeprüft als Freigabe für alles andere zu verwenden.
Tastaturweg im Überblick
| Schritt | Erwartetes Ergebnis |
|---|---|
| Tab am Einstieg | Sprunglink wird sichtbar |
| Enter am Sprunglink | Hauptinhalt erhält Fokus |
| Tab, dann Enter | Filteraktion erreicht und Dialog geöffnet |
| Tab und Pfeiltasten | Radioauswahl erreichen und ändern |
| Anwenden | Auswahl übernehmen und zum Auslöser zurückkehren |
| Escape oder Abbrechen | Ohne neue Übernahme zum Auslöser zurückkehren |
Checkliste für den eigenen Bestand
- Echte Aufgaben einschließlich Abbruch und Korrektur beschreiben.
- Natürliche Reihenfolge und passende native Elemente prüfen.
- Fokus deutlich sichtbar und frei von Überlagerungen halten.
- Sprungziele und Rückkehrposition tatsächlich testen.
- Dialoge mit Enter, Leertaste, Pfeilen, Tab und Escape bedienen.
- Wiederholtes Öffnen nach Übernahme und Abbruch prüfen.
- Hell/Dunkel, kleine Ansichten und fehlendes JavaScript berücksichtigen.
- Weitere Browser und tatsächlich eingesetzte Hilfstechniken gesondert abnehmen.
Quellen und Prüfstand
Primärquellen am 09.11.2026 geprüft. Die Leistungsübersicht ist ein eigener fiktiver Entwurf. 76 tatsächlich ausgeführte Edge-Prüfungen betreffen den gezeigten Code. Eine vollständige Hilfstechnikprüfung oder rechtliche Freigabe des gesamten Bestands wird damit nicht behauptet.
