Iconbox — Format, regler och exempel

En iconbox parar en ändamålsenlig ikon med en kort etikett och en fokuserad förklaring. Ikonen gör ämnet igenkännbart, etiketten namnger det och texten förklarar varför det är viktigt. Elementet fungerar bäst som en medlem i en liten grupp av jämbördiga objekt, till exempel tre produktkapaciteter eller fyra krav – inte som dekoration utspridd på en sida.

Bocksymbolen är ändamålsenlig: den förstärker verifiering snarare än att fylla ett tomt hörn. Eftersom den synliga etiketten redan anger samma innebörd, döljs den renderade symbolen för hjälpmedelsteknik. En skärmläsaranvändare får hela meddelandet från “Verifierade källor” och dess förklaring utan att höra redundant ikonutdata.

Varför detta element är viktigt

Läsare bearbetar inte varje mening i ordning. De letar efter landmärken som svarar på frågan “Handlar det här om det jag behöver?” En iconbox skapar ett kompakt igenkänningsmönster: form först, etikett sedan, förklaring sist. I en välorganiserad grupp kan läsare skanna etiketterna, identifiera en relevant kategori och sedan endast läsa den understödjande text de behöver. Detta minskar ansträngningen att packa upp ett stycke som innehåller flera likvärdigt viktiga idéer.

Det psykologiska värdet kommer från igenkänning, gruppering och konsekvens. En välbekant sköld kan signalera skydd, en klocka kan signalera tid och ett dokument kan signalera rapportering innan läsaren hunnit läsa klart etiketten. Etiketten eliminerar sedan tvetydighet. Upprepad geometri talar om för läsaren att objekten har samma redaktionella rang. Den signalen är användbar endast när innehållet verkligen är parallellt; ett kortrutnät kan inte förvandla orelaterade påståenden till en sammanhängande uppsättning.

Maskinextraherbarhet innebär att programvara kan isolera en innehållsenhet samtidigt som den behåller dess ämne och påstående. En strukturerad iconbox exponerar ett namngivet objekt med en koncis brödtext och en stabil position inom en valfri grupp. Hämtningssystem kan extrahera “Verifierade källor” tillsammans med dess förklaring snarare än att gissa vilken mening som hör till vilken visuell symbol. Själva ikontillgången bidrar lite till extraktion, så de synliga orden måste bära hela propositionen.

Ikonen måste fortfarande ha redaktionell innebörd. En godtycklig gnistra, raket eller abstrakt form skapar brus för människor och inga användbara semantiker för maskiner. “Ändamålsenlig men redundant” är ett giltigt tillgänglighetsläge: en ikon kan hjälpa seende läsare att känna igen en kategori medan den döljs för hjälpmedelsteknik eftersom den synliga etiketten redan ger dess innebörd. Följ skrivreglerna för element genom att först utforma hela idén och välja iconbox först i ett senare strukturellt steg. De elementspecifika gränserna här har företräde för ikonval, gruppering och tillgänglighetsmappning.

När det ska användas

Använd en iconbox när innehållet är en koncis, namngiven idé och en ikon från det godkända systemet kan representera den idén utan gissningsarbete. En grupp är lämplig när två till sex objekt svarar på samma underförstådda fråga med jämförbar djup: “Vad ingår?”, “Vilka säkerhetsåtgärder gäller?” eller “Vad producerar detta arbetsflöde?” Varje objekt bör vara begripligt när det kopieras som vanlig text.

Starka användningsområden inkluderar en funktionssammanfattning med ett resultat per objekt, en kravöversikt före detaljerade instruktioner, en uppsättning tjänsteprinciper eller en kompakt förklaring av arbetsflödesutdata. Ikonen är ett igenkänningshjälpmedel, inte beviset. Detaljer som filformat, svarstider, system som stöds eller äganderätt hör fortfarande hemma i etiketten och brödtexten.

Nästan-träffar är vanliga:

• Använd en vanlig punktlista när ikonen skulle vara samma bock på varje objekt. Upprepning förmedlar ingen kategoribetydelse.
• Använd en jämförelsetabell när objekt måste bedömas mot gemensamma kriterier. Separata iconboxes gör jämförelse mellan objekt svårare.
• Använd en steglista när ordning, slutförande eller beroende är viktigt. En rad iconboxes indikerar jämbördiga objekt, inte en sekvens.
• Använd en definitionsruta när en obekant term behöver en formell innebörd. En ikon förstärker inte en precis definition.
• Använd en varning eller notering när allvar och avbrott är huvuduppgifterna. En iconbox har neutral strukturell vikt.
• Använd fullständiga avsnitt när varje objekt behöver flera stycken, bevis, media eller underrubriker.

Använd inte iconboxes enbart för att få en texttung sida att se designad ut. Om författaren väljer ikonen efter att ha sökt efter något visuellt tilltalande snarare än semantiskt korrekt, behöver innehållet förmodligen inte detta element.

Var det ska placeras

Placera en fristående iconbox omedelbart efter det stycke den stöder. Placera en iconbox-grupp efter en rubrik och ett inledande stycke som namnger den gemensamma frågan. Detta sammanhang förklarar varför objekten hör ihop; gruppen ger sedan det kompakta svaret. Följ gruppen med detaljer, bevis eller nästa beslut snarare än att upprepa varje ruta i brödtext.

I en artikel bör den första gruppen visas först efter det direkta svaret eller den inledande definitionen. På en kommersiell sida kan en kapacitetsgrupp följa problem- och resultatbeskrivningen, men den får inte föregå värdeerbjudandet enbart för att skapa en visuell hjälte. I dokumentation, placera en kravgrupp före proceduren den styr, samtidigt som obligatorisk sekvens och acceptanskriterier hålls i vanliga instruktioner.

Placera inte en iconbox-grupp direkt bredvid ett annat kortrutnät, en jämförelsetabell, en logovägg, en statistikband eller en flerkolumnig uppmaning till handling. Intilliggande rutnät plattar till informationshierarkin och får redaktionella fakta att likna reklam. Infoga förklarande text eller en avsnittsgräns mellan dem. Sätt inte en iconbox mellan ett påstående och dess källa, mellan ett steg och dess förväntade resultat, inuti en tabellcell eller inuti en annan iconbox. Placera aldrig två grupper rygg mot rygg.

Anatomi

En iconbox innehåller tre författade regioner och en kontextuell relation. Skärmdumpen märker betydelsebärande regioner snarare än pixelvärden så att kontraktet överlever visuell omdesign.

1. Ikonregion: Använder en godkänd ikon vars koncept matchar objektet. Den ersätter aldrig synliga ord.
2. Kort etikett: Namnger funktionen, kravet, resultatet eller kategorin med konkret språk.
3. Textkropp: Förklarar konsekvensen, omfattningen eller beviset i ett kompakt stycke.
4. Valfri destination: Ger ett beskrivande nästa steg när den länkade varianten används.
5. Gruppkontext: En föregående rubrik eller tillgänglig gruppetikett anger frågan som alla syskon-iconboxes besvarar.

Kantlinje, bakgrund, hörnradie, ikonstorlek, färg, rutnätskolumner och brytpunkter tillhör renderaren. Författare väljer semantiskt innehåll, ikonidentitet, källordning och tillgänglighetsläge.

Designexempel

Elementet stöder fyra presentationsvarianter. Alla bevarar samma ikon-etikett-kropp-hierarki och samma källordning.

Standard: Standardkortet, fristående eller i grupp. Använd när brödtexten behöver 25–60 ord för att förklara ett objekt.

Kompakt: Använder en brödtext på en mening med 12–30 ord. Den är lämplig för välbekanta koncept, inte för att komprimera en nyanserad kvalifikation.

Länkad: Lägger till en destination. Föredra en synlig beskrivande länk. Om hela kortet är interaktivt måste renderaren tillhandahålla ett enda länkmål och ett tydligt fokustillstånd.

Status: Förmedlar ett tillstånd som tillgänglig, begränsad, godkänd eller väntande. Statusordet måste vara synligt; varken färg eller ikonform får vara den enda signalen.

Smal vyport: Alla grupper blir en kolumn i källordning. Renderaren får inte omordna rutor för att balansera deras höjder.

Tillgänglighetsläge är separat från presentationsvariant. En redundant ikon är dold för hjälpmedelsteknik eftersom dess etikett bär samma innebörd. En genuint informativ ikon får en programmerbar textekvivalent, men författare bör normalt lägga till den informationen i den synliga etiketten istället för att underhålla ett ikon-endast-faktum.

Parametrar

Kontraktet håller författad innebörd separerad från presentation. Gränser gäller för alla varianter om inte en striktare gräns anges.

icon måste lösas genom det godkända ikonregistret; författare kan inte tillhandahålla godtycklig SVG, emoji, bild-URL:er eller ikon-teckensnittsklassnamn. Begränsad Markdown tillåter betoning, inline-kod och en inline-länk. Den utesluter nästlade rubriker, listor, tabeller, media, formulär, knappar, accordions och andra komponenter. När den första brödtextrubriken tillhandahåller label, tar adaptern bort den rubriken från brödtexten och renderar den på korrekt sidrelativ nivå.

Syntax och kodexempel

Varje notation mappar till samma ikon, etikett, brödtext, variant och tillgänglighetsläge. Ikonnyckeln är semantisk och portabel; varje plattform mappar shield-check till sin godkända lokala tillgång.

Portabel Markdown-direktiv

:::iconbox{icon="shield-check" iconMode="redundant" variant="standard"}
### Verifierade källor

Varje faktapåstående länkar till en källa som en granskare kan inspektera, så att bevis förblir synliga under skrivande, godkännande och senare uppdateringar.
:::

Den första rubriken blir label; det återstående stycket blir content. Ikonen är redundant eftersom “Verifierade källor” ger den fullständiga innebörden i synlig text.

Hugo shortcode

{{< iconbox icon="shield-check" label="Verifierade källor" iconMode="redundant" variant="standard" >}}
Varje faktapåstående länkar till en källa som en granskare kan inspektera, så att bevis förblir synliga under skrivande, godkännande och senare uppdateringar.
{{< /iconbox >}}

Adaptern använder endast namngivna parametrar. Den måste avvisa en okänd ikonnyckel eller variant snarare än att tyst visa en reservation som kan ändra innebörden.

WordPress-block

<!-- wp:amicited/iconbox {"icon":"shield-check","label":"Verifierade källor","iconMode":"redundant","variant":"standard"} -->
<p>Varje faktapåstående länkar till en källa som en granskare kan inspektera, så att bevis förblir synliga under skrivande, godkännande och senare uppdateringar.</p>
<!-- /wp:amicited/iconbox -->

Redigeraren bör exponera en sökbar väljare för godkända ikoner, inte ett fritextfält för tillgångar. Dess tillgängliga-namn-förhandsvisning bör visa om ikonen är dold eller meddelad.

Exempel

Bra exempel

Detta fungerar eftersom dokumentsymbolen matchar rapportkonceptet, etiketten namnger en konkret kapacitet och brödtexten förklarar utdata och dess praktiska konsekvens. Den synliga texten är komplett utan symbolen, så symbolen kan döljas för hjälpmedelsteknik.

Dåligt exempel

Detta misslyckas på alla nivåer. Raketen är dekorativ snarare än en korrekt kategorimarkör, etiketten innehåller ingen specifik kapacitet och brödtexten ger ingen mekanism, gräns eller verifierbart resultat. Emojin kan också meddelas oförutsägbart. Ersätt blocket med ett konkret påstående – vad blir snabbare, genom vilken mekanism, under vilka förhållanden – eller ta bort det.

Schema-markup och tillgänglighet

Iconbox har ingen dedikerad Schema.org-typ. Dess etikett och brödtext förblir innehåll i den omslutande Article, TechArticle, WebPage, Product eller annan sidnivåenhet när den markeringen annars är motiverad. En visuell grupp är inte automatiskt en ItemList; använd listmarkering endast när uppsättningen är komplett eller ordnad i innehållsmodellen. En status-iconbox motiverar inte egenskaperna Review, Rating eller tillgänglighet utan de nödvändiga underliggande data.

Rendera en icke-interaktiv iconbox som en section när den är en del av huvudargumentet eller som en aside när den är kompletterande. Ge den ett tillgängligt namn genom den synliga etiketten. Använd en verklig rubrik på rätt nivå; välj inte h3 enbart för att dess standardteckenstorlek ser rätt ut. Upprepade syskon kan sitta inuti en lista när gruppen verkligen är en lista, med varje iconbox i ett listobjekt.

De flesta ikoner bör vara inline-SVG med aria-hidden="true" och focusable="false", eftersom den synliga etiketten upprepar deras innebörd. Detta gör dem inte redaktionellt dekorativa: de hjälper fortfarande visuell igenkänning, men att meddela samma koncept två gånger skapar brus. Om en ikon förmedlar information som saknas i etiketten, tillhandahåll en tillgänglig textekvivalent genom komponentens iconText-mappning. Ännu bättre, revidera den synliga etiketten så att alla läsare får faktat.

Förlita dig aldrig enbart på färg, position, rörelse eller ikonform. En grön bock behöver synlig text som “Godkänd”; ett lås behöver “Begränsad” eller det exakta åtkomstvillkoret. Ikoner kräver tillräcklig kontrast mot sin bakgrund, men renderaren äger färgtoken. Dekorativa utsmyckningar som inte förmedlar något bör tas bort, inte tilldelas utförlig alt-text. Undvik alt="icon", filnamn, Unicode-glyfnamn och dubbletttext som “Sköld, Verifierade källor.”

För den länkade varianten har en iconbox en destination. Det interaktiva namnet måste förmedla den destinationen, tangentbordsfokus måste vara synligt och det klickbara området får inte innehålla en annan länk eller knapp. Hovring kan inte avslöja essentiell text. Läs- och tangentbordsordningen måste matcha källordningen vid varje visningsportsbredd.

Skrivregler

Skriv etiketten innan du väljer ikon. Etiketten bör vara en konkret substantivfras eller ett kort resultat: “Rollbaserad åtkomst”, “Veckovis export” eller “Mänsklig granskning.” Håll syskonetiketter grammatiskt parallella. Undvik generiska påståenden som “Kraftfull”, “Sömlös”, “Innovativ” och “Bäst i klassen”, eftersom de varken namnger en kapacitet eller ett beslut.

Använd 2–6 ord och högst 55 tecken för etiketten. Använd ett brödtextstycke på 12–60 ord; den kompakta varianten bör hålla sig inom 12–30. Inled med den specifika mekanismen, omfattningen eller resultatet. Håll en lugn, faktabaserad ton. Om en kvalifikation ändrar löftet, placera den i samma ruta snarare än i avlägset finstilt.

Använd två till sex rutor per grupp. Ge varje objekt jämförbart djup och låt dem besvara samma fråga. Ordna efter läsarprioritet, arbetsflödeslogik eller en angiven kategori – inte efter vilken ikon som ser bäst ut. Använd inte samma ikon för olika betydelser inom en grupp, och använd inte flera visuella stilar eller ikonfamiljer tillsammans.

Placera aldrig dessa inuti en iconbox:

• En lång funktionsförteckning, flerstegsprocedure, nästlad punktlista, tabell, formulär, vittnesmål, pris eller juridisk ansvarsfriskrivning.
• En ikon-endast-etikett, en oförklarad akronym eller en status uttryckt endast genom färg.
• Mer än en länk, konkurrerande uppmaningar till handling eller en knapp inuti en helkortslänk.
• En skärmdump, video, diagram, logotyp, fotografi eller en annan iconbox.
• Bevis som gäller för flera rutor men visas i endast en, vilket får gruppen att se ojämn eller missvisande ut.

Om innehållet överskrider dessa gränser, uppgradera det till ett vanligt avsnitt. Om varje objekt behöver samma bock, ta bort ikonerna och använd en lista. Om etiketterna inte är begripliga utan sina bilder, skriv om etiketterna innan publicering.

Inläggstyper som använder det

Fältet postTypes i frontmatter är källan för denna tabell. Inkludering innebär att elementet är tillgängligt när innehållet utgör en genuin grupp av jämbördiga objekt, inte att varje sida av den typen bör innehålla iconboxes.

QA-checklista

• Ändamålsenlig ikon: Varje ikon har en uppenbar relation till sin etikett; att ta bort den skulle minska visuell igenkänning, inte faktisk innebörd.
• Komplett synlig text: Etiketten och brödtexten förmedlar hela propositionen utan att förlita sig på ikon, färg eller position.
• Korrekt tillgänglighetsläge: Redundanta ikoner är dolda; informativa ikoner har en koncis textekvivalent och en dokumenterad anledning.
• Äkta jämbördig grupp: Syskon svarar på samma fråga, har jämförbart djup och använder parallell etikettgrammatik.
• Säkert antal: En grupp innehåller två till sex objekt; större uppsättningar kategoriseras eller flyttas till en mer lämplig struktur.
• Precis text: Etiketter namnger konkreta kapaciteter, krav, tillstånd eller resultat; brödtexter ger en mekanism, omfattning eller konsekvens.
• Giltig ikonkälla: Varje ikonnyckel finns i det godkända registret och ingen emoji, godtycklig SVG, bild-URL eller ikon-teckensnittsklassnamn är författad.
• Sund placering: Gruppen följer sin inramande kontext och separerar inte påståenden från källor, steg från resultat eller varningar från berörda åtgärder.
• Säkra grannar: Inget kortrutnät, tabell, logovägg, statistikband eller flerkolumnig CTA sitter direkt bredvid gruppen.
• Tillgänglig struktur: Rubriknivåer följer dokumentet, kontrasten är tillräcklig, status har synlig text och källordningen matchar läsordningen.
• Interaktionsbegränsning: En länkad iconbox har en destination, ett beskrivande namn, ett synligt fokustillstånd och ingen nästlad interaktiv kontroll.
• Notationsparitet: Portabel Markdown, Hugo och WordPress bevarar samma ikonnyckel, etikett, innehåll, variant och tillgänglighetsbeteende.
• Schemabegränsning: Komponenten lägger till inget fristående schema och härleder inte ItemList- eller statuseegenskaper från utseende.
• Responsiv verifiering: Vid smala bredder staplas rutor i källordning utan klippning, horisontell rullning eller dold essentiell text.

Avvisa elementet om dess ikon är godtycklig, dess etikett är vag eller dess synliga text är beroende av symbolen. Det är innehållsmodellbrister; att ändra avstånd, färg eller illustrationsstil kan inte reparera dem.

FAQ

Frontmatter-FAQ:n täcker gruppstorlek, alternativ text, länkade kort, emoji och schemabeteende. Att hålla de godkända svaren i strukturerad frontmatter gör att akademilayouten kan rendera dem konsekvent utan att duplicera samma frågor i artikelns brödtext.