Tabs / Persona Switcher: Format, Regeln und Beispiele

Ein Tabs-/Persona-Switcher bietet mehreren Lesern unterschiedliche Pfade durch ein eingegrenztes Thema, ohne sie auf separate Seiten zu schicken. Die Bezeichnungen identifizieren den Pfad; durch Auswahl eines Tabs wird dessen Panel an derselben Stelle angezeigt. Das Element ist nur dann sinnvoll, wenn die Panels echte gleichrangige Elemente sind und jedes Panel im initialen HTML der Seite vorhanden bleibt.

Der gerenderte Zustand zeigt ein aktives Panel, aber die anderen beiden Panels sind ebenfalls im Document Object Model (DOM) vorhanden – der strukturierten Darstellung der Seite im Browser. Sie sind mit dem nativen Attribut hidden ausgeblendet und werden nicht erst nach einem Klick angefordert. Ein Produktions-Renderer fügt das unten beschriebene Tastatur- und Zeigerverhalten hinzu; der vom Autor erstellte Inhaltsvertrag bleibt plattformübergreifend derselbe.

Warum dieses Element wichtig ist

Leser filtern eine Seite nach ihrer Rolle, ihrem Ziel und ihrem Verantwortungsgrad. Ein Content-Spezialist möchte möglicherweise Anweisungen zum Verfassen, ein SEO-Spezialist Validierungsregeln und ein Teamleiter Leitlinien. Ein gut beschrifteter Persona-Switcher reduziert den Aufwand, allgemeine Ratschläge in „Was bedeutet das für mich?" zu übersetzen. Er hält außerdem die gemeinsame Prämisse an einem Ort, wodurch drei nahezu identische Seiten vermieden werden, die um dieselbe Suchintention konkurrieren.

Der psychologische Vorteil liegt in der Wiedererkennung statt Interpretation. Ein Leser kann eine Bezeichnung wie „SEO-Teams" schneller erkennen, als drei Absätze zu scannen, um abzuleiten, welcher für ihn zutrifft. Tabs bewahren zudem den räumlichen Kontext: Das Panel wechselt an Ort und Stelle, sodass der Leser gleichrangige Pfade vergleichen kann, ohne wiederholt an der gemeinsamen Einleitung vorbeiscrollen zu müssen.

Dieser Komfort schafft jedoch einen Kompromiss bei der Maschinenextrahierbarkeit. Maschinenextrahierbarkeit ist die Fähigkeit eines Crawlers, Suchindexes, einer Assistenztechnologie oder eines Abrufsystems, Inhalte zu isolieren und dabei deren Thema und Beziehungen zu bewahren. Sichtbare Überschriften und Absätze erscheinen in einer offensichtlichen Lesereihenfolge. Tab-Panels führen einen Interaktionszustand ein: Eines ist sichtbar, mehrere nicht, und die Software muss jede Tab-Beschriftung dem richtigen Panel zuordnen. Eine schwache Implementierung hinterlässt nur das aktive Panel im HTML, lädt andere Panels erst nach einem Klick oder wiederholt generische Überschriften wie „Vorteile" ohne den Persona-Namen. In jedem Fall erhält eine Maschine weniger Kontext als der Leser sieht.

Selbst eine korrekte Implementierung kann die Extrahierbarkeit im Vergleich zu gewöhnlichen Abschnitten verringern. Manche Systeme priorisieren anfänglich sichtbaren Text, vereinfachen interaktive Beziehungen oder lassen ausgeblendete Inhalte aus Auszügen weg. Tabs sind daher ein Werkzeug zur Informationslenkung, nicht eine Methode, um wesentliche Antworten zu verbergen. Platzieren Sie die gemeinsame Antwort, Definition, Warnung, Berechtigungsbedingung und Schlussfolgerung außerhalb des Tab-Sets. Verwenden Sie Panels für zielgruppenspezifische Anwendungen, Beispiele, Arbeitsabläufe oder Nachweise, die auch nach Kenntnis der gemeinsamen Antwort nützlich bleiben.

Wenden Sie die Element-Schreibregeln an: Formulieren Sie die vollständige Erklärung zuerst, klassifizieren Sie dann eine echte Menge gleichrangiger Leserpfade als dieses typisierte Element. Die Regeln auf dieser Seite haben für Panel-Zuordnung, Interaktion und Inhaltsbegrenzungen Vorrang.

Wann es verwendet wird

Verwenden Sie einen Tabs-/Persona-Switcher, wenn alle folgenden Bedingungen zutreffen:

1. Zwei bis fünf unterscheidbare Zielgruppen, Kontexte oder Modi benötigen unterschiedliche Anwendungen desselben Themas.
2. Jedes Panel beantwortet dieselbe Frage in vergleichbarer Tiefe.
3. Die meisten Leser benötigen jeweils ein Panel, während eine Minderheit zwei oder mehr vergleichen möchte.
4. Die gemeinsame Antwort kann außerhalb des Elements formuliert werden, ohne dass der Leser jeden Tab öffnen muss.
5. Die Pfade auf einer Seite zu belassen, ist klarer, als separate Seiten mit weitgehend duplizierten Einleitungen zu pflegen.

Starke Anwendungsfälle sind Implementierungsanleitungen für „Entwickler / Redakteure / Prüfer", Onboarding-Pfade für „Einzelperson / Team / Agentur" und eine Funktion, die über „Planen / Produzieren / Messen" erklärt wird. Persona-Bezeichnungen sollten sinnvolle Unterschiede im Workflow, in den Nachweisen, Berechtigungen oder angestrebten Ergebnissen widerspiegeln – keine demografischen Vermutungen.

Grenzfälle entstehen oft durch den Versuch, eine Seite zu kürzen. Stecken Sie keine sequenziellen Schritte in Tabs; das Verstecken von Schritt zwei, bis der Leser ihn auswählt, zerstört die Reihenfolge des Verfahrens. Verwenden Sie keine Tabs für eine kurze Liste von Definitionen, da gewöhnliche Überschriften dieselben Informationen mit weniger Interaktion bereitstellen. Verwenden Sie keine Tabs für einen detaillierten Funktionsvergleich: Eine Vergleichstabelle hält die Kriterien gleichzeitig sichtbar. Verwenden Sie Tabs nicht als Navigation zwischen nicht verwandten Themen und teilen Sie Informationen nicht nur deshalb auf, weil die Seite lang wirkt.

Ein Akkordeon ist besser geeignet, wenn die Abschnitte unabhängige Fragen in einem vertikalen Lesefluss sind oder wenn mehrere Antworten geöffnet bleiben sollen. Separate Seiten sind besser, wenn jede Zielgruppe eine eigene Suchintention, Überschrift, eigenen Nachweissatz, Conversion-Pfad oder mehr als etwa 300 Wörter einzigartigen Inhalts benötigt. Wenn ein Leser alle Panels benötigt, um sicher oder korrekt zu handeln, sind Tabs die falsche Komponente.

Wo es platziert wird

Platzieren Sie den Switcher nach der gemeinsamen Antwort und dem Absatz, der erklärt, warum sich die Pfade unterscheiden. Der Leser sollte das gemeinsame Thema verstehen, bevor er eine Bezeichnung auswählt. Auf einer Produkt- oder Lösungsseite bedeutet dies in der Regel nach dem zentralen Wertversprechen und der gemeinsamen Funktionserklärung, aber vor detaillierten Nachweisen und der primären abschließenden Aktion. In der Dokumentation platzieren Sie es unmittelbar vor den rollenspezifischen Anweisungen, die es steuert.

Platzieren Sie ein Tab-Set nicht vor der direkten Antwort, Definition oder zwingenden Warnung der Seite. Platzieren Sie es nicht zwischen einer Behauptung und ihrer Quelle, zwischen einer Voraussetzung und dem Verfahren, das sie regelt, oder zwischen einem Preis und seinen Qualifikationen. Diese Beziehungen müssen auch dann Bestand haben, wenn kein Panel ausgewählt ist. Ein Tab-Set darf nicht neben einem anderen Tab-Set, einem Akkordeon, einem großen Vergleichsraster oder einem Karussell stehen; benachbarte Interaktionsmodelle erzeugen konkurrierende Bedienelemente und eine unklare Lesereihenfolge.

Vermeiden Sie verschachtelte Tabs. Die äußere Auswahl verbirgt die innere Auswahl, erzeugt schwieriges Tastaturverhalten und macht Deep Linking mehrdeutig. Vermeiden Sie auch, einen Persona-Switcher unmittelbar über einem anderen Zielgruppenselektor in einem Formular oder CTA zu platzieren. Wenn beide Steuerelemente ähnliche Bezeichnungen verwenden, wissen Leser möglicherweise nicht, ob sie sichtbare Inhalte ändern oder eine Präferenz übermitteln.

Anatomie

Die Anatomie besteht aus einem beschrifteten Container, einer geordneten Tab-Liste und einem Panel für jeden Tab. Der Screenshot muss sowohl inaktive Panels im DOM-Inspektor als auch den sichtbaren Zustand zeigen, da die Präsenz im Quelltext Teil des Elements ist, kein Implementierungsdetail.

1. Gemeinsame Überschrift: Gibt die gemeinsame Frage oder Aufgabe an, die jedes Panel behandelt.
2. Tab-Liste: Fasst zwei bis fünf gleichrangige Bezeichnungen in einer stabilen, vom Autor festgelegten Reihenfolge zusammen.
3. Tab-Beschriftung: Benennt eine Zielgruppe, einen Kontext oder Modus in einer für Leser erkennbaren Sprache.
4. Ausgewählter Zustand: Kommuniziert den aktiven Tab durch Textsemantik und eine sichtbare Darstellung, nicht nur durch Farbe.
5. Panel: Enthält eine eigenständige Überschrift und den Inhalt für eine Beschriftung.
6. Programmatische Beziehung: aria-controls am Tab und aria-labelledby am Panel verbinden jedes Paar.
7. Fallback-Reihenfolge: Stellt sicher, dass die gemeinsame Überschrift, Beschriftungen und alle Panel-Inhalte sinnvoll bleiben, wenn Skripte oder Styling nicht ausgeführt werden.

Abstände, Rahmen, Indikatorform, Animation und Breakpoint gehören zum Renderer. Autoren kontrollieren Beschriftungen, Quellreihenfolge, Panel-Inhalte und eine optionale stabile Fragmentkennung.

Design-Beispiele

Die Komponente unterstützt vier Varianten. Jede Variante verwendet dasselbe Inhaltsmodell und dieselben DOM-Anforderungen.

Persona-Tabs: Verwenden Sie Rollenbezeichnungen, wenn sich Workflows, Nachweise oder nächste Aktionen je nach Leser tatsächlich unterscheiden. Bevorzugen Sie etablierte Kundensprache wie „Interne Teams" gegenüber erfundenen Personas wie „Wachstumsgurus".

Kontext-Tabs: Verwenden Sie Nicht-Persona-Zustände wie Teamgröße, Betriebsmodell oder Implementierungsmodus. Die gemeinsame Überschrift muss die sich ändernde Dimension benennen, damit die Beschriftungen nicht mit der Seitennavigation verwechselt werden.

Vertikale Tabs: Verwenden Sie diese nur, wenn die Beschriftungen mehr horizontalen Platz benötigen und es nicht mehr als fünf gibt. DOM- und Tastaturreihenfolge bleiben Tab eins bis fünf, gefolgt von ihren zugehörigen Panels gemäß der gewählten zugänglichen Implementierung.

Schmaler Viewport und Fallback-Zustand: Beschriftungen können horizontal scrollen, wenn ein sichtbarer Hinweis den Überlauf deutlich macht, oder der Renderer kann Panels als gestapelte beschriftete Abschnitte anzeigen. Es darf keine Beschriftungen zu mehrdeutigen Fragmenten abschneiden oder inaktive Inhalte aus dem HTML entfernen.

Parameter

Der Inhaltsvertrag hält die Beziehung explizit, während visuelles und responsives Verhalten dem Renderer überlassen bleiben.

Beschriftungen sind Attribute, weil sie das Steuerelement bedienen; Panel-Überschriften stammen aus der ersten Überschrift, weil sie zum Inhalt gehören. Beide können ähnlich sein, aber eine prägnante Tab-Beschriftung kann auf eine vollständigere, extrahierbare Panel-Überschrift verweisen. Panel-Bodies erlauben Absätze, eine kurze Liste, Inline-Code, ein Bild und eine kontextbezogene Aktion. Sie erlauben kein weiteres Tab-Set, Akkordeon, keine Datentabelle, kein Formular, keinen Videoplayer und kein mehrstufiges Verfahren.

Syntax und Code-Beispiele

Alle drei Notationen bewahren eine Überschrift, geordnete Beschriftungen, Panel-Überschriften, Panel-Bodies, stabile IDs und die anfängliche Standardauswahl. Die portable Markdown-Direktive ist die kanonische Autorenform.

Portable Markdown-Direktive

:::tabs-persona-switcher{default=content-teams variant=horizontal}
## Choose your team

::item{label="Content teams" id=content-teams}
### Turn the brief into a repeatable draft

Start with the required answer, evidence, and element set. Draft the reasoning in full before applying components.
::

::item{label="SEO teams" id=seo-teams}
### Verify discovery and extraction

Inspect the rendered HTML, internal links, headings, and structured fields. Confirm that every panel arrives in the initial response.
::

::item{label="Team leaders" id=team-leaders}
### Review the system, not just the page

Approve the shared promise once, then review where each audience genuinely needs a different workflow, proof point, or next action.
::
:::

Die erste Überschrift des übergeordneten Bodies wird auf title abgebildet. Jedes verschachtelte Item übernimmt label und id aus Attributen, bildet seine erste Überschrift auf item.title und den Rest auf item.content ab.

Hugo-Shortcode

{{< tabs-persona-switcher title="Choose your team" default="content-teams" variant="horizontal" >}}
  {{< tab-item label="Content teams" id="content-teams" title="Turn the brief into a repeatable draft" >}}
  Start with the required answer, evidence, and element set. Draft the reasoning in full before applying components.
  {{< /tab-item >}}
  {{< tab-item label="SEO teams" id="seo-teams" title="Verify discovery and extraction" >}}
  Inspect the rendered HTML, internal links, headings, and structured fields. Confirm that every panel arrives in the initial response.
  {{< /tab-item >}}
  {{< tab-item label="Team leaders" id="team-leaders" title="Review the system, not just the page" >}}
  Approve the shared promise once, then review where each audience genuinely needs a different workflow, proof point, or next action.
  {{< /tab-item >}}
{{< /tabs-persona-switcher >}}

Der Adapter verwendet nur benannte Parameter. Er muss alle Item-Bodies während der Server-Antwort rendern, doppelte IDs ablehnen und die Interaktion initialisieren, ohne das Inhaltsmodell zu überschreiben.

WordPress-Block

<!-- wp:amicited/tabs-persona-switcher {"title":"Choose your team","default":"content-teams","variant":"horizontal"} -->
  <!-- wp:amicited/tab-item {"label":"Content teams","id":"content-teams","title":"Turn the brief into a repeatable draft"} -->
  <p>Start with the required answer, evidence, and element set. Draft the reasoning in full before applying components.</p>
  <!-- /wp:amicited/tab-item -->
  <!-- wp:amicited/tab-item {"label":"SEO teams","id":"seo-teams","title":"Verify discovery and extraction"} -->
  <p>Inspect the rendered HTML, internal links, headings, and structured fields. Confirm that every panel arrives in the initial response.</p>
  <!-- /wp:amicited/tab-item -->
  <!-- wp:amicited/tab-item {"label":"Team leaders","id":"team-leaders","title":"Review the system, not just the page"} -->
  <p>Approve the shared promise once, then review where each audience genuinely needs a different workflow, proof point, or next action.</p>
  <!-- /wp:amicited/tab-item -->
<!-- /wp:amicited/tabs-persona-switcher -->

WordPress sollte innere Blöcke auf registrierte Tab-Items beschränken. Vorschau, gespeichertes Markup und Frontend-Rendering müssen jedes Panel beibehalten; der Editor-Komfort darf inaktive Items nicht clientseitig abgerufene Inhalte werden lassen.

Beispiele

Gutes Beispiel

Einen Implementierungspfad wählen

Gehostete Plattform – Start ohne Infrastruktur-Wartung

Verbinden Sie die genehmigte Datenquelle, konfigurieren Sie Rollen und validieren Sie die Ausgabe in einer Staging-Umgebung. Der Anbieter übernimmt Laufzeit-Updates und Überwachung; Ihr Team ist für die Inhaltsfreigabe und Zugriffsprüfung verantwortlich.

Self-Hosted – Kontrolle über Bereitstellung und Datengrenzen

Stellen Sie das unterstützte Paket in Ihrer Umgebung bereit, verbinden Sie dieselbe genehmigte Datenquelle und ernennen Sie einen Verantwortlichen für Upgrades, Überwachung, Backups und Zugriffsprüfung.

Dies funktioniert, weil beide Panels dieselbe Implementierungsfrage beantworten, den operativen Unterschied benennen und vergleichbare Verantwortlichkeiten enthalten. „Gehostete Plattform" und „Self-Hosted" sind erkennbare Bezeichnungen. Die gemeinsame Entscheidung bleibt klar, wenn beide Panels in die Quellreihenfolge eingefügt werden.

Schlechtes Beispiel

Alles erkunden

Überblick: Unsere Plattform macht moderne Teams effektiver.

Preise: Kontaktieren Sie den Vertrieb für ein persönliches Angebot und wichtige Vertragsbedingungen.

Sicherheit: Lesen Sie unsere Sicherheitsdokumentation.

Karriere: Werden Sie Teil unseres wachsenden Teams.

Dies ist eine Seitenavigation, die als Tabs getarnt ist. Die Panels beantworten keine gemeinsame Frage, die Beschriftungen vermischen Käuferinformationen mit Unternehmensinhalten, und wichtige Preisinformationen werden hinter einer Interaktion versteckt. Ersetzen Sie das Set durch gewöhnliche Seitenabschnitte und echte Navigation. Wenn Preisoptionen gleichzeitig bewertet werden müssen, verwenden Sie eine Preis- oder Vergleichsstruktur anstelle von Tabs.

Schema-Markup und Barrierefreiheit

Tabs und Persona-Switcher erzeugen keinen eigenen Schema.org-Typ. Ihr Inhalt bleibt Teil des umschließenden Article, TechArticle, Product oder WebPage, wenn diese Seite unabhängig qualifiziert. Markieren Sie Tabs nicht als ItemList, nur weil sie wiederholt werden, und erzeugen Sie keine mehreren Person-Entitäten aus Persona-Bezeichnungen. Eine Bezeichnung wie „Agentur" beschreibt einen Leserpfad, keine faktische Entitätsaussage.

Verwenden Sie das WAI-ARIA-Tabs-Muster nur, wenn die Schnittstelle sich tatsächlich wie Tabs verhält. Der Container hat role="tablist"; jedes Steuerelement hat role="tab", eine eindeutige ID, aria-controls und einen korrekten aria-selected-Wert; jedes Panel hat role="tabpanel" und aria-labelledby. Verwenden Sie Buttons für Steuerelemente, keine Links mit gefälschten Zielen. Der ausgewählte Tab gehört in die Tab-Reihenfolge der Seite; inaktive Tabs verwenden tabindex="-1" und bleiben mit den Pfeiltasten erreichbar. Home und End bewegen sich zum ersten bzw. letzten Tab. Die Aktivierung darf dem Fokus nur folgen, wenn der Panel-Wechsel sofort erfolgt; andernfalls aktiviert die Eingabetaste (Enter) oder die Leertaste (Space) den fokussierten Tab.

Der Fokus muss vorhersagbar bleiben. Das Auswählen eines Tabs verschiebt den Fokus nicht automatisch in sein Panel. Ein Panel kann tabindex="0" verwenden, wenn sein erster Inhalt nicht anderweitig fokussierbar ist, sodass Tastaturbenutzer in das Panel wechseln können. Ein sichtbarer Fokusindikator und ein Auswahlindikator müssen sich unterscheiden, und keiner darf ausschließlich auf Farbe beruhen.

Alle Panels müssen in der initialen HTML-Antwort gerendert werden. Das Ausblenden inaktiver Panels mit hidden, CSS oder einem progressiv verbesserten Äquivalent ist akzeptabel; sie erst nach einem Klick zu erzeugen, ist nicht akzeptabel. Ohne JavaScript muss der Fallback jedes beschriftete Panel in Quellreihenfolge anzeigen oder echte Links zu servergerenderten Zielen bereitstellen. Stabile Fragmente können ein Panel aktivieren, aber die kanonische Seite bleibt eine URL. Testen Sie Zoom, schmale Bildschirme, lange übersetzte Beschriftungen, Screenreader-Beziehungen, Tastaturreihenfolge und Skriptfehler.

Schreibregeln

Beginnen Sie mit der gemeinsamen Frage. Wenn jedes vorgeschlagene Panel eine andere Frage beantwortet, verwenden Sie keine Tabs. Schreiben Sie zwei bis fünf Items, wobei drei oder vier bevorzugt werden. Halten Sie Beschriftungen auf ein bis vier Wörter und nach Möglichkeit 28 Zeichen. Verwenden Sie parallele Grammatik: alle Rollen („Redakteure / Prüfer"), alle Modi („Gehostet / Self-Hosted") oder alle Phasen („Planen / Produzieren / Messen"). Mischen Sie keine Rolle, ein Verb und einen Marketingbegriff.

Geben Sie jedem Panel eine Überschrift mit 3–10 Wörtern, die sowohl den relevanten Pfad als auch dessen Ergebnis benennt, wenn die Tab-Beschriftung allein nicht ausreicht. Schreiben Sie 40–180 Wörter pro Panel, mit 300 als absolutem Maximum. Panels sollten eine vergleichbare Tiefe haben, aber sie benötigen keine identischen Wortzahlen. Verwenden Sie direkte Sprache und konkrete Unterschiede bei Aufgaben, Nachweisen, Berechtigungen, Einschränkungen oder Aktionen. Nur die Pronomen von „Sie" zu „Ihr Team" zu ändern, rechtfertigt kein weiteres Panel.

Halten Sie gemeinsame Informationen außerhalb des Elements. Das Wiederholen desselben einleitenden Satzes in jedem Panel erzeugt Wartungsabweichungen und lässt extrahierte Passagen wie Duplikate wirken. Platzieren Sie Unterschiede innerhalb der Panels und machen Sie jeden Unterschied explizit genug, um eine Extraktion zu überstehen. Bevorzugen Sie „Agentur-Teams können kundenbezogene Rollen zuweisen" gegenüber „Sie erhalten mehr Kontrolle", das sein Subjekt verliert, wenn es von der ausgewählten Bezeichnung getrennt wird.

Platzieren Sie niemals Folgendes innerhalb eines Tab-Sets:

• Die einzige Definition der Seite, direkte Antwort, Schlussfolgerung, Sicherheitswarnung, rechtliche Qualifikation, Berechtigungsregel oder Quellenangabe.
• Sequenzielle Schritte, die jeder Leser absolvieren muss, oder Voraussetzungen, die Inhalte außerhalb eines Panels betreffen.
• Ein weiteres Tab-Set, Akkordeon, Karussell, eine komplexe Datentabelle, ein mehrfeldriges Formular oder automatisch abspielende Medien.
• Mehr als eine primäre Handlungsaufforderung pro Panel oder Aktionen, die zu nicht zusammenhängenden Trichterstufen führen.
• Inhalte, die erst nach Interaktion geladen werden, selbst wenn der Ladezustand für einen menschlichen Benutzer schnell ist.
• Bezeichnungen wie „Sonstiges", „Mehr", „Allgemein" oder „Ressourcen", die eine undefinierte Beziehung verbergen.

Wenn jedes Panel 300 Wörter überschreitet, einen eigenen Nachweissatz benötigt oder auf eine andere Suchintention abzielt, veröffentlichen Sie dedizierte Abschnitte oder Seiten. Wenn Leser mehrere Kriterien gleichzeitig vergleichen müssen, verwenden Sie eine Tabelle. Wenn der Inhalt lediglich optionales Detail ist, verwenden Sie Prosa oder ein Akkordeon entsprechend der Beziehung.

Beitragstypen, die es verwenden

Das Feld postTypes im Frontmatter ist die Quelle für diese Tabelle. Die Aufnahme bedeutet, dass das Format Tabs unterstützen kann; es macht sie nicht verpflichtend.

QA-Checkliste

• Eine gemeinsame Frage: Jedes Panel beantwortet dieselbe eingegrenzte Frage für eine andere Zielgruppe, einen anderen Kontext oder Modus.
• Angemessene Anzahl: Das Set enthält zwei bis fünf Tabs, vorzugsweise drei oder vier, mit prägnanten parallelen Beschriftungen.
• Sichtbare gemeinsame Antwort: Die Definition, Kernantwort, zwingende Qualifikation und Schlussfolgerung bleiben außerhalb des Tab-Sets.
• Initiale DOM-Präsenz: Jedes Panel und sein vollständiger, vom Autor erstellter Inhalt erscheint im initialen servergerenderten HTML.
• Expliziter Kontext: Jede Panel-Überschrift und jeder einleitende Satz bleiben verständlich, wenn sie ohne den visuellen Tab-Zustand extrahiert werden.
• Korrekte Beziehungen: Tab- und Panel-IDs sind eindeutig; aria-controls und aria-labelledby paaren sie korrekt.
• Tastaturverhalten: Das Verhalten von Pfeiltasten, Home, End, Eingabetaste, Leertaste, Tab und Umschalt+Tab entspricht dem gewählten Aktivierungsmodell.
• Fokusklarheit: Fokus und Auswahl sind sichtbar unterscheidbar, und die Auswahl verschiebt den Fokus nicht unerwartet.
• Stabiler Fallback: Skriptfehler zeigen beschriftete Inhalte oder nutzbare servergerenderte Ziele an, ohne Informationen zu verlieren.
• Responsives Verhalten: Beschriftungen bleiben bei schmalen Breiten, 200 % Zoom und mit längerem übersetztem Text vollständig und auffindbar.
• Sichere Platzierung: Die Komponente trennt keine Behauptung von ihrem Nachweis, keine Warnung von ihrem Geltungsbereich und keine Voraussetzungen von Anweisungen.
• Keine komplexe Verschachtelung: Panels enthalten begrenzte Prosa und einfache unterstützende Inhalte, kein weiteres Interaktionssystem.
• Schema-Zurückhaltung: Der Renderer erfindet keine Listen-, Personen- oder Zielgruppen-Schemas aus Präsentationsbezeichnungen.
• Notationsparität: Markdown, Hugo und WordPress bewahren dieselbe Reihenfolge, IDs, Standardwerte, Beschriftungen, Überschriften und Panel-Bodies.

Ein Prüfer sollte die Komponente ablehnen, wenn inaktive Inhalte eine klickausgelöste Netzwerkanfrage erfordern, wenn wesentliche Informationen nur in einem Panel existieren oder wenn die Beschriftungen keine gleichrangigen Pfade beschreiben. Dies sind Inhalts- und Architekturfehler; visuelle Verfeinerung kann sie nicht beheben.

FAQ

Die strukturierten FAQ-Einträge im Frontmatter behandeln Indexierung, Fragment-URLs, Tab-Anzahl, Handlungsaufforderungen und die Unterscheidung zwischen Tabs und Akkordeons. Sie befinden sich absichtlich außerhalb des interaktiven Elements, damit jeder Leser und Renderer dieselbe Implementierungsanleitung erhält.