Accordion: Regler for progressiv visning og eksempler

En accordion er en grupperet samling af mærkede visningskontroller, der lader læseren afsløre eller skjule supplerende indhold på stedet. Brug den til valgfrie referencedetaljer, ikke til sidens primære svar.

Dette gengivne par demonstrerer progressiv visning: etiketterne kan scannes, ét panel er åbent, og begge svar findes i sidens HTML, uanset om en besøgende interagerer.

Hvorfor dette element er vigtigt

Progressiv visning betyder at vise den information, der er nødvendig for den aktuelle beslutning, mens dybere eller mindre almindelige detaljer er tilgængelige på forespørgsel. Det hjælper, når en side betjener læsere med forskellige vidensniveauer. En tilbagevendende kunde kan scrolle forbi implementeringsnoter; en førstegangsbruger kan åbne dem. Kontrollen sænker visuel tæthed uden at slette indhold eller tvinge hver læser gennem hver undtagelse.

Den samme bekvemmelighed kan blive til skjul. En læser, der søger efter et direkte svar, lander på siden og ser otte lukkede etiketter, må gætte, hvilket panel der indeholder svaret, og udføre en ekstra handling. På mobil flytter gentagen åbning og lukning også indhold rundt i viewporten. Accordionen fortjener derfor kun sin plads, når de fleste læsere kan fuldføre deres primære opgave uden at åbne hvert panel.

Maskinel udtrækkelighed tilføjer en strengere test. Udtrækkelighed er evnen hos søgemaskiner, AI-svarsystemer, parserere og hjælpeværktøjer til at modtage teksten og bevare dens relation til etiketten. Hvert svar skal være til stede i det indledende servergengivne Document Object Model (DOM), browserens strukturerede repræsentation af siden. CSS kan visuelt skjule et tilstedeværende panel; JavaScript må ikke hente eller fremstille svaret først efter et klik. En crawler kan måske aldrig klikke, udføre klientkoden eller vente på en sekundær forespørgsel.

Følg skrivereglerne for elementer før du bruger dette mønster. Hvis indholdets formål matcher et mere specifikt typebestemt element, har dette element forrang. En accordion kan indeholde tilladt understøttende indhold, men den må ikke omdøbe eller flade en advarsel, sammenligning, definition eller trinsekvens ud blot for at gøre siden kortere.

Hvornår skal det bruges

Brug en accordion, når alle fire betingelser er opfyldt:

1. Læseren kan forudsige panelets indhold ud fra etiketten.
2. Indholdet er nyttigt for en delmængde af læsere snarere end nødvendigt for alle.
3. Alt panelindhold leveres i den indledende HTML og forbliver tilgængeligt uden pegeredskab.
4. Sammenklapning forbedrer væsentligt scanning på den forventede viewport.

Gode kandidater inkluderer valgfrie kompatibilitetsdetaljer, usædvanlige fejlgrene, supplerende definitioner, sekundære politikklausuler, forsendelsesundtagelser og grupperede referencesvar. En accordion kan også fungere til en stor FAQ-samling, når hvert spørgsmål forbliver synligt, og hvert svar er selvstændigt.

Nærmissere afslører den mest almindelige fejlbrug:

• En kort side med to korte sektioner: synlige overskrifter og afsnit er hurtigere at scanne end to kontroller.
• En lang artikel gjort kortere: at klappe ti omfattende sektioner sammen reducerer den opfattede højde, men øger interaktion og skjuler sidens omfang.
• Primær produktinformation: pris, tilgængelighed, materialebegrænsninger, annulleringsvilkår og kerneegenskaber påvirker beslutningen og må ikke afhænge af udvidelse.
• En sekventiel procedure: trin kræver rækkefølge og kontekst. Et lukket panel kan få læsere til at springe en forudsætning over eller udføre trin i forkert rækkefølge.
• En sammenligning: læsere har brug for samtidig synlighed på tværs af samme kriterier. Separate paneler tvinger til hukommelsesbaseret sammenligning.
• En sikkerhedsadvarsel eller juridisk kvalifikation: konsekvensen af at overse den er højere end den visuelle fordel ved at skjule den.
• En navigationserstatning: en accordion er ikke en indholdsfortegnelse. Den afslører indhold på samme sted i stedet for at flytte til stabile sideafsnit.

Når du er i tvivl, så udgiv indholdet synligt. Ekstra scroll er normalt genopretteligt; et misset svar, en ikke-oplyst begrænsning eller en utilgængelig DOM-node er det ikke.

Hvor skal det placeres

Placer accordionen efter at siden har leveret sit direkte svar og nok synlig forklaring til at læseren forstår, hvad gruppen indeholder. Introducer den med en H2 og én sætning om omfang. Gruppen fungerer derefter som et supplerende referencelag inden for den sektion.

Præcise placeringsregler:

• Placer den efter den synlige forklaring, den kvalificerer, aldrig mellem en påstand og evidensen, der understøtter den.
• Hold den inden for den overordnede sektion, hvis emne mærker hvert element. Hvis etiketterne kun giver mening med en manglende overskrift, er gruppen forkert placeret.
• Placer en accordion med produktdetaljer efter kerneværdien, priskonteksten og købsbetingelserne; placer fejlfindingsgrene efter den fælles diagnose og den sikreste første kontrol.
• Hold en afsluttende FAQ-accordion efter hovedkonklusionen og før den endelige næste handling, forudsat at den besvarer resterende snarere end gentagne spørgsmål.
• Giv gruppen et stabilt sektionsanker, når læsere kan linke til den. Individuelle panelelementlinks er valgfrie, men hvis de leveres, skal de åbne og fokusere det korrekte element.

En accordion må ikke sidde direkte ved siden af faner, en anden accordion eller en tæt sammenligningstabel. Tilstødende interaktionsmønstre tvinger læsere til at vælge en mekanisme, før de kan vælge indhold. Den må ikke afbryde ordinerede trin, opdele en advarsel fra dens konsekvens eller sidde mellem en produktpris og betingelserne, der styrer denne pris. Placer ikke en promoveringsbanner inde i gruppen eller umiddelbart efter hvert panel; promovering konkurrerer med referenceopgaven og får udvidelse til at føles som en salgsfælde.

Anatomi

Den mærkede anatomi består af syv dele:

1. Gruppeoverskrift: navngiver det fælles emne i det omgivende dokumenthierarki.
2. Elementetiket: forudsiger det specifikke indhold uden vage etiketter som “Lær mere”.
3. Visningskontrol: en indbygget summary eller en button, der modtager tastaturfokus og skifter ét panel.
4. Tilstandsindikator: kommunikerer åben eller lukket visuelt, mens den programmatiske tilstand eksponeres via indbygget semantik eller aria-expanded.
5. Panel: indeholder svaret eller referencedetaljen og forbliver i den oprindelige DOM.
6. Kontrolrelation: indbygget <details>/<summary>-semantik eller aria-controls plus matchende ID’er forbinder hver kontrol med præcis ét panel.
7. Elementafgrænsning: afstand, kant og DOM-gruppering sikrer, at én etiket ikke ser ud til at styre et nabosvar.

Den synlige chevron er dekorativ. Skjul den for hjælpeteknologi, fordi den udvidede tilstand allerede leverer betydningen. Rotation alene kan ikke kommunikere tilstand; kontrolsemantikken skal gøre det.

Designeksempler

Hver variant bruger de samme felter og DOM-tilstedeværelsesregel. Vælg varianten ud fra læseopgaven, ikke udenad.

Standard enkeltåben gruppe

Åbning af ét element lukker det tidligere åbne element. Brug dette, når paneler er alternativer, og læsere normalt har brug for ét ad gangen, såsom gensidigt udelukkende fejlfindingssymptomer.

Multiåben referencegruppe

Læsere kan holde flere paneler åbne. Brug dette, når de kan sammenligne eller kombinere supplerende detaljer, såsom understøttede filtyper og kontorettigheder. Hvis samtidig sammenligning er den primære opgave, brug en synlig tabel i stedet.

Standardåben orientering

Åbn det første eller mest almindelige element ved indledende indlæsning, når det demonstrerer indholdsmønsteret og giver nyttig orientering. Åbn aldrig mere end ét element blot for at fylde plads.

Kompakt FAQ-variant

Brug spørgsmålsetiketter og korte selvstændige svar. Interaktionen i sig selv berettiger ikke struktureret data; skema afhænger af indholdstypen og de nøjagtige synlige poster.

Langt indhold – belastningstilstand

Et panel med mere end to korte afsnit signalerer, at materialet måske fortjener en synlig sektion. Belastningsvarianten findes til test af ombrydning, links, lister, fokus og responsivt flow, ikke som det normale redaktionelle mål.

Parametre

Kontrakten adskiller gruppeadfærd fra elementindhold, så hver platform kan bevare de samme etiketter, tilstande og relationer.

Den første overordnede overskrift mappes til heading. Hvert indlejret elements første overskrift mappes til label, og alt derefter mappes til elementets content. Dette er en eksplicit indlejret elementmapping, konsistent med basispræcedens og brødtekstregler. open=true angiver kun indledende præsentation; det ændrer ikke indholdsvigtighed. Når linkable=true, skal navigation til et elementfragment udvide det, flytte fokus forudsigeligt og efterlade overskriften synlig under eventuel klæbrig header.

Syntaks og kodeeksempler

Alle tre notationer repræsenterer én kanonisk gruppe. De kan gengive forskellige wrapper-klasser, men skal bevare indhold i den indledende HTML, kildeorden, tilgængelige navne og tilstand.

Portabel Markdown-instruktion

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

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

Eksporten indeholder de felter, der aktuelt er tilgængelige for din konto og rapportafgrænsning.
::

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

Ja. Bekræft den aktive datoperiode, marked og statusfiltre før du opretter 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-adapterspecifikationen. Et repositorium opfylder den ikke ved at tilføje klasser til vilkårlige overskrifter; det har brug en renderer, der producerer indbygget visnings-HTML eller en tilsvarende knap-og-panel-relation.

WordPress-blok

<!-- 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 registrerede WordPress-blok gemmer de kanoniske felter frem for at stole på en visuel gruppe af uafhængige Details-blokke. Dens servergengivelse skal udsende hvert svar før interaktion.

Eksempler

Godt eksempel

Detaljer om kontosletning vises efter en synlig forklaring af, hvad sletning gør, og en synlig advarsel om, at det er irreversibelt. Dens tre etiketter er “Hvad sker der med planlagte eksport?”, “Hvor længe forbliver et anmodet arkiv tilgængeligt?” og “Kan en anden administrator annullere anmodningen?” Hvert panel indeholder én valgfri gren, alle svar er i HTML, og tastaturfokus er synligt.

Dette virker, fordi hovedkonsekvensen og den påkrævede handling forbliver synlige. Accordionen indeholder sekundære spørgsmål, der gælder for forskellige læsere, og hver etiket lader læseren forudsige, om det er værd at åbne den.

Dårligt eksempel

Vælg din plan indeholder lukkede paneler mærket “Starter”, “Team” og “Enterprise”. Pris, brugsgrænser, kontraktperiode, annulleringsbetingelser og tilgængelighed er inde i panelerne. Kun én plan kan være åben ad gangen.

Dette fejler, fordi købskriterier har brug for side-by-side-synlighed. Læseren skal gentagne gange åbne paneler og huske fakta, mens en ikke-interaktiv ekstraheringsenhed kan gå glip af klientindlæste priser. Erstat det med en synlig pris- eller specifikationstabel og reserver visning til valgfrie detaljer såsom fakturaformater eller usædvanlige berettigelsesregler.

Skema-markup og tilgængelighed

Accordion har ingen dedikeret Schema.org-type. Interaktionen fodrer ingen strukturerede data blot ved at eksistere. Hvis dens poster er ægte spørgsmål og svar, kan FAQ-indholdskontrakten fodre FAQPage; hvis gruppen indeholder produktdetaljer, politikker eller fejlfindingsnoter, brug kun det skema, der er berettiget af siden og indholdet. Synlig tekst og enhver struktureret repræsentation skal matche.

Foretræk indbygget <details> og <summary> til ligetil visninger, fordi browseren leverer tastaturbetjening og tilstandssemantik. Hvor design eller enkeltåben-adfærd kræver en brugerdefineret implementering, skal hver kontrol være en button, eksponere aria-expanded="true" eller "false", referere til sit panel med aria-controls og have et unikt ID, som panelet kan referere med aria-labelledby. Placer ikke kontrollen på en div med en klik-håndtering.

Enter eller Mellemrum skal betjene den fokuserede kontrol. Tab bevæger sig gennem kontroller og interaktivt indhold i det åbne panel; fokus må ikke gå ind i lukket indhold. Åbning eller lukning af et panel efterlader normalt fokus på kontrollen. Piletast-navigation mellem overskrifter er valgfri, men hvis den implementeres, må den ikke erstatte normal Tab-adfærd.

Hold alle etiketter i tilgængelighedstræet og alle svar i kilde-HTML. Et visuelt lukket panel må bruge indbygget visningsadfærd eller en understøttet skjult tilstand, men dets indhold skal blive tilgængeligt, når det udvides uden en anden hentning. Den sammenklappede tilstand må ikke forårsage duplikeret indhold gennem separate desktop- og mobilkopier. Test ved 200% zoom, med lange etiketter, kun tastatur, reduceret animation og en skærmlæser. Animer højde eller ikonrotation kun, når animationen kan undertrykkes, og indhold ikke forsinkes.

Skriveregler

Etiketten bærer omkostningen ved interaktionen, så den må give et præcist løfte. Skriv 3–14 ord og normalt højst 120 tegn. Brug et direkte spørgsmål til FAQ-indhold og en beskrivende substantivfrase til referenceindhold. Undgå “Mere”, “Detaljer”, “Læs dette” og etiketter, der kun adskiller sig med et tal.

Brug 3–8 elementer pr. gruppe. Hvert panel bør normalt indeholde 20–120 ord og højst 250. To korte paneler er tydeligere som åben prosa; ni eller flere har brug for gruppering, synlig navigation eller redaktionel konsolidering. Hold etiketter grammatisk parallelle og arrangér elementer efter læserens opgave, forventet hyppighed eller en reel rækkefølge af kategorier – ikke alfabetisk, medmindre opslag rent faktisk er alfabetisk.

Paneltonen er direkte, selvstændig og faktuel. Angiv svaret i første sætning, fordi læseren allerede har betalt en interaktionsomkostning. Definer eventuelle nødvendige termer inden for panelet eller i synlig tekst umiddelbart før gruppen. Start ikke med indledende fyld som “Der er flere ting at overveje.”

Placer aldrig kun disse inde i en accordion:

• sidens direkte svar eller unikke værditilbud;
• sikkerhedsadvarsler, kontraindikationer, juridiske forpligtelser eller irreversible konsekvenser;
• pris, tilgængelighed, materielle produktgrænser eller påkrævede købsbetingelser;
• ordinerede trin, forudsætninger eller en fuldførelseskontrol;
• evidens nødvendig for at understøtte den omgivende påstand;
• en primær sammenligning eller beslutningsmatrix;
• formularer, checkout-kontroller, samtykke eller sidens primære call to action;
• en anden accordion, faner eller en karrusel.

En kompakt liste, lille tabel, inline-link eller understøttende billede er acceptabelt, når det udelukkende tilhører ét valgfrit element og forbliver brugbart på mobil. Hvis et panel har brug for sin egen indholdsfortegnelse eller mere end ét overskriftsniveau, frem det til en synlig sektion eller separat side.

Indlægstyper der bruger det

postTypes-frontmatter-arrayet er kilden til denne brugsmatrix. Inklusion betyder, at elementet er tilgængeligt under den angivne betingelse, ikke obligatorisk på hver side af den type.

QA-tjekliste

• Et synligt direkte svar vises før accordionen.
• Hvert element er valgfrit referenceindhold, ikke information alle læsere har brug for.
• Gruppen har 3–8 elementer med præcise, parallelle etiketter.
• Hvert panels fulde tekst er til stede i den indledende servergengivne HTML.
• Intet svar afhænger af en klikudløst netværksanmodning eller klient-only indsættelse.
• Indbygget details/summary eller rigtige knapper giver korrekt tastaturadfærd.
• Brugerdefinerede kontroller eksponerer aria-expanded, aria-controls, unikke ID’er og en tilknyttet paneletiket.
• Fokus er synligt, forbliver forudsigeligt efter skift og kan ikke gå ind i et lukket panel.
• Lange etiketter brydes uden afskæring, overlap eller skjulning af tilstandsindikatoren.
• Layoutet fungerer ved 200% zoom og på en smal viewport uden vandret scroll.
• Animation respekterer reduceret-animation-præferencer og forsinker aldrig adgang til indhold.
• Individuelle fragmentlinks åbner og afslører det korrekte panel, når de understøttes.
• Strukturerede data er baseret på indholdsbetydning, ikke accordionens udseende.
• FAQPage-poster, hvis de udsendes, matcher nøjagtigt den synlige spørgsmål- og svar-tekst.
• Ingen indlejret accordion, tilstødende fanesæt, gentagen mobilkopi eller primær CTA er til stede.
• Siden kommunikerer stadig sit primære svar, når hvert panel er lukket.

Ofte stillede spørgsmål

Frontmatteren gemmer de kanoniske FAQ-poster for denne side. Deres svar forstærker implementeringsgrænsen: indhold kan være visuelt sammenklappet, men det forbliver til stede, tilgængeligt og sekundært i forhold til det synlige svar.