WCAG 2.4.5: Flera sätt

Vad den här regeln innebär

WCAG 2.4.5 — Flera sätt är ett framgångskriterium på nivå AA under principen Hanterbar (Operable). Det kräver att varje webbsida som är del av en större uppsättning webbsidor måste kunna nås via minst två olika navigeringsmekanismer. Med andra ord ska en användare aldrig tvingas förlita sig på en enda väg för att hitta en sida.

Vanliga navigeringsmekanismer som uppfyller detta kriterium inkluderar: en webbplatsövergripande sökfunktion, en webbplatskarta (antingen som en fristående sida eller en inbäddad struktur), en innehållsförteckning, en konsekvent navigeringsmeny eller sidopanel, brödsmulor (breadcrumb trails) och länkar mellan relaterade sidor. Vilka som helst två av dessa — eller andra likvärdiga mekanismer — som används tillsammans uppfyller kravet.

Kriteriet gäller specifikt för uppsättningar av webbsidor. En fristående webbsida som inte tillhör en större webbplats eller applikation är undantagen. Dessutom är sidor som är resultatet av eller ett steg i en process — såsom en sida för bekräftelse av utcheckning, en sida som visar att ett formulär skickats in, eller ett steg i en guide (wizard) — också uttryckligen undantagna. Detta beror på att sådana sidor i sig är sekventiella och det vore olämpligt eller skadligt att tillåta direkt åtkomst till dem i fel ordning.

Ett godkänt resultat kräver att minst två oberoende navigeringsmekanismer finns, fungerar och är tillgängliga på hela webbplatsen. Ett underkänt resultat uppstår när endast en mekanism finns — till exempel en webbplats som bara har en toppnavigeringsmeny utan sökfunktion, utan webbplatskarta och utan andra navigeringshjälpmedel. Det blir också underkänt om den sekundära mekanismen inte fungerar eller är otillgänglig (t.ex. en sökruta som inte ger några resultat, eller en webbplatskarta som är dold för hjälpmedelsteknik).

Viktigt är att detta kriterium inte föreskriver någon specifik kombination av mekanismer. Flexibiliteten är avsiktlig: olika användare har fundamentalt olika strategier för att hitta innehåll, och standarden erkänner denna mångfald genom att kräva redundans snarare än att föreskriva en viss lösning.

Varför det är viktigt

Navigering är grunden för alla webbupplevelser, och hinder i navigeringen drabbar personer med funktionsnedsättning oproportionerligt hårt. När det bara finns en navigeringsväg är användare som inte kan använda den vägen i praktiken utestängda från innehållet.

För användare med motoriska funktionsnedsättningar — inklusive de som använder switch-styrning, ögonstyrningsenheter, röststyrningsprogram eller enbart tangentbordsnavigering — kan komplexa hierarkiska menyer vara utmattande eller omöjliga att ta sig igenom effektivt. En webbplatssökning gör det möjligt för dem att hoppa direkt till innehåll utan att behöva navigera genom flera nivåer av menyer. Omvänt kan användare med vissa kognitiva svårigheter eller minnessvårigheter uppleva öppna sökfält som förvirrande eller svåra att använda effektivt; för dem är en tydligt strukturerad webbplatskarta eller en bläddringsbar kategoriträdstruktur mycket mer användbar.

För blinda användare som förlitar sig på skärmläsare kan en tät navigeringsmeny bli ett återkommande hinder vid varje sidbesök, även med hoppa-över-länkar. En webbplatskarta eller en genväg till sökfunktionen minskar den kognitiva och fysiska belastningen avsevärt. För användare med nedsatt syn som använder skärmförstoring kan breda navigeringsmenyer bara delvis vara synliga vid hög zoomnivå, vilket gör en textbaserad sökfunktion eller webbplatskarta till en kritisk reservlösning.

För användare med kognitiva funktionsnedsättningar såsom dyslexi eller uppmärksamhetsstörningar kan möjligheten att söka med ungefärliga eller ofullständiga termer — istället för att behöva minnas eller känna igen den exakta menyhierarkin — vara avgörande för om de hittar innehåll på egen hand eller ger upp helt.

Ett konkret scenario från verkligheten: föreställ dig en användare med reumatoid artrit som besöker en turkisk e-handelsplattform med enbart tangentbordsnavigering. Webbplatsens megameny kräver precisa muspekarrörelser för att visa underkategorier, och tangentbordsfokus beter sig opålitligt. Om webbplatsen också tillhandahåller en sökruta och en webbplatskarta kan den användaren ändå hitta den produktsida hen behöver. Utan dessa alternativ är webbplatsen i praktiken oanvändbar för hen — vilket innebär en förlorad kund och en potentiell juridisk risk.

Utöver tillgänglighet ger flera navigeringsmekanismer mätbara SEO- och användbarhetsfördelar. Webbplatskartor förbättrar genomsökbarheten för sökmotorrobotar. Webbplatssökning ökar användarengagemanget och minskar avvisningsfrekvensen. Brödsmulor förbättrar klickfrekvensen i sökresultatsidor när de implementeras med strukturerad data. Dessa fördelar innebär att uppfyllandet av 2.4.5 inte bara är en fråga om efterlevnad — det är god webbdesignpraxis.

Relaterade Axe-core-regler

WCAG 2.4.5 kräver manuell testning eftersom inget automatiserat verktyg pålitligt kan avgöra om en webbplats erbjuder tillräcklig navigationsvariation. Automatiska skannrar kan verifiera om specifika element finns och är syntaktiskt korrekta, men de kan inte utvärdera den övergripande navigationsarkitekturen eller avgöra om en given kombination av mekanismer verkligen är tillräcklig. Följande överväganden vägleder manuell utvärdering:

• Förekomst av webbplatssökning (manuell kontroll): Automatiska verktyg kan inte bekräfta om ett sökfält fungerar, ger meningsfulla resultat eller är tillgängligt på hela webbplatsen. En testare måste manuellt verifiera att en sökfunktion finns, kan nås via tangentbordet och ger relevanta resultat för representativa sökningar.
• Förekomst av webbplatskarta eller alternativ navigeringsmekanism (manuell kontroll): Verktyg kan inte avgöra om en sida med webbplatskarta finns, om den är länkad från alla sidor eller om den täcker webbplatsens innehåll på ett heltäckande sätt. En mänsklig granskare måste bekräfta att minst en ytterligare mekanism utöver den primära navigeringen finns och är tillgänglig.
• Konsekvent navigering (relaterar till 2.4.3 och 3.2.3, manuell kontroll): Automatiska verktyg kan flagga inkonsekvent komponentordning mellan sidor, men kan inte bedöma om den övergripande navigeringsstrategin förblir sammanhängande och tillräcklig för användare med funktionsnedsättning. Manuell granskning av flera representativa sidtyper krävs.
• Tillgänglighet hos sekundära mekanismer (manuell kontroll): Även om en webbplatskarta eller sökfunktion finns kan en automatisk skanning missa fall där dessa mekanismer inte kan nås med tangentbord, har bristfällig märkning för skärmläsare eller är visuellt dolda på ett sätt som påverkar användbarheten. Manuell testning med tangentbord och skärmläsare måste bekräfta att varje mekanism fungerar från början till slut.

Hur man testar

1. Automatisk skanning — fastställ en baslinje: Kör axe DevTools eller Lighthouse på representativa sidor av webbplatsen. Även om inget av verktygen direkt flaggar överträdelser av 2.4.5, använd granskningen för att identifiera navigeringskomponenter (menyer, sökfält, brödsmulor) med underliggande tillgänglighetsproblem såsom saknade etiketter, felaktiga ARIA-roller eller problem med fokus­hantering. Åtgärda dessa först, eftersom en trasig navigeringsmekanism inte kan räknas som ett giltigt ”sätt” enligt 2.4.5.
2. Kartlägg navigeringsmekanismer: Granska webbplatsen manuellt och lista varje distinkt mekanism som en användare kan använda för att nå en viss sida: toppnavigeringsmenyer, sidfotslänkar, webbplatssökning, sidor med webbplatskarta, brödsmulor, länkar till relaterat innehåll, kategoriindex och så vidare. Bekräfta att minst två av dessa mekanismer finns, fungerar och är tillgängliga på varje sida som inte är del av en sekventiell process.
3. Test med enbart tangentbord: Använd endast Tab, Enter, piltangenterna och Escape (ingen mus) och försök nå en specifik sida som inte är startsidan via två olika mekanismer. Använd till exempel sökrutan för att hitta en produktsida och använd sedan webbplatskartan eller navigeringsmenyn för att nå samma sida. Bekräfta att båda vägarna är fullt fungerande utan mus.
4. Skärmläsartest med NVDA + Firefox: Starta NVDA, öppna Firefox och navigera till startsidan. Använd NVDA:s bläddringsläge (F6 för landmärken, H för rubriker) för att hitta söklandmärket och eventuella länkar till webbplatskarta eller navigering. Bekräfta att båda mekanismerna annonseras korrekt, att formulärfält har tillgängliga etiketter och att resultat- eller målsidor laddas och går att läsa.
5. Skärmläsartest med VoiceOver + Safari (macOS/iOS): Aktivera VoiceOver (Cmd+F5) och använd Rotorn (VO+U) för att inspektera sidans formulärkontroller och länkar. Bekräfta att sökfältet listas och är märkt, och att navigeringslänkar som leder till en webbplatskarta eller ett alternativt index finns och fungerar.
6. Skärmläsartest med JAWS + Chrome: Använd JAWS snabbkommandon (F för att hoppa till formulär, Insert+F7 för länklista) för att verifiera att sökfältet och eventuella länkar till webbplatskarta kan upptäckas och användas både med tangentbordet och den virtuella markören.
7. Kontroll av undantag för sekventiella processer: Identifiera alla sidor som är steg i en process (utcheckning, flerstegsfomulär, inloggningsflöden). Bekräfta att dessa sidor inte behöver uppfylla kravet på flera sätt. Dokumentera detta i din tillgänglighetsgranskning för att undvika felaktiga underkännanden.
8. Verifiering av fungerande sökresultat: Genomför flera representativa sökningar (produktnamn, artikelrubriker, supportämnen). Bekräfta att resultat visas, är relevanta och att resultatsidan är tillgänglig och går att navigera med tangentbord och skärmläsare.

Hur man åtgärdar

Saknad webbplatssökning — Felaktigt

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

Saknad webbplatssökning — Korrekt

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

Otillgänglig webbplatskarta — Felaktigt

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

Otillgänglig webbplatskarta — Korrekt

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

Sökformulär utan tillgänglig etikett — Felaktigt

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

Sökformulär utan tillgänglig etikett — Korrekt

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

Vanliga misstag

• Att räkna en XML-webbplatskarta som en användarvänd navigeringsmekanism: En XML-webbplatskarta som skickas in till sökmotorer (t.ex. /sitemap.xml) är en maskinläsbar fil och kan inte användas av vanliga besökare. Endast en HTML-webbplatskarta, som kan bläddras av människor, räknas som en giltig andra navigeringsmekanism.
• Att tillhandahålla ett sökformulär som är rent dekorativt eller trasigt: Ett sökfält som alltid returnerar tomma resultat, ger fel vid inskickning eller omdirigerar till en 404-sida uppfyller inte 2.4.5. Mekanismen måste fungera på riktigt för att kriteriet ska vara uppfyllt.
• Att dölja länken till webbplatskartan bakom JavaScript som fallerar eller är inaktiverat: Om den enda länken till en webbplatskarta finns i ett dynamiskt infogat modal-fönster eller en JavaScript-beroende rullgardinsmeny som inte fungerar i vissa miljöer, förlorar användare som inte kan köra det JavaScriptet (inklusive vissa konfigurationer av hjälpmedelsteknik) åtkomsten till den navigeringsmekanismen.
• Att använda display:none eller visibility:hidden på en navigeringsmekanism i mobila vyer: Att helt dölja en sökruta eller länk till webbplatskarta i mobil-layouten tar bort den mekanismen helt för mobilanvändare, vilket är ett underkännande — även om desktop-layouten blir godkänd. Att fälla in mekanismen bakom en tillgänglig växlingsknapp är acceptabelt; att ta bort den från DOM:en eller tillgänglighetsträdet är det inte.
• Att behandla brödsmulor som en fristående andra mekanism utan ytterligare stöd: Brödsmulor visar bara vägen till den aktuella sidan och är inte i sig tillräckliga för att hjälpa en användare att upptäcka och navigera till godtyckliga sidor på en webbplats. De kan komplettera andra mekanismer men kan normalt inte fungera som en av de två obligatoriska mekanismerna på egen hand.
• Att undanta sidor från kravet på felaktiga grunder: Undantaget för sekventiella processer gäller endast sidor som bokstavligen är steg i en process (t.ex. steg 2 av 4 i en utcheckning). Kategorisidor, produktsidor och blogginlägg är inte undantagna, även om användaren kom dit via en tratt (funnel).
• Att använda ett sökfält med type='text' istället för type='search' och utelämna role='search' på formuläret: Även om detta inte är en direkt överträdelse av 2.4.5 innebär det att skärmläsaranvändare som bläddrar efter landmärken inte kan hitta sökområdet. Mekanismen finns tekniskt sett men är praktiskt svårare att upptäcka, vilket undergräver kriteriets avsikt.
• Att tillhandahålla två mekanismer som i praktiken är identiska: En toppnavigeringsmeny och en sidfotsnavigeringsmeny som innehåller exakt samma länkar i exakt samma struktur utgör inte två meningsfullt olika navigeringsmekanismer. Avsikten är att användare med olika behov ska kunna hitta alternativa strategier — inte att samma strategi visas två gånger på sidan.
• Att utesluta vissa sidtyper från navigationssystemet: Vissa CMS-konfigurationer placerar blogginlägg, juridiska sidor eller användarkontosidor utanför den huvudsakliga webbplatskartan eller sökindexet. Om användare inte kan hitta dessa sidor via minst två mekanismer underkänns de enligt 2.4.5 oavsett hur väl resten av webbplatsen är strukturerad.
• Att inte testa mekanismerna med hjälpmedelsteknik: Eftersom 2.4.5 kräver manuell testning kommer team som enbart förlitar sig på automatiska verktyg att missa fel som orsakas av tangentbordsfällor i sökformulär, omärkta inmatningsfält eller webbplatskartor som finns i DOM:en men inte kan nås via skärmläsarens landmärkesnavigering.

Relation till Turkiets tillgänglighetsreglering

Turkiets presidentcirkulär nr 2025/10, publicerat i Officiella tidningen (Resmî Gazete) nr 32933 den 21 juni 2025, fastställer bindande krav på webbtillgänglighet för ett brett spektrum av offentliga och privata aktörer. Cirkuläret kräver efterlevnad av internationellt erkända tillgänglighetsstandarder och anpassar turkiska rättsliga krav till WCAG 2.1 och WCAG 2.2 nivå AA som grundläggande förväntan.

WCAG 2.4.5 — Flera sätt är ett kriterium på nivå AA, vilket innebär att det ligger helt inom den efterlevnadsnivå som krävs enligt cirkuläret. Aktörer som omfattas av regleringen måste säkerställa att alla webbsidor som tillhör en uppsättning tillhandahåller minst två navigeringsmekanismer, enligt beskrivningen i detta kriterium. Underlåtenhet att uppfylla detta krav är en direkt bristande efterlevnad av det regulatoriska mandatet.

De aktörer som omfattas av presidentcirkulär 2025/10 inkluderar: offentliga institutioner och myndigheter på alla nivåer; banker och finansiella institutioner; sjukhus och vårdgivare; e-handelsplattformar; teleoperatörer med 200,000 eller fler abonnenter; resebyråer; privata transportföretag; och privatskolor som verkar med tillstånd från utbildningsministeriet (Millî Eğitim Bakanlığı, MEB). Var och en av dessa aktörstyper förväntas upprätthålla tillgänglig navigering med flera vägar på sina webbplatser.

Utöver de obligatoriska kraven på efterlevnad utfärdar familje- och socialministeriet (Aile ve Sosyal Hizmetler Bakanlığı) Erişilebilirlik Logosu (tillgänglighetslogotypen) till organisationer som uppvisar starka tillgänglighetsrutiner. För att få denna logotyp krävs full efterlevnad på nivå AA, inklusive uppfyllande av 2.4.5. För företag som verkar på Turkiets konkurrensutsatta digitala marknad — särskilt e-handelsplattformar, banker och vårdgivare — fungerar tillgänglighetslogotypen både som en förtroendesignal för användare med funktionsnedsättning och som bevis på god regelefterlevnad.

I praktiken har turkiska webbplatser som betjänar olika användargrupper stor nytta av att implementera flera navigeringsmekanismer. Turkiet har en stor andel äldre internetanvändare och användare i regioner med lägre digital kompetens, vilka båda gynnas av den redundans som 2.4.5 kräver. En webbplatssökning med stöd för turkiska språket (inklusive korrekt hantering av turkiska specialtecken som ı, İ, ş, ğ, ü, ö, ç) kombinerad med en tydligt strukturerad HTML-webbplatskarta utgör en tillgänglig, regelkompatibel implementering som tjänar denna målgrupp väl. Organisationer som vill få eller behålla Erişilebilirlik Logosu bör betrakta efterlevnad av 2.4.5 inte som en valfri förbättring utan som ett grundläggande krav i sitt tillgänglighetsarbete.