Was macht das focusgroup-Attribut genau?

Es gibt einem Container deklarativ das Tastaturverhalten eines zusammengesetzten Widgets. Der Browser uebernimmt die Pfeiltastennavigation zwischen den Kindelementen, sorgt fuer einen einzigen Tab-Stopp fuer die ganze Gruppe und merkt sich das zuletzt fokussierte Element. Genau das, was man sonst als roving tabindex per JavaScript baut.

Welche Werte sind bei focusgroup erlaubt?

Ein Verhaltenstoken ist Pflicht, moeglich sind toolbar, tablist, radiogroup, listbox, menu, menubar und none. Dazu kommen optional die Modifikatoren inline oder block fuer die Achse, wrap oder nowrap fuer den Umbruch am Ende sowie nomemory. Der frueher diskutierte Wert grid fuer zweidimensionale Navigation ist im Open-UI-Explainer als future markiert und in Chrome 150 nicht verfuegbar.

Funktioniert focusgroup in Firefox und Safari?

Nein. Ausgeliefert wird es aktuell in Chrome 150 und Edge 150. Mozilla hat eine positive Standards-Position vergeben, das ist aber keine Implementierungszusage. WebKit hat in seinem Positions-Repository bisher gar keine Position gesetzt. Wer das Attribut heute nutzt, braucht einen Fallback.

Ersetzt focusgroup die ARIA-Arbeit an einem Widget?

Nur den Navigationsteil. Chrome schreibt zum radiogroup-Beispiel ausdruecklich, dass der Auswahlzustand weiterhin Sache des Entwicklers ist. aria-checked, aria-selected, aria-expanded, Toggle-Logik und das Oeffnen von Menues bleiben Handarbeit.

Das focusgroup-Attribut ersetzt den handgeschriebenen roving tabindex

Eine Formatierungs-Toolbar mit zwoelf Buttons ueber einem Editor. Wer mit der Tastatur arbeitet, drueckt zwoelfmal Tab, bevor er im Textfeld ankommt. Das ist der Grund, warum die ARIA Authoring Practices fuer zusammengesetzte Widgets ein anderes Muster vorsehen. Die ganze Gruppe bekommt genau einen Tab-Stopp, navigiert wird darin mit den Pfeiltasten. Umgesetzt wurde das bisher als roving tabindex, per JavaScript, in jedem Projekt neu.

Seit Chrome 150 geht das auch deklarativ.

Was roving tabindex an Handarbeit verlangt

Die APG beschreibt das Muster in drei Schritten. Beim Aufbau bekommt genau ein Element tabindex="0", alle anderen tabindex="-1". Bei jedem Pfeiltastendruck wird der tabindex umgesetzt und auf dem Ziel focus() aufgerufen. Und beim Verlassen der Gruppe muss sichergestellt sein, dass das Element, das beim naechsten Tab wieder dran ist, den Wert 0 traegt. Als Alternative nennt die APG aria-activedescendant, was die Sache nicht einfacher macht.

Dazu kommt der Kleinkram, der in keiner Kurzbeschreibung steht. Deaktivierte Elemente ueberspringen. Bei Rechts-nach-links-Schreibrichtung die Achse spiegeln. Entscheiden, ob am Ende der Liste umgebrochen wird. Den Zustand aktuell halten, wenn Elemente per JavaScript dazukommen oder verschwinden.

Arbeitsplatz mit aufgeklapptem Laptop auf einem hellen Schreibtisch Foto: glenncarstenspeters / Unsplash

Chrome nennt in seinem WHATWG-Issue genau das als Motivation fuer die Standardisierung. Entwickler schreiben diese Logik routinemaessig von Hand, das Ergebnis ist inkonsistentes Tastaturverhalten und ein erhoehtes Accessibility-Risiko. Die APG zaehlt als Composite Widgets mit Einzel-Tab-Stopp unter anderem combobox, grid, listbox, menu, menubar, radio group, tabs, toolbar, treegrid und tree view auf. Das ist viel Oberflaeche fuer handgeschriebene Fokuslogik.

Wo es laeuft

Chrome 150 ist am 30.06.2026 stabil erschienen und bringt focusgroup mit. Microsoft Edge 150 folgte am 02.07.2026, die Edge-Release-Notes zeigen als Beispiel eine Formatierungs-Toolbar. Vorher lief ein Chromium-Origin-Trial von Chrome 146 bis Chrome 149.

Das Grundmuster sieht so aus:

<div focusgroup="toolbar wrap" aria-label="Formatierung">
  <button>Fett</button>
  <button>Kursiv</button>
  <button>Unterstrichen</button>
</div>

Kein Skript. Ein Tab-Stopp fuer die Gruppe, Pfeil links und rechts wandern zwischen den Buttons, am Ende geht es wieder von vorne los und beim erneuten Betreten der Gruppe landet der Fokus dort, wo er zuletzt war.

Die Syntax hat ein Pflichttoken

Hier ist ein Punkt wichtig, an dem sich viele frueh kursierende Beschreibungen vertan haben. focusgroup nimmt nicht einfach eine Liste aus Richtungs- und Verhaltensflags. Der erste Wert ist ein Pflicht-Verhaltenstoken, danach kommen optionale Modifikatoren.

focusgroup="<behavior> [inline|block] [wrap|nowrap] [nomemory]"

behavior (Pflicht): toolbar | tablist | radiogroup | listbox | menu | menubar | none
inline   : nur Pfeil links/rechts (respektiert die Schreibrichtung)
block    : nur Pfeil hoch/runter
wrap     : Pfeiltasten springen vom letzten zum ersten Element und zurueck
nowrap   : hebt ein wrap-Default wieder auf
nomemory : merkt sich das zuletzt fokussierte Element NICHT

Zwei Details, die im Alltag Fehler sparen. Das Memory-Token heisst nomemory, in einem Wort, ohne Bindestrich. Und grid fuer zweidimensionale Navigation gibt es nicht. Der Open-UI-Explainer markiert den Wert ausdruecklich als future und hat ihn aus dem aktuellen Vorschlag herausgenommen. Wer eine echte Tabellennavigation braucht, schreibt sie weiter selbst.

Jedes Verhaltenstoken bringt eigene Defaults mit, die man nur ueberschreiben muss, wenn man etwas anderes will:

toolbar     -> Mindestrolle toolbar,     Default: inline
tablist     -> Mindestrolle tablist,     Default: inline wrap,  Kindrolle tab
radiogroup  -> Mindestrolle radiogroup,  Default: wrap,         Kindrolle radio
listbox     -> Mindestrolle listbox,     Default: block,        Kindrolle option
menu        -> Mindestrolle menu,        Default: block wrap,   Kindrolle menuitem
menubar     -> Mindestrolle menubar,     Default: inline wrap,  Kindrolle menuitem
none        -> Opt-out fuer Element und Teilbaum

Dazu kommt ein zweites Attribut. focusgroupstart legt fest, welches Element beim ersten Betreten der Gruppe den Fokus bekommt.

<div focusgroup="listbox" aria-label="Vorschlaege">
  <div tabindex="-1">Erster Eintrag</div>
  <div tabindex="-1" focusgroupstart>Empfohlener Eintrag</div>
  <div tabindex="-1">Dritter Eintrag</div>
</div>

Das Memory hat dabei Vorrang. Wurde die Gruppe schon einmal verlassen, gewinnt das zuletzt fokussierte Element gegen focusgroupstart. Wer wirklich jedes Mal am definierten Startpunkt landen will, kombiniert es mit nomemory.

Die Rollen kommen mit, und das ist der eigentliche Eingriff

focusgroup ist kein reines Verhaltensattribut. Es vergibt eine ARIA-Rolle, wenn ein generischer Container wie ein div noch keine hat. Native Elemente behalten ihre Semantik. Kindrollen werden abgeleitet, ein button in focusgroup="tablist" wird zu role=tab, in menu oder menubar zu menuitem, in listbox zu option, in radiogroup zu radio. Nur toolbar vergibt keine Kindrolle, was es zum unaufgeregtesten der sieben Muster macht.

Das ist bewusst so gebaut. Eine frueher vorgeschlagene, ungescopte Fassung von focusgroup war an Accessibility-Problemen gescheitert. Die jetzige Scoped-Variante begrenzt die Nutzung deshalb auf Muster, die eine Mindestrolle mitliefern. Man bekommt die Pfeiltasten also nicht ohne die semantischen Folgen.

Nahaufnahme einer Computertastatur Foto: majortomagency / Unsplash

Verschachtelung ist geregelt. Eine innere focusgroup meldet sich automatisch von der aeusseren ab, und focusgroup="none" nimmt ein Element samt Teilbaum aus der Pfeiltastennavigation der Vorfahren heraus.

Was das Attribut nicht uebernimmt

Nur die Navigation. Chrome schreibt zum radiogroup-Beispiel unmissverstaendlich, dass der Auswahl-Code beim Entwickler bleibt. aria-checked, aria-selected, Toggle-Zustaende, das Oeffnen von Menues, all das schreibt man weiter selbst.

// focusgroup navigiert, den Zustand pflegt man selbst
group.addEventListener('focusin', (event) => {
  const item = event.target;
  for (const other of group.children) {
    other.setAttribute('aria-checked', String(other === item));
  }
});

Wer also gehofft hat, ein Attribut ersetze das halbe Widget, wird enttaeuscht. Es ersetzt den Teil, den ohnehin alle gleich bauen sollten.

Der Stand bei assistiver Technik

Hier wird es duenn, und das gehoert dazugesagt. Eine systematische, veroeffentlichte Screenreader-Testreihe zu focusgroup gibt es zum jetzigen Zeitpunkt nicht.

Was es gibt, sind Adrian Rosellis Focusgroup Tests vom 05.07.2026, aktualisiert am 14.07.2026. Er hat sechs skriptfreie Demos zu listbox, menu, menubar, radiogroup, tablist und toolbar gebaut und in Chrome 150 untersucht, im Kern am Accessibility-Tree und an den Accessibility-APIs. Drei Befunde daraus sind fuer die Praxis relevant.

Erstens greift role="presentation" beziehungsweise role="none" auf einem Knoten mit focusgroup nicht. Die abgeleitete Rolle bleibt im Accessibility-Tree sichtbar. Man kann die Interaktion also nicht uebernehmen und die Rollen-Folgepflichten gleichzeitig abstreifen.

Zweitens aendert focusgroup="menubar" in seiner Demo allein gar keine Rollen. Eine Liste behaelt ihre native Semantik, das Attribut ueberschreibt sie nicht. Erst wenn zusaetzlich role="menubar" gesetzt ist, verlieren die li-Kindelemente ihre Rolle und button-Kinder werden zu menuitem hochgestuft. Die Ableitung greift also dort, wo vorher keine eigene Semantik stand, und wer die Rollen wirklich braucht, setzt sie weiterhin selbst und nimmt die Umetikettierung des Markups in Kauf.

Drittens nahm ein Button mit focusgroup="none" in seinem Test zusammen mit den Nachbarn weiterhin Tab-Fokus an, behielt dabei aber die Rolle des Elements statt der geforderten Kindrolle.

Arbeitsplatz mit Monitor und Tastatur Foto: ryanancill / Unsplash

Roselli sagt selbst dazu, dass er kein vollstaendiges Screenreader-Testing gemacht hat und kein taeglicher Screenreader-Nutzer ist. James Scholes hat ihn zum Verhalten des virtuellen Cursors in NVDA und JAWS im Forms Mode korrigiert. Steve Frenzel hat am 20.04.2026 eine Einordnung des Vorschlags veroeffentlicht, hinterfragt darin die Notwendigkeit eines eigenen radiogroup-Musters neben fieldset und merkt fehlende Rueckmeldung fuer JAWS- und NVDA-Nutzer bei der Chatbot-Demo an, gestuetzt auf die vorhandenen Demos.

Ich habe focusgroup selbst nicht getestet und behaupte deshalb nichts ueber NVDA- oder JAWS-Ansagen. Der Stand ist, dass die Rollen-Ableitung dokumentierte Kanten hat und die Ansage-Seite offen ist.

Standardisierung und Browserlage

focusgroup ist noch nicht Teil des HTML Living Standard. Der Spezifikations-PR whatwg/html#11723 wurde am 29.09.2025 eroeffnet und war zum Recherchezeitpunkt weiterhin offen, angefragt sind unter anderem Reviewer von Mozilla. Die ARIA-Abbildung laeuft separat im PR w3c/aria#2778, seit 22.05.2026 review-ready, gelabelt mit waiting for implementations. Er haelt fest, dass das Attribut selbst kein direktes Accessibility-API-Mapping hat und der User Agent die Rollen nur ableitet.

Mozilla hat eine positive Standards-Position vergeben, WebKit hat bis heute keine gesetzt und fuehrt den Eintrag unter dem Label concerns: device independence. Eine MDN-Referenzseite fuer das Attribut gibt es noch nicht, der Aufruf liefert am 27.07.2026 eine 404. Der caniuse-Eintrag fehlt ebenfalls, das Feature-Request-Issue liegt seit dem 20.02.2022 offen. Polyfill-Ansaetze existieren als npm-Pakete, unter anderem eines von Microsoft, das Chrome im Intent to Ship als Fallback nennt. Geprueft habe ich sie nicht.

Wer wissen will, wie sich so eine Lage anfuehlt, findet die Parallele bei der View Transitions API. Ein nuetzliches Feature, ausgeliefert in einer Engine, mit Fallback im Produktivcode.

Einsatz heute

Feature-Detection ist zweizeilig:

if ('focusgroup' in HTMLElement.prototype) {
  // Browser uebernimmt Pfeiltasten, Tab-Stopp und Memory
} else {
  // eigenen roving tabindex aktivieren
}

Fuer ein Produktivprojekt wuerde ich so vorgehen. Erst toolbar, weil das einzige Muster ohne Kindrollen-Ableitung das kleinste Risiko traegt, und den bestehenden roving tabindex als Fallback stehen lassen, statt ihn zu loeschen. Bei menubar und listbox lohnt vorher ein Blick in den Accessibility-Tree der DevTools, um zu sehen, welche Rollen am Ende tatsaechlich ankommen. Und keine Struktur umbauen, nur damit focusgroup daran passt.

Was sich durch das Attribut nicht aendert, sind die Pflichten. WCAG 2.1 verlangt in 2.1.1 Keyboard auf Level A, dass alle Funktionen ueber eine Tastaturschnittstelle bedienbar sind, in 2.4.3 Focus Order eine Fokusreihenfolge, die Bedeutung und Bedienbarkeit erhaelt, und in 4.1.2 Name, Role, Value die korrekte Rollenvergabe. Ueber EN 301 549 haengt daran auch die Tastaturbedienbarkeit im Rahmen des BFSG. Ein Attribut, das die Rollen selbst vergibt, nimmt einem die Pruefung nicht ab, es verschiebt sie nur. Aehnlich wie bei WebGL und Barrierefreiheit zaehlt am Ende, was bei der Nutzerin ankommt.

Detailaufnahme einzelner Tasten einer Tastatur Foto: bayusyaits / Unsplash

Kurz gefasst, focusgroup loest ein echtes Problem und spart Code, den niemand gerne schreibt. Die Rollen-Ableitung ist der Teil, den man verstehen muss, bevor man es breit einsetzt.

Wenn du ein Widget hast, das mit der Tastatur hakt, eine Toolbar, ein Tab-Set oder ein Menue, schau ich mir das gerne an und sage dir, ob focusgroup dort heute schon Sinn ergibt oder ob der roving tabindex bei dir die ruhigere Loesung bleibt. Melde dich einfach bei mir.