WCAG 3.3.5: Hjälp

Vad den här regeln innebär

\n

WCAG framgångskriterium 3.3.5 Help (nivå AAA) säger: \"Context-sensitive help is available.\" Detta innebär att varhelst en webbsida eller applikation ber användare att mata in information, måste lämplig hjälp tillhandahållas för att klargöra vad som förväntas. Hjälpen måste vara kontextuell — det vill säga den måste relatera direkt till det fält, den uppgift eller den process som användaren för närvarande är engagerad i, snarare än att vara en generell hjälpsida gömd någonstans i navigeringen.

\n

Kriteriet gäller alla användargränssnittskomponenter som kräver inmatning: textfält, rullgardinsmenyer, datumväljare, kontroller för filuppladdning, kryssrutor, alternativknappar och flerstegsfomulär. Kontextkänslig hjälp kan ta många former, inklusive inline-instruktioner, beskrivande etiketter, vägledning i platshållare, verktygstips, hjälpikoner som expanderar förklaringar, länkar till relevanta hjälpartiklar eller till och med livechatt-support — så länge hjälpen finns tillgänglig i närheten av den inmatning som kräver den.

\n

Ett godkänt resultat uppnås när minst ett av följande finns för varje inmatning som kan orsaka användarförvirring: en tydligt skriven etikett som fullt ut förklarar den förväntade inmatningen; kompletterande beskrivande text intill fältet (inte bara en platshållare, som försvinner när man börjar skriva); en synlig hjälplänk eller ett expanderbart verktygstips som ger ytterligare förklaring; eller en lättillgänglig hjälp-mekanism (som en frågeteckenikon) som visar vägledning specifik för den aktuella kontexten. Hjälpen behöver inte vara identisk för alla fält — det centrala kravet är att varhelst en användare kan vara osäker på vad som ska anges, ska hjälp verkligen finnas tillgänglig och vara åtkomlig.

\n

Ett underkänt resultat uppstår när fält inte ger någon förklaring av vad som förväntas, när hjälp endast finns tillgänglig efter att formuläret skickats in och ett fel uppstått, när verktygstips eller hjälptext är oåtkomliga för tangentbords- eller skärmläsaranvändare, eller när hjälplänkar leder till en allmän FAQ-sida i stället för innehåll som är relevant för den specifika inmatningen. Avgörande är att enbart förlita sig på felmeddelanden i efterhand inte uppfyller detta kriterium — hjälp måste finnas tillgänglig före eller under inmatningen, inte bara efter att ett misstag har gjorts.

\n

WCAG 3.3.5 definierar inte en strikt, enskild implementeringsmetod. Det erkänner att kontextkänslig hjälp kan implementeras på många giltiga sätt, vilket ger utvecklare flexibilitet, men avsikten är entydig: användare ska aldrig lämnas gissande kring vad ett formulärfält förväntar sig. Det finns inga officiella undantag från detta kriterium — det gäller universellt varhelst användarinmatning efterfrågas.

\n\n

Varför det är viktigt

\n

Formulär är bland de mest utmanande delarna av alla digitala gränssnitt. För användare med kognitiva funktionsnedsättningar — inklusive personer med dyslexi, uppmärksamhetsstörningar, intellektuella funktionsnedsättningar eller minnesnedsättningar — kan otydliga formulärfält vara ett oöverstigligt hinder. Utan tydlig, kontextuell hjälp kan dessa användare upprepade gånger misslyckas med att slutföra uppgifter, uppleva betydande frustration eller överge processen helt. Enligt Världshälsoorganisationen lever ungefär 1 av 6 personer världen över med någon form av betydande funktionsnedsättning, och kognitiva nedsättningar utgör en betydande del av denna population.

\n

Användare med låg digital kompetens eller begränsad erfarenhet av webbgränssnitt har också enorm nytta av kontextkänslig hjälp. En förstagångsanvändare av en myndighets e-tjänsteportal, en äldre person som ansöker om ett hälsobidrag online eller en småföretagare som fyller i en skattedeklaration kanske inte vet vilket format som förväntas för ett skatteidentifikationsnummer, vilka filtyper som accepteras för dokumentuppladdningar eller vad skillnaden är mellan två snarlikt namngivna fält. Utan vägledning i kontext lämnas dessa användare sårbara för fel och den ångest som följer av att inte veta vad de har gjort fel.

\n

Överväg ett konkret scenario: en användare med en kognitiv funktionsnedsättning ansöker om ett subventionerat resekort via en kommunal kollektivtrafikmyndighets webbportal. Formuläret frågar efter ett \"Reference Number\" utan förklaring. Användaren har flera dokument — sitt nationella ID, sitt resekort och en tidigare ansökningsbekräftelse — alla med olika numeriska identifierare. Utan kontextkänslig hjälp som anger vilket specifikt dokument eller format som förväntas, är det sannolikt att användaren anger fel nummer, utlöser ett valideringsfel och eventuellt ger upp. Om en enkel hjälpikon eller en inline-beskrivning hade funnits — \"Enter the 10-digit number from the top-right corner of your transit card\" — skulle hela interaktionen ha lyckats på första försöket.

\n

För användare som är blinda eller har nedsatt syn är kontextkänslig hjälp också viktig. Skärmläsare kan läsa upp associerad hjälptext, aria-describedby-beskrivningar eller länkad hjälpinformation, men bara om dessa är korrekt implementerade. När hjälp förmedlas enbart visuellt (som en färgindikator eller en ikon utan tillgänglig text) utesluts skärmläsaranvändare. Att säkerställa att hjälp både finns och är tillgänglig stärker inkludering över olika funktionsnedsättningsgrupper.

\n

Utöver tillgänglighet förbättrar kontextkänslig hjälp den övergripande användbarheten och konverteringsgraderna. Webbplatser med tydlig formulärvägledning har lägre avhoppsfrekvens, färre supportförfrågningar och högre grad av slutförda formulär. För e-handelssajter har varje procentenhet förbättring i slutförda kassaprocesser direkt intäktsmässig påverkan. Sökmotorer belönar också sidor med tydligt, strukturerat innehåll, och välmärkta, välbeskrivna formulär bidrar positivt till sidans kvalitetssignaler.

\n\n

Relaterade Axe-core-regler

\n

WCAG 3.3.5 kräver manuell testning eftersom efterlevnaden beror på kvaliteten, relevansen och den kontextuella lämpligheten hos hjälpinnehållet — faktorer som automatiserade verktyg inte kan utvärdera. En automatiserad skanner kan bekräfta att en etikett finns eller att ett aria-describedby-attribut pekar på ett verkligt element, men den kan inte avgöra om innehållet i den etiketten eller beskrivningen faktiskt är hjälpsamt, korrekt eller tillräckligt för en given inmatning.

\n

\n
• Manuell granskning — Förekomst av kontextkänslig hjälp: Automatiserade verktyg kan inte bedöma om hjälptext verkligen besvarar användarens sannolika frågor om ett specifikt fält. Ett verktyg kan upptäcka att ett <label>-element finns, men kan inte avgöra om \"Enter your number\" är tillräckligt beskrivande för ett fält som förväntar sig ett formaterat momsregistreringsnummer. Manuella testare måste utvärdera om varje inmatning som kan orsaka förvirring åtföljs av vägledning som på ett meningsfullt sätt minskar den förvirringen.
\n
• Manuell granskning — Hjälpens tillgänglighet: Även om hjälp är visuellt närvarande, kanske automatiserade verktyg inte flaggar fall där den hjälpen är oåtkomlig för hjälpmedelsteknik. Till exempel passerar ett verktygstips som bara triggas vid muspekning, utan tangentbordsåtkomlig motsvarighet, många automatiserade kontroller men misslyckas för verkliga användare. Testare måste verifiera att alla hjälp-mekanismer — verktygstips, expanderbara sektioner, hjälplänkar — är nåbara och användbara via tangentbord och läses upp korrekt av skärmläsare.
\n
• Manuell granskning — Hjälpens placering och närhet: Automatiska skanningar kan inte utvärdera om hjälptext är placerad tillräckligt nära det relevanta fältet för att meningsfullt associeras med det. Ett hjälpparagrafsblock längst ned på sidan, eller i en modal som kräver flera interaktioner för att nås, kan tekniskt sett finnas men misslyckas med avsikten med kontextkänslig hjälp. Manuell granskning måste bekräfta att hjälp finns tillgänglig vid behovstillfället.
\n
• Manuell granskning — Fullständighet vid komplexa formulär: Komplexa, flerstegsformulär innebär ytterligare utmaningar. Automatiserade verktyg kontrollerar enskilda fält isolerat men kan inte bedöma om den samlade hjälp som ges genom en flerstegsguide är tillräcklig för att vägleda en användare genom en komplex process. Manuella genomgångar är nödvändiga för att identifiera luckor i vägledningen som bara blir uppenbara när man upplever formuläret som helhet.
\n

\n\n

Hur man testar

\n

\n
1. Kör en automatiserad tillgänglighetsskanning som baslinje. Använd axe DevTools (webbläsartillägg eller CLI), Lighthouse i Chrome DevTools eller IBM Equal Access Checker på sidan som innehåller formuläret. Även om dessa verktyg inte direkt kommer att flagga överträdelser av 3.3.5, kommer de att lyfta fram relaterade problem som saknade etiketter (label-element som inte är associerat med en inmatning), saknade aria-describedby-mål eller otillgängliga implementeringar av verktygstips. Att åtgärda dessa grundläggande problem först säkerställer att när kontextkänslig hjälp läggs till är den också tekniskt tillgänglig.
\n
2. Granska varje formulärfält manuellt för tillgång till hjälp. För varje inmatningsfält, fråga: (a) Förklarar etiketten ensam fullt ut vilken inmatning som krävs, inklusive eventuella formatkrav? (b) Finns det kompletterande hjälptext synlig intill fältet? (c) Finns det en hjälpikon, ett verktygstips eller en expanderbar sektion som ger ytterligare vägledning? (d) Finns det en länk till relevant hjälpinnehåll? Om svaret på allt detta är nej, och fältet har någon form av tvetydighet, är detta ett misslyckande av 3.3.5.
\n
3. Testa tangentbordstillgänglighet för alla hjälp-mekanismer. Tabba genom formuläret med enbart tangentbord (ingen mus). Verifiera att varje verktygstips, hjälpikon, expanderbar beskrivning eller hjälplänk är nåbar och aktiverbar via tangentbord. Verktygstips bör visas vid fokus såväl som vid hovring. Hjälpknappar bör kunna triggas med Enter eller mellanslag. Alla hjälp-mekanismer som endast är nåbara med mus misslyckas i detta test.
\n
4. Testa med NVDA + Firefox. Navigera till varje formulärfält med Tab. Lyssna på vad NVDA läser upp för varje fält — läser den upp etiketten? Läser den upp någon associerad beskrivning (via aria-describedby)? Aktivera eventuella hjälpikoner eller verktygstips och bekräfta att deras innehåll läses upp. Försök nå länkad hjälpinformation och verifiera att den relaterar till det aktuella fältet.
\n
5. Testa med VoiceOver + Safari (macOS eller iOS). Använd VoiceOver för att navigera i formuläret. På macOS, använd Tab för att flytta mellan fält och lyssna på den fullständiga upplysningen för varje. På iOS, använd svepnavigering. Verifiera att allt hjälpinnehåll som är associerat med inmatningar läses upp, och att hjälp-utlösare (knappar, länkar) är tillgängliga och korrekt etiketterade av VoiceOver.
\n
6. Testa med JAWS + Chrome. Använd JAWS formulärläge (aktivera med Enter när du står på ett formulärelement). Navigera mellan fält med Tab och verifiera att JAWS läser upp associerade instruktioner och beskrivningar. Använd JAWS virtuella markör för att kontrollera att hjälpinnehåll som placerats utanför standardassociationer för etiketter också är nåbart.
\n
7. Genomför en kognitiv genomgång. Be en person som är obekant med formuläret (eller simulera detta genom att granska formuläret efter en paus) att försöka fylla i det utan extern vägledning. Notera varje punkt där personen tvekar, ställer en fråga eller gör ett fel på grund av oklara förväntningar. Varje sådan punkt är en kandidat för förbättrad kontextkänslig hjälp enligt 3.3.5.
\n

\n\n

Hur man åtgärdar

\n

Tvetydigt textfält utan förklaring — Felaktigt

\n

<!-- No help provided for an ambiguous field expecting a specific format -->\n<label for='tc-kimlik'>TC Kimlik No</label>\n<input type='text' id='tc-kimlik' name='tc-kimlik'>

\n

Tvetydigt textfält med inline-hjälp — Korrekt

\n

<!-- Inline description associated via aria-describedby gives format guidance before the user types -->\n<label for='tc-kimlik'>TC Kimlik No</label>\n<input\n  type='text'\n  id='tc-kimlik'\n  name='tc-kimlik'\n  aria-describedby='tc-kimlik-help'\n  autocomplete='off'\n  maxlength='11'\n>\n<p id='tc-kimlik-help'>\n  Nüfus cüzdanınızda yer alan 11 haneli TC Kimlik Numaranızı giriniz.\n  (Enter your 11-digit Turkish National ID number as shown on your ID card.)\n</p>

\n\n

Hjälpikons verktygstips otillgängligt för tangentbordsanvändare — Felaktigt

\n

<!-- Tooltip only shown on mouseover; keyboard users and screen reader users cannot access it -->\n<label for='iban'>IBAN <span class='help-icon' title='What is IBAN?'>?</span></label>\n<input type='text' id='iban' name='iban'>

\n

Hjälpikons verktygstips tillgängligt för alla användare — Korrekt

\n

<!-- Button with aria-expanded controls a help panel; accessible via keyboard and screen readers -->\n<label for='iban'>IBAN</label>\n<button\n  type='button'\n  aria-expanded='false'\n  aria-controls='iban-help'\n  class='help-toggle'\n  aria-label='Help: What is an IBAN?'\n>\n  ?\n</button>\n<input type='text' id='iban' name='iban' aria-describedby='iban-help'>\n<div id='iban-help' hidden>\n  <p>\n    IBAN (International Bank Account Number) is a 26-character code starting\n    with "TR" used to identify your Turkish bank account. You can find it\n    in your bank's mobile app under Account Details.\n  </p>\n</div>\n<!-- JavaScript toggles aria-expanded and the hidden attribute on button click/keypress -->

\n\n

Komplext flerstegsformulär utan vägledning på stegnivå — Felaktigt

\n

<!-- Step 2 of a 4-step application with no explanation of what documents are needed -->\n<h2>Step 2: Upload Documents</h2>\n<label for='doc-upload'>Upload File</label>\n<input type='file' id='doc-upload' name='doc-upload'>

\n

Komplext flerstegsformulär med kontextuell steghjälp — Korrekt

\n\n

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