WCAG 1.3.1: Info en relaties

Wat Deze Regel Betekent

WCAG 1.3.1 — Informatie en Relaties is een criterium op Niveau A onder het principe Waarneembaar. De kernvereiste is eenvoudig maar verstrekkend: alle informatie of relaties die visueel worden gecommuniceerd, moeten ook worden uitgedrukt op een manier die hulpptechnologieën kunnen detecteren en aan gebruikers kunnen overbrengen. Als je ontwerp visuele aanwijzingen gebruikt — inspringing om een lijst te impliceren, vetgedrukte tekst om een verplicht veld aan te duiden, kleur om een fout aan te geven of grootte om een kop aan te geven — dan moeten diezelfde semantiek ook in de onderliggende code aanwezig zijn.

Het criterium is van toepassing op drie categorieën van betekenis die webinhoud regelmatig via presentatie overbrengt:

• Informatie — feiten of gegevens die op de pagina worden gecommuniceerd, zoals welke formuliervelden verplicht zijn of welke tabelcellen een relatie delen.
• Structuur — het organisatorische schema van de inhoud, zoals koppenhiërarchieën, geordende of ongeordende lijsten en gegevenstabellen.
• Relaties — associaties tussen elementen, zoals een label en de bijbehorende invoer, een tabelkop en de bijbehorende datacellen, of een term en de bijbehorende definitie.

Een pagina voldoet aan 1.3.1 wanneer elk stuk structurele of relationele informatie dat beschikbaar is voor een ziende gebruiker óf is gecodeerd in geldige, semantische HTML óf wordt blootgelegd via een correcte ARIA-rol, -eigenschap of -status die hulpptechnologieën kunnen interpreteren. Een pagina faalt wanneer visuele structuur alleen in CSS of afbeeldingen bestaat, of wanneer ARIA-markup in tegenspraak is met of ontbreekt in de DOM-structuur die wordt gepresenteerd.

Officiële uitzonderingen zijn minimaal. Het criterium vereist niet dat alle visuele decoratie semantische betekenis heeft — puur esthetische opmaak zoals een decoratieve rand of achtergrondkleur hoeft geen programmatisch equivalent te hebben. Maar elke opmaak die een gebruiker redelijkerwijs zou interpreteren als betekenisdragend (verplichte sterretjes, vetgedrukte termen in een woordenlijst, genummerde stappen) moet een overeenkomstige programmatische uitdrukking hebben.

Waarom Het Belangrijk Is

Informatie en relaties liggen aan de basis van vrijwel elke interactie die een gebruiker met een webpagina heeft. Wanneer die structuur uitsluitend in visuele presentatie opgesloten zit, wordt een aanzienlijk deel van de bevolking feitelijk uitgesloten van het begrijpen van de inhoud.

Schermlezers — doorgaans gebruikt door blinde of slechtziende personen — navigeren pagina’s door de toegankelijkheidsboom te bevragen, die is opgebouwd uit semantische HTML en ARIA. Wanneer een ontwikkelaar een <div> gebruikt die is gestileerd als een kop in plaats van een echte <h2>, zal een schermlezergebruiker die met de toets H tussen koppen springt, deze volledig overslaan. Die persoon vindt mogelijk nooit de sectie die ermee wordt ingeleid. Volgens de Wereldgezondheidsorganisatie leven wereldwijd ongeveer 2,2 miljard mensen met een vorm van visuele beperking, en tientallen miljoenen vertrouwen dagelijks op schermlezers.

Gebruikers met cognitieve beperkingen profiteren net zo veel van een duidelijke structuur. Correct geneste koppen, betekenisvolle lijstmarkering en gelabelde formulierelementen verlagen de cognitieve belasting door voorspelbare patronen te bieden. Een schermlezer die aankondigt: "kopniveau 2, Producten" gevolgd door "kopniveau 3, Laptops" geeft een cognitieve kaart van de pagina. Een vlakke muur van gestileerde tekst zonder structurele ankerpunten is desoriënterend voor iedereen, maar vooral voor gebruikers met aandachts- of geheugenproblemen.

Motorisch beperkte gebruikers die vertrouwen op toetsenbordnavigatie, schakelbediening of spraakbesturingssoftware zijn eveneens afhankelijk van programmatische structuur. Spraakbesturingssoftware zoals Dragon NaturallySpeaking genereert klikbare doelen op basis van toegankelijke namen die zijn afgeleid van labels en rollen — formuliervelden zonder gekoppelde labels kunnen simpelweg niet betrouwbaar met spraakcommando’s worden aangestuurd.

Neem een concreet scenario: een patiëntenportaal van een ziekenhuis toont een tabel met aankomende afspraken. De tabel gebruikt visuele uitlijning en achtergrondkleur om datums met artsen te associëren, maar de <th>-elementen missen scope-attributen en de datacellen verwijzen niet naar koppen. Een blinde gebruiker met een schermlezer hoort geïsoleerde celwaarden — "9:00 AM", "Dr. Ayşe Kaya", "Cardiology" — zonder te weten welke waarde bij welke kolom hoort. Die persoon kan het tijdstip van de afspraak verkeerd begrijpen of bij de verkeerde afdeling verschijnen. Correct gebruik van scope='col' op koppen en headers-attributen op cellen zou de relaties hoorbaar hebben gemaakt.

Naast toegankelijkheid heeft structurele HTML aanzienlijke SEO-waarde. Zoekmachinecrawlers gebruiken koppenhiërarchieën om paginathema’s te begrijpen, lijstmarkering om opgesomde inhoud te identificeren en labelassociaties om het doel van formulieren te begrijpen. Een pagina die voldoet aan 1.3.1 is bijna altijd een pagina die zoekmachines nauwkeuriger kunnen parseren en rangschikken.

Gerelateerde Axe-core Regels

De volgende axe-core-regels komen direct overeen met schendingen van WCAG 1.3.1. Elke regel richt zich op een specifiek aspect van programmatische structuur of relatie:

• aria-required-children — Controleert of elementen met bepaalde ARIA-rollen de vereiste kindrollen bevatten. Een role='list' moet bijvoorbeeld kinderen bevatten met role='listitem'. Zonder de juiste kindstructuur is de relatie tussen een container en zijn items verbroken voor hulpptechnologieën.
• aria-required-parent — Het omgekeerde van bovenstaande: controleert of elementen met rollen die een specifieke oudercontext vereisen, die ouder daadwerkelijk hebben. Een role='listitem' dat niet binnen een role='list' of <ul>/<ol> staat, wordt gemarkeerd omdat de relatiecontext ontbreekt.
• aria-roles — Valideert dat alle waarden van het attribuut role geldige ARIA-rollen zijn. Een ongeldige of verkeerd gespelde rol (bijv. role='heading' in plaats van een kop-element te gebruiken, of een volledig verzonnen rol) betekent dat de hulpptechnologie geen bruikbare informatie ontvangt en het element mogelijk volledig negeert.
• definition-list — Verifieert dat <dl>-elementen alleen toegestane kinderen bevatten: <dt>, <dd>, <div>, <script> en <template>. Het direct invoegen van andere elementen zoals <p> in een <dl> maakt de term-definitierelatiestructuur ongeldig.
• dlitem — Controleert dat <dt>- en <dd>-elementen alleen binnen <dl>-elementen worden gebruikt. Het gebruik van deze elementen buiten hun vereiste oudercontext vernietigt de semantische betekenis van het term-definitiepaar.
• heading-order — Markeert kopniveaus die in de documentstructuur worden overgeslagen (bijv. een sprong van <h2> naar <h4>). Hoewel dit niet altijd een strikte fout is, misleidt het overslaan van niveaus hulpptechnologieën over de hiërarchische structuur van de pagina en verwart het gebruikers die op koppen navigeren.
• label — Verifieert dat elk formulierveld een programmatisch gekoppeld label heeft, via <label for='...'>, aria-label, aria-labelledby of een omhullend <label>-element. Een invoerveld zonder toegankelijk label onthoudt blinde en spraakgestuurde gebruikers de informatie die ze nodig hebben om te begrijpen wat ze moeten invoeren.
• list — Zorgt ervoor dat <ul>- en <ol>-elementen alleen <li>-elementen als directe kinderen bevatten (plus <script> en <template>). Ongeldige kindelementen breken de lijststructuur die schermlezers gebruiken om het aantal items en posities aan te kondigen.
• listitem — Controleert dat <li>-elementen alleen worden gebruikt binnen containers <ul>, <ol> of role='list'. Verweesde lijstitems verliezen hun semantische betekenis volledig.
• scope-attr-valid — Valideert dat het attribuut scope op <th>-elementen alleen de toegestane waarden bevat: col, row, colgroup of rowgroup. Een ongeldige of ontbrekende scope-waarde op een complexe gegevenstabel betekent dat schermlezers niet betrouwbaar kunnen aankondigen welke kop op een bepaalde datacel van toepassing is.
• td-headers-attr — Controleert dat wanneer datacellen het attribuut headers gebruiken, elke genoemde ID daadwerkelijk in dezelfde tabel bestaat en tot een kopcel behoort. Gebroken of ontbrekende verwijzingen verbreken de programmatische relatie tussen gegevens en de beschrijvende kop, waardoor schermlezergebruikers zonder context achterblijven.

Let op dat geautomatiseerde tools zoals axe-core niet elke schending van 1.3.1 kunnen detecteren. Een ontwikkelaar kan bijvoorbeeld een visueel gestileerde <div> met role='list' en correct gestructureerde kindelementen met role='listitem' gebruiken — axe zal dit goedkeuren — maar een menselijke tester kan ontdekken dat de visuele inspringing een geneste sublijst impliceert die niet in de ARIA-structuur is weergegeven. Wanneer visuele hiërarchie complex is, zijn handmatige inspectie en testen met schermlezers essentiële aanvullingen op geautomatiseerde scans.

Hoe te Testen

1. Geautomatiseerde scan met axe DevTools of Lighthouse: Installeer de browserextensie axe DevTools (Chrome of Firefox). Open de te testen pagina, open DevTools, ga naar het axe-tabblad en voer een scan van de volledige pagina uit. Filter resultaten op de tag wcag131 of bekijk alle issues die zijn getagd onder "Info and Relationships." Let specifiek op schendingen van de elf hierboven genoemde axe-regels. Voer in Lighthouse (Chrome DevTools Audits-paneel) een toegankelijkheidsaudit uit en controleer in de categorie "Accessibility" op fouten met betrekking tot kopvolgorde, labels en lijsten. Noteer alle gemarkeerde elementen en hun DOM-selectors voor herstel.
2. Handmatige controle van de kopstructuur: Gebruik de browserextensie HeadingsMap of het paneel "Headings" in axe DevTools om de volledige koppenstructuur van de pagina te bekijken. Controleer of de structuur logisch en hiërarchisch is — deze zou moeten lezen als een goed gestructureerde inhoudsopgave. Bevestig dat er geen kopniveaus worden overgeslagen en dat de koptekst betekenisvol is en niet slechts visuele styling op niet-kop-elementen.
3. Verificatie van formulierlabels: Navigeer met Tab door elk interactief formulierelement op de pagina. Controleer voor elk input-, select- en textarea-element of er een zichtbaar label aanwezig is en of dit programmatisch is gekoppeld (controleer het element in DevTools en zoek naar een overeenkomend for/id-paar of een aria-label/aria-labelledby). Gebruik de toegankelijkheidsboom in Chrome DevTools (tabblad Elements → Accessibility) om de berekende toegankelijke naam voor elk besturingselement te bevestigen.
4. Schermlezertest met NVDA + Firefox: Start NVDA en open de pagina in Firefox. Druk op H om door koppen te bladeren en controleer of de aangekondigde kopniveaus overeenkomen met de visuele hiërarchie. Druk op F om tussen formuliervelden te gaan en bevestig dat het label van elk veld wordt aangekondigd. Druk op T om naar tabellen te navigeren en met pijltjestoetsen door cellen te gaan, en luister naar de aankondiging van koppen. Druk op L om door lijsten te bladeren en bevestig dat het aantal items wordt aangekondigd.
5. Schermlezertest met VoiceOver + Safari (macOS/iOS): Schakel VoiceOver in (Cmd+F5 op macOS). Open de Rotor (Ctrl+Option+U) en bekijk Headings, Links, Form Controls en Tables. Bevestig dat alle structurele elementen in de Rotor verschijnen en dat hun aangekondigde namen betekenisvol en correct zijn.
6. Schermlezertest met JAWS + Chrome: Open JAWS en de pagina in Chrome. Gebruik de JAWS List of Headings (Insert+F6) om de koppenstructuur te bekijken. Gebruik Insert+F5 voor formuliervelden om labelassociaties te verifiëren. Navigeer door tabellen met pijltjestoetsen en bevestig dat JAWS kolom- en rijkoppen voor elke datacel aankondigt.
7. Controle van tabelkoprelaties: Identificeer alle gegevenstabellen op de pagina. Controleer voor eenvoudige tabellen of <th>-elementen de juiste scope-attributen hebben. Controleer voor complexe tabellen met meerlagige koppen of datacellen het attribuut headers gebruiken dat naar de juiste id-waarden verwijst. Volg elke cel visueel naar de logische rij- en kolomkoppen en bevestig vervolgens dat hetzelfde pad in de code is weergegeven.

Hoe te Herstellen

Visuele koppen geïmplementeerd als gestileerde divs — Onjuist

<!-- 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>

Visuele koppen geïmplementeerd als gestileerde divs — Correct

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

Formulierveld zonder gekoppeld label — Onjuist

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

Formulierveld zonder gekoppeld label — Correct

<!-- 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' />

Gegevenstabel zonder scope-attributen — Onjuist

<!-- 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>

Gegevenstabel zonder scope-attributen — Correct

<!-- 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>

Lijstitems gebruikt buiten een lijstcontainer — Onjuist

<!-- 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>

Lijstitems gebruikt buiten een lijstcontainer — Correct

<!-- 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>

Veelvoorkomende Fouten

• Alleen font-size- en font-weight-CSS gebruiken om de visuele weergave van koppen op <div>- of <span>-elementen te creëren, zonder ooit role='heading' en aria-level toe te voegen of om te zetten naar echte <h1>–<h6>-elementen — schermlezers kunnen deze niet als navigeerbare koppen ontdekken.
• placeholder-tekst gebruiken als het enige label voor formuliervelden, waardoor het label verdwijnt zodra de gebruiker begint te typen en het veld gedurende de invoer onlabeld blijft — koppel invoervelden altijd aan een persistent <label>-element.
• Verplichte velden markeren met een rood sterretje (*) dat alleen in een visuele legenda bovenaan het formulier wordt uitgelegd, zonder aria-required='true' toe te voegen of "required" in het programmatische label op te nemen, zodat schermlezergebruikers dezelfde informatie ontvangen.
• list-style: none via CSS toepassen op een <ul> zonder te begrijpen dat sommige schermlezers (met name Safari + VoiceOver) het element dan mogelijk niet langer als lijst aankondigen — als de lijstsemantiek betekenisvol is, voeg dan expliciet role='list' toe om deze te behouden.
• Kopniveaus overslaan — bijvoorbeeld een <h4> direct na een <h2> plaatsen omdat de ontwerper kleinere tekst wilde — in plaats van het juiste kopniveau te gebruiken en het visuele uiterlijk via CSS te regelen.
• Complexe gegevenstabellen bouwen met samengevoegde cellen (colspan/rowspan) zonder het attribuut headers op datacellen toe te voegen, waardoor schermlezergebruikers niet kunnen bepalen welke kop een dubbelzinnige samengevoegde cel aanstuurt.
• <table>-elementen gebruiken voor lay-outdoeleinden en vervolgens role='presentation' inconsistent toevoegen — sommige cellen bevatten nog steeds koppen die buiten context worden aangekondigd, wat verwarrend is voor gebruikers die niet kunnen zien dat de tabel puur decoratief is.
• Een <dt>/<dd>-paar omwikkelen met een <p> of <div> dat een direct kind is van een <dl>, zonder te begrijpen dat in HTML5 alleen <div>-omhullingen binnen <dl> zijn toegestaan en dat het mengen van andere blok-elementen de structuur van de definitielijst vernietigt.
• aria-labelledby toevoegen aan een invoerveld dat verwijst naar een ID die niet in de DOM bestaat, of verwijzen naar de ID van een niet-tekstelement — de berekende toegankelijke naam wordt leeg en het invoerveld is voor hulpptechnologieën feitelijk onlabeld.
• Aannemen dat een pagina, omdat deze er visueel correct uitziet en een Lighthouse-score boven 90 behaalt, voldoet aan 1.3.1 — geautomatiseerde tools kunnen niet elke structurele schending detecteren, zoals visuele nestingsrelaties die niet in de ARIA-rolhiërarchie zijn weerspiegeld, waardoor handmatige en schermlezertests onmisbaar zijn.

Relatie met de Toegankelijkheidsregelgeving van Turkije

De Presidentiële Circulaire 2025/10 van Turkije, gepubliceerd in het Staatsblad nr. 32933 op 21 juni 2025, stelt verplichte webtoegankelijkheidsverplichtingen vast die zijn afgestemd op WCAG 2.2 voor een brede groep entiteiten die in Turkije actief zijn. WCAG 1.3.1 is een criterium op Niveau A, wat betekent dat het zich op het fundamentele niveau van conformiteit bevindt — het minimaal aanvaardbare niveau van toegankelijkheid — en daarom volledig verplicht is voor alle onder de circulaire vallende entiteiten.

De circulaire definieert twee nalevingstermijnen. Overheidsinstellingen — waaronder centrale overheidsorganen, gemeenten, staatsuniversiteiten en openbare ziekenhuizen — moeten binnen één jaar na inwerkingtreding van de circulaire volledige conformiteit op Niveau A bereiken. Partijen in de private sector die onder de regeling vallen, hebben een termijn van twee jaar om te voldoen. De verplichting is echter voor geen van beide groepen optioneel: niet-naleving stelt betrokken entiteiten bloot aan toezicht door de toezichthouder en mogelijke handhavingsmaatregelen.

De private sectorpartijen die expliciet onder de circulaire vallen, omvatten e-commerceplatforms, banken en financiële instellingen, particuliere ziekenhuizen en zorgaanbieders, telecommunicatiebedrijven met 200,000 of meer abonnees, erkende reisbureaus, particuliere vervoersbedrijven en particuliere scholen die opereren onder een vergunning van het Ministerie van Nationaal Onderwijs (MoNE). Elk van deze entiteiten die een publiek toegankelijke website of mobiele webapplicatie exploiteert, moet ervoor zorgen dat 1.3.1 op al hun digitale eigendommen wordt nageleefd.

Voor praktische naleving is 1.3.1 een van de meest impactvolle criteria op Niveau A, omdat het de fundamentele paginastructuur regelt. Een Turkse e-commercesite waarvan de productcategoriepagina’s gestileerde <div>-elementen voor koppen gebruiken, waarvan de invoervelden in het afrekenformulier geen labelassociaties hebben, of waarvan het besteloverzicht een ongestructureerde tabel zonder scope-attributen is, zou 1.3.1 op brede schaal schenden. Herstel is niet alleen een wettelijke verplichting — het verbetert direct de ervaring voor de naar schatting 700,000 of meer blinde en slechtziende personen in Turkije die op hulpptechnologieën vertrouwen om online te winkelen, te bankieren, zorg te krijgen en met overheidsdiensten te communiceren.

Organisaties die willen aantonen dat ze voldoen, wordt aangeraden zowel geautomatiseerde axe-core-scans als handmatige schermlezeraudits uit te voeren die de volledige breedte van hun digitale inhoud bestrijken. Structurele toegankelijkheid — de basis die 1.3.1 afdwingt — moet worden ingebouwd in ontwerpsystemen en componentbibliotheken, zodat naleving behouden blijft terwijl inhoud wordt gecreëerd en bijgewerkt, in plaats van te worden behandeld als een eenmalige herstelactie.