WCAG 3.2.6: Konsekvent hjälp

Vad den här regeln innebär

WCAG:s framgångskriterium 3.2.6 Konsekvent hjälp (nivå AA, infört i WCAG 2.2) anger: ”Om en webbsida innehåller någon av följande hjälpmekanismer, och dessa mekanismer upprepas på flera webbsidor, ska de förekomma i samma relativa ordning i förhållande till annat sidinnehåll, om inte en ändring initieras av användaren.” Hjälpmekanismerna som omfattas av detta kriterium är: kontaktuppgifter till en människa (till exempel ett telefonnummer, en e‑postadress eller öppettider), en kontaktmekanism med en människa (till exempel en livechatt‑widget eller ett kontaktformulär), ett självhjälpsalternativ (till exempel en sida med vanliga frågor, ett hjälpcenter eller en kunskapsbas) och en helt automatiserad kontaktmekanism (till exempel en chatbot eller virtuell assistent).

Det centrala kravet är konsekvent relativ ordning, inte identisk pixelplacering. Om en livechatt‑knapp visas i det nedre högra hörnet på startsidan måste den visas i samma nedre högra position på alla andra sidor där den förekommer. Om en ”Hjälp”-länk är det tredje objektet i den övre navigationslisten på en sida måste den förbli det tredje objektet – eller åtminstone behålla samma relativa relation till omgivande innehåll – på alla andra sidor där den navigationslisten visas.

En sida klarar detta kriterium när: (a) ingen hjälpmekanism finns på webbplatsen, eller (b) en hjälpmekanism finns på endast en sida, eller (c) där en hjälpmekanism upprepas på flera sidor visas den i samma relativa ordning inom sidlayouten. En sida underkänns när en hjälpmekanism som finns på flera sidor ändrar sin position i sidordningen från en sida till en annan utan att användaren har initierat den ändringen – till exempel en chatt‑widget som flyter i nedre högra hörnet på produktsidan men flyttas till nedre vänstra hörnet på kassasidan.

Kriteriet innehåller ett uttryckligt undantag: ordningen får ändras om användaren initierar ändringen. Om en användare till exempel drar och placerar om en flytande hjälp‑widget, eller om en användarinställning växlar hjälppanelen från ena sidan till den andra, är den omplaceringen användarinitierad och utgör inte ett fel. Detta undantag speglar samma användarinitierade logik som finns i SC 3.2.2 (Vid inmatning).

Det är viktigt att notera att detta kriterium inte kräver att varje sida har en hjälpmekanism, och det kräver inte heller att hjälpmekanismen är effektiv eller lätt att använda. Det reglerar endast positionsmässig konsekvens när mekanismen finns på flera sidor.

Varför det är viktigt

Konsekvent placering av hjälp är främst utformad för att gynna användare med kognitiva funktionsnedsättningar, inklusive personer med minnesnedsättningar, koncentrationssvårigheter, inlärningssvårigheter som dyslexi och tillstånd som ADHD eller tidig demens. För dessa användare kräver det medveten kognitiv ansträngning att hitta ett bekant gränssnittselement. När en hjälpknapp eller kontaktlänk visas på olika plats på varje sida måste de lägga ned den ansträngningen om och om igen, vilket ökar den kognitiva belastningen och risken för frustration, desorientering eller att de avbryter uppgiften.

Användare som är nya på webben eller har begränsad digital kompetens – en betydande grupp i Turkiet och globalt – är också starkt beroende av förutsägbar placering. Enligt Världshälsoorganisationen lever över 1,3 miljarder människor världen över med någon form av funktionsnedsättning, och kognitiva och neurologiska tillstånd utgör en betydande del av den gruppen. Att utforma för positionsmässig konsekvens tjänar därför en bred målgrupp långt bortom dem med kliniskt diagnostiserade funktionsnedsättningar.

Överväg ett konkret scenario: en användare med tidig Alzheimers sjukdom försöker slutföra en flygbokning online. Hon minns att flygbolagets webbplats har en livechatt som hon kan använda när hon blir förvirrad. På sidan med sökresultat visas chattikonen i det nedre högra hörnet. Men när hon går vidare till sidan för sätesval har chatt‑widgeten flyttats till det övre högra hörnet i en hopfällbar hjälplåda. Hon kan inte hitta den, blir överväldigad och avbryter bokningen helt. Detta är ett direkt, förebyggbart fel enligt SC 3.2.6.

För motoriskt funktionsnedsatta användare som navigerar med switch‑styrning, ögonstyrningsprogram eller huvudpekare innebär omplacering av en hjälpmekanism att de måste skanna av och sikta in sig på ett nytt område på skärmen – en ansträngande och tidskrävande process som konsekvent placering eliminerar.

Skärmläsaranvändare som har memorerat tabbordningen eller rubrikstrukturen på en webbplats för att snabbt nå hjälpdelen påverkas på samma sätt när DOM‑ordningen för den mekanismen ändras från sida till sida, även om den visuella positionen ser likadan ut.

Utöver tillgänglighet finns en tydlig användbarhets- och affärsnytta: användare som snabbt kan hitta hjälp är mindre benägna att avbryta en transaktion, vilket minskar avhoppsfrekvens och supportkostnader. Konsekventa UI‑mönster stärker också varumärkesförtroende och professionalitet.

Relaterade Axe-core-regler

WCAG 3.2.6 klassas som att den kräver endast manuell testning och har ingen motsvarande automatiserad axe‑core‑regel som kan flagga överträdelser programmatiskt. Detta är avsiktligt, och att förstå varför hjälper testare att uppskatta kriteriets natur.

• Manuell granskning krävs – ingen axe‑regel tillgänglig: Automatiserade verktyg som axe‑core, Lighthouse eller IBM Equal Access Checker analyserar en enskild sida isolerat. De har ingen inneboende förståelse för vad en ”hjälpmekanism” är, ingen möjlighet att jämföra den relativa DOM‑positionen för ett element över flera sidladdningar eller URL:er, och inget sätt att avgöra om ett visst element fyller den funktionella rollen att tillhandahålla hjälp. En chatt‑widget kan till exempel implementeras som ett vanligt <div>, en shadow DOM‑komponent, ett <iframe> eller ett skript injicerat av tredje part – inget av detta kan pålitligt identifieras som en ”hjälpmekanism” av en regelmotor utan mänsklig bedömning. Axe‑core skulle behöva tillståndsmedvetenhet över flera sidor och igenkänning av semantisk avsikt för att kunna flagga detta, förmågor som ligger utanför ramen för statisk analys av en enskild sida. Det är därför WCAG 2.2 själv anger 3.2.6 som ett kriterium som kräver mänsklig utvärdering genom strukturerade manuella granskningar och jämförelser mellan sidor.

Hur man testar

1. Inventera hjälpmekanismer: Innan du testar enskilda sidor, skapa en lista över alla hjälpmekanismer som finns på webbplatsen – livechatt‑widgets, kontakttelefonnummer, e‑postlänkar, FAQ‑länkar, chatbot‑startare, kontaktformulär och länkar till hjälpcenter. Notera på vilka sidor varje mekanism förekommer. Om en mekanism bara finns på en sida är den utanför kriteriets omfattning.
2. Kör en automatiserad skanning för grundläggande kontext: Använd axe DevTools (webbläsartillägg) eller Lighthouse på representativa sidor för att fånga ögonblicksbilder av DOM‑ordningen och identifiera den strukturella positionen för hjälprelaterade element. Även om ingen axe‑regel riktar sig direkt mot SC 3.2.6 kan DOM‑ordningen som rapporteras av dessa verktyg jämföras manuellt mellan sidor. Exportera eller ta skärmdumpar av tillgänglighetsträdet för varje sida som innehåller en hjälpmekanism.
3. Jämför relativa positioner mellan sidor: Öppna två eller fler sidor som delar samma hjälpmekanism sida vid sida (eller efter varandra). Identifiera för varje mekanism dess position i förhållande till omgivande landmärkesregioner (<header>, <main>, <footer>, <nav>). Notera om mekanismen visas i samma landmärkesregion och i samma relativa ordning (före eller efter angränsande element) på varje sida. En förändring i position utgör ett potentiellt fel.
4. Testa med tangentbordsnavigering (alla webbläsare): Tabba igenom varje sida som innehåller en hjälpmekanism. Räkna antalet tabb‑stopp som krävs för att nå hjälpmekanismen från sidans början. Jämför detta antal mellan sidor. En betydande skillnad – till exempel att den kan nås med 5 tabbningar på startsidan men 47 tabbningar på kassasidan – indikerar en förändring i DOM‑ordningen även om den visuella positionen verkar liknande.
5. Testa med NVDA + Firefox: Öppna NVDA:s elementlista (NVDA‑tangent + F7) och växla till vyn Länkar eller Knappar. Leta upp hjälpmekanismen i listan. Notera dess position i förhållande till andra listade element. Upprepa på varje sida där mekanismen förekommer och jämför positionerna.
6. Testa med VoiceOver + Safari (macOS/iOS): Använd VoiceOver‑rotorn (VO + U) för att öppna listan Länkar eller Formulärkontroller. Navigera till hjälpmekanismen och notera dess position i listan. Jämför mellan sidor.
7. Testa med JAWS + Chrome: Använd JAWS länklistefunktion (Insert + F7) för att hitta hjälpmekanismen. Notera dess ordningsnummer och angränsande element. Upprepa mellan sidor.
8. Kontrollera användarinitierade undantag: Om webbplatsen låter användare flytta eller dölja hjälpmekanismer (t.ex. en flyttbar chatt‑widget), kontrollera att omplaceringen utlöses av en uttrycklig användaråtgärd och att preferensen bevaras på ett logiskt sätt. Dokumentera detta som ett giltigt undantag enligt kriteriet.
9. Granska på mobila vyportar: Responsiva layouter omordnar ibland DOM‑element vid olika brytpunkter. Testa både på desktop- och mobilvyportar (375px och 1440px bredd som minimum) för att bekräfta att hjälpmekanismen behåller konsekvent relativ placering vid alla vanliga skärmstorlekar.

Hur man åtgärdar

Flytande chatt‑widget – felaktig

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

Flytande chatt‑widget – korrekt

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

Hjälplänk i navigation – felaktig

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

Hjälplänk i navigation – korrekt

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

Villkorlig visning av hjälp – felaktig

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

Villkorlig visning av hjälp – korrekt

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

Vanliga misstag

• Att placera chatt‑widgeten i olika hörn i olika sidmallar: Utvecklingsteam använder ofta fast positionering för chatt‑widgets per mall i stället för via ett globalt stilmall, vilket gör att widgeten visas nere till höger på marknadssidor och nere till vänster på appsidor. Använd en enda globalt inkluderad komponent med en låst positionsklass.
• Att ta bort hjälplänken från navigationen på kassasidor för att minska röran: Vissa UX‑mönster rensar medvetet navigationen på kassasidor för att optimera konvertering. Om en hjälpmekanism är en del av den navigationen bryter man konsekvensen genom att ta bort den från denna sidmall. Behåll i stället hjälplänken i en minimal header även i avskalade kassaflöden.
• Att injicera hjälpmekanismer via tredjepartsskript som laddas med oförutsägbara DOM‑positioner: Många livechatt‑SDK:er injicerar sin widget asynkront i DOM:en, och deras infogningspunkt kan variera beroende på skriptets laddningsordning. Detta kan göra att widgeten visas på olika positioner i tillgänglighetsträdet mellan sidor. Konfigurera tredjepartswidgets så att de alltid läggs till ett fast, känt DOM‑ankarelement.
• Att använda CSS order eller flexbox/grid‑omordning för att visuellt flytta hjälpelementet utan att ändra DOM‑ordningen, och sedan ändra den CSS:en per sida: Även om den visuella positionen kan verka konsekvent, innebär sidvisa CSS‑överstyrningar som ändrar den visuella ordningen för en hjälpmekanism ändå att den användarupplevda ordningen ändras och kan förvirra skärmläsaranvändare vars läsordning följer DOM:en.
• Att förlita sig på A/B‑testverktyg som byter position på hjälpelementet mellan testvarianter: Om användare i variant A ser hjälpknappen i topplisten och användare i variant B ser den i footern, kommer dessa användare att uppleva inkonsekvent hjälppositionering mellan sidor inom sin session när A/B‑ramverket tillämpar olika varianter på olika sidor. Säkerställ att A/B‑tester som påverkar placeringen av hjälpmekanismer tillämpar varianten konsekvent på alla sidor i en session.
• Att behandla autentiserade och icke‑autentiserade lägen som olika ”webbplatser” och använda olika hjälplayouter: Användare som loggar in mitt i en session kommer plötsligt att hitta hjälpmekanismen på en ny plats. Ändringen av autentiseringstillstånd är inte användarinitierad i kontexten av hjälppositionering, så detta är fortfarande ett fel enligt SC 3.2.6. Använd en konsekvent hjälplayout i alla autentiseringstillstånd.
• Att bara lägga in hjälptelefonnumret i tät footer‑text på vissa sidor och i en dedikerad header‑rad på andra: Även om telefonnumret tekniskt sett finns på alla sidor är en betydande förändring i dess relativa position (från det första interaktiva elementet i headern till att vara begravt i footern efter hundratals länkar) ett brott mot kravet på konsekvent ordning.
• Att anta att eftersom en hjälpikon alltid är visuellt ”i hörnet” så uppfyller man kriteriet: Kriteriet mäter relativ ordning i sidinnehållet, inte bara absoluta pixelkoordinater. En chattikon som alltid är visuellt nere till höger men förekommer på helt olika ställen i DOM‑ordningen på olika sidor (t.ex. direkt efter <body>-taggen på en sida och precis före den avslutande </body>-taggen på en annan) kan ändå vara ett fel för tangentbords- och skärmläsaranvändare.
• Att glömma att granska responsiva brytpunkter: En hjälpmekanism som är konsekvent vid desktop‑bredder kan döljas eller flyttas in i en mobil hamburgermeny vid smalare vyportar, vilket resulterar i en annan position på mobil. Om mobilanvändare upplever en annan relativ position än desktop‑användare bör detta utvärderas mot kriteriet – särskilt om mobil är den primära åtkomstmetoden för målgruppen.
• Att inte dokumentera hjälpmekanismers placering i designsystem: Utan en dokumenterad standard för var hjälpmekanismer ska finnas kommer enskilda utvecklare och designers att fatta egna beslut som skapar inkonsekvenser över tid. Lägg till regler för placering av hjälpmekanismer uttryckligen i dokumentationen för ditt designsystem eller din komponentkatalog.

Relation till Turkiets tillgänglighetsreglering

Turkiets presidentcirkulär 2025/10, publicerat i den officiella tidningen med nummer 32933 den 21 juni 2025, etablerar ett omfattande nationellt ramverk för digital tillgänglighet. Cirkuläret kräver överensstämmelse med WCAG 2.2 nivå AA som grundläggande tillgänglighetsstandard för ett brett spektrum av digitala tjänster som verkar i Turkiet. WCAG 3.2.6 Konsekvent hjälp, som ett kriterium på nivå AA infört i WCAG 2.2, faller direkt inom ramen för denna rättsliga skyldighet.

De enhetstyper som omfattas av presidentcirkulär 2025/10 inkluderar: offentliga institutioner och myndigheter på både central och lokal nivå; banker och finansiella tjänsteleverantörer som regleras av Banktillsyns- och regleringsmyndigheten (BDDK); e‑handelsplattformar och online‑marknadsplatser; sjukhus och vårdgivare som erbjuder patientinriktade digitala tjänster; telekomföretag med 200,000 eller fler abonnenter; resebyråer med onlinebokningssystem; privata transportföretag som bedriver linjetrafik; och privatskolor och utbildningsinstitutioner som auktoriserats av utbildningsministeriet (MoNE). För alla dessa enheter är hela uppsättningen WCAG 2.2 nivå AA‑kriterier – inklusive SC 3.2.6 – den tillämpliga standarden.

Efterlevnad av WCAG 3.2.6 är också ett krav för att få Erişilebilirlik Logosu (tillgänglighetslogotypen) som utfärdas av det turkiska ministeriet för familje- och socialtjänster (Aile ve Sosyal Hizmetler Bakanlığı). Denna logotyp fungerar som en officiell markering av tillgänglighetsöverensstämmelse och blir i allt högre grad igenkänd av turkiska konsumenter och upphandlare som en kvalitetsindikator. Organisationer som vill ha logotypen måste visa full överensstämmelse med WCAG 2.2 nivå AA i sina digitala tillgångar, vilket innebär att inkonsekvent placering av hjälp – även om den verkar liten – kan diskvalificera en ansökan.

Ur ett praktiskt efterlevnadsperspektiv är SC 3.2.6 särskilt relevant för turkiska e‑handels- och finansiella tjänsteleverantörer, vars webbplatser och mobila webbappar vanligtvis har livechatt‑widgets, WhatsApp‑kontaktlänkar och FAQ‑sektioner som primära kundsupportkanaler. Att säkerställa att dessa hjälpmekanismer visas på konsekventa positioner på produktsidor, kundvagnssidor, kassaflöden och kontohanteringssektioner är både en rättslig skyldighet enligt cirkuläret och en sund UX‑praxis för att betjäna Turkiets mångfacetterade internetanvändarbas – som inkluderar en stor grupp förstagångs- och lågkompetenta digitala användare som har störst nytta av förutsägbara gränssnittsmönster.

Organisationer som omfattas av cirkuläret och ännu inte har granskat placeringen av sina hjälpmekanismer bör prioritera en granskning av konsekvens mellan sidor som en del av sin WCAG 2.2‑efterlevnadsplan. Eftersom detta kriterium kräver manuell testning bör det ingå både i initiala överensstämmelsegranskningar och i löpande kvalitetssäkringscykler, särskilt efter större redesigns eller malländringar som oavsiktligt kan flytta positionen för hjälpelement.