WCAG 3.2.6: Consistente hulp

Wat Deze Regel Betekent

WCAG Succescriterium 3.2.6 Consistente hulp (niveau AA, geïntroduceerd in WCAG 2.2) stelt: “Als een webpagina een van de volgende hulpmiddelen bevat, en deze hulpmiddelen worden herhaald op meerdere webpagina’s, dan komen ze in dezelfde relatieve volgorde ten opzichte van andere paginainhoud voor, tenzij een wijziging door de gebruiker wordt geïnitieerd.” De hulpmiddelen die onder dit criterium vallen zijn: contactgegevens van een persoon (zoals een telefoonnummer, e‑mailadres of openingstijden), een contactmechanisme met een persoon (zoals een livechatwidget of een contactformulier), een zelfhulpmogelijkheid (zoals een pagina met veelgestelde vragen, een helpcentrum of een kennisbank) en een volledig geautomatiseerd contactmechanisme (zoals een chatbot of virtuele assistent).

De belangrijkste eis is consistentie van relatieve volgorde, niet identieke pixelpositie. Als een livechatknop in de rechterbenedenhoek van de homepage verschijnt, moet deze op elke andere pagina waar hij wordt weergegeven in dezelfde rechterbenedenhoek staan. Als een “Help”-link het derde item in de bovenste navigatiebalk op één pagina is, moet deze het derde item blijven — of in elk geval dezelfde relatieve relatie tot de omringende inhoud behouden — op alle andere pagina’s waar die navigatiebalk voorkomt.

Een pagina voldoet aan dit criterium wanneer: (a) er geen hulpmiddel op de site bestaat, of (b) een hulpmiddel slechts op één pagina bestaat, of (c) overal waar een hulpmiddel op meerdere pagina’s wordt herhaald, het in dezelfde relatieve volgorde binnen de paginalay-out verschijnt. Een pagina voldoet niet wanneer een hulpmiddel dat op meerdere pagina’s aanwezig is, zijn positie in de paginavolgorde van de ene pagina naar de andere verschuift zonder dat de gebruiker die wijziging heeft geïnitieerd — bijvoorbeeld een chatwidget die rechtsonder op de productoverzichtspagina zweeft maar linksonder op de afrekenpagina verschijnt.

Het criterium bevat een expliciete uitzondering: de volgorde mag veranderen als de gebruiker de wijziging initieert. Als een gebruiker bijvoorbeeld een zwevende hulpwidget versleept en verplaatst, of als een gebruikersvoorkeur het hulppaneel van de ene naar de andere kant schakelt, dan is die verplaatsing door de gebruiker geïnitieerd en vormt deze geen fout. Deze uitzondering weerspiegelt dezelfde door de gebruiker geïnitieerde logica als in SC 3.2.2 (Bij invoer).

Belangrijk is dat dit criterium niet vereist dat elke pagina een hulpmiddel heeft, en evenmin dat het hulpmiddel effectief of gemakkelijk te gebruiken is. Het regelt alleen de positionele consistentie wanneer het hulpmiddel op meerdere pagina’s aanwezig is.

Waarom Het Belangrijk Is

Consistente plaatsing van hulp is primair bedoeld om gebruikers met cognitieve beperkingen te ondersteunen, waaronder mensen met geheugenstoornissen, aandachtsproblemen, leerstoornissen zoals dyslexie en aandoeningen zoals ADHD of dementie in een vroeg stadium. Voor deze gebruikers kost het lokaliseren van een vertrouwd interface-element bewuste cognitieve inspanning. Wanneer een helpknop of contactlink op elke pagina op een andere plek verschijnt, moeten zij die inspanning telkens opnieuw leveren, wat de cognitieve belasting en het risico op frustratie, desoriëntatie of het afbreken van de taak vergroot.

Gebruikers die nieuw zijn op het web of beperkte digitale vaardigheden hebben — een aanzienlijke groep in Turkije en wereldwijd — zijn eveneens sterk afhankelijk van voorspelbare plaatsing. Volgens de Wereldgezondheidsorganisatie leven wereldwijd meer dan 1,3 miljard mensen met een of andere vorm van beperking, en cognitieve en neurologische aandoeningen vormen een substantieel deel van die populatie. Ontwerpen voor positionele consistentie bedient daarom een brede doelgroep, ver voorbij mensen met klinisch gediagnosticeerde beperkingen.

Neem een concreet scenario: een gebruiker met de ziekte van Alzheimer in een vroeg stadium probeert een online vluchtboeking te voltooien. Ze herinnert zich dat de website van de luchtvaartmaatschappij een livechatoptie heeft die ze kan gebruiken wanneer ze in de war raakt. Op de zoekresultatenpagina verschijnt het chaticoon in de rechterbenedenhoek. Maar wanneer ze naar de stoelkeuzepagina gaat, is de chatwidget verplaatst naar de rechterbovenhoek in een inklapbare hulpbalk. Ze kan deze niet vinden, raakt overweldigd en breekt de boeking volledig af. Dit is een directe, te voorkomen fout ten aanzien van SC 3.2.6.

Voor motorisch beperkte gebruikers die navigeren met schakelbediening, oogvolgsoftware of hoofdaanwijzers, betekent het verplaatsen van een hulpmiddel dat ze een nieuw deel van het scherm opnieuw moeten scannen en aanviseren — een inspannend en tijdrovend proces dat consistente plaatsing overbodig maakt.

Schermlezersgebruikers die de tabvolgorde of kopstructuur van een site hebben gememoriseerd om snel de helpsectie te bereiken, worden evenzeer getroffen wanneer de DOM-volgorde van dat hulpmiddel van pagina tot pagina verandert, zelfs als de visuele positie vergelijkbaar lijkt.

Naast toegankelijkheid is er een duidelijk bruikbaarheids- en zakelijk voordeel: gebruikers die snel hulp kunnen vinden, breken minder snel een transactie af, wat uitvalpercentages en ondersteuningskosten verlaagt. Consistente UI‑patronen versterken bovendien het vertrouwen in het merk en de professionele uitstraling.

Gerelateerde Axe-core-regels

WCAG 3.2.6 is geclassificeerd als uitsluitend handmatig te testen en heeft geen overeenkomstige geautomatiseerde axe-core-regel die overtredingen programmatisch kan signaleren. Dit is bewust zo ontworpen, en begrijpen waarom helpt testers de aard van dit criterium te waarderen.

• Handmatige inspectie vereist — geen axe-regel beschikbaar: Geautomatiseerde tools zoals axe-core, Lighthouse of IBM Equal Access Checker analyseren een enkele pagina in isolatie. Ze hebben geen inherent begrip van wat een “hulpmiddel” is, geen mogelijkheid om de relatieve DOM-positie van een element over meerdere paginaladingen of URL’s te vergelijken, en geen manier om te bepalen of een bepaald element de functionele rol van hulpverlening vervult. Een chatwidget kan bijvoorbeeld worden geïmplementeerd als een gewone <div>, een shadow DOM-component, een <iframe> of een door derden geïnjecteerd script — geen van deze kan door een regelengine zonder menselijke beoordeling betrouwbaar als “hulpmiddel” worden geïdentificeerd. Axe-core zou bewustzijn van status over pagina’s heen en herkenning van semantische intentie nodig hebben om dit te signaleren, mogelijkheden die buiten het bereik van statische analyse van één pagina vallen. Daarom bestempelt WCAG 2.2 zelf 3.2.6 als een criterium dat menselijke evaluatie vereist via gestructureerde handmatige audits en vergelijking tussen pagina’s.

Hoe te Testen

1. Maak een inventaris van hulpmiddelen: Maak vóór het testen van afzonderlijke pagina’s een lijst van alle hulpmiddelen die op de site aanwezig zijn — livechatwidgets, contacttelefoonnummers, e‑maillinks, FAQ-links, chatbotstarters, contactformulieren en helpcentrumlinks. Noteer op welke pagina’s elk hulpmiddel voorkomt. Als een hulpmiddel slechts op één pagina voorkomt, valt het buiten de scope van dit criterium.
2. Voer een geautomatiseerde scan uit voor basiscontext: Gebruik axe DevTools (browserextensie) of Lighthouse op representatieve pagina’s om momentopnamen van de DOM-volgorde vast te leggen en de structurele positie van hulpgerelateerde elementen te identificeren. Hoewel geen enkele axe-regel direct is gericht op SC 3.2.6, kan de DOM-volgorde die door deze tools wordt gerapporteerd handmatig tussen pagina’s worden vergeleken. Exporteer of maak een screenshot van de toegankelijkheidsboom voor elke pagina met een hulpmiddel.
3. Vergelijk relatieve posities tussen pagina’s: Open twee of meer pagina’s die hetzelfde hulpmiddel delen naast elkaar (of achtereenvolgens). Identificeer voor elk hulpmiddel de positie ten opzichte van omliggende landmarkregio’s (<header>, <main>, <footer>, <nav>). Noteer of het hulpmiddel in dezelfde landmarkregio en in dezelfde relatieve volgorde (voor of na aangrenzende elementen) op elke pagina verschijnt. Een positiewijziging vormt een potentiële fout.
4. Test met toetsenbordnavigatie (alle browsers): Doorloop elke pagina met een hulpmiddel met de Tab-toets. Tel het aantal tabstops dat nodig is om vanaf het begin van de pagina het hulpmiddel te bereiken. Vergelijk deze telling tussen pagina’s. Een significant verschil — bijvoorbeeld bereikbaar in 5 tabs op de homepage maar 47 tabs op de afrekenpagina — duidt op een wijziging in de DOM-volgorde, zelfs als de visuele positie vergelijkbaar lijkt.
5. Test met NVDA + Firefox: Open de NVDA-elementenlijst (NVDA-toets + F7) en schakel naar de weergave Links of Knoppen. Lokaliseer het hulpmiddel in de lijst. Noteer de positie ten opzichte van andere elementen in de lijst. Herhaal dit op elke pagina waar het hulpmiddel verschijnt en vergelijk de posities.
6. Test met VoiceOver + Safari (macOS/iOS): Gebruik de VoiceOver-rotor (VO + U) om de lijst Links of Formulierelementen te openen. Navigeer naar het hulpmiddel en noteer de positie in de lijst. Vergelijk tussen pagina’s.
7. Test met JAWS + Chrome: Gebruik de JAWS-linklijst (Insert + F7) om het hulpmiddel te lokaliseren. Noteer de ordinale positie en aangrenzende elementen. Herhaal dit op meerdere pagina’s.
8. Controleer door de gebruiker geïnitieerde uitzonderingen: Als de site gebruikers toestaat hulpmiddelen te verplaatsen of te verbergen (bijv. een versleepbare chatwidget), controleer dan of de verplaatsing wordt geactiveerd door een expliciete gebruikersactie en of de voorkeur logisch wordt bewaard. Documenteer dit als een geldige uitzondering onder het criterium.
9. Beoordeel op mobiele viewports: Responsieve lay-outs herschikken soms DOM-elementen bij verschillende breekpunten. Test op zowel desktop- als mobiele viewports (minimaal breedtes van 375px en 1440px) om te bevestigen dat het hulpmiddel op alle gangbare schermformaten een consistente relatieve plaatsing behoudt.

Hoe te Herstellen

Zwevende chatwidget — Onjuist

<!-- Page A (homepage): chat button in bottom-right -->
<div class='chat-widget' style='position:fixed; bottom:20px; right:20px;'>
  <button>Chat with Us</button>
</div>

<!-- Page B (checkout): chat button moved to bottom-left -->
<div class='chat-widget' style='position:fixed; bottom:20px; left:20px;'>
  <button>Chat with Us</button>
</div>
<!-- FAIL: The widget changes its fixed position between pages,
     breaking consistent help placement. -->

Zwevende chatwidget — Juist

<!-- Both Page A and Page B: chat button consistently in bottom-right -->
<div class='chat-widget chat-widget--bottom-right'>
  <button type='button' aria-label='Open live chat support'>
    Chat with Us
  </button>
</div>
<!-- PASS: The widget appears in the same corner on every page.
     Use a CSS class defined in a shared stylesheet rather than
     inline styles, so the position is controlled centrally and
     applied consistently across all templates. -->

Helplink in navigatie — Onjuist

<!-- Page A: Help is the 4th nav item -->
<nav aria-label='Main navigation'>
  <ul>
    <li><a href='/products'>Products</a></li>
    <li><a href='/about'>About</a></li>
    <li><a href='/pricing'>Pricing</a></li>
    <li><a href='/help'>Help</a></li>
  </ul>
</nav>

<!-- Page B (product detail): Help link removed from nav,
     placed in a footer section instead -->
<footer>
  <a href='/help'>Help Center</a>
</footer>
<!-- FAIL: The Help link has moved from the main navigation
     to the footer, changing its relative order significantly. -->

Helplink in navigatie — Juist

<!-- Both Page A and Page B share the same navigation template -->
<nav aria-label='Main navigation'>
  <ul>
    <li><a href='/products'>Products</a></li>
    <li><a href='/about'>About</a></li>
    <li><a href='/pricing'>Pricing</a></li>
    <li><a href='/help'>Help</a></li>
  </ul>
</nav>
<!-- PASS: The Help link is the 4th item in the main nav
     on every page where the nav is present. Using a shared
     navigation component or server-side include ensures
     this is maintained automatically. -->

Voorwaardelijke weergave van hulp — Onjuist

<!-- On logged-out pages: phone number in header -->
<header>
  <p>Need help? Call <a href='tel:+908501234567'>0850 123 45 67</a></p>
</header>

<!-- On logged-in pages: phone number removed from header,
     only available deep inside an account dropdown menu -->
<header>
  <nav aria-label='Account menu'>
    <details>
      <summary>My Account</summary>
      <ul>
        <li><a href='/orders'>Orders</a></li>
        <li><a href='/contact'>Contact: 0850 123 45 67</a></li>
      </ul>
    </details>
  </nav>
</header>
<!-- FAIL: The contact number changes its relative position
     dramatically depending on authentication state,
     making it unpredictable for returning users. -->

Voorwaardelijke weergave van hulp — Juist

<!-- Both logged-out and logged-in pages: phone in the same header position -->
<header>
  <div class='header-support'>
    <a href='tel:+908501234567' aria-label='Call support: 0850 123 45 67'>
      <svg aria-hidden='true' focusable='false'><!-- phone icon --></svg>
      0850 123 45 67
    </a>
  </div>
  <nav aria-label='Account menu'>
    <!-- account links here -->
  </nav>
</header>
<!-- PASS: The contact mechanism is always in the same position
     within the header regardless of authentication state.
     Additional account-specific links can appear elsewhere
     without moving the help mechanism. -->

Veelvoorkomende Fouten

• De chatwidget in verschillende hoeken plaatsen op verschillende paginatemplates: Ontwikkelteams passen vaak vaste positionering voor chatwidgets per template toe in plaats van via een globale stylesheet, waardoor de widget rechtsonder op marketingpagina’s en linksonder op app-pagina’s verschijnt. Gebruik één globaal opgenomen component met een vaste positieklasse.
• De helplink uit de navigatie verwijderen op afrekenpagina’s om rommel te verminderen: Sommige UX‑patronen strippen bewust navigatie op afrekenpagina’s om conversie te optimaliseren. Als een hulpmiddel deel uitmaakt van die navigatie, verbreekt het verwijderen ervan uit dit paginatemplate de consistentie. Behoud in plaats daarvan de helplink in een minimale header, zelfs in uitgeklede checkoutflows.
• Hulpmiddelen injecteren via scripts van derden die met onvoorspelbare DOM-posities laden: Veel livechat-SDK’s injecteren hun widget asynchroon in de DOM, en hun invoegpunt kan variëren op basis van de laadv volgorde van scripts. Dit kan ertoe leiden dat de widget op een andere positie in de toegankelijkheidsboom verschijnt op verschillende pagina’s. Configureer widgets van derden zo dat ze altijd worden toegevoegd aan een vast, bekend DOM-ankerelement.
• CSS order of flexbox/grid-herschikking gebruiken om het hulpelement visueel te verplaatsen zonder de DOM-volgorde te wijzigen, en die CSS vervolgens per pagina veranderen: Hoewel de visuele positie consistent kan lijken, veranderen per pagina overschreven CSS-regels die de visuele volgorde van een hulpmiddel aanpassen nog steeds de door de gebruiker waarneembare volgorde en kunnen ze schermlezersgebruikers verwarren, van wie de leesvolgorde de DOM volgt.
• Vertrouwen op A/B‑testtools die de positie van het hulpelement tussen testvarianten wisselen: Als gebruikers in variant A de helpknop in de bovenbalk zien en gebruikers in variant B deze in de footer zien, ervaren die gebruikers inconsistente plaatsing van hulp op pagina’s binnen hun sessie, omdat het A/B‑framework verschillende varianten op verschillende pagina’s toepast. Zorg ervoor dat A/B‑tests die de plaatsing van hulpmiddelen beïnvloeden, de variant consistent toepassen op alle pagina’s in een sessie.
• Geauthenticeerde en niet-geauthenticeerde toestanden als verschillende “sites” behandelen en verschillende hulplay-outs toepassen: Gebruikers die halverwege de sessie inloggen, vinden het hulpmiddel plotseling op een nieuwe locatie. De wijziging van de authenticatiestatus is niet door de gebruiker geïnitieerd in de context van de plaatsing van hulp, dus dit is nog steeds een fout ten aanzien van SC 3.2.6. Pas een consistente hulplay-out toe in alle authenticatiestaten.
• Het hulpphone-nummer alleen opnemen in dichte voetteksttekst op sommige pagina’s en in een speciale headerbalk op andere: Zelfs als het telefoonnummer technisch op alle pagina’s aanwezig is, is een significante wijziging in de relatieve positie (van het eerste interactieve element in de header naar begraven in de footer na honderden links) een fout in consistente volgorde.
• Aannemen dat omdat een hulppictogram altijd visueel “in de hoek” staat, het aan het criterium voldoet: Het criterium meet de relatieve volgorde in de paginainhoud, niet alleen absolute pixelcoördinaten. Een chaticoon dat altijd visueel rechtsonder staat maar op verschillende pagina’s op een sterk afwijkend punt in de DOM-volgorde verschijnt (bijv. direct na de <body>-tag op de ene pagina en vlak voor de afsluitende </body>-tag op een andere) kan nog steeds een fout vormen voor toetsenbord- en schermlezersgebruikers.
• Vergeten responsieve breekpunten te auditen: Een hulpmiddel dat consistent is bij desktopbreedtes kan verborgen zijn of verplaatst worden naar een mobiel hamburgermenu bij smalle viewports, wat resulteert in een andere positie op mobiel. Als mobiele gebruikers een andere relatieve positie ervaren dan desktopgebruikers, moet dit worden beoordeeld ten opzichte van het criterium — vooral als mobiel de primaire toegangsmethode is voor de beoogde doelgroep.
• Locaties van hulpmiddelen niet documenteren in designsystemen: Zonder een gedocumenteerde standaard voor waar hulpmiddelen moeten verschijnen, zullen individuele ontwikkelaars en ontwerpers onafhankelijke beslissingen nemen die na verloop van tijd inconsistenties veroorzaken. Voeg regels voor de plaatsing van hulpmiddelen expliciet toe aan de documentatie van je designsysteem of componentenbibliotheek.

Relatie met de Toegankelijkheidsregelgeving van Turkije

De Turkse Presidential Circular 2025/10, gepubliceerd in het Staatsblad met nummer 32933 op 21 juni 2025, stelt een uitgebreid nationaal kader voor digitale toegankelijkheid vast. De circulaire verplicht naleving van WCAG 2.2 niveau AA als de basisnorm voor toegankelijkheid voor een breed scala aan digitale diensten die in Turkije actief zijn. WCAG 3.2.6 Consistente hulp, als een criterium op niveau AA dat in WCAG 2.2 is geïntroduceerd, valt rechtstreeks binnen de reikwijdte van deze wettelijke verplichting.

De entiteitstypen die onder Presidential Circular 2025/10 vallen, omvatten: publieke instellingen en agentschappen op zowel centraal als lokaal overheidsniveau; banken en financiële dienstverleners die onder toezicht staan van de Banking Regulation and Supervision Agency (BDDK); e‑commerceplatforms en online marktplaatsen; ziekenhuizen en zorgaanbieders die digitale diensten voor patiënten aanbieden; telecommunicatiebedrijven met 200,000 of meer abonnees; reisagentschappen met online boekingssystemen; particuliere vervoersbedrijven die lijndiensten exploiteren; en particuliere scholen en onderwijsinstellingen die zijn gemachtigd door het Ministry of National Education (MoNE). Voor al deze entiteiten is de volledige set WCAG 2.2 niveau AA‑criteria — inclusief SC 3.2.6 — de toepasselijke standaard.

Naleving van WCAG 3.2.6 is ook een vereiste voor het verkrijgen van het Erişilebilirlik Logosu (Toegankelijkheidslogo) dat wordt uitgegeven door het Turkse Ministry of Family and Social Services (Aile ve Sosyal Hizmetler Bakanlığı). Dit logo dient als een officieel keurmerk voor toegankelijkheidsconformiteit en wordt door Turkse consumenten en inkoopverantwoordelijken in toenemende mate erkend als een kwaliteitsindicator. Organisaties die het logo willen verkrijgen, moeten volledige WCAG 2.2 niveau AA‑conformiteit aantonen voor hun digitale eigendommen, wat betekent dat inconsistente plaatsing van hulp — zelfs als deze ogenschijnlijk klein is — een aanvraag kan diskwalificeren.

Vanuit praktisch nalevingsperspectief is SC 3.2.6 in het bijzonder relevant voor Turkse e‑commerce- en financiële dienstverleners, van wie de websites en mobiele webapps doorgaans livechatwidgets, WhatsApp-contactlinks en FAQ-secties bevatten als primaire kanalen voor klantenondersteuning. Ervoor zorgen dat deze hulpmiddelen op consistente posities verschijnen op productoverzichtspagina’s, winkelwagenpagina’s, checkoutflows en accountbeheersecties is zowel een wettelijke verplichting onder de circulaire als een goede UX‑praktijk voor het bedienen van de diverse internetgebruikers in Turkije — waaronder een grote groep eerste- en laaggeletterde digitale gebruikers die het meest profiteren van voorspelbare interfacepatronen.

Organisaties die onder de circulaire vallen en hun plaatsing van hulpmiddelen nog niet hebben geaudit, zouden een audit op consistentie tussen pagina’s moeten prioriteren als onderdeel van hun WCAG 2.2‑nalevingsroutekaart. Omdat dit criterium handmatig testen vereist, moet het worden opgenomen in zowel initiële conformiteitsaudits als doorlopende kwaliteitsborgingscycli, met name na grote herontwerpen of templatewijzigingen die onbedoeld de positie van hulpelementen kunnen verschuiven.