WCAG 1.3.1: Information och relationer

Vad den här regeln innebär

WCAG 1.3.1 — Info and Relationships är ett kriterium på nivå A under principen Uppfattningsbar (Perceivable). Dess kärnkrav är enkelt men långtgående: all information eller alla relationer som kommuniceras visuellt måste också uttryckas på ett sätt som hjälpmedelsteknik kan upptäcka och förmedla till användare. Om din design använder visuella ledtrådar — indrag för att antyda en lista, fet stil för att markera ett obligatoriskt fält, färg för att indikera ett fel eller storlek för att ange en rubrik — måste samma semantik finnas i den underliggande koden.

Kriteriet gäller tre kategorier av betydelse som webbinnehåll regelbundet förmedlar genom presentation:

• Information — fakta eller data som kommuniceras på sidan, till exempel vilka formulärfält som är obligatoriska eller vilka tabellceller som delar en relation.
• Struktur — innehållets organisatoriska schema, såsom rubrikhierarkier, ordnade eller oordnade listor och datatabeller.
• Relationer — kopplingar mellan element, såsom en etikett och dess inmatningsfält, en tabellrubrik och dess dataceller eller en term och dess definition.

En sida klarar 1.3.1 när varje bit av strukturell eller relationell information som är tillgänglig för en seende användare antingen är kodad i giltig, semantisk HTML eller exponerad genom en korrekt ARIA-roll, -egenskap eller -tillstånd som hjälpmedelsteknik kan tolka. En sida underkänns när visuell struktur endast finns i CSS eller bilder, eller när ARIA-markup motsäger eller saknas i den DOM-struktur som presenteras.

Officiella undantag är minimala. Kriteriet kräver inte att all visuell dekoration bär semantisk betydelse — rent estetisk formatering som en dekorativ ram eller bakgrundsfärg behöver ingen programmatisk motsvarighet. Men all formatering som en användare rimligen skulle tolka som meningsbärande (obligatoriska asterisker, fetstilta termer i en ordlista, numrerade steg) måste ha ett motsvarande programmatiskt uttryck.

Varför det är viktigt

Information och relationer ligger till grund för nästan varje interaktion en användare har med en webbsida. När den strukturen är inlåst enbart i visuell presentation utestängs en betydande del av befolkningen i praktiken från att förstå innehållet över huvud taget.

Skärmläsaranvändare — vanligtvis blinda eller personer med nedsatt syn — navigerar på sidor genom att fråga av tillgänglighetsträdet, som byggs upp från semantisk HTML och ARIA. När en utvecklare använder ett <div> som är stylat att se ut som en rubrik i stället för ett faktiskt <h2>, kommer en skärmläsaranvändare som hoppar mellan rubriker med H-tangenten att hoppa över den helt. De kanske aldrig hittar avsnittet den introducerar. Enligt Världshälsoorganisationen lever cirka 2,2 miljarder människor världen över med någon form av synnedsättning, och tiotals miljoner förlitar sig dagligen på skärmläsare.

Användare med kognitiva funktionsnedsättningar gynnas minst lika mycket av tydlig struktur. Korrekt nästlade rubriker, meningsfull listmarkup och etiketterade formulärkontroller minskar kognitiv belastning genom att ge förutsägbara mönster. En skärmläsare som meddelar "rubrik nivå 2, Produkter" följt av "rubrik nivå 3, Laptops" ger en kognitiv karta över sidan. En platt vägg av stylad text utan strukturella ankare är desorienterande för alla, men särskilt för användare med uppmärksamhets- eller minnessvårigheter.

Motoriskt funktionsnedsatta användare som förlitar sig på tangentbordsnavigering, switch-styrning eller röststyrningsprogramvara är också beroende av programmatisk struktur. Röststyrningsprogramvara som Dragon NaturallySpeaking genererar klickbara mål från tillgängliga namn härledda från etiketter och roller — formulärfält utan associerade etiketter kan helt enkelt inte pålitligt riktas med röstkommandon.

Överväg ett konkret scenario: en patientportal för ett sjukhus visar en tabell över kommande besök. Tabellen använder visuell justering och bakgrundsfärg för att koppla datum till läkare, men <th>-elementen saknar scope-attribut och datacellerna refererar inte till rubriker. En blind användare med skärmläsare hör isolerade cellvärden — "9:00 AM", "Dr. Ayşe Kaya", "Cardiology" — utan möjlighet att veta vilket värde som hör till vilken kolumn. De kan misstolka sin besökstid eller dyka upp på fel avdelning. Korrekt användning av scope='col' på rubriker och headers-attribut på celler skulle ha gjort relationerna hörbara.

Utöver tillgänglighet har strukturell HTML betydande SEO-värde. Sökmotorers crawlers använder rubrikhierarkier för att förstå sidans ämnen, listmarkup för att identifiera uppräknat innehåll och etikettassociationer för att förstå formulärens syfte. En sida som klarar 1.3.1 är nästan alltid en sida som sökmotorer kan tolka och ranka mer korrekt.

Relaterade Axe-core-regler

Följande axe-core-regler motsvarar direkt överträdelser av WCAG 1.3.1. Varje regel riktar in sig på en specifik aspekt av programmatisk struktur eller relation:

• aria-required-children — Kontrollerar att element med vissa ARIA-roller innehåller de obligatoriska underordnade rollerna. Till exempel måste ett role='list' innehålla barn med role='listitem'. Utan korrekt barnstruktur bryts relationen mellan en behållare och dess objekt för hjälpmedelsteknik.
• aria-required-parent — Motsatsen till ovan: kontrollerar att element med roller som kräver ett specifikt överordnat sammanhang faktiskt har det överordnade elementet. Ett role='listitem' som inte finns inuti ett role='list' eller <ul>/<ol> flaggas eftersom relationssammanhanget saknas.
• aria-roles — Validerar att alla värden i role-attributet är giltiga ARIA-roller. En ogiltig eller felstavad roll (t.ex. role='heading' i stället för att använda ett rubrikelement, eller en helt påhittad roll) innebär att hjälpmedelsteknik inte får någon användbar information och kan ignorera elementet helt.
• definition-list — Verifierar att <dl>-element endast innehåller tillåtna barn: <dt>, <dd>, <div>, <script> och <template>. Att infoga andra element som <p> direkt inuti ett <dl> ogiltigförklarar strukturens term–definitions-relation.
• dlitem — Kontrollerar att <dt>- och <dd>-element endast används inuti <dl>-element. Att använda dessa element utanför deras obligatoriska överordnade sammanhang förstör den semantiska betydelsen av term–definitions-paret.
• heading-order — Flaggar rubriknivåer som hoppas över i dokumentets disposition (t.ex. att hoppa från <h2> till <h4>). Även om det inte alltid är ett strikt fel, vilseleder att hoppa över nivåer hjälpmedelsteknik om sidans hierarkiska struktur och förvirrar användare som navigerar via rubriker.
• label — Verifierar att varje formulärfält har en programmatiskt associerad etikett, antingen via <label for='...'>, aria-label, aria-labelledby eller ett omslutande <label>-element. Ett fält utan en tillgänglig etikett förnekar blinda och röststyrningsanvändare den information de behöver för att förstå vad som ska anges.
• list — Säkerställer att <ul>- och <ol>-element endast innehåller <li>-element som direkta barn (plus <script> och <template>). Ogiltiga barnelement bryter liststrukturen som skärmläsare använder för att meddela antal objekt och positioner.
• listitem — Kontrollerar att <li>-element endast används inuti <ul>, <ol> eller behållare med role='list'. Föräldralösa listobjekt förlorar sin semantiska betydelse helt.
• scope-attr-valid — Validerar att scope-attributet på <th>-element endast innehåller de tillåtna värdena: col, row, colgroup eller rowgroup. Ett ogiltigt eller frånvarande scope-värde i en komplex datatabell innebär att skärmläsare inte pålitligt kan meddela vilken rubrik som gäller för en viss datacell.
• td-headers-attr — Kontrollerar att när dataceller använder headers-attributet, existerar varje ID som refereras faktiskt i samma tabell och tillhör en rubrikcell. Trasiga eller saknade referenser bryter den programmatiska relationen mellan data och dess beskrivande rubrik, vilket lämnar skärmläsaranvändare utan sammanhang.

Observera att automatiserade verktyg som axe-core inte kan fånga varje överträdelse av 1.3.1. Till exempel kan en utvecklare använda ett visuellt stylat <div> med role='list' och korrekt strukturerade underordnade element med role='listitem' — axe kommer att godkänna detta — men en mänsklig testare kan upptäcka att den visuella indragningen antyder en nästlad underlista som inte representeras i ARIA-strukturen. När den visuella hierarkin är komplex är manuell inspektion och skärmläsartestning oumbärliga komplement till automatiserad skanning.

Hur man testar

1. Automatiserad skanning med axe DevTools eller Lighthouse: Installera webbläsartillägget axe DevTools (Chrome eller Firefox). Öppna sidan som ska testas, öppna DevTools, navigera till axe-fliken och kör en fullständig sidskanning. Filtrera resultat efter taggen wcag131 eller granska alla problem taggade under "Info and Relationships." Leta specifikt efter överträdelser av de elva axe-reglerna som listas ovan. I Lighthouse (panelen Audits i Chrome DevTools) kör du en tillgänglighetsgranskning och kontrollerar kategorin "Accessibility" för fel relaterade till rubrikordning, etiketter och listor. Notera alla flaggade element och deras DOM-selektorer för åtgärd.
2. Manuell granskning av rubrikstruktur: Använd webbläsartillägget HeadingsMap eller panelen "Headings" i axe DevTools för att visa sidans fullständiga rubrikdisposition. Verifiera att dispositionen är logisk och hierarkisk — den ska läsa som en välstrukturerad innehållsförteckning. Bekräfta att inga rubriknivåer hoppas över och att rubriktexten är meningsfull och inte bara visuell styling som tillämpats på icke-rubrikelement.
3. Verifiering av formuläretiketter: Tabba igenom varje interaktivt formulärelement på sidan. För varje input, select och textarea, bekräfta att en synlig etikett finns och att den är programmatiskt associerad (kontrollera elementet i DevTools och leta efter ett matchande for/id-par eller ett aria-label/aria-labelledby). Använd tillgänglighetsträdet i Chrome DevTools (panelen Elements → fliken Accessibility) för att bekräfta det beräknade tillgängliga namnet för varje kontroll.
4. Skärmläsartestning med NVDA + Firefox: Starta NVDA och öppna sidan i Firefox. Tryck på H för att cykla genom rubriker och verifiera att de meddelade rubriknivåerna matchar den visuella hierarkin. Tryck på F för att flytta mellan formulärfält och bekräfta att varje fälts etikett meddelas. Tryck på T för att navigera i tabeller och piltangenterna genom celler, och lyssna efter rubrikmeddelanden. Tryck på L för att cykla genom listor och bekräfta att antal objekt meddelas.
5. Skärmläsartestning med VoiceOver + Safari (macOS/iOS): Aktivera VoiceOver (Cmd+F5 på macOS). Öppna Rotor (Ctrl+Option+U) och inspektera Headings, Links, Form Controls och Tables. Bekräfta att alla strukturella element visas i Rotor och att deras meddelade namn är meningsfulla och korrekta.
6. Skärmläsartestning med JAWS + Chrome: Öppna JAWS och sidan i Chrome. Använd JAWS List of Headings (Insert+F6) för att granska rubrikträdet. Använd Insert+F5 för formulärfält för att verifiera etikettassociationer. Navigera i tabeller med piltangenterna och bekräfta att JAWS meddelar kolumn- och radrubriker för varje datacell.
7. Kontroll av tabellrubrikrelationer: Identifiera alla datatabeller på sidan. För enkla tabeller verifierar du att <th>-element har lämpliga scope-attribut. För komplexa tabeller med flernivårubriker verifierar du att dataceller använder headers-attributet som refererar till korrekta id-värden. Följ visuellt varje cell till dess logiska rad- och kolumnrubriker och bekräfta sedan att samma väg representeras i koden.

Hur man åtgärdar

Visuella rubriker implementerade som stylade divar — Felaktigt

<!-- Heading conveyed only through CSS font-size and font-weight -->
<div class='section-title'>Our Services</div>
<div class='subsection-title'>Web Development</div>
<p>We build fast, accessible websites.</p>

Visuella rubriker implementerade som stylade divar — Korrekt

<!-- Semantic heading elements expose hierarchy to assistive technologies -->
<h2>Our Services</h2>
<h3>Web Development</h3>
<p>We build fast, accessible websites.</p>

Formulärfält utan associerad etikett — Felaktigt

<!-- The placeholder is not a substitute for a label; it disappears on input -->
<p>Email Address *</p>
<input type='email' placeholder='Enter your email' />

Formulärfält utan associerad etikett — Korrekt

<!-- The for attribute ties the label to the input by matching id -->
<label for='email'>Email Address <span aria-hidden='true'>*</span><span class='sr-only'>(required)</span></label>
<input type='email' id='email' aria-required='true' />

Datatabell utan scope-attribut — Felaktigt

<!-- Headers have no scope; screen readers cannot associate columns with data -->
<table>
  <tr>
    <th>Tarih</th>
    <th>Doktor</th>
    <th>Klinik</th>
  </tr>
  <tr>
    <td>15 Temmuz 2025</td>
    <td>Dr. Ayşe Kaya</td>
    <td>Kardiyoloji</td>
  </tr>
</table>

Datatabell utan scope-attribut — Korrekt

<!-- scope='col' tells screen readers each th describes its entire column -->
<table>
  <caption>Yaklaşan Randevular</caption>
  <thead>
    <tr>
      <th scope='col'>Tarih</th>
      <th scope='col'>Doktor</th>
      <th scope='col'>Klinik</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>15 Temmuz 2025</td>
      <td>Dr. Ayşe Kaya</td>
      <td>Kardiyoloji</td>
    </tr>
  </tbody>
</table>

Listobjekt använda utanför en listbehållare — Felaktigt

<!-- li elements without a parent ul or ol have no semantic meaning -->
<div class='features'>
  <li>Fast performance</li>
  <li>WCAG compliant</li>
  <li>Mobile friendly</li>
</div>

Listobjekt använda utanför en listbehållare — Korrekt

<!-- Wrapping ul gives screen readers item count and navigation context -->
<ul class='features'>
  <li>Fast performance</li>
  <li>WCAG compliant</li>
  <li>Mobile friendly</li>
</ul>

Vanliga misstag

• Att använda enbart CSS-egenskaperna font-size och font-weight för att skapa den visuella framtoningen av rubriker på <div>- eller <span>-element, utan att någonsin lägga till role='heading' och aria-level eller konvertera till faktiska <h1>–<h6>-element — skärmläsare kan inte upptäcka dessa som navigerbara rubriker.
• Att använda placeholder-text som den enda etiketten för formulärfält, vilket gör att etiketten försvinner så snart användaren börjar skriva, och lämnar fältet oetiketterat under resten av inmatningen — para alltid fält med ett bestående <label>-element.
• Att markera obligatoriska fält med en röd asterisk (*) som endast förklaras i en visuell förklaring högst upp i formuläret, utan att lägga till aria-required='true' eller inkludera "required" i den programmatiska etiketten så att skärmläsaranvändare får samma information.
• Att tillämpa list-style: none via CSS på ett <ul> utan att förstå att vissa skärmläsare (särskilt Safari + VoiceOver) då kan sluta meddela elementet som en lista — om listsemantiken är meningsfull, lägg till role='list' uttryckligen för att bevara den.
• Att hoppa över rubriknivåer — till exempel placera ett <h4> direkt efter ett <h2> eftersom designern ville ha mindre text — i stället för att använda korrekt rubriknivå och styra det visuella utseendet via CSS.
• Att bygga komplexa datatabeller med sammanslagna celler (colspan/rowspan) utan att lägga till headers-attributet på dataceller, vilket gör att skärmläsaranvändare inte kan avgöra vilken rubrik som styr en tvetydig sammanslagen cell.
• Att använda <table>-element för layoutändamål och sedan lägga till role='presentation' inkonsekvent — vissa celler innehåller fortfarande rubriker som meddelas ur sitt sammanhang, vilket förvirrar användare som inte kan se att tabellen är rent dekorativ.
• Att kapsla in ett <dt>/<dd>-par i ett <p> eller <div> som är ett direkt barn till ett <dl> utan att förstå att endast <div>-omslag är tillåtna inuti <dl> i HTML5, och att blandning av andra blockelement förstör definitionslistans struktur.
• Att lägga till aria-labelledby på ett fält som refererar till ett ID som inte existerar i DOM:en, eller refererar till ID:t för ett icke-textelement — det beräknade tillgängliga namnet blir tomt och fältet är i praktiken oetiketterat för hjälpmedelsteknik.
• Att anta att eftersom en sida ser korrekt ut visuellt och får en Lighthouse-poäng över 90, så uppfyller den 1.3.1 — automatiserade verktyg kan inte upptäcka varje strukturell överträdelse, såsom visuella nästlingsrelationer som inte återspeglas i ARIA-rollhierarkin, vilket kräver obligatorisk manuell och skärmläsarbaserad verifiering.

Relation till Turkiets tillgänglighetsreglering

Turkiets presidentcirkulär 2025/10, publicerat i den officiella tidningen nr 32933 den 21 juni 2025, fastställer obligatoriska krav på webbtillgänglighet i linje med WCAG 2.2 för ett brett spektrum av aktörer som är verksamma i Turkiet. WCAG 1.3.1 är ett kriterium på nivå A, vilket innebär att det ligger på den grundläggande nivån för överensstämmelse — den minsta acceptabla nivån av tillgänglighet — och är därför fullt obligatoriskt för alla berörda aktörer enligt cirkuläret.

Cirkuläret definierar två tidslinjer för efterlevnad. Offentliga institutioner — inklusive centrala statliga organ, kommuner, statliga universitet och offentliga sjukhus — måste uppnå full överensstämmelse på nivå A inom ett år från det att cirkuläret trätt i kraft. Privata aktörer som omfattas av regleringen har ett tvåårigt fönster för att uppfylla kraven. Skyldigheten är dock inte valfri för någon av grupperna: bristande efterlevnad utsätter berörda aktörer för tillsyn och potentiella verkställighetsåtgärder.

De privata aktörer som uttryckligen omfattas av cirkuläret inkluderar e-handelsplattformar, banker och finansiella institutioner, privata sjukhus och vårdgivare, telekommunikationsföretag med 200,000 eller fler abonnenter, licensierade resebyråer, privata transportföretag och privatskolor som verkar med tillstånd från Ministry of National Education (MoNE). Alla dessa aktörer som driver en publik webbplats eller mobil webbapplikation måste säkerställa att 1.3.1 är uppfyllt i hela deras digitala miljö.

För praktisk efterlevnad är 1.3.1 ett av de mest betydelsefulla kriterierna på nivå A eftersom det styr grundläggande sidstruktur. En turkisk e-handelssajt vars produktsidor för kategorier använder stylade <div>-element som rubriker, vars fält i kassaflödet saknar etikettassociationer eller vars ordersammanställning är en ostrukturerad tabell utan scope-attribut skulle underkännas mot 1.3.1 i sin helhet. Åtgärd är inte bara en juridisk skyldighet — den förbättrar direkt upplevelsen för de uppskattningsvis 700,000 eller fler blinda och personer med nedsatt syn i Turkiet som förlitar sig på hjälpmedelsteknik för att handla, sköta bankärenden, få vård och interagera med offentliga tjänster online.

Organisationer som vill visa att de uppfyller kraven rekommenderas att genomföra både automatiserade axe-core-skanningar och manuella skärmläsargranskningar som täcker hela bredden av deras digitala innehåll. Strukturell tillgänglighet — den grund som 1.3.1 upprätthåller — bör byggas in i designsystem och komponentbibliotek så att efterlevnad upprätthålls när innehåll skapas och uppdateras, i stället för att behandlas som en engångsinsats för åtgärd.