WCAG 2.4.5: Meerdere manieren

Wat Deze Regel Betekent

WCAG 2.4.5 — Meerdere manieren is een succescriterium op niveau AA onder het principe Bedienbaar. Het vereist dat elke webpagina die deel uitmaakt van een grotere set webpagina’s via ten minste twee verschillende navigatiemechanismen bereikbaar moet zijn. Met andere woorden: een gebruiker mag nooit gedwongen worden om op één enkele route te vertrouwen om een pagina te vinden.

Veelvoorkomende navigatiemechanismen die aan dit criterium voldoen zijn: een sitebrede zoekfunctie, een sitemap (als aparte pagina of als inline structuur), een inhoudsopgave, een consistente navigatiemenu of zijbalk, kruimelpaden en links tussen gerelateerde pagina’s. Elk willekeurig tweetal hiervan — of andere gelijkwaardige mechanismen — dat samen wordt gebruikt, voldoet aan de eis.

Het criterium is specifiek van toepassing op sets van webpagina’s. Een op zichzelf staande webpagina die niet tot een grotere site of applicatie behoort, is uitgezonderd. Daarnaast zijn pagina’s die het resultaat zijn van of een stap in een proces — zoals een afrekenbevestigingspagina, een succespagina na het verzenden van een formulier of een wizardstap — ook expliciet uitgezonderd. Dit komt doordat dergelijke pagina’s inherent sequentieel zijn en het ongepast of schadelijk zou zijn om directe toegang tot deze pagina’s buiten de volgorde om toe te staan.

Een pass vereist dat er ten minste twee onafhankelijke navigatiemechanismen aanwezig, functioneel en toegankelijk zijn in de hele site. Een fail treedt op wanneer er slechts één mechanisme bestaat — bijvoorbeeld een site die alleen een hoofdmenu bovenaan biedt, zonder zoekfunctie, zonder sitemap en zonder andere navigatiehulpmiddelen. Het is ook een fail als het secundaire mechanisme niet functioneert of niet toegankelijk is (bijv. een zoekveld dat geen resultaten oplevert, of een sitemap die verborgen is voor ondersteunende technologieën).

Belangrijk is dat dit criterium geen specifieke combinatie van mechanismen voorschrijft. De flexibiliteit is bewust: verschillende gebruikers hebben fundamenteel verschillende strategieën om content te vinden, en de standaard erkent deze diversiteit door redundantie te vereisen in plaats van een bepaalde oplossing voor te schrijven.

Waarom Het Belangrijk Is

Navigatie is de basis van elke webervaring, en barrières in de navigatie treffen mensen met een beperking onevenredig zwaar. Wanneer er maar één navigatiepad bestaat, worden gebruikers die dat pad niet kunnen gebruiken feitelijk buitengesloten van de content.

Voor gebruikers met motorische beperkingen — waaronder mensen die gebruikmaken van switch access, oogvolgapparaten, spraakbesturingssoftware of uitsluitend toetsenbordnavigatie — kunnen complexe hiërarchische menu’s uitputtend of onmogelijk zijn om efficiënt te doorlopen. Een sitezoekfunctie stelt hen in staat direct naar content te springen zonder meerdere menuniveaus te hoeven doorlopen. Omgekeerd kunnen gebruikers met bepaalde cognitieve of geheugenbeperkingen open zoekvelden verwarrend of moeilijk effectief te gebruiken vinden; voor hen is een duidelijk gestructureerde sitemap of een doorbladerbare categoriebomenstructuur veel nuttiger.

Voor blinde gebruikers die vertrouwen op schermlezers kan een dichtbevolkt navigatiemenu een terugkerende hindernis worden bij elk paginabezoek, zelfs met skiplinks. Een sitemap of zoek-snelkoppeling vermindert die cognitieve en fysieke belasting aanzienlijk. Voor gebruikers met slechte of beperkte gezichtsscherpte die schermvergroting gebruiken, zijn brede navigatiemenu’s bij hoge zoomniveaus mogelijk slechts gedeeltelijk zichtbaar, waardoor een tekstgebaseerde zoekfunctie of sitemap een cruciale fallback wordt.

Voor gebruikers met cognitieve beperkingen zoals dyslexie of aandachtsstoornissen kan de mogelijkheid om te zoeken met benaderende of gedeeltelijke termen — in plaats van de exacte menuhiërarchie te moeten onthouden of herkennen — het verschil maken tussen zelfstandig content vinden en volledig afhaken.

Een concreet scenario uit de praktijk: stel je een gebruiker met reumatoïde artritis voor die een Turks e-commerceplatform bezoekt en alleen het toetsenbord gebruikt. Het mega-menu van de site vereist precieze muis-hoverinteracties om subcategorieën te tonen, en het focusgedrag via het toetsenbord is onbetrouwbaar. Als de site ook een zoekbalk en een sitemap biedt, kan die gebruiker nog steeds de productpagina vinden die hij of zij nodig heeft. Zonder die alternatieven is de site in de praktijk onbruikbaar voor deze persoon — en dat betekent een verloren klant en een potentiële juridische aansprakelijkheid.

Los van toegankelijkheid bieden meerdere navigatiemechanismen meetbare SEO- en bruikbaarheidsvoordelen. Sitemaps verbeteren de crawlbaarheid door zoekmachinebots. Sitezoekfunctionaliteit verhoogt de gebruikersbetrokkenheid en verlaagt het bouncepercentage. Kruimelpaden verbeteren de doorklikratio in zoekresultatenpagina’s wanneer ze met gestructureerde data zijn geïmplementeerd. Deze voordelen betekenen dat voldoen aan 2.4.5 niet alleen een nalevingsoefening is — het is goed webdesign.

Gerelateerde Axe-core-regels

WCAG 2.4.5 vereist handmatige tests omdat geen enkel geautomatiseerd hulpmiddel betrouwbaar kan bepalen of een site voldoende variatie in navigatie biedt. Geautomatiseerde scanners kunnen controleren of specifieke elementen bestaan en syntactisch correct zijn, maar ze kunnen de sitebrede navigatiearchitectuur niet beoordelen of bepalen of een bepaalde combinatie van mechanismen werkelijk toereikend is. De volgende overwegingen sturen de handmatige evaluatie:

• Aanwezigheid van een sitezoekfunctie (handmatige controle): Geautomatiseerde tools kunnen niet bevestigen of een zoekveld functioneel is, zinvolle resultaten oplevert of toegankelijk is op de hele site. Een tester moet handmatig verifiëren dat er een zoekmechanisme bestaat, via het toetsenbord bereikbaar is en relevante resultaten oplevert voor representatieve zoekopdrachten.
• Aanwezigheid van een sitemap of alternatief navigatiemechanisme (handmatige controle): Tools kunnen niet bepalen of er een sitemappagina bestaat, of deze vanaf alle pagina’s is gelinkt of dat deze de site-inhoud volledig dekt. Een menselijke beoordelaar moet bevestigen dat er ten minste één extra mechanisme naast de primaire navigatie beschikbaar en toegankelijk is.
• Consistentie van navigatie (heeft betrekking op 2.4.3 en 3.2.3, handmatige controle): Geautomatiseerde tools kunnen inconsistente volgordes van componenten op verschillende pagina’s signaleren, maar kunnen niet beoordelen of de algehele navigatiestrategie coherent en voldoende blijft voor gebruikers met een beperking. Handmatige beoordeling van meerdere representatieve paginatypen is vereist.
• Toegankelijkheid van secundaire mechanismen (handmatige controle): Zelfs als er een sitemap of zoekfunctie bestaat, kan een geautomatiseerde scan geen gevallen detecteren waarin deze mechanismen niet met het toetsenbord te bedienen zijn, slechte schermlezerlabels hebben of visueel verborgen zijn op een manier die de bruikbaarheid beïnvloedt. Handmatige toetsenbord- en schermlezertests moeten bevestigen dat elk mechanisme end-to-end werkt.

Hoe te Testen

1. Geautomatiseerde scan — stel een basislijn vast: Voer axe DevTools of Lighthouse uit op representatieve pagina’s van de site. Hoewel geen van beide tools direct 2.4.5-overtredingen markeert, gebruik je de audit om navigatiecomponenten (menu’s, zoekvelden, kruimelpaden) te identificeren met onderliggende toegankelijkheidsproblemen zoals ontbrekende labels, onjuiste ARIA-rollen of focusbeheerproblemen. Los deze eerst op, omdat een defect navigatiemechanisme niet kan meetellen als een geldige “manier” onder 2.4.5.
2. Breng navigatiemechanismen in kaart: Beoordeel de site handmatig en maak een lijst van elk afzonderlijk mechanisme dat een gebruiker kan gebruiken om een bepaalde pagina te bereiken: hoofdmenu’s, footerlinks, sitezoekfunctie, sitemappagina’s, kruimelpaden, links naar gerelateerde content, categorie-indexen, enzovoort. Bevestig dat ten minste twee van deze mechanismen aanwezig, functioneel en beschikbaar zijn op elke pagina die geen deel uitmaakt van een sequentieel proces.
3. Test met alleen toetsenbordnavigatie: Gebruik uitsluitend de Tab-, Enter-, pijltjestoetsen en Escape (geen muis) en probeer een specifieke niet-homepagina via twee verschillende mechanismen te bereiken. Gebruik bijvoorbeeld de zoekbalk om een productpagina te vinden en gebruik vervolgens de sitemap of het navigatiemenu om dezelfde pagina te bereiken. Bevestig dat beide paden volledig zonder muis te bedienen zijn.
4. Schermlezertest met NVDA + Firefox: Start NVDA, open Firefox en navigeer naar de homepage. Gebruik de browse-modus van NVDA (F6 voor landmarks, H voor koppen) om de zoek-landmark en eventuele sitemap- of navigatielinks te vinden. Bevestig dat beide mechanismen correct worden aangekondigd, dat formuliervelden toegankelijke labels hebben en dat resultaten- of bestemmingspagina’s laden en leesbaar zijn.
5. Schermlezertest met VoiceOver + Safari (macOS/iOS): Activeer VoiceOver (Cmd+F5) en gebruik de Rotor (VO+U) om de formulierelementen en links op de pagina te inspecteren. Bevestig dat het zoekveld wordt vermeld en gelabeld, en dat navigatielinks die naar een sitemap of alternatief indexoverzicht leiden aanwezig en bedienbaar zijn.
6. Schermlezertest met JAWS + Chrome: Gebruik JAWS-navigatietoetsen (F om naar formulieren te springen, Insert+F7 voor de linklijst) om te verifiëren dat het zoekveld en eventuele sitemapslinks vindbaar en bruikbaar zijn via zowel het toetsenbord als de virtuele cursor.
7. Controle van de uitzondering voor sequentiële processen: Identificeer alle pagina’s die stappen in een proces zijn (afrekenen, meerstapsformulieren, inlogflows). Bevestig dat deze pagina’s niet hoeven te voldoen aan de eis van meerdere manieren. Documenteer dit in je toegankelijkheidsaudit om fout-positieve fails te voorkomen.
8. Verificatie van functionele zoekresultaten: Voer meerdere representatieve zoekopdrachten uit (productnamen, artikeltitels, ondersteuningsthema’s). Bevestig dat er resultaten verschijnen, dat deze relevant zijn en dat de resultatenpagina toegankelijk en navigeerbaar is met toetsenbord en schermlezer.

Hoe te Herstellen

Ontbrekende sitezoekfunctie — Onjuist

<!-- Site only has a navigation menu; no search or sitemap provided -->
<nav aria-label='Main navigation'>
  <ul>
    <li><a href='/urunler'>Ürünler</a></li>
    <li><a href='/hakkimizda'>Hakkımızda</a></li>
    <li><a href='/iletisim'>İletişim</a></li>
  </ul>
</nav>
<!-- No search, no sitemap link, no other navigation mechanism -->

Ontbrekende sitezoekfunctie — Juist

<!-- Navigation menu retained, and a site search is added as a second mechanism -->
<nav aria-label='Main navigation'>
  <ul>
    <li><a href='/urunler'>Ürünler</a></li>
    <li><a href='/hakkimizda'>Hakkımızda</a></li>
    <li><a href='/iletisim'>İletişim</a></li>
  </ul>
</nav>

<!-- Second navigation mechanism: accessible site search -->
<form role='search' action='/arama' method='get'>
  <label for='site-search'>Sitede Ara</label>
  <input
    type='search'
    id='site-search'
    name='q'
    placeholder='Ürün veya konu arayın...'
    aria-label='Site genelinde arama'
  />
  <button type='submit'>Ara</button>
</form>

Ona toegankelijke sitemap — Onjuist

<!-- Sitemap link is present but visually hidden and unreachable by keyboard -->
<footer>
  <a href='/site-haritasi' style='display:none;'>Site Haritası</a>
</footer>
<!-- display:none removes the element from both visual display AND
     the accessibility tree, so screen reader users cannot reach it.
     This sitemap cannot count as a valid second navigation mechanism. -->

Ona toegankelijke sitemap — Juist

<!-- Sitemap link is visible and accessible to all users -->
<footer>
  <nav aria-label='Footer navigation'>
    <ul>
      <li><a href='/site-haritasi'>Site Haritası</a></li>
      <li><a href='/gizlilik'>Gizlilik Politikası</a></li>
      <li><a href='/iletisim'>İletişim</a></li>
    </ul>
  </nav>
</footer>
<!-- The sitemap page itself should list all major sections and pages
     of the site using <nav>, <ul>, and <a> elements. -->

Zoekformulier zonder toegankelijk label — Onjuist

<!-- Search input has no label; screen readers announce only 'edit text' -->
<form action='/search'>
  <input type='text' name='q' placeholder='Search...' />
  <button type='submit'><img src='search-icon.png' /></button>
</form>

Zoekformulier zonder toegankelijk label — Juist

<!-- role='search' identifies the landmark; label associates text with input;
     submit button has an accessible name via aria-label -->
<form role='search' action='/arama' method='get'>
  <label for='global-search'>Arama</label>
  <input
    type='search'
    id='global-search'
    name='q'
    autocomplete='off'
  />
  <button type='submit' aria-label='Aramayı başlat'>
    <img src='search-icon.png' alt='' aria-hidden='true' />
  </button>
</form>

Veelvoorkomende Fouten

• Een XML-sitemap meetellen als een voor gebruikers bedoeld navigatiemechanisme: Een XML-sitemap die bij zoekmachines wordt ingediend (bijv. /sitemap.xml) is een machineleesbaar bestand en kan niet door gewone bezoekers worden gebruikt. Alleen een HTML-sitemappagina, door mensen te doorbladeren, telt als een geldig tweede navigatiemechanisme.
• Een zoekformulier aanbieden dat puur decoratief of defect is: Een zoekveld dat altijd lege resultaten teruggeeft, fouten oplevert bij het verzenden of doorstuurt naar een 404-pagina voldoet niet aan 2.4.5. Het mechanisme moet daadwerkelijk functioneel zijn om het criterium te halen.
• De sitemaplink verbergen achter JavaScript dat faalt of is uitgeschakeld: Als de enige link naar een sitemap zich in een dynamisch ingeladen modal bevindt of in een van JavaScript afhankelijke dropdown die in bepaalde omgevingen faalt, verliezen gebruikers die dat JavaScript niet kunnen uitvoeren (waaronder sommige configuraties met ondersteunende technologie) de toegang tot dat navigatiemechanisme.
• display:none of visibility:hidden toepassen op een navigatiemechanisme op mobiele viewports: Het volledig verbergen van een zoekbalk of sitemaplink in de mobiele layout verwijdert dat mechanisme volledig voor mobiele gebruikers, wat een fail is — zelfs als de desktoplayout wel slaagt. Het mechanisme achter een toegankelijke toggleknop verbergen is acceptabel; het uit de DOM of de toegankelijkheidsboom verwijderen is dat niet.
• Kruimelpaden als zelfstandig tweede mechanisme beschouwen zonder extra ondersteuning: Kruimelpaden tonen alleen het pad naar de huidige pagina en zijn op zichzelf niet voldoende om een gebruiker te helpen willekeurige pagina’s op een site te ontdekken en te bereiken. Ze kunnen andere mechanismen aanvullen, maar kunnen doorgaans niet als een van de twee vereiste mechanismen op zichzelf dienen.
• Pagina’s ten onrechte van de eis uitzonderen: De uitzondering voor sequentiële processen geldt alleen voor pagina’s die letterlijk stappen in een proces zijn (bijv. stap 2 van 4 in een checkout). Categoriepagina’s, productdetailpagina’s en blogposts zijn niet uitgezonderd, zelfs niet als de gebruiker daar via een funnel is terechtgekomen.
• Een zoekveld met type='text' gebruiken in plaats van type='search' en role='search' op het formulier weglaten: Hoewel dit geen directe 2.4.5-overtreding is, betekent het dat schermlezergebruikers die via landmarks navigeren de zoekregio niet kunnen vinden. Het mechanisme bestaat technisch gezien, maar is in de praktijk moeilijker te ontdekken, wat de bedoeling van het criterium ondermijnt.
• Twee mechanismen bieden die in feite identiek zijn: Een hoofdmenu bovenaan en een footermenu met exact dezelfde links in exact dezelfde structuur vormen geen twee betekenisvol verschillende navigatiemechanismen. De bedoeling is dat gebruikers met verschillende behoeften alternatieve strategieën kunnen vinden — niet dat dezelfde strategie twee keer op de pagina verschijnt.
• Bepaalde paginatypen uitsluiten van het navigatiesysteem: Sommige CMS-configuraties plaatsen blogposts, juridische pagina’s of gebruikersaccountpagina’s buiten de hoofdsitekaart of zoekindex. Als gebruikers deze pagina’s niet via ten minste twee mechanismen kunnen vinden, falen die pagina’s 2.4.5, ongeacht hoe goed de rest van de site is gestructureerd.
• De mechanismen niet testen met ondersteunende technologie: Omdat 2.4.5 handmatige tests vereist, zullen teams die uitsluitend op geautomatiseerde tools vertrouwen, fails missen die worden veroorzaakt door toetsenbordvallen in zoekformulieren, niet-gelabelde invoervelden of sitemaps die wel in de DOM staan maar onbereikbaar zijn via schermlezer-landmarknavigatie.

Relatie met de Toegankelijkheidsregelgeving van Turkije

Het Turkse Presidentieel Circulaire nr. 2025/10, gepubliceerd in het Staatsblad (Resmî Gazete) nr. 32933 op 21 juni 2025, stelt bindende webtoegankelijkheidsverplichtingen vast voor een breed scala aan publieke en private organisaties. De Circulaire schrijft conformiteit met internationaal erkende toegankelijkheidsstandaarden voor en brengt de Turkse wettelijke vereisten in lijn met WCAG 2.1 en WCAG 2.2 niveau AA als minimale verwachting.

WCAG 2.4.5 — Meerdere manieren is een criterium op niveau AA, wat betekent dat het volledig binnen het conformiteitsniveau valt dat door de Circulaire wordt vereist. Organisaties die onder de regelgeving vallen, moeten ervoor zorgen dat alle webpagina’s die tot een set behoren ten minste twee navigatiemechanismen bieden, zoals in dit criterium beschreven. Het niet voldoen aan deze eis is een directe niet-naleving van het wettelijke voorschrift.

De organisaties die onder Presidentieel Circulaire 2025/10 vallen, omvatten: overheidsinstellingen en -organen op alle niveaus; banken en financiële instellingen; ziekenhuizen en zorgaanbieders; elektronische handelsplatforms; telecomoperators met 200.000 of meer abonnees; reisbureaus; particuliere vervoersbedrijven; en particuliere scholen die opereren onder autorisatie van het Ministerie van Nationaal Onderwijs (Millî Eğitim Bakanlığı, MEB). Van elk van deze typen organisaties wordt verwacht dat zij toegankelijke navigatie met meerdere paden op hun webdomeinen in stand houden.

Naast de verplichte conformiteitseisen verstrekt het Ministerie van Gezin en Sociale Diensten (Aile ve Sosyal Hizmetler Bakanlığı) het Erişilebilirlik Logosu (Toegankelijkheidslogo) aan organisaties die sterke toegankelijkheidspraktijken aantonen. Het verkrijgen van dit logo vereist volledige conformiteit met niveau AA, inclusief naleving van 2.4.5. Voor bedrijven die actief zijn op de concurrerende digitale markt van Turkije — met name e-commerceplatforms, banken en zorgaanbieders — fungeert het Toegankelijkheidslogo zowel als een vertrouwenssignaal voor gebruikers met een beperking als bewijs van goede trouw in de naleving van regelgeving.

In de praktijk profiteren Turkse websites die diverse gebruikerspopulaties bedienen aanzienlijk van de implementatie van meerdere navigatiemechanismen. Turkije heeft een grote populatie oudere internetgebruikers en gebruikers in regio’s met een lagere digitale geletterdheid, die beiden baat hebben bij de redundantie die 2.4.5 voorschrijft. Een sitezoekfunctie met Turkse taalondersteuning (inclusief correcte verwerking van Turks-specifieke tekens zoals ı, İ, ş, ğ, ü, ö, ç) in combinatie met een duidelijk gestructureerde HTML-sitemap vormt een toegankelijke, aan de regelgeving conforme implementatie die deze doelgroep goed bedient. Organisaties die het Erişilebilirlik Logosu willen verkrijgen of behouden, moeten 2.4.5-conformiteit niet als een optionele verbetering zien, maar als een fundamentele vereiste van hun toegankelijkheidsprogramma.