WCAG 1.3.6: Doel identificeren

Wat Deze Regel Betekent

\n

WCAG 1.3.6 — Identify Purpose is een criterium op niveau AAA onder Principe 1 (Waarneembaar) dat de bestaande structuur- en semantiekvereisten uitbreidt naar een fijner detailniveau. Concreet vereist het dat het doel van elk gebruikersinterfacecomponent, pictogram, gebied en bepaalde invoervelden programmatisch kan worden bepaald — wat betekent dat de semantische informatie zo wordt blootgelegd dat browsers, browserextensies en ondersteunende technologieën deze kunnen lezen en erop kunnen reageren.

\n

Het criterium bouwt direct voort op 1.3.1 (Info and Relationships) en 1.3.5 (Identify Input Purpose). Waar 1.3.5 zich richt op veelvoorkomende invoervelden voor persoonsgegevens (naam, e‑mail, telefoon, enz.), verbreedt 1.3.6 de eis naar alle gebruikersinterfacegebieden en -componenten, waaronder navigatielandmarks, pictogrammen, knoppen en interactieve widgets. De kernidee is dat een user agent of personalisatietool de standaardpresentatie moet kunnen vervangen — tekstlabels vervangen door symbolen, een drukke navigatie vereenvoudigen of de meest relevante bedieningselementen markeren — op basis van machinaal leesbare doeldata die in de markup is ingebed.

\n

In praktische termen voldoet een pagina aan 1.3.6 wanneer deze HTML5-landmarkelementen gebruikt (zoals <header>, <nav>, <main>, <aside>, <footer> en <section>), waar geen landmarkelementen worden gebruikt passende ARIA-landmarkrollen toepast, het doel van pictogrammen en andere niet-tekstuele UI-componenten blootlegt via toegankelijke namen of rollen, en — waar van toepassing — gestandaardiseerde purposetokens gebruikt zoals gedefinieerd in de W3C Personalization Semantics-specificatie (voorheen bekend als het COGA Semantics-voorstel), bijvoorbeeld via de aui--attribuutwoordenschat.

\n

Een pagina faalt wanneer haar gebieden zijn geïmplementeerd als generieke <div>- of <span>-containers zonder semantische rol, wanneer pictogrammen betekenis dragen maar geen toegankelijke naam of ondersteunende semantiek hebben, of wanneer interactieve componenten geen programmatische aanwijzing geven over hun functie buiten hun zichtbare uiterlijk. Er geldt een officiële uitzondering: de eis is alleen van toepassing op content die is geïmplementeerd met technologieën die ondersteuning bieden voor het identificeren van de verwachte betekenis. Als er geen ondersteunende technologie of specificatie bestaat voor een bepaald componenttype in een bepaalde technologiestack, kan het criterium redelijkerwijs niet op dat component worden toegepast.

\n\n

Waarom Het Belangrijk Is

\n

De primaire begunstigden van WCAG 1.3.6 zijn mensen met cognitieve en leerstoornissen, waaronder dyslexie, aandachtstekortstoornissen, autismespectrumstoornissen, geheugenstoornissen en verstandelijke beperkingen. Volgens de Wereldgezondheidsorganisatie leeft ongeveer 1 op de 6 mensen wereldwijd — meer dan één miljard individuen — met een vorm van significante beperking, en cognitieve beperkingen vormen een van de grootste en meest onderbediende groepen. Veel van deze gebruikers hebben moeite met complexe navigatiestructuren, dicht opeengepakte tekstmenu’s en pictogram‑only bedieningselementen die geen semantisch houvast bieden.

\n

Neem een concreet scenario: een gebruiker met ernstige dyslexie vertrouwt op een browserextensie die standaard navigatielabels vervangt door persoonlijke symboolsets — op afbeeldingen gebaseerde pictogrammen van een communicatiebord dat zij in het dagelijks leven gebruiken. Om deze vervanging te laten werken, moet de extensie kunnen bepalen dat een bepaalde <div> in feite een navigatielandmark is, dat een sterpictogram “toevoegen aan favorieten” betekent, en dat een cirkelvormige pijl “vernieuwen” betekent. Zonder programmatisch bepaalbaar doel heeft de extensie niets om zich aan vast te houden en faalt de vervanging stilzwijgend, waardoor de gebruiker achterblijft met een interface die zij niet kunnen ontcijferen.

\n

Motorisch beperkte gebruikers die afhankelijk zijn van switch access of spraakbesturing profiteren ook aanzienlijk, omdat doelbewuste tools sneltoetsoverlays of spraakcommandomappingen kunnen genereren alleen voor bedieningselementen waarvan de functie machinaal leesbaar is. Blinde gebruikers die via schermlezers interageren, profiteren van duidelijk gelabelde landmarkgebieden, waarmee zij direct naar <main>-content kunnen springen of herhalende navigatie kunnen overslaan. Gebruikers met een beperkt gezichtsvermogen die browserzoom of aangepaste stylesheets gebruiken, profiteren van landmarkstructuur omdat deze de browser in staat stelt content voorspelbaar te herschikken.

\n

Naast toegankelijkheid levert het implementeren van de semantiek die door 1.3.6 wordt vereist meetbare SEO‑voordelen op. Zoekmachinecrawlers gebruiken landmark- en schemamarkup om de paginastructuur te begrijpen, inhoudshiërarchieën te indexeren en rijke resultaten te genereren. Een goed gestructureerde pagina met betekenisvolle landmarkgebieden heeft meer kans op featured snippets en hogere relevantiescores. Er is ook een direct bruikbaarheidsdividend: pagina’s met een duidelijke semantische structuur zijn eenvoudiger te onderhouden, testen en uitbreiden door ontwikkelingsteams, wat de langetermijn technische schuld vermindert.

\n\n

Gerelateerde Axe-core-regels

\n

WCAG 1.3.6 vereist handmatig testen naast eventuele geautomatiseerde controles. Geautomatiseerde tools kunnen de aanwezigheid van semantische markup verifiëren, maar kunnen niet bepalen of die markup het doel van elk component net zo nauwkeurig en volledig weergeeft als een menselijke tester. De volgende axe-core-regels zijn nauw verwant en dienen als geautomatiseerde proxy’s voor aspecten van dit criterium:

\n

\n
• region — Controleert of alle content op de pagina binnen een landmarkgebied is opgenomen. Het markeert content die buiten een erkend landmarkelement of ARIA-landmarkrol valt. Hoewel deze regel de nauwkeurigheid van doelidentificatie niet test, zorgt hij ervoor dat de structurele basis die door 1.3.6 wordt vereist aanwezig is. Een fail betekent dat significante content onzichtbaar is voor landmarkgebaseerde navigatie.
\n
• landmark-one-main — Verifieert dat de pagina precies één <main>-element of element met role='main' bevat. Dit is fundamenteel voor 1.3.6 omdat het hoofdcontentgebied een van de belangrijkste regio’s is waarvan het doel identificeerbaar moet zijn. Meerdere of ontbrekende <main>-landmarks maken het onmogelijk voor personalisatietools om primaire content te isoleren.
\n
• landmark-complementary-is-top-level — Controleert dat <aside>-elementen of role='complementary'-gebieden niet binnen het hoofdcontentgebied zijn genest op een manier die hun doel verkeerd weergeeft. Onjuiste nesting misleidt ondersteunende technologie over de relatie tussen gebieden.
\n
• aria-allowed-role en aria-valid-attr-value — Markeren ongeldige of ongeschikte ARIA-roltoewijzingen. Omdat 1.3.6 afhankelijk is van nauwkeurige rolsemantiek, ondermijnt het gebruik van een onjuiste rol (bijv. role='navigation' op een buttongroep) actief de doelidentificatie en deze regels zullen dergelijke mismatches aan het licht brengen.
\n
• button-name en link-name — Verifiëren dat interactieve bedieningselementen toegankelijke namen hebben. Pictogram‑only knoppen en links zonder toegankelijke namen zijn een primaire faalmodus voor 1.3.6, omdat er geen doel kan worden bepaald voor een bedieningselement zonder naam. Deze regels markeren de afwezigheid van aria-label, aria-labelledby of zichtbare tekst.
\n

\n

Handmatig testen is vereist omdat geautomatiseerde tools niet kunnen beoordelen of de gekozen purposetokens of semantische rollen de werkelijke functie van het component binnen de context van de applicatie nauwkeurig weergeven. Een knop kan een toegankelijke naam en een geldige ARIA-rol hebben, maar nog steeds niet voldoen aan 1.3.6 als de naam misleidend is of de rol niet weerspiegelt wat het bedieningselement daadwerkelijk doet.

\n\n

Hoe te Testen

\n

\n
1. Voer een geautomatiseerde scan uit met axe DevTools of Lighthouse. Open de pagina in Chrome, activeer de axe DevTools-extensie en voer een scan van de volledige pagina uit. Filter de resultaten op de hierboven vermelde regels: region, landmark-one-main, button-name en link-name. Noteer eventuele overtredingen en hun impactratings. Voer in Lighthouse een Accessibility-audit uit en bekijk de secties over landmarks en ARIA. Documenteer alle fouten als basislijn, maar begrijp dat deze slechts een subset van de 1.3.6‑compliance vertegenwoordigen.
\n
2. Inspecteer de landmarkstructuur handmatig met behulp van browserontwikkeltools. Open DevTools, navigeer naar het Accessibility Tree-paneel (Chrome) of de Accessibility Inspector (Firefox) en verifieer dat de pagina een coherente landmarkhiërarchie blootlegt: één <header> op het hoogste niveau, één <main>, ten minste één <nav> (met een onderscheidend label als er meerdere aanwezig zijn) en een <footer>. Bevestig dat geen enkel betekenisvol contentgebied uitsluitend is omwikkeld met een generieke <div> of <span>.
\n
3. Test met NVDA en Firefox. Start NVDA, open de pagina in Firefox en druk op D om door landmarks te bladeren. Verifieer dat elke landmark wordt aangekondigd met een betekenisvolle rol en, waar meerdere landmarks van hetzelfde type bestaan, een uniek label. Navigeer naar elke pictogram‑only knop met de Tab-toets en bevestig dat NVDA een beschrijvende toegankelijke naam aankondigt — geen lege string, bestandsnaam of generiek label zoals “button”.
\n
4. Test met VoiceOver en Safari (macOS/iOS). Schakel VoiceOver in (Cmd+F5 op macOS). Gebruik de Rotor (Vo+U) om de lijst met Landmarks te openen en verifieer dat alle verwachte gebieden verschijnen. Tab door interactieve bedieningselementen en luister naar betekenisvolle beschrijvingen. Gebruik op iOS een veeg met drie vingers om te navigeren op koppen en landmarks en bevestig dat het doel van elk gebied correct wordt aangekondigd.
\n
5. Test met JAWS en Chrome. Open de pagina in Chrome met JAWS actief. Druk op R om door gebieden te navigeren en bevestig dat de rol en het label van elk gebied kloppen. Gebruik de JAWS Virtual Cursor om pictogramknoppen door te lezen en verifieer dat hun doel wordt overgebracht. Gebruik de JAWS List of Links (Insert+F7) om alle linknamen op betekenisvolheid te controleren.
\n
6. Test personalisatiesemantiek (indien geïmplementeerd). Als je pagina de W3C Personalization Semantics-woordenschat gebruikt (bijv. data-purpose of aui--attributen), gebruik dan de Personalization Semantics test tool of een compatibele browserextensie om te verifiëren dat purposetokens correct zijn toegepast en machinaal leesbaar zijn voor user agents die de specificatie ondersteunen.
\n
7. Voer een component-voor-component-doelaudit uit. Stel voor elk interactief component en pictogram op de pagina de vraag: kan het doel van dit component worden bepaald zonder visuele context? Als het verwijderen van alle CSS en afbeeldingen het doel van het component nog steeds duidelijk laat blijken uit alleen de DOM- en ARIA-attributen, dan slaagt het. Als het doel uitsluitend visueel wordt overgebracht, faalt het.
\n

\n\n

Hoe te Herstellen

\n\n

Generieke div-gebieden zonder landmarks — Onjuist

\n

<div class='site-header'>\n  <div class='logo'>Accsible</div>\n  <div class='main-nav'>\n    <a href='/home'>Home</a>\n    <a href='/pricing'>Pricing</a>\n  </div>\n</div>\n<div class='main-content'>\n  <p>Welcome to our platform.</p>\n</div>\n<div class='sidebar'>\n  <p>Related articles</p>\n</div>\n<div class='site-footer'>\n  <p>© 2025 Accsible</p>\n</div>

\n\n

Generieke div-gebieden zonder landmarks — Juist

\n

<!-- Gebruik native HTML5-landmarkelementen zodat browsers en AT\n     het doel van elk gebied programmatisch kunnen identificeren -->\n<header>\n  <a href='/' aria-label='Accsible home'>\n    <img src='logo.svg' alt='Accsible' />\n  </a>\n  <nav aria-label='Primary navigation'>\n    <a href='/home'>Home</a>\n    <a href='/pricing'>Pricing</a>\n  </nav>\n</header>\n<main>\n  <p>Welcome to our platform.</p>\n</main>\n<aside aria-label='Related articles'>\n  <p>Related articles</p>\n</aside>\n<footer>\n  <p>© 2025 Accsible</p>\n</footer>

\n\n

Pictogram‑only knop zonder toegankelijke naam — Onjuist

\n

<!-- Een pictogramknop waarvan het doel niet programmatisch\n     kan worden bepaald — hij heeft helemaal geen toegankelijke naam -->\n<button class='btn-icon'>\n  <svg viewBox='0 0 24 24' width='24' height='24'>\n    <path d='M12 2l3.09 6.26L22 9.27l-5 4.87 1.18 6.88L12 17.77l-6.18 3.25L7 14.14 2 9.27l6.91-1.01L12 2z'/>\n  </svg>\n</button>

\n\n

Pictogram‑only knop zonder toegankelijke naam — Juist

\n

<!-- aria-label geeft de knop een programmatisch bepaalbaar\n     doel; de SVG is verborgen voor AT omdat het label dit afdekt -->\n<button class='btn-icon' aria-label='Add to favourites'>\n  <svg viewBox='0 0 24 24' width='24' height='24' aria-hidden='true' focusable='false'>\n    <path d='M12 2l3.09 6.26L22 9.27l-5 4.87 1.18 6.88L12 17.77l-6.18 3.25L7 14.14 2 9.27l6.91-1.01L12 2z'/>\n  </svg>\n</button>

\n\n

Meerdere navigatielandmarks zonder onderscheidende labels — Onjuist

\n

<!-- Twee nav-elementen met identieke rollen maar geen labels:\n     schermlezers kunnen hun doel niet onderscheiden -->\n<nav>\n  <a href='/home'>Home</a>\n  <a href='/about'>About</a>\n</nav>\n\n<nav>\n  <a href='/page1'>Chapter 1</a>

(Content truncated due to token limit — please retry this article.)