WCAG 2.4.6: Rubriker och etiketter

Vad den här regeln innebär

WCAG 2.4.6 säger: "Headings and labels describe topic or purpose." I grunden kräver detta kriterium att varje rubrik (<h1> till <h6>) eller etikett (<label>, aria-label, aria-labelledby) som visas på en sida måste vara tillräckligt beskrivande för att förmedla ämnet för innehållet den introducerar eller syftet med den kontroll den identifierar.

Detta kriterium kräver inte att rubriker eller etiketter måste finnas — den skyldigheten täcks av andra framgångskriterier som 1.3.1 (Info and Relationships) och 2.4.2 (Page Titled). Vad 2.4.6 reglerar är kvaliteten på rubriker och etiketter som redan finns: när du har dem måste de vara meningsfulla. En rubrik som lyder "Section 1" eller en etikett som lyder "Field" säger ingenting användbart för användare om innehållet som följer eller inmatningen den beskriver. Jämför detta med "Your Shipping Address" eller "Monthly Budget Summary", som omedelbart orienterar användare.

Etiketter i detta sammanhang inkluderar inte bara HTML-elementet <label> som är associerat med formulärkontroller utan också alla programmässiga märkningsmekanismer: aria-label, aria-labelledby, attributet title när det används som ett tillgängligt namn, och elementet legend för fieldsets. Alla dessa som exponeras för hjälpmedel måste tydligt beskriva syftet med den associerade kontrollen.

Ett fel uppstår när en rubrik eller etikett är så generisk, tvetydig eller oinformativ att en användare inte kan avgöra vad avsnittet eller kontrollen handlar om utan att läsa det omgivande sammanhanget. Till exempel misslyckas ett formulär med tre inmatningsfält som alla är märkta "Enter here" med detta kriterium, liksom en sida som använder upprepade rubriker som "More Info" för varje underavsnitt. Lika mycket är en rubrik som tekniskt sett finns i DOM:en men som fullständigt vilseleder användaren — till exempel att märka ett kontaktformulärsavsnitt med en rubrik som säger "News and Updates" — också ett fel.

Det finns ett viktigt officiellt undantag: WCAG 2.4.6 gäller endast när rubriker och etiketter används. Om en sida legitimt saknar rubriker (till exempel ett mycket kort dokument med ett enda ämne) eller en formulärkontroll som saknar synlig eller programmatisk etikett (vilket skulle fångas av 1.3.1 istället), gäller inte 2.4.6 i sig. Kriteriets räckvidd handlar strikt om beskrivande kvalitet, inte om närvaro.

Varför det är viktigt

Beskrivande rubriker och etiketter gynnar en anmärkningsvärt bred publik, men påverkan är mest påtaglig för personer med funktionsnedsättning som är beroende av struktur för att navigera.

Skärmläsaranvändare — främst personer som är blinda eller har svår synnedsättning — navigerar rutinmässigt på sidor genom att hoppa från rubrik till rubrik med hjälp av snabbkommandon (H i NVDA/JAWS, Rotor i VoiceOver). Om rubriker är vaga eller vilseledande bryter denna navigationsstrategi helt samman. En blind användare som landar på en portal för offentliga tjänster som använder "Section A", "Section B" och "Section C" som rubriker måste läsa varje ord i varje avsnitt sekventiellt för att hitta det de behöver, vilket eliminerar den effektivitetsfördel som rubriker är tänkta att ge. Enligt Världshälsoorganisationen har cirka 2,2 miljarder människor världen över någon form av synnedsättning, vilket gör detta till en betydande global population.

Personer med kognitiva funktionsnedsättningar, inklusive de med uppmärksamhetsstörningar, minnesnedsättningar eller inlärningssvårigheter, är i hög grad beroende av tydliga, förutsägbara etiketter och rubriker för att minska kognitiv belastning. När ett formulärfält endast är märkt "Name" på en sida som samlar in både ett företagsnamn och en kontaktpersons namn, kanske en kognitivt nedsatt användare inte kan lösa tvetydigheten enbart utifrån sammanhanget, vilket leder till fel och frustration.

Användare med motoriska funktionsnedsättningar som är beroende av switch-styrning, ögonspårningsprogramvara eller röststyrning (såsom Dragon NaturallySpeaking) gynnas av beskrivande etiketter eftersom de kan aktivera ett specifikt formulärfält genom att uttala dess etikettnamn. Om flera fält delar samma etiketttext kan röststyrningsprogramvara inte skilja dem åt, vilket tvingar användaren till ytterligare steg som är fysiskt ansträngande.

Överväg ett scenario i verkligheten: en person som använder en skärmläsare besöker en e-handels kassasida. Sidan innehåller tre adressavsnitt — faktureringsadress, leveransadress och en adress för presentmottagare — men varje avsnitt använder samma generiska rubrik "Address" och varje uppsättning inmatningsfält använder samma etiketter: "Street", "City", "Postal Code". Utan unika, beskrivande rubriker och etiketter kan skärmläsaranvändaren inte avgöra vilken grupp av fält de fyller i, vilket dramatiskt ökar risken för beställningsfel och sannolikheten att de överger köpet helt.

Utöver tillgänglighet ger beskrivande rubriker ett betydande SEO-värde. Sökmotorer använder rubrikstruktur som en stark signal för att förstå sidinnehåll och matcha det mot användarfrågor. Meningsfulla rubriker hjälper sökmotorer att indexera sidor mer exakt och kan förbättra klickfrekvensen i sökresultat där rubriker ofta visas som förhandsvisningstext. Detta anpassar affärsincitament direkt till tillgänglighetskrav.

Relaterade Axe-core-regler

WCAG 2.4.6 kräver manuell testning eftersom inget automatiserat verktyg pålitligt kan avgöra om en rubrik eller etikett är descriptive. Beskrivande kvalitet är en semantisk, kontextuell bedömning — en rubrik som lyder "Products" kan vara helt beskrivande på en sida och fullständigt tvetydig på en annan. Automatiska skannrar kan upptäcka förekomst eller frånvaro av rubriker och etiketter, men de kan inte bedöma om texten i dessa rubriker och etiketter är meningsfull utan mänsklig tolkning.

• Manuell granskning av rubriktext: Axe-core flaggar saknade rubriker eller felaktig nästling (via regler som heading-order), men det kan inte flagga en rubrik som säger "Click Here" eller "Untitled Section" som en 2.4.6-överträdelse. En mänsklig testare måste läsa varje rubrik isolerat — så som en skärmläsaranvändare skulle stöta på den när hen navigerar via rubriker — och bedöma om den förmedlar ämnet för innehållet nedanför.
• Manuell granskning av formuläretiketter: Axe-cores regel label verifierar att varje formulärinmatning har en associerad etikett, men den utvärderar inte om etikettens text är beskrivande. Ett label-element som endast innehåller ett platshållartecken, ett ikon-tecken eller ett generiskt ord som "Input" kommer att klara automatiska kontroller men ändå misslyckas med 2.4.6. Manuell granskning kräver att man läser varje etikett och bekräftar att den korrekt beskriver syftet med den associerade kontrollen.
• Manuell granskning av aria-label- och aria-labelledby-värden: På samma sätt bekräftar axe-core-familjen av regler aria-label-is-accessible att ARIA-etiketter är syntaktiskt giltiga och att refererade element finns, men de bedömer inte om etikettexten är semantiskt meningsfull eller beskrivande för kontrollens syfte.
• Upptäckt av duplicerade etiketter: Även om vissa verktyg kan flagga duplicerad etiketttext på en sida, kan de inte avgöra om dupliceringen är avsiktlig och lämplig (två fält med samma syfte på olika rader i en tabell) eller ett verkligt misslyckande i beskrivande kvalitet där flera olika kontroller delar en tvetydig etikett. Manuell granskning krävs för att göra denna åtskillnad.

Hur man testar

1. Kör en automatiserad skanning först: Använd axe DevTools (webbläsartillägg) eller Lighthouse i Chrome DevTools för att identifiera strukturella rubrik- eller etikettproblem som automatiserade verktyg kan fånga, såsom saknade etiketter, hoppade rubriknivåer eller tomma rubrikelement. Även om dessa inte är direkta 2.4.6-överträdelser indikerar de områden som bör granskas mer noggrant under manuell granskning. Notera varje rubrik och märkt kontroll som flaggas eller identifieras i rapporten.
2. Extrahera rubriklistan: Använd ett webbläsartillägg som HeadingsMap (tillgängligt för Firefox och Chrome) eller WAVE-verktyget för att generera en platt lista över alla rubriker på sidan, rensade från sitt omgivande innehåll. Läs igenom denna lista som om den vore en innehållsförteckning. Fråga: skulle en användare kunna förstå strukturen och huvudämnena på denna sida enbart utifrån rubrikerna, utan att läsa brödtexten? Om någon rubrik är tvetydig eller oinformativ i sig är det ett 2.4.6-fel.
3. Testa med NVDA och Firefox: Öppna sidan och tryck på H för att navigera rubrik för rubrik. Lyssna på varje rubrikuppläsning och bedöm om den beskriver innehållet som följer. Tryck sedan på F för att cykla genom formulärfält och lyssna på etiketten som läses upp för varje inmatning. Notera varje rubrik eller etikett som inte tydligt beskriver sitt ämne eller syfte.
4. Testa med VoiceOver och Safari (macOS/iOS): Använd Web Rotor (VO+U) för att öppna rubriklistan och listan över formulärkontroller. Navigera genom varje lista och utvärdera varje objekts beskrivande kvalitet oberoende av sidans sammanhang. På iOS använder du en svepning med tre fingrar för att navigera via rubriker i Rotor.
5. Testa med JAWS och Chrome: Tryck på H för att navigera rubriker och använd Forms Mode (F) för att flytta mellan formulärkontroller. Använd JAWS List of Headings-dialogen (Insert+F6) för att visa alla rubriker i en platt lista, vilket återskapar hur en skärmläsaranvändare skulle skanna sidstrukturen.
6. Utvärdera formuläretiketter isolerat: För varje formulärkontroll, täck över eller ignorera allt omgivande sammanhang och läs endast den programmatiska etiketten (synlig etikettext, aria-label eller aria-labelledby-mål). Bekräfta att etiketten i sig är tillräcklig för att förstå vilken information som ska anges eller vilken åtgärd kontrollen utför.
7. Kontrollera duplicerad rubrik- eller etiketttext: Sök på sidan efter upprepad rubriktext (t.ex. flera "Read More"-rubriker eller flera "Learn More"-avsnitt). Om samma text används för rubriker eller etiketter som hänvisar till olika ämnen eller kontroller är detta ett misslyckande med 2.4.6.

Hur man åtgärdar

Generiska avsnittsrubriker — felaktigt

<section>
  <h2>Section 1</h2>
  <p>We offer a range of enterprise software solutions tailored for logistics companies.</p>
</section>
<section>
  <h2>Section 2</h2>
  <p>Our pricing is flexible and based on the number of active users.</p>
</section>

Generiska avsnittsrubriker — korrekt

<!-- Each heading now describes the actual topic of its section,
     enabling screen reader users to jump directly to what they need -->
<section>
  <h2>Enterprise Logistics Software Solutions</h2>
  <p>We offer a range of enterprise software solutions tailored for logistics companies.</p>
</section>
<section>
  <h2>Flexible User-Based Pricing</h2>
  <p>Our pricing is flexible and based on the number of active users.</p>
</section>

Tvetydiga formuläretiketter — felaktigt

<!-- A checkout form with two address blocks, both using identical labels -->
<fieldset>
  <legend>Address</legend>
  <label for='street1'>Street</label>
  <input type='text' id='street1'>
  <label for='city1'>City</label>
  <input type='text' id='city1'>
</fieldset>
<fieldset>
  <legend>Address</legend>
  <label for='street2'>Street</label>
  <input type='text' id='street2'>
  <label for='city2'>City</label>
  <input type='text' id='city2'>
</fieldset>

Tvetydiga formuläretiketter — korrekt

<!-- Legends now distinguish the two fieldsets; labels remain short because
     the legend provides the distinguishing context programmatically -->
<fieldset>
  <legend>Billing Address</legend>
  <label for='billing-street'>Street</label>
  <input type='text' id='billing-street'>
  <label for='billing-city'>City</label>
  <input type='text' id='billing-city'>
</fieldset>
<fieldset>
  <legend>Shipping Address</legend>
  <label for='shipping-street'>Street</label>
  <input type='text' id='shipping-street'>
  <label for='shipping-city'>City</label>
  <input type='text' id='shipping-city'>
</fieldset>

Icke-beskrivande ARIA-etikett på ikonknapp — felaktigt

<!-- aria-label provides a label but it does not describe the button's purpose -->
<button aria-label='button'>
  <svg aria-hidden='true' focusable='false'><!-- search icon --></svg>
</button>

Icke-beskrivande ARIA-etikett på ikonknapp — korrekt

<!-- aria-label now clearly communicates what activating the button will do -->
<button aria-label='Search products'>
  <svg aria-hidden='true' focusable='false'><!-- search icon --></svg>
</button>

Upprepade "Read More"-rubriker eller länkar — felaktigt

<article>
  <h3>Latest News</h3>
  <p>Istanbul metro expands to three new districts...</p>
</article>
<article>
  <h3>Latest News</h3>
  <p>New regulations affect e-commerce platforms...</p>
</article>

Upprepade "Read More"-rubriker eller länkar — korrekt

<!-- Each article has a unique, descriptive heading that identifies its topic -->
<article>
  <h3>Istanbul Metro Expands to Three New Districts</h3>
  <p>Istanbul metro expands to three new districts...</p>
</article>
<article>
  <h3>New Regulations Affect E-Commerce Platforms</h3>
  <p>New regulations affect e-commerce platforms...</p>
</article>

Vanliga misstag

• Att använda positions- eller ordningsrubriker som "Step 1", "Step 2", "Section A" utan någon beskrivande text: dessa rubriker talar bara om för användaren var de befinner sig i en sekvens, inte vad avsnittet handlar om. Kombinera alltid sekvensindikatorer med en beskrivande nominalfras, t.ex. "Step 2: Verify Your Email Address."
• Att ge alla kort- eller artikelkomponenter på en listingsida samma rubriktext (t.ex. att varje produktkort har en <h3> som bara säger "Product"): varje kortrubrik måste unikt identifiera just den produkten, blogginlägget eller objektet.
• Att använda platshållartext som tillgänglig etikett för ett formulärfält (att förlita sig på attributet placeholder istället för ett <label>-element eller aria-label): platshållare försvinner vid inmatning och läses inte pålitligt upp av alla skärmläsare som tillgängliga namn. Även när en platshållare finns krävs en separat beskrivande etikett.
• Att skriva en aria-label som bara upprepar elementtypen snarare än dess syfte, såsom aria-label='input' på ett textfält eller aria-label='button' på en knapp: etiketten måste beskriva vad kontrollen gör eller vilket värde den samlar in, inte vilken typ av element den är.
• Att använda tooltip-text eller title-attribut som den enda etiketten för en formulärkontroll och anta att detta uppfyller 2.4.6: etiketter baserade på title är ofta otillgängliga för tangentbordsanvändare och läses inte konsekvent upp av skärmläsare. Förlita dig istället på synliga <label>-element eller aria-label.
• Att märka sökfält endast med "Search" på en sida där flera sökområden finns (t.ex. en webbplatsövergripande sökning och en sökning i en datatabell): när två kontroller utför olika sökningar måste varje etikett ange omfattningen, såsom "Search all products" och "Search within order history."
• Att ge en modal dialogs rubrik samma rubriktext som sidans huvudrubrik: modalrubriker bör beskriva den specifika uppgiften eller innehållet i dialogen (t.ex. "Confirm Your Cancellation") snarare än att ärva sidtiteln, vilket skulle vara förvirrande för skärmläsaranvändare som navigerar i dialogen.
• Att utelämna en beskrivande <legend> för grupper av radioknappar eller kryssrutor samtidigt som man tillhandahåller individuella alternativetiketter: <legend> ger väsentlig kontext som gör varje individuell etikett meningsfull. "Yes" och "No" som fristående alternativetiketter är oinformativa utan en legend som "Do you agree to the terms and conditions?"
• Att trunkera rubriktext i DOM:en av visuella designskäl (t.ex. en rubrik som bara innehåller en ikon eller ett enda ord eftersom hela texten finns i angränsande visuella element): den programmatiska rubriken måste vara fullt beskrivande eftersom skärmläsaranvändare hör den utan att se den omgivande visuella layouten.
• Att anta att eftersom en etikett är synlig för seende användare är den därför tillräckligt beskrivande för alla användare: en etikett som är beroende av rumslig position (t.ex. en kolumnrubrik i ett anpassat rutnät där etiketts betydelse beror på att man ser dess relation till omgivande celler) kan vara visuellt tydlig men misslyckas med att förmedla samma information programmatiskt. Verifiera alltid att det tillgängliga namnet i sig är tillräckligt.

Relation till Turkiets tillgänglighetsreglering

Turkiets Presidential Circular 2025/10, publicerad i Official Gazette nr 32933 den 21 juni 2025, fastställer obligatoriska krav på digital tillgänglighet för ett brett spektrum av offentliga och privata aktörer som är verksamma i Turkiet. Cirkuläret hänvisar uttryckligen till WCAG 2.1 nivå AA som den tekniska standarden för överensstämmelse, och nivå AA-krav enligt WCAG 2.2 — som är bakåtkompatibel med WCAG 2.1 på AA-nivå — uppmuntras starkt och krävs för aktörer som söker det officiella Accessibility Logo (Erişilebilirlik Logosu) som utfärdas av Ministry of Family and Social Services (Aile ve Sosyal Hizmetler Bakanlığı).

WCAG 2.4.6 är ett kriterium på nivå AA, vilket innebär att det faller direkt inom ramen för vad berörda aktörer måste hantera för att uppnå full överensstämmelse. Följande aktörstyper omfattas av Presidential Circular: offentliga institutioner och statliga myndigheter; e-handelsplattformar; banker och finansiella institutioner; sjukhus och vårdgivare; teleoperatörer med 200,000 eller fler abonnenter; resebyråer; privata transportföretag; och privatskolor som auktoriserats av Ministry of National Education (Millî Eğitim Bakanlığı).

För dessa aktörer innebär underlåtenhet att tillhandahålla beskrivande rubriker och etiketter en konkret regulatorisk risk. En myndighetsportal med vaga avsnittsrubriker hindrar medborgare med funktionsnedsättning från att få tillgång till offentliga tjänster, vilket står i direkt konflikt med cirkulärets uttalade mål att säkerställa lika tillgång. En e-handelssajt med tvetydiga formuläretiketter i sin kassaflöde kan hindra användare med syn- eller kognitiva funktionsnedsättningar från att slutföra köp, vilket utgör ett hinder för ekonomiskt deltagande som cirkuläret är utformat för att eliminera.

Aktörer som söker Erişilebilirlik Logosu måste visa överensstämmelse genom en tillgänglighetsrevision, och 2.4.6 är ett av kriterierna som revisorer kommer att utvärdera manuellt. Eftersom detta kriterium kräver mänsklig bedömning — automatiserade verktyg kan inte bedöma beskrivande kvalitet — bör organisationer inkludera strukturerad manuell granskning av alla rubriker och formuläretiketter som en standarddel av sin tillgänglighetsrevisionsprocess. Att bygga in denna granskning i innehållshanteringsarbetsflöden och designsystem, snarare än att behandla den som en engångsuppgift vid revision, är den mest effektiva strategin för att upprätthålla löpande efterlevnad när innehåll förändras över tid.