Begin bij taken en een kleine informatiearchitectuur
Informatiearchitectuur is hoe inhoud en functies worden gegroepeerd, benoemd en verbonden. Noteer bezoekerstaken en map voor elke taak de startpagina, de volgende pagina en de succesvolle eindstaat. Dit toont of een menu-item nuttig is of een interne term die bezoekers moeten ontcijferen. Houd de primaire navigatie gericht op secties die die taken starten.
Navigatie is geen sitemap. GOV.UK raadt aan nuttige topniveausecties te benoemen in plaats van elk onderdeel van een dienst. Als een traject een verplichte volgorde heeft, toon die dan in de inhoud of een takenlijst in plaats van bezoekers die uit een globaal menu te laten afleiden.
Plaats pagina’s samen wanneer bezoekers hetzelfde antwoord of dezelfde taak verwachten, niet omdat één team ze beheert.
Gebruik landingspagina’s en contextuele links voor detail in plaats van een dicht header-menu.
Gebruik labels die de bestemming voorspellen
Een label is een belofte over wat volgt. Geef de voorkeur aan vertrouwde namen zoals “Pricing”, “Documentation”, “Get support” of “Manage account” wanneer ze bij de bestemming passen. Vermijd vage labels zoals “Resources” of “Explore” tenzij bezoekers de inhoud kunnen voorspellen. Houd woordkeuze en volgorde consistent.
Google adviseert beknopte, relevante linktekst die buiten context begrijpelijk is. Generieke “klik hier” en met zoekwoorden volgestouwde links doen dat niet. Geef een alleen-icoonbediening een toegankelijke naam die de actie beschrijft.
Gebruik “View plans” in plaats van “Learn more” wanneer de bestemming plannen zijn.
Markeer de actieve bestemming visueel en programmatisch; W3C beschrijft aria-current=page voor de weergegeven pagina.
Maak bestemmingen crawlable en structureel duidelijk
Een navigatiebestemming moet normaal gesproken een HTML-anchor met een href zijn die naar een echte webadres verwijst. Google zegt dat het dit formaat doorgaans kan crawlen, inclusief dynamisch ingevoegde anchors wanneer de gerenderde markup die structuur behoudt. Een click-handler of aangepast attribuut alleen is geen betrouwbare vervanging. Inspecteer de gerenderde output, niet alleen de framework-bron.
Gebruik semantische structuur rond belangrijke navigatie. W3C raadt een nav-element aan en, voor gewone site-navigatie, een lijst. Als een pagina meerdere navigatieregio’s heeft, label elke regio zodat een screenreader-gebruiker primaire navigatie van footer- of lokale navigatie kan onderscheiden.
Bevestig dat belangrijke desktop- en mobielbestemmingen anchors en href-waarden hebben na client-side rendering.
URL Inspection levert Google crawl-, index- en serving-informatie; het bewijst niet dat bezoekers een pagina kunnen vinden.
Ontwerp het mobiele menu als een complete interactie
Responsieve navigatie mag inklappen, maar bestemmingen die blijven moeten dezelfde woordkeuze, volgorde en doel hebben op alle schermformaten. W3C staat toe om items in subnavigatie te verbergen of in te klappen terwijl het consistentie vraagt. Maak geen kritisch pad alleen desktop-beschikbaar omdat de header vol raakt; verplaats lagere prioriteit of heroverweeg de hiërarchie.
Voor een show-en-hide-menu gebruik je een knop om de groep links te bedienen en om te communiceren of deze open is. W3C’s disclosure-navigation-voorbeeld gebruikt aria-expanded en aria-controls en documenteert Tab, Shift+Tab en Escape. Het is instructief, dus test je component met de combinaties die jouw publiek gebruikt.
Wanneer zowel een ouderpagina als zijn kindlinks nodig zijn, onderscheid dan de paginalink van de bediening die het uitklapt.
Alles wat door pointer-hover wordt onthuld moet ook vindbaar zijn met toetsenbordsfocus en touch.
Ondersteun oriëntatie en toetsenbordnavigatie
Toegankelijkheid via toetsenbord is geen afronding. WCAG 2.1 Success Criterion 2.1.1 vereist dat functionaliteit via een toetsenbordinterface bedienbaar is, behalve voor pad-afhankelijke invoer. In een header moeten bezoekers met Tab door controles kunnen, de focus zien, links en knoppen activeren en weg kunnen bewegen zonder in een val te lopen.
Herhaalde header-links kunnen pagina’s traag maken om door te reizen. Een skip-link vlak bij het begin geeft toetsenbordgebruikers een route naar de hoofdinhoud. GOV.UK legt uit dat deze visueel verborgen is totdat toetsenbordgebruik hem activeert. Test dat hij op een betekenisvol doel landt.
Verwijder de browser-focusindicator niet zonder een duidelijk alternatief dat zichtbaar blijft bij inzoomen.
Gebruik Tab, Shift+Tab, Enter, Space en Escape van de header naar de doelpagina.
Test vindbaarheid voor en na release
Vraag representatieve mensen een realistische taak uit te voeren, zoals het vinden van annuleringsinstructies of het vergelijken van plannen. Let waar ze verwachten heen te gaan, welke labels ze verkeerd lezen en of ze zoekfunctionaliteit gebruiken omdat de navigatie faalt. Leid ze niet naar het bedoelde label. Leg elke belemmering vast en de kleinste wijziging die die wegneemt.
Koppel taaktesten aan technische controles. W3C’s Easy Checks raadt testen zonder muis aan, inclusief zichtbaarheid van focus, tabvolgorde, toetsenbordvallen en dropdowns. Herhaal kerntaken bij smalle breedtes en grotere tekstgroottes. Geautomatiseerde checks kunnen markupproblemen aangeven, maar kunnen niet vaststellen of een label logisch is.
Leg het bedoelde eindpunt en ondersteunde apparaat- of invoermethode vast vóór het testen.
Test de oude en nieuwe route met dezelfde taken in plaats van op stakeholdervoorkeur te vertrouwen.
Behandel navigatiewijzigingen als beschikbaarheidsgevoelige releases
Een header kan laden terwijl een kritisch pad effectief onbeschikbaar is: een checkout, login, supportroute of documentatiepagina kan achter een kapotte staat, een verouderde link of een verkeerde redirect zitten. Voer vóór release een inventarisatie uit van kritieke bestemmingen, test desktop- en mobielroutes en bevestig dat gerenderde links naar de bedoelde pagina leiden. Gebruik geautoriseerde omgevingen voor geauthenticeerde of regionale paden.
De rol van SIU is proactieve herstelactie: voer een preflight (controle vooraf) uit, verifieer essentiële paden na uitrol en maak correctie omkeerbaar. Houd een versieerbare menukonfiguratie bij, benoem de persoon die deze kan herstellen en valideer herstelde paden. Dit beperkt de impact van een release; het vervangt geen gebruikersonderzoek of live-statusmonitoring.
Blokkeer publicatie wanneer een kritieke bestemming ontbreekt, onjuist is of niet bereikbaar is met toetsenbord en touch.
Documenteer de vorige configuratie, eigenaar, trigger en validatiestappen vóór herstructurering.