Faner / Personabytter: Format, regler og eksempler

En fane-/personabytter gir flere lesere distinkte stier gjennom ett avgrenset emne uten å sende dem til separate sider. Etikettene identifiserer stien; valg av én viser panelet på samme sted. Elementet er bare nyttig når panelene er genuine likeverdige og hvert panel forblir til stede i sidens opprinnelige HTML.

Den gjengitte tilstanden viser ett aktivt panel, men de to andre panelene er også til stede i dokumentobjektmodellen (DOM) – nettleserens strukturerte representasjon av siden. De er skjult med det opprinnelige hidden-attributtet, ikke hentet etter et klikk. En produksjonsgjengiver legger til tastatur- og pekeratferden beskrevet nedenfor; innholdskontrakten forblir den samme på tvers av plattformer.

Hvorfor dette elementet betyr noe

Lesere filtrerer en side gjennom sin rolle, mål og ansvarsnivå. En innholdsspesialist vil kanskje ha skriveinstruksjoner, en SEO-spesialist vil ha valideringsregler, og en teamleder vil ha styringsprinsipper. En godt merket personabytter reduserer innsatsen med å oversette generiske råd til «hva betyr dette for meg?» Den holder også den felles premissen på ett sted, noe som unngår at tre nesten identiske sider konkurrerer om samme søkeintensjon.

Den psykologiske fordelen er gjenkjennelse fremfor tolkning. En leser kan gjenkjenne en etikett som «SEO-team» raskere enn de kan skanne tre avsnitt for å finne ut hvilket som gjelder. Faner bevarer også romlig kontekst: panelet endres på samme sted, så leseren kan sammenligne likeverdige stier uten å måtte rulle forbi den felles introduksjonen gjentatte ganger.

Denne bekvemmeligheten skaper en avveining for maskinuttrekkbarhet. Maskinuttrekkbarhet er evnen til en crawler, søkeindeks, hjelpeteknologi eller gjenfinningssystem til å isolere innhold samtidig som emnet og relasjonene bevares. Synlige overskrifter og avsnitt vises i en åpenbar leserekkefølge. Fanepaneler introduserer en interaksjonstilstand: ett er synlig, flere er ikke, og programvare må koble hver faneetikett til riktig panel. En svak implementering etterlater bare det aktive panelet i HTML-en, laster andre paneler etter et klikk, eller gjentar generiske overskrifter som «Fordeler» uten personanavnet. I hvert tilfelle mottar en maskin mindre kontekst enn leseren ser.

Selv en korrekt implementering kan redusere uttrekkbarheten sammenlignet med vanlige seksjoner. Noen systemer prioriterer innledningsvis synlig tekst, flater ut interaktive relasjoner, eller utelater skjult innhold fra utdrag. Faner er derfor et informasjonsrutingverktøy, ikke en måte å skjule essensielle svar. Plasser det felles svaret, definisjonen, advarselen, kvalifikasjonsbetingelsen og konklusjonen utenfor fanesettet. Bruk paneler til målgruppespesifikke anvendelser, eksempler, arbeidsflyter eller bevis som fortsatt er nyttige etter at det felles svaret er kjent.

Bruk skrivereglene for elementer : skriv den komplette forklaringen først, klassifiser deretter et ekte sett med likeverdige leserstier som dette typed elementet. Reglene på denne siden går foran for panelkartlegging, interaksjon og innholdsbegrensninger.

Når skal det brukes

Bruk en fane-/personabytter når alle disse betingelsene er oppfylt:

1. To til fem gjenkjennelige målgrupper, kontekster eller moduser trenger ulike anvendelser av samme emne.
2. Hvert panel svarer på samme spørsmål med sammenlignbar dybde.
3. De fleste lesere trenger ett panel om gangen, mens et mindretall kan sammenligne to eller flere.
4. Det felles svaret kan formuleres utenfor elementet uten å tvinge leseren til å åpne hver fane.
5. Det er tydeligere å holde stiene på én side enn å vedlikeholde separate sider med stort sett dupliserte introduksjoner.

Sterke bruksområder inkluderer implementeringsveiledning for «Utviklere / Redaktører / Kontrollører», introduksjonsstier for «Solo / Team / Byrå», og én kapabilitet forklart gjennom «Planlegg / Produser / Mål». Personaetiketter bør gjenspeile meningsfulle forskjeller i arbeidsflyt, bevis, tillatelser eller ønsket resultat – ikke demografiske gjetninger.

Nære bomtilfeller kommer ofte fra forsøk på å forkorte en side. Ikke legg sekvensielle trinn i faner; å skjule trinn to til en leser velger det, ødelegger prosedyrens rekkefølge. Ikke sett en kort liste med definisjoner i faner, fordi vanlige overskrifter viser samme informasjon med mindre interaksjon. Ikke bruk faner for en detaljert funksjonssammenligning: en sammenligningstabell holder kriteriene synlige samtidig. Ikke bruk faner som navigasjon mellom urelaterte emner, og ikke del opp informasjon bare fordi siden føles lang.

Et trekkspill passer bedre når seksjonene er uavhengige spørsmål i en vertikal leseflyt, eller når flere svar bør forbli åpne. Separate sider er bedre når hver målgruppe trenger en distinkt søkeintensjon, tittel, bevisoppsett, konverteringssti eller mer enn omtrent 300 ord med unikt innhold. Hvis en leser trenger alle panelene for å handle trygt eller korrekt, er faner feil komponent.

Hvor skal det plasseres

Plasser bytteren etter det felles svaret og avsnittet som forklarer hvorfor stiene er forskjellige. Leseren bør forstå det felles emnet før de velger en etikett. På en produkt- eller løsningsside betyr det vanligvis etter kjerneproposisjonen og den felles kapabilitetsforklaringen, men før detaljerte bevis og den primære avsluttende handlingen. I dokumentasjon plasseres den umiddelbart før de rollespesifikke instruksjonene den styrer.

Ikke plasser et fanesett før sidens direkte svar, definisjon eller obligatoriske advarsel. Ikke plasser det mellom en påstand og dens kilde, mellom en forutsetning og prosedyren den styrer, eller mellom en pris og dens kvalifikasjoner. Disse relasjonene må overleve selv når ingen fane er valgt. Et fanesett kan ikke stå ved siden av et annet fanesett, et trekkspill, et stort sammenligningsrutenett eller en karusell; tilstøtende interaksjonsmodeller skaper konkurrerende kontroller og uklar leserekkefølge.

Unngå nestede faner. Det ytre valget skjuler det indre valget, skaper vanskelig tastaturoppførsel og gjør dyp lenking tvetydig. Unngå også å plassere en personabytter rett over en annen målgruppevelger i et skjema eller en CTA. Hvis begge kontrollene bruker lignende etiketter, vet leserne kanskje ikke om de endrer synlig innhold eller sender inn en preferanse.

Anatomi

Anatomin har én merket beholder, én ordnet faneliste og ett panel for hver fane. Skjermbildet må vise inaktive paneler i DOM-inspektøren i tillegg til den synlige tilstanden, fordi tilstedeværelse i kildekoden er en del av elementet, ikke en implementeringsdetalj.

1. Felles tittel: Angir det felles spørsmålet eller oppgaven som hvert panel adresserer.
2. Faneliste: Grupperer to til fem likeverdige etiketter i en stabil rekkefølge.
3. Faneetikett: Navngir en målgruppe, kontekst eller modus på et språk lesere gjenkjenner.
4. Valgt tilstand: Kommuniserer den aktive fanen gjennom tekstsemantikk og en synlig behandling, ikke bare farge.
5. Panel: Inneholder en selvstendig overskrift og innholdet for én etikett.
6. Programmatisk relasjon: aria-controls på fanen og aria-labelledby på panelet forbinder hvert par.
7. Fallback-rekkefølge: Holder den felles tittelen, etikettene og alt panelinnhold meningsfylt når skript eller stilark ikke kjører.

Avstand, kantlinje, indikatorform, animasjon og bruddpunkt tilhører gjengiveren. Forfattere kontrollerer etiketter, kildeorden, panelinnhold og en valgfri stabil fragmentidentifikator.

Designeksempler

Komponenten støtter fire varianter. Hver variant bruker samme innholdsmodell og DOM-krav.

Personafaner: Bruk rolleetiketter når arbeidsflyter, bevis eller neste handlinger faktisk varierer etter leser. Foretrekk etablert kundespråk som «Interne team» fremfor oppdiktede personaer som «Vekstguruer.»

Kontekstfaner: Bruk ikke-personatilstander som teamstørrelse, driftsmodell eller implementeringsmodus. Den felles tittelen må navngi den skiftende dimensjonen slik at etikettene ikke forveksles med side-navigasjon.

Vertikale faner: Bruk bare når etiketter trenger mer horisontal plass og det ikke er mer enn fem. DOM- og tastaturrekkefølgen forblir fane én til fane fem, etterfulgt av deres tilhørende paneler i henhold til den valgte tilgjengelige implementeringen.

Smalt visningsformat og fallback-tilstand: Etiketter kan rulles horisontalt når et synlig signal gjør overløp åpenbart, eller gjengiveren kan vise paneler som stablede merkede seksjoner. Den må ikke forkorte etiketter til tvetydige fragmenter eller fjerne inaktivt innhold fra HTML-en.

Parametere

Innholdskontrakten holder relasjonen tydelig samtidig som visuell og responsiv oppførsel overlates til gjengiveren.

Etiketter er attributter fordi de styrer kontrollen; paneloverskrifter kommer fra den første overskriften fordi de tilhører innholdet. De to kan være like, men en konsis faneetikett kan kartlegges til en fyldigere, uttrekkbar paneloverskrift. Panelbrødtekster tillater avsnitt, en kort liste, innebygd kode, ett bilde og én kontekstuell handling. De tillater ikke et annet fanesett, trekkspill, datatabell, skjema, videospiller eller flertrinnsprosedyre.

Syntaks og kodeeksempler

Alle tre notasjonene bevarer én tittel, ordnede etiketter, paneloverskrifter, panelbrødtekster, stabile ID-er og den opprinnelige standarden. Det bærbare Markdown-direktivet er den kanoniske forfatterformen.

Portabelt Markdown-direktiv

:::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.
::
:::

Den overordnede brødtektens første overskrift kartlegges til title. Hvert nestede element tar label og id fra attributter, kartlegger sin første overskrift til item.title, og resten til item.content.

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 >}}

Adapteren bruker kun navngitte parametere. Den må gjengi alle elementenes brødtekster under serversvaret, avvise dupliserte ID-er, og initialisere interaksjon uten å omskrive innholdsmodellen.

WordPress-blokk

<!-- 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 bør begrense indre blokker til registrerte faneelementer. Forhåndsvisning, lagret markup og frontend-gjengivelse må beholde alle paneler; redigeringspraktiskhet må ikke gjøre inaktive elementer til klient-hentet innhold.

Eksempler

Godt eksempel

Velg en implementeringssti

Vertikalt vertet plattform – Lanser uten å vedlikeholde infrastruktur

Koble til den godkjente datakilden, konfigurer roller, og valider resultatet i et staging-miljø. Leverandøren håndterer kjøretidsoppdateringer og overvåking; teamet ditt eier innholdsgodkjenning og tilgangsstyring.

Selv-vertet – Kontroller distribusjon og datagrenser

Distribuer den støttede pakken i ditt miljø, koble til den samme godkjente datakilden, og tildel en ansvarlig for oppgraderinger, overvåking, sikkerhetskopiering og tilgangsstyring.

Dette fungerer fordi begge panelene svarer på samme implementeringsspørsmål, navngir den operasjonelle forskjellen, og inneholder sammenlignbare ansvarsområder. «Vertikalt vertet plattform» og «Selv-vertet» er gjenkjennelige etiketter. Den felles beslutningen forblir tydelig hvis begge panelene flates ut i kildeorden.

Dårlig eksempel

Utforsk alt

Oversikt: Vår plattform gjør moderne team mer effektive.

Pris: Kontakt salg for et personlig tilbud og viktige kontraktsvilkår.

Sikkerhet: Les vår sikkerhetsdokumentasjon.

Karriere: Bli med i vårt voksende team.

Dette er sidenavigasjon forkledd som faner. Panelene svarer ikke på ett felles spørsmål, etikettene blander kjøperinformasjon med bedriftsinnhold, og viktige prisbetingelser er skjult bak en interaksjon. Erstatt settet med vanlige sideseksjoner og ekte navigasjon. Hvis prisalternativer trenger samtidig evaluering, bruk en pris- eller sammenligningsstruktur heller enn faner.

Skjemamerking og tilgjengelighet

Faner og personabyttere oppretter ikke en dedikert Schema.org-type. Innholdet deres forblir en del av den omsluttende Article, TechArticle, Product eller WebPage når den siden uavhengig kvalifiserer. Ikke merk faner som ItemList bare fordi de gjentas, og ikke generer flere Person-entiteter fra personaetiketter. En etikett som «Byrå» beskriver en lesersti, ikke en faktisk enhetspåstand.

Bruk WAI-ARIA-fanemønsteret bare når grensesnittet faktisk oppfører seg som faner. Beholderen har role="tablist"; hver kontroll har role="tab", en unik ID, aria-controls og en nøyaktig aria-selected-verdi; hvert panel har role="tabpanel" og aria-labelledby. Bruk knapper for kontroller, ikke lenker med falske destinasjoner. Den valgte fanen tilhører sidens fanerekkefølge; inaktive faner bruker roving tabindex="-1" og forblir tilgjengelige med piltaster. Home og End flytter til første og siste fane. Aktivering kan følge fokus bare når panelbytting er umiddelbar; ellers aktiverer Enter eller Mellomrom den fokuserte fanen.

Fokus må forbli forutsigbart. Valg av en fane flytter ikke fokus automatisk inn i panelet. Et panel kan bruke tabindex="0" når dets første innhold ellers ikke er fokuserbart, slik at tastaturbrukere kan flytte seg inn i det. En synlig fokusindikator og valgt indikator må være forskjellige, og ingen av dem kan stole på farge alene.

Alle paneler må gjengis i den opprinnelige HTML-responsen. Å skjule inaktive paneler med hidden, CSS eller en progressivt forbedret ekvivalent er akseptabelt; å opprette dem først etter et klikk er det ikke. Uten JavaScript må fallbacken eksponere hvert merket panel i kildeorden eller tilby ekte lenker til server-gjengitte destinasjoner. Stabile fragmenter kan aktivere et panel, men den kanoniske siden forblir én URL. Test zoom, smale skjermer, lange oversatte etiketter, skjermleser-relasjoner, tastaturrekkefølge og skriptsvikt.

Skriveregler

Begynn med det felles spørsmålet. Hvis hvert foreslåtte panel svarer på et annet spørsmål, ikke bruk faner. Skriv to til fem elementer, med tre eller fire foretrukket. Hold etiketter på én til fire ord og 28 tegn der det er mulig. Bruk parallell grammatikk: alle roller («Redaktører / Kontrollører»), alle moduser («Vertet / Selv-vertet»), eller alle stadier («Planlegg / Produser / Mål»). Ikke bland en rolle, et verb og en markedsføringsfrase.

Gi hvert panel en overskrift på 3–10 ord som navngir både den relevante stien og dens utfall når faneetiketten alene er utilstrekkelig. Skriv 40–180 ord per panel, med 300 som absolutt maksimum. Paneler bør ha sammenlignbar dybde, men de trenger ikke identisk ordantall. Bruk direkte språk og konkrete forskjeller i oppgaver, bevis, tillatelser, begrensninger eller handlinger. Å bare endre pronomen fra «du» til «teamet ditt» rettferdiggjør ikke et nytt panel.

Hold felles informasjon utenfor elementet. Å gjenta den samme innledende setningen i hvert panel skaper vedlikeholdsdrift og får uttrukne passasjer til å se dupliserte ut. Plasser forskjeller inne i panelene, og gjør hver forskjell tydelig nok til å overleve uttrekking. Foretrekk «Byråteam kan tildele roller på klientnivå» fremfor «Du får mer kontroll», som mister subjektet når det skilles fra den valgte etiketten.

Aldri plasser følgende i et fanesett:

• Sidens eneste definisjon, direkte svar, konklusjon, sikkerhetsadvarsel, juridiske kvalifikasjon, kvalifikasjonsregel eller kildeangivelse.
• Sekvensielle trinn som hver leser må fullføre, eller forutsetninger som styrer innhold utenfor ett panel.
• Et annet fanesett, trekkspill, karusell, kompleks datatabell, flerfeltskjema eller autoavspillende media.
• Mer enn én primær handlingsknapp per panel, eller handlinger som fører til urelaterte traktsteg.
• Innhold som lastes først etter interaksjon, selv om lastetilstanden er rask for et menneske.
• Etiketter som «Annet», «Mer», «Generelt» eller «Ressurser» som skjuler en udefinert relasjon.

Hvis hvert panel overstiger 300 ord, trenger sitt eget bevisoppsett eller retter seg mot en annen søkeintensjon, publiser dedikerte seksjoner eller sider. Hvis lesere trenger å sammenligne flere kriterier samtidig, bruk en tabell. Hvis innholdet bare er valgfri detalj, bruk prosa eller et trekkspill i henhold til relasjonen.

Innholdstyper som bruker det

Feltet postTypes i frontmatter er kilden for denne tabellen. Inkludering betyr at formatet kan støtte faner; det gjør dem ikke obligatoriske.

QA-sjekkliste

• Ett felles spørsmål: Hvert panel svarer på samme avgrensede spørsmål for en annen målgruppe, kontekst eller modus.
• Passende antall: Settet inneholder to til fem faner, fortrinnsvis tre eller fire, med konsise parallelle etiketter.
• Synlig felles svar: Definisjonen, kjernesvaret, obligatoriske kvalifikasjoner og konklusjonen forblir utenfor fanesettet.
• Tilstedeværelse i opprinnelig DOM: Hvert panel og dets komplette forfatterinnhold vises i den opprinnelige server-gjengitte HTML-en.
• Eksplisitt kontekst: Hver paneloverskrift og innledende setning forblir forståelig når den trekkes ut uten visuell fanetilstand.
• Korrekte relasjoner: Fane- og panel-ID-er er unike; aria-controls og aria-labelledby parer dem korrekt.
• Tastaturoppførsel: Pil, Home, End, Enter, Mellomrom, Tab og Shift+Tab oppførsel samsvarer med den valgte aktiveringsmodellen.
• Fokusklarhet: Fokus og valg er visuelt distinkte, og valg flytter ikke fokus uventet.
• Stabil fallback: Skriptsvikt eksponerer merket innhold eller brukbare server-gjengitte destinasjoner uten å miste informasjon.
• Responsiv oppførsel: Etiketter forblir fullstendige og oppdagbare på smale bredder, 200 % zoom og med lengre oversatt tekst.
• Trygg plassering: Komponenten skiller ikke en påstand fra bevis, en advarsel fra dens omfang, eller forutsetninger fra instruksjoner.
• Ingen kompleks nesting: Paneler inneholder avgrenset prosa og enkelt støttende innhold, ikke et annet interaksjonssystem.
• Skjemarestriksjon: Gjengiveren finner ikke opp liste-, person- eller målgruppeskjema fra presentasjonsetiketter.
• Notasjonsparitet: Markdown, Hugo og WordPress bevarer samme rekkefølge, ID-er, standard, etiketter, overskrifter og panelbrødtekster.

En kontrollør bør avvise komponenten når inaktivt innhold krever en klikk-utløst nettverksforespørsel, når essensiell informasjon bare finnes inne i ett panel, eller når etikettene ikke beskriver likeverdige stier. Dette er innholds- og arkitekturfeil; visuell foredling kan ikke reparere dem.

FAQ

De strukturerte FAQ-oppføringene i frontmatter adresserer indeksering, fragment-URL-er, faneantall, handlingsknapper og skillet mellom faner og trekkspill. De er bevisst plassert utenfor det interaktive elementet slik at hver leser og gjengiver mottar den samme implementeringsveiledningen.