Accordion: Regler och exempel för progressiv informationsvisning

Ett accordion är en grupperad uppsättning märkta visningskontroller som låter en läsare visa eller dölja stödjande innehåll på plats. Använd det för valfria referensdetaljer, inte för sidans huvudsakliga svar.

Detta renderade par demonstrerar progressiv informationsvisning: etiketterna förblir skanningsbara, en panel är öppen och båda svaren finns i sidans HTML oavsett om en besökare interagerar eller inte.

Varför detta element är viktigt

Progressiv informationsvisning innebär att visa den information som behövs för det aktuella beslutet samtidigt som djupare eller mindre vanliga detaljer finns tillgängliga på begäran. Det hjälper när en sida betjänar läsare med olika kunskapsnivåer. En återkommande kund kan skanna förbi implementeringsanteckningar; en förstagångsanvändare kan öppna dem. Kontrollen minskar den visuella tätheten utan att ta bort innehåll eller tvinga varje läsare genom varje undantag.

Samma bekvämlighet kan bli döljande. En läsare som söker efter ett direkt svar, landar på sidan och ser åtta stängda etiketter måste gissa vilken panel som innehåller svaret och utföra en extra handling. På mobil flyttar upprepad öppning och stängning också innehåll runt i visningsporten. Accordionen förtjänar därför sin plats endast när de flesta läsare kan slutföra sin primära uppgift utan att öppna varje panel.

Maskinell extraherbarhet lägger till ett strängare test. Extraherbarhet är förmågan hos sökmotorer, AI-svarssystem, parsers och hjälpmedelsverktyg att ta emot texten och bevara dess relation till sin etikett. Varje svar måste finnas i den initiala serverrenderade Document Object Model (DOM), webbläsarens strukturerade representation av sidan. CSS kan visuellt fälla ihop en befintlig panel; JavaScript får inte hämta eller tillverka svaret först efter ett klick. En crawler kanske aldrig klickar, exekverar klientkoden eller väntar på en sekundär förfrågan.

Följ skrivreglerna för element innan du använder detta mönster. Om innehållets syfte matchar ett mer specifikt typat element har det elementet företräde. En accordion kan innehålla tillåtet stödjande innehåll, men den får inte byta namn på eller platta till en varning, jämförelse, definition eller stegsekvens endast för att göra sidan kortare.

När du ska använda det

Använd en accordion när alla fyra villkoren är uppfyllda:

1. Läsaren kan förutse panelens innehåll från dess etikett.
2. Innehållet är användbart för en delmängd läsare snarare än nödvändigt för alla.
3. Allt panelinnehåll levereras i den ursprungliga HTML-koden och förblir tillgängligt utan pekdon.
4. Hopfällning förbättrar avsevärt skanningsbarheten på den förväntade visningsporten.

Bra kandidater inkluderar valfria kompatibilitetsdetaljer, ovanliga felgrenar, stödjande definitioner, sekundära policyklausuler, fraktundantag och grupperade referenssvar. En accordion kan också fungera för en stor FAQ-samling när varje fråga förblir synlig och varje svar är fristående.

Nästan-träffar visar den vanligaste missbruket:

• En kort sida med två korta sektioner: synliga rubriker och stycken går snabbare att skanna än två kontroller.
• En lång artikel gjord för att se kortare ut: att fälla ihop tio omfattande sektioner minskar upplevd höjd men ökar interaktionen och döljer sidans omfattning.
• Primär produktinformation: pris, tillgänglighet, materialbegränsningar, uppsägningsvillkor och kärnspecifikationer påverkar beslutet och får inte vara beroende av expansion.
• En sekventiell procedur: steg kräver ordning och sammanhang. En stängd panel kan få läsare att hoppa över ett förkrav eller utföra steg i fel ordning.
• En jämförelse: läsare behöver samtidig synlighet över samma kriterier. Separata paneler tvingar fram minnesbaserad jämförelse.
• En säkerhetsvarning eller juridisk kvalifikation: konsekvensen av att missa den är högre än den visuella fördelen med att dölja den.
• En navigationsersättning: en accordion är inte en innehållsförteckning. Den visar innehåll på samma plats istället för att flytta till stabila sidsektioner.

När du är osäker, publicera innehållet synligt. Extra scrollning är oftast återhämtningsbart; ett missat svar, en odiskloserad begränsning eller en otillgänglig DOM-nod är det inte.

Var du ska placera det

Placera accordionen efter att sidan har levererat sitt direkta svar och tillräckligt med synlig förklaring för att läsaren ska förstå vad gruppen innehåller. Introducera den med en H2 och en omfattningsmening. Gruppen fungerar sedan som ett kompletterande referenslager inom den sektionen.

Exakta positionsregler:

• Placera den efter den synliga förklaring den kvalificerar, aldrig mellan ett påstående och beviset som stöder det påståendet.
• Håll den inom den överordnade sektionen vars ämne etiketterar varje objekt. Om etiketterna bara är meningsfulla med en saknad rubrik är gruppen felplacerad.
• Placera en accordion för produktdetaljer efter kärnvärdet, prissammanhanget och köpvillkoren; placera felsökningsgrenar efter den gemensamma diagnosen och den säkraste första kontrollen.
• Håll en avslutande FAQ-accordion efter huvudslutsatsen och före den slutliga nästa åtgärden, förutsatt att den besvarar kvarvarande snarare än upprepade frågor.
• Ge gruppen ett stabilt sektionsankare när läsare kan länka till den. Individuella panellänkar är valfria, men om de tillhandahålls måste de öppna och fokusera rätt objekt.

En accordion får inte sitta direkt intill flikar, en andra accordion eller en tät jämförelsetabell. Intilliggande interaktionsmönster tvingar läsare att välja en mekanism innan de kan välja innehåll. Den får inte avbryta ordnade steg, dela en varning från dess konsekvens eller sitta mellan en produkts pris och de villkor som styr priset. Placera inte en reklambanner inuti gruppen eller omedelbart efter varje panel; reklam konkurrerar med referensuppgiften och får expansion att kännas som en säljfälla.

Anatomi

Den märkta anatomien består av sju delar:

1. Grupprubrik: namnger det delade ämnet i den omgivande dokumenthierarkin.
2. Objektetikett: förutsäger det specifika innehållet utan vaga etiketter som “Lär dig mer”.
3. Visningskontroll: en inbyggd summary eller en button som tar emot tangentbordsfokus och växlar en panel.
4. Tillståndsindikator: kommunicerar öppet eller stängt visuellt medan det programmatiska tillståndet exponeras via inbyggd semantik eller aria-expanded.
5. Panel: innehåller svaret eller referensdetaljen och finns kvar i den ursprungliga DOM:en.
6. Kontrollrelation: inbyggd <details>/<summary>-semantik eller aria-controls plus matchande ID:n kopplar varje kontroll till exakt en panel.
7. Objektgräns: avstånd, kantlinje och DOM-gruppering säkerställer att en etikett inte ser ut att styra ett angränsande svar.

Den synliga vinkeln är dekorativ. Dölj den för hjälpmedelsteknik eftersom det expanderade tillståndet redan förmedlar betydelsen. Rotation ensam kan inte kommunicera tillstånd; kontrollsemantiken måste göra det.

Designexempel

Varje variant använder samma fält och DOM-närvaroregeln. Välj variant baserat på läsuppgift, inte på dekoration.

Standardgrupp med enkel öppning

Att öppna ett objekt stänger det tidigare öppna objektet. Använd detta när paneler är alternativ och läsare normalt behöver en i taget, såsom ömsesidigt uteslutande felsökningssymptom.

Referensgrupp med flera öppningar

Läsare kan ha flera paneler öppna samtidigt. Använd detta när de kan behöva jämföra eller kombinera kompletterande detaljer, såsom filtyper som stöds och kontobehörigheter. Om samtidig jämförelse är huvuduppgiften, använd en synlig tabell istället.

Standardöppen orientering

Öppna det första eller vanligaste objektet vid initial laddning när det demonstrerar innehållsmönstret och ger användbar orientering. Öppna aldrig mer än ett objekt endast för att fylla utrymme.

Kompakt FAQ-variant

Använd frågeetiketter och koncisa fristående svar. Interaktionen motiverar inte i sig strukturerad data; schema beror på innehållstypen och exakta synliga poster.

Långt innehåll – stress-tillstånd

En panel med mer än två korta stycken signalerar att materialet kanske förtjänar en synlig sektion. Stress-varianten finns för testning av radbrytning, länkar, listor, fokus och responsivt flöde, inte som det normala redaktionella målet.

Parametrar

Kontraktet separerar gruppbeteende från objektinnehåll så att varje plattform kan bevara samma etiketter, tillstånd och relationer.

Den första överordnade rubriken mappas till heading. Varje nästlat objekts första rubrik mappas till label, och allt därefter mappas till objektets content. Detta är en explicit nästlad objektmappning, i linje med basens prioritets- och brödtextregler. open=true ställer endast in initial presentation; det ändrar inte innehållets vikt. När linkable=true måste navigering till ett objektfragment expandera det, flytta fokus förutsägbart och lämna rubriken synlig under eventuell sticky-header.

Syntax och kodexempel

Alla tre notationerna representerar en kanonisk grupp. De kan rendera olika wrapper-klasser, men de måste bevara innehållet i den ursprungliga HTML-koden, källordningen, tillgängliga namn och tillstånd.

Portabel Markdown-direktiv

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

::item{id="included-fields" open=true}
### Vilka fält ingår?

Exporten innehåller de fält som för närvarande är tillgängliga för ditt konto och din rapportomfattning.
::

::item{id="filter-behavior"}
### Påverkar filter exporten?

Ja. Bekräfta aktivt datumintervall, marknad och statusfilter innan du skapar filen.
::
:::

Hugo shortcode

{{< accordion heading="Exportdetaljer" mode="multiple" linkable="true" >}}
{{< accordion-item id="included-fields" label="Vilka fält ingår?" open="true" >}}
Exporten innehåller de fält som för närvarande är tillgängliga för ditt konto och din rapportomfattning.
{{< /accordion-item >}}
{{< accordion-item id="filter-behavior" label="Påverkar filter exporten?" >}}
Ja. Bekräfta aktivt datumintervall, marknad och statusfilter innan du skapar filen.
{{< /accordion-item >}}
{{< /accordion >}}

Detta är Hugo-adapter-specifikationen. Ett repo uppfyller den inte genom att lägga till klasser på godtyckliga rubriker; det behöver en renderare som producerar inbyggd visnings-HTML eller en motsvarande knapp-och-panel-relation.

WordPress-block

<!-- wp:amicited/accordion {"heading":"Exportdetaljer","mode":"multiple","linkable":true} -->
<!-- wp:amicited/accordion-item {"id":"included-fields","label":"Vilka fält ingår?","open":true} -->
<p>Exporten innehåller de fält som för närvarande är tillgängliga för ditt konto och din rapportomfattning.</p>
<!-- /wp:amicited/accordion-item -->
<!-- wp:amicited/accordion-item {"id":"filter-behavior","label":"Påverkar filter exporten?"} -->
<p>Ja. Bekräfta aktivt datumintervall, marknad och statusfilter innan du skapar filen.</p>
<!-- /wp:amicited/accordion-item -->
<!-- /wp:amicited/accordion -->

Det registrerade WordPress-blocket lagrar de kanoniska fälten istället för att förlita sig på en visuell grupp av orelaterade Details-block. Dess server-render måste skicka ut varje svar före interaktion.

Exempel

Bra exempel

Information om borttagning av konto visas efter en synlig förklaring av vad borttagning innebär och en synlig varning om att det är oåterkalleligt. Dess tre etiketter är “Vad händer med schemalagda exporter?”, “Hur länge förblir ett begärt arkiv tillgängligt?” och “Kan en annan administratör avbryta begäran?” Varje panel innehåller en valfri gren, alla svar finns i HTML och tangentbordsfokus är synligt.

Detta fungerar eftersom huvudkonsekvensen och den nödvändiga åtgärden förblir synliga. Accordionen innehåller sekundära frågor som gäller olika läsare, och varje etikett låter läsaren förutsäga om det är värt att öppna den.

Dåligt exempel

Välj din plan innehåller stängda paneler märkta “Starter”, “Team” och “Enterprise”. Pris, användningsgränser, kontraktsvillkor, uppsägningsvillkor och tillgänglighet finns inuti panelerna. Endast en plan kan vara öppen åt gången.

Detta misslyckas eftersom köpkriterier kräver sida-vid-sida-visibilitet. Läsaren måste upprepade gånger öppna paneler och memorera fakta, medan en icke-interaktiv extraheringsfunktion kan missa klientladdade priser. Ersätt med en synlig pris- eller specifikationstabell och reservera visning för valfria detaljer såsom fakturaformat eller ovanliga behörighetsregler.

Schema-markup och tillgänglighet

Accordion har ingen dedikerad Schema.org-typ. Interaktionen matar ingen strukturerad data endast genom att existera. Om posterna är äkta frågor och svar kan FAQ-innehållskontraktet mata FAQPage; om gruppen innehåller produktdetaljer, policyer eller felsökningsanteckningar, använd endast det schema som motiveras av sidan och innehållet. Synlig text och eventuell strukturerad representation måste matcha.

Föredra inbyggda <details> och <summary> för enkla visningar eftersom webbläsaren tillhandahåller tangentbordshantering och tillståndssemantik. Där design eller enkel-öppet-beteende kräver en anpassad implementering måste varje kontroll vara en button, exponera aria-expanded="true" eller "false", referera till sin panel med aria-controls och ha ett unikt ID som panelen kan referera med aria-labelledby. Placera inte kontrollen på en div med en klickhanterare.

Enter eller Mellanslag måste aktivera den fokuserade kontrollen. Tab flyttar genom kontroller och interaktivt innehåll i den öppna panelen; fokus får inte gå in i stängt innehåll. Att öppna eller stänga en panel lämnar normalt fokus på dess kontroll. Pill-navigering mellan rubriker är valfritt, men om det implementeras får det inte ersätta normalt Tab-beteende.

Håll alla etiketter i tillgänglighetsträdet och alla svar i käll-HTML. En visuellt stängd panel får använda inbyggt visningsbeteende eller ett dolt tillstånd som stöds, men dess innehåll måste bli tillgängligt när det expanderas utan en andra hämtning. Det hopfällda tillståndet får inte orsaka dubbletter av innehåll genom separata stationära och mobila kopior. Testa vid 200 % zoom, med långa etiketter, endast tangentbord, reducerad rörelse och en skärmläsare. Animera höjd eller ikonrotation endast när rörelsen kan undertryckas och innehåll inte försenas.

Skrivregler

Etiketten bär kostnaden för interaktionen, så den måste göra ett precist löfte. Skriv 3–14 ord och vanligtvis inte mer än 120 tecken. Använd en direkt fråga för FAQ-innehåll och en beskrivande nominalfras för referensinnehåll. Undvik “Mer”, “Detaljer”, “Läs detta” och etiketter som endast skiljer sig åt med en siffra.

Använd 3–8 objekt per grupp. Varje panel bör normalt innehålla 20–120 ord och inte mer än 250. Två korta paneler är tydligare som öppen prosa; nio eller fler behöver gruppering, synlig navigering eller redaktionell konsolidering. Håll etiketter grammatiskt parallella och arrangera objekt efter läsarens uppgift, förväntad frekvens eller en verklig kategoriseringssekvens – inte alfabetiskt om inte sökning verkligen är alfabetisk.

Panelens ton är direkt, självständig och faktabaserad. Ange svaret i första meningen eftersom läsaren redan har betalat en interaktionskostnad. Definiera eventuell nödvändig term inom panelen eller i synlig text omedelbart före gruppen. Börja inte med utfyllnad som “Det finns flera saker att överväga.”

Placera aldrig endast följande inuti en accordion:

• sidans direkta svar eller unika värdeerbjudande;
• säkerhetsvarningar, kontraindikationer, juridiska skyldigheter eller oåterkalleliga konsekvenser;
• pris, tillgänglighet, materiella produktbegränsningar eller nödvändiga köpvillkor;
• ordnade steg, förkrav eller en slutförandekontroll;
• bevis som krävs för att stödja det omgivande påståendet;
• en primär jämförelse eller beslutsmatris;
• formulär, utcheckningskontroller, samtycke eller sidans huvudsakliga uppmaning till handling;
• en annan accordion, flikar eller en karusell.

En kompakt lista, liten tabell, inline-länk eller stödjande bild är acceptabelt när den helt tillhör ett valfritt objekt och förblir användbar på mobil. Om en panel behöver sin egen innehållsförteckning eller mer än en rubriknivå, flytta upp den till en synlig sektion eller separat sida.

Inläggstyper som använder det

postTypes-frontmatter-arrayen är källan till denna användningsmatris. Inkludering innebär att elementet är tillgängligt under angivet villkor, inte obligatoriskt på varje sida av den typen.

QA-checklista

• Ett synligt direkt svar visas före accordionen.
• Varje objekt är valfritt referensinnehåll, inte information som alla läsare behöver.
• Gruppen har 3–8 objekt med precisa, parallella etiketter.
• Varje panels fullständiga text finns i den initiala serverrenderade HTML-koden.
• Inget svar är beroende av en klickutlöst nätverksförfrågan eller klientsidig infogning.
• Inbyggda details/summary eller riktiga knappar ger korrekt tangentbordsbeteende.
• Anpassade kontroller exponerar aria-expanded, aria-controls, unika ID:n och en tillhörande paneletikett.
• Fokus är synligt, förblir förutsägbart efter växling och kan inte gå in i en stängd panel.
• Långa etiketter bryts utan beskärning, överlappning eller att tillståndsindikatorn döljs.
• Layouten fungerar vid 200 % zoom och på en smal visningsport utan horisontell scrollning.
• Rörelse respekterar preferenser för reducerad rörelse och försenar aldrig åtkomst till innehåll.
• Individuella fragmentlänkar, när de stöds, öppnar och visar korrekt panel.
• Strukturerad data baseras på innehållets betydelse, inte accordionens utseende.
• FAQPage-poster, om de skickas ut, matchar exakt den synliga fråge- och svarstexten.
• Ingen nästlad accordion, intilliggande flikuppsättning, upprepad mobilkopia eller huvud-CTA finns.
• Sidan kommunicerar fortfarande sitt primära svar när varje panel är stängd.

Vanliga frågor

Frontmatter lagrar de kanoniska FAQ-posterna för denna sida. Deras svar förstärker implementationsgränsen: innehåll kan vara visuellt hopfällt, men det förblir närvarande, tillgängligt och sekundärt till det synliga svaret.