Accordion: Regler for progressiv avsløring og eksempler

En accordion er en gruppert samling av merkede avsløringskontroller som lar en leser vise eller skjule støtteinnhold på stedet. Bruk den for valgfrie referansedetaljer, ikke for sidens hovedsvar.

Dette gjengitte paret demonstrerer progressiv avsløring: etikettene forblir skannbare, ett panel er åpent, og begge svarene er til stede i sidens HTML uavhengig av om en besøkende interagerer.

Hvorfor dette elementet betyr noe

Progressiv avsløring betyr å vise informasjonen som trengs for den aktuelle beslutningen, samtidig som dypere eller mindre vanlige detaljer er tilgjengelige ved behov. Det hjelper når en side betjener lesere med ulike kunnskapsnivåer. En returnerende kunde kan skanne forbi implementeringsnotater; en førstegangsbruker kan åpne dem. Kontrollen reduserer visuell tetthet uten å slette innhold eller tvinge hver leser gjennom hvert unntak.

Den samme bekvemmeligheten kan bli skjult. En leser som søker etter et direkte svar, lander på siden og ser åtte lukkede etiketter, må gjette hvilket panel som inneholder det og utføre en ekstra handling. På mobil flytter gjentatt åpning og lukking også innhold rundt i visningsområdet. Accordionen fortjener derfor sin plass bare når de fleste lesere kan fullføre sin primære oppgave uten å åpne hvert panel.

Maskinell uttrekkbarhet legger til en strengere test. Uttrekkbarhet er evnen til søkemotorer, AI-svarssystemer, tolkere og hjelpeverktøy til å motta teksten og bevare dens forhold til etiketten. Hvert svar må være til stede i den innledende server-gjengitte Document Object Model (DOM), nettleserens strukturerte representasjon av siden. CSS kan visuelt skjule et tilstedeværende panel; JavaScript må ikke hente eller produsere svaret først etter et klikk. En crawler kan aldri klikke, kjøre klientkoden eller vente på en sekundær forespørsel.

Følg skrivereglene for elementer før du bruker dette mønsteret. Hvis innholdets formål samsvarer med et mer spesifikt typet element, har det elementet forrang. En accordion kan inneholde tillatt støtteinnhold, men den må ikke omdøpe eller flate ut en advarsel, sammenligning, definisjon eller trinnsekvens bare for å gjøre siden kortere.

Når du skal bruke det

Bruk en accordion når alle fire betingelser er oppfylt:

1. Leseren kan forutsi panelets innhold ut fra etiketten.
2. Innholdet er nyttig for en undergruppe av lesere, ikke nødvendig for alle.
3. Alt panelinnhold leveres i den opprinnelige HTML-en og forblir tilgjengelig uten pekeenhet.
4. Sammenlegging forbedrer skanning vesentlig på forventet visningsflate.

Gode kandidater inkluderer valgfrie kompatibilitetsdetaljer, uvanlige feilgrener, støttende definisjoner, sekundære retningslinjeklausuler, fraktunntak og grupperte referansesvar. En accordion kan også fungere for en stor FAQ-samling når hvert spørsmål forblir synlig og hvert svar er selvstendig.

Nære bommerter avslører den vanligste feilbruken:

• En kort side med to korte seksjoner: synlige overskrifter og avsnitt er raskere å skanne enn to kontroller.
• En lang artikkel som er gjort for å se kortere ut: å skjule ti omfattende seksjoner reduserer oppfattet høyde, men øker interaksjon og skjuler sidens omfang.
• Primær produktinformasjon: pris, tilgjengelighet, materialbegrensninger, kanselleringsvilkår og kjernespesifikasjoner påvirker beslutningen og må ikke være avhengig av utvidelse.
• En sekvensiell prosedyre: trinn krever rekkefølge og kontekst. Et lukket panel kan få lesere til å hoppe over en forutsetning eller utføre trinn i feil rekkefølge.
• En sammenligning: lesere trenger samtidig synlighet på tvers av samme kriterier. Separate paneler tvinger frem hukommelsesbasert sammenligning.
• En sikkerhetsadvarsel eller juridisk kvalifikasjon: konsekvensen av å gå glipp av den er høyere enn den visuelle fordelen ved å skjule den.
• En navigasjonserstatning: en accordion er ikke en innholdsfortegnelse. Den avslører innhold på samme sted i stedet for å flytte til stabile seksjoner på siden.

Når du er usikker, publiser innholdet synlig. Ekstra scrolling er vanligvis håndterbart; et glemt svar, en ikke avslørt begrensning eller en utilgjengelig DOM-node er det ikke.

Hvor du skal plassere det

Plasser accordionen etter at siden har levert sitt direkte svar og nok synlig forklaring til at leseren forstår hva gruppen inneholder. Introduser den med en H2 og én setning om omfang. Gruppen fungerer deretter som et supplerende referanselag innenfor den seksjonen.

Eksakte plasseringsregler:

• Plasser den etter den synlige forklaringen den kvalifiserer, aldri mellom en påstand og bevisene som støtter den påstanden.
• Hold den innenfor overordnet seksjon hvis emne etiketterer hvert element. Hvis etikettene bare gir mening uten en manglende overskrift, er gruppen feilplassert.
• Plasser en accordion med produktdetaljer etter kjerneverdien, priskonteksten og kjøpsbetingelsene; plasser feilsøkingsgrener etter den felles diagnosen og den sikreste første kontrollen.
• Hold en avsluttende FAQ-accordion etter hovedkonklusjonen og før den endelige neste handlingen, forutsatt at den besvarer gjenværende snarere enn gjentatte spørsmål.
• Gi gruppen et stabilt seksjonsanker når lesere kan lenke til den. Individuelle panel-lenker er valgfrie, men hvis de finnes, må de åpne og fokusere riktig element.

En accordion kan ikke sitte rett ved siden av faner, en annen accordion eller en tett sammenligningstabell. Tilstøtende interaksjonsmønstre tvinger lesere til å velge en mekanisme før de kan velge innhold. Den kan ikke avbryte ordnede trinn, dele en advarsel fra konsekvensen, eller sitte mellom en produktpris og betingelsene som styrer den prisen. Ikke plasser en reklamebanner inne i gruppen eller umiddelbart etter hvert panel; reklame konkurrerer med referanseoppgaven og får utvidelse til å føles som en salgsfelle.

Anatomi

Den merkede anatomien består av syv deler:

1. Gruppeoverskrift: navngir det felles emnet i det omkringliggende dokumenthierarkiet.
2. Elementetikett: forutsier det spesifikke innholdet uten vage etiketter som «Les mer».
3. Avsløringskontroll: en native summary eller en button som mottar tastaturfokus og veksler ett panel.
4. Tilstandsindikator: kommuniserer åpen eller lukket visuelt, mens den programmatiske tilstanden eksponeres gjennom native semantikk eller aria-expanded.
5. Panel: inneholder svaret eller referansedetaljen og forblir i den opprinnelige DOM-en.
6. Kontrollrelasjon: native <details>/<summary>-semantikk eller aria-controls pluss matchende ID-er knytter hver kontroll til nøyaktig ett panel.
7. Elementgrense: mellomrom, kantlinje og DOM-gruppering hindrer at én etikett ser ut til å styre et nabosvar.

Den synlige chevronen er dekorativ. Skjul den for hjelpeteknologi fordi den utvidede tilstanden allerede formidler betydningen. Rotasjon alene kan ikke kommunisere tilstand; kontrollsemantikken må gjøre det.

Designeksempler

Hver variant bruker de samme feltene og DOM-tilstedeværelsesregelen. Velg varianten basert på oppgave, ikke på dekorasjon.

Standard enkeltåpen gruppe

Åpning av ett element lukker det tidligere åpne elementet. Bruk dette når paneler er alternativer og lesere normalt trenger én om gangen, for eksempel gjensidig utelukkende feilsøkingssymptomer.

Multiåpen referansegruppe

Lesere kan holde flere paneler åpne. Bruk dette når de kan sammenligne eller kombinere supplerende detaljer, for eksempel støttede filtyper og kontotillatelser. Hvis samtidig sammenligning er hovedoppgaven, bruk en synlig tabell i stedet.

Forhåndsåpen orientering

Åpne det første eller vanligste elementet ved innledende lasting når det demonstrerer innholdsmønsteret og gir nyttig orientering. Åpne aldri mer enn ett element bare for å fylle plass.

Kompakt FAQ-variant

Bruk spørsmålsetiketter og konsise selvstendige svar. Interaksjonen rettferdiggjør ikke i seg selv strukturert data; skjema avhenger av innholdstypen og eksakte synlige oppføringer.

Spenningstilstand for langt innhold

Et panel med mer enn to korte avsnitt signaliserer at materialet kan fortjene en synlig seksjon. Spenningsvarianten finnes for testing av linjebryting, lenker, lister, fokus og responsiv flyt, ikke som det normale redaksjonelle målet.

Parametere

Kontrakten skiller gruppeadferd fra elementinnhold, slik at hver plattform kan bevare de samme etikettene, tilstandene og relasjonene.

Den første overordnede overskriften tilordnes heading. Hvert nestet elements første overskrift tilordnes label, og alt etter den tilordnes elementets content. Dette er en eksplisitt nestet-element-tilordning, i samsvar med grunnleggende presedens- og brødtekstregler. open=true angir bare innledende presentasjon; det endrer ikke innholdets viktighet. Når linkable=true, må navigering til et element-fragment utvide det, flytte fokus forutsigbart og etterlate overskriften synlig under eventuelle stikkende overskrifter.

Syntaks og kodeeksempler

Alle tre notasjonene representerer én kanonisk gruppe. De kan gjengi forskjellige innpakningsklasser, men de må bevare innhold i den opprinnelige HTML-en, kildeordrekkefølge, tilgjengelige navn og tilstand.

Bærbar Markdown-direktiv

:::accordion{mode=multiple linkable=true}
## Eksportdetaljer

::item{id="included-fields" open=true}
### Hvilke felter er inkludert?

Eksporten inneholder feltene som for øyeblikket er tilgjengelige for kontoen din og rapportomfanget.
::

::item{id="filter-behavior"}
### Påvirker filtre eksporten?

Ja. Bekreft aktiv datoperiode, marked og statusfiltre før du oppretter filen.
::
:::

Hugo shortcode

{{< accordion heading="Export details" mode="multiple" linkable="true" >}}
{{< accordion-item id="included-fields" label="Which fields are included?" open="true" >}}
The export contains the fields currently available to your account and report scope.
{{< /accordion-item >}}
{{< accordion-item id="filter-behavior" label="Do filters affect the export?" >}}
Yes. Confirm the active date range, market, and status filters before creating the file.
{{< /accordion-item >}}
{{< /accordion >}}

Dette er Hugo-adapter-spesifikasjonen. Et depot oppfyller den ikke ved å legge til klasser på vilkårlige overskrifter; det trenger en renderer som produserer native avslørings-HTML eller en tilsvarende knapp-og-panel-relasjon.

WordPress-blokk

<!-- wp:amicited/accordion {"heading":"Export details","mode":"multiple","linkable":true} -->
<!-- wp:amicited/accordion-item {"id":"included-fields","label":"Which fields are included?","open":true} -->
<p>The export contains the fields currently available to your account and report scope.</p>
<!-- /wp:amicited/accordion-item -->
<!-- wp:amicited/accordion-item {"id":"filter-behavior","label":"Do filters affect the export?"} -->
<p>Yes. Confirm the active date range, market, and status filters before creating the file.</p>
<!-- /wp:amicited/accordion-item -->
<!-- /wp:amicited/accordion -->

Den registrerte WordPress-blokken lagrer de kanoniske feltene i stedet for å stole på en visuell gruppe med urelaterte Details-blokker. Server-gjengivelsen må levere hvert svar før interaksjon.

Eksempler

Godt eksempel

Detaljer om kontosletting vises etter en synlig forklaring av hva sletting innebærer og en synlig advarsel om at det er irreversibelt. Dens tre etiketter er «Hva skjer med planlagte eksporter?», «Hvor lenge forblir et forespurt arkiv tilgjengelig?» og «Kan en annen administrator kansellere forespørselen?» Hvert panel inneholder én valgfri gren, alle svar er i HTML, og tastaturfokus er synlig.

Dette fungerer fordi hovedkonsekvensen og nødvendig handling forblir synlige. Accordionen inneholder sekundære spørsmål som gjelder ulike lesere, og hver etikett lar leseren forutsi om det er verdt å åpne den.

Dårlig eksempel

Velg din plan inneholder lukkede paneler merket «Starter», «Team» og «Enterprise». Pris, bruksgrenser, kontraktsperiode, kanselleringsbetingelser og tilgjengelighet er inne i panelene. Bare én plan kan være åpen om gangen.

Dette mislykkes fordi kjøpskriterier trenger side-ved-side-synlighet. Leseren må gjentatte ganger åpne paneler og huske fakta, mens en ikke-interaktiv uttrekker kan gå glipp av klientlastede priser. Erstatt det med en synlig pris- eller spesifikasjonstabell og reserver avsløring for valgfrie detaljer som fakturaformater eller uvanlige kvalifikasjonsregler.

Skjemaoppmerking og tilgjengelighet

Accordion har ingen dedikert Schema.org-type. Interaksjonen mater ingen strukturert data bare ved å eksistere. Hvis oppføringene er genuine spørsmål og svar, kan FAQ-innholdskontrakten mate FAQPage; hvis gruppen inneholder produktdetaljer, retningslinjer eller feilsøkingsnotater, bruk kun skjemaet som er rettferdiggjort av siden og innholdet. Synlig tekst og enhver strukturert representasjon må samsvare.

Foretrekk native <details> og <summary> for enkle avsløringer fordi nettleseren leverer tastaturoperasjon og tilstandssemantikk. Hvis design eller enkeltåpen-adferd krever en tilpasset implementering, må hver kontroll være en button, eksponere aria-expanded="true" eller "false", referere til panelet med aria-controls og ha en unik ID som panelet kan referere til med aria-labelledby. Ikke plasser kontrollen på en div med en klikkbehandler.

Enter eller Mellomrom må betjene den fokuserte kontrollen. Tab beveger seg gjennom kontroller og interaktivt innhold i det åpne panelet; fokus må ikke gå inn i lukket innhold. Åpning eller lukking av et panel etterlater normalt fokus på kontrollen. Piltastnavigering mellom overskrifter er valgfritt, men hvis implementert må det ikke erstatte normal Tab-adferd.

Hold alle etiketter i tilgjengelighetstreet og alle svar i kilde-HTML. Et visuelt lukket panel kan bruke native avsløringsatferd eller en støttet skjult tilstand, men innholdet må bli tilgjengelig når det utvides uten en ny henting. Den sammenkollapsede tilstanden må ikke forårsake duplisert innhold gjennom separate stasjonære og mobile kopier. Test ved 200 % zoom, med lange etiketter, kun tastatur, redusert bevegelse og en skjermleser. Animer høyde eller ikonrotasjon bare når bevegelsen kan undertrykkes og innhold ikke blir forsinket.

Skriveregler

Etiketten bærer kostnaden av interaksjonen, så den må gi et presist løfte. Skriv 3–14 ord og vanligvis ikke mer enn 120 tegn. Bruk et direkte spørsmål for FAQ-innhold og en beskrivende substantivfrase for referanseinnhold. Unngå «Mer», «Detaljer», «Les dette» og etiketter som bare skiller seg med et tall.

Bruk 3–8 elementer per gruppe. Hvert panel bør normalt inneholde 20–120 ord og ikke mer enn 250. To korte paneler er tydeligere som åpen prosa; ni eller flere trenger gruppering, synlig navigasjon eller redaksjonell konsolidering. Hold etiketter grammatisk parallelle og ordne elementer etter leserens oppgave, forventet frekvens eller en faktisk sekvens av kategorier — ikke alfabetisk med mindre oppslag virkelig er alfabetisk.

Paneltonen er direkte, selvstendig og saklig. Angi svaret i første setning fordi leseren allerede har betalt en interaksjonskostnad. Definer eventuelle nødvendige begreper i panelet eller i synlig tekst umiddelbart før gruppen. Ikke start med oppvarmingsfraser som «Det er flere ting å vurdere.»

Sett aldri bare disse inni en accordion:

• sidens direkte svar eller unike verdiforslag;
• sikkerhetsadvarsler, kontraindikasjoner, juridiske forpliktelser eller irreversible konsekvenser;
• pris, tilgjengelighet, materielle produktbegrensninger eller nødvendige kjøpsbetingelser;
• ordnede trinn, forutsetninger eller en fullføringssjekk;
• dokumentasjon nødvendig for å støtte den omkringliggende påstanden;
• en primær sammenligning eller beslutningsmatrise;
• skjemaer, utsjekkingskontroller, samtykke eller sidens hovedhandlingskall;
• en annen accordion, faner eller en karusell.

En kompakt liste, liten tabell, innebygd lenke eller støttebilde er akseptabelt når det utelukkende tilhører ett valgfritt element og forblir brukbart på mobil. Hvis et panel trenger sin egen innholdsfortegnelse eller mer enn ett overskriftsnivå, frem det til en synlig seksjon eller egen side.

Innholdstyper som bruker det

postTypes-frontmatter-arrayet er kilden til denne bruksmatrisen. Inkludering betyr at elementet er tilgjengelig under den angitte betingelsen, ikke obligatorisk på hver side av den typen.

QA-sjekkliste

• Et synlig direkte svar vises før accordionen.
• Hvert element er valgfritt referanseinnhold, ikke informasjon alle lesere trenger.
• Gruppen har 3–8 elementer med presise, parallelle etiketter.
• Hvert panels fullstendige tekst er til stede i den opprinnelige server-gjengitte HTML-en.
• Intet svar er avhengig av en klikkutløst nettverksforespørsel eller klient-eksklusiv innsetting.
• Native details/summary eller reelle knapper gir korrekt tastaturoppførsel.
• Tilpassede kontroller eksponerer aria-expanded, aria-controls, unike ID-er og en tilhørende paneletikett.
• Fokus er synlig, forblir forutsigbart etter veksling og kan ikke gå inn i et lukket panel.
• Lange etiketter brytes uten beskjæring, overlapping eller skjuling av tilstandsindikatoren.
• Oppsettet fungerer ved 200 % zoom og på et smalt visningsområde uten horisontal scrolling.
• Bevegelse respekterer redusert-bevegelse-preferanser og forsinker aldri tilgang til innhold.
• Individuelle fragmentlenker, når de støttes, åpner og viser riktig panel.
• Strukturert data er basert på innholdsbetydning, ikke accordionens utseende.
• FAQPage-poster, hvis utstedt, samsvarer nøyaktig med synlig spørsmåls- og svartekst.
• Ingen nestet accordion, tilstøtende fanesett, gjentatt mobilkopi eller hoved-HA er til stede.
• Siden formidler fortsatt sitt primære svar når hvert panel er lukket.

Ofte stilte spørsmål

Frontmatteren lagrer de kanoniske FAQ-postene for denne siden. Svarene deres forsterker implementeringsgrensen: innhold kan være visuelt sammenkollapset, men det forblir til stede, tilgjengelig og sekundært i forhold til det synlige svaret.