Partager cet articleLinkedInXWhatsApp

En praktisk guide för HR-team att granska och förbättra tillgängligheten för karriärsajter, ansökningsformulär, ATS-plattformar, introduktionsdokument och intern kommunikation enligt WCAG 2.2 AA-standarder.

Digital Accessibility för HR-team: Gör rekrytering och arbetsplatssystem WCAG-kompatibla

Introduktion

Om din karriärwebbplats, ansökningsformulär eller interna system inte är tillgängliga, utesluter du kvalificerade kandidater och anställda med funktionsnedsättningar — och du kan bryta mot lagen. Web Content Accessibility Guidelines (WCAG) 2.2, publicerad av W3C, är den aktuella versionen av standarden, och nivå AA är det riktmärke som de flesta organisationer strävar efter. Det är allt oftare inskrivet i reglering: brittiska offentliga sektorsaktörer måste uppfylla WCAG 2.2 AA, och US Department of Justice:s 2024 ADA Title II-regel gör WCAG 2.1 Level AA till den tekniska standarden för statliga och lokala myndigheters webbinnehål och mobilappar.

Den här guiden ger HR-team en konkret, handlingsbar färdplan för att göra rekrytering och arbetsplatssystem tillgängliga.

Steg 1: Granska din karriärwebbplats

Din karriärwebbplats är porten till din organisation för varje kandidat. En otillgänglig karriärwebbplats skickar ett klart meddelande till funktionshindrade sökande: ni är inte välkomna här.

WCAG 2.2 AA-checklista för karriärwebbplatser

Perceptibel

  • Alla bilder har meningsfull alt-text (dekorativa bilder använder tomma alt-attribut)
  • Videor har textning och ljudbeskrivningar
  • Färgkontrasten uppfyller minimiförhållandena (4,5:1 för normal text, 3:1 för stor text)
  • Text kan förstoras upp till 200% utan förlust av innehål eller funktionalitet, och innehål återflödar utan tvådimensionell scrollning vid en bredd på 320 CSS-pixlar (motsvarar 400% zoom på en 1280px bred skärm)
  • Information förmedlas inte endast genom färg

Manövrabel

  • All funktionalitet är tillgänglig via tangentbord (Tab, Enter, Mellanslag, Piltangenter)
  • Fokusindikationer är synliga och distinkta
  • Det finns ingen fokus-fälla (användare kan alltid tabb bort från alla element)
  • Sidor har hoppa över navigering-länkar
  • Användare har tillräckligt med tid för att slutföra uppgifter (eller kan förlänga tidsgränser)
  • Inget innehål blinkar mer än tre gånger per sekund

Förståelig

  • Sidspråk är deklarat i HTML
  • Formuleringsetiketter är programmatiskt kopplade till inmatningsfält
  • Felmeddelanden är tydliga och specifika (t.ex. "E-postadress måste innehålla en @-symbol" istället för "Ogiltig inmatning")
  • Navigering är konsekvent på alla sidor

Robust

  • Sidor använder välformad, semantisk HTML (WCAG 2.2 markerar det gamla kriteriet 4.1.1 Parsing som föråldrat och borttaget, men ren kod hjälper fortfarande assistive teknik)
  • Anpassade widgets använder ARIA-roller, tillstånd och egenskaper på rätt sätt
  • Innehål fungerar med aktuell assistive teknik (skärmläsare, förstoringsprogram, röststyrning)

Steg 2: Gör ansökningsformulär tillgängliga

Ansökningsformulär är där de flesta tillgänglighetsproblem uppstår. Vanliga problem och deras lösningar:

Etiketter och instruktioner

  • Problem: Platshållartext används som enda etikett. Skärmläsare kanske inte tillkännager platshållartext konsekvent.
  • Lösning: Använd synliga `<label>-element kopplade till varje inmatningsfält via for/id`-attribut.

Felhantering

  • Problem: Fel visas endast med röd text bredvid fältet, utan programmatisk koppling.
  • Lösning: Använd `aria-describedby för att länka felmeddelanden till fält. Tillhandahåll en felsammanfattning överst i formuläret. Använd aria-invalid="true"` på fält med fel.

Tangentbordsnavigation

  • Problem: Anpassade rullgardinsmenyer och datumväljare som bara fungerar med en mus.
  • Lösning: Använd interna HTML `<select>`-element där möjligt. För anpassade widgets implementerar du fullständig tangentbordsstöd enligt WAI-ARIA Authoring Practices.

Filuppladdning

  • Problem: Endast dra-och-släpp-resumé med ingen alternativ.
  • Lösning: Tillhandahåll alltid en standard filinmatning (`<input type="file">`) tillsammans med något dra-och-släpp-gränssnitt.

Förloppsindikatorer

  • Problem: Flerstegformulär som inte anger aktuell position eller tillåter bakåtnavigation.
  • Lösning: Använd `aria-current="step"` och tillhandahåll tydliga stegantal (t.ex. "Steg 2 av 4"). Låt användare navigera tillbaka till tidigare steg utan att förlora data.

Steg 3: Konfigurera din ATS för tillgänglighet

Applicant Tracking Systems (ATS) genererar många av de sidor som kandidater interagerar med. Vanliga ATS-tillgänglighetsproblem:

  • Automatiskt genererade jobannonsidor kan sakna rubrikstruktur. Arbeta med din ATS-leverantör för att säkerställa att H1/H2/H3-taggar används korrekt.
  • Ansök-via-LinkedIn eller liknande engångsklickfunktioner kanske inte är tangentbordsåtkomliga. Testa noggrant eller tillhandahåll ett manuellt alternativ.
  • CAPTCHA på ansökningsformulär kan blockera skärmläsaranvändare och personer med kognitiva funktionsnedsättningar. Använd verifieringsmetoder som inte förlitar sig på ett visuellt eller kognitivt pussel, och notera att WCAG 2.2 Success Criterion 3.3.8 (Accessible Authentication) begränsar kognitiva funktionstester i inloggningssteg.
  • Sessiontimeouts under långa ansökningar missgynnar användare som skriver långsamt. Förläng eller ta bort timeouts, eller varna användare före timeout och tillåt förlängning.

Åtgärdspunkt: Begär en Accessibility Conformance Report (ACR) — en slutförd VPAT (Voluntary Product Accessibility Template) — från din ATS-leverantör. Om de inte kan tillhandahålla en, överväg att byta till en leverantör som tar tillgänglighet på allvar.

Steg 4: Skapa tillgängliga introduktionsdokument

Nyanställda mottar ett överflöd av dokument: kontrakt, handböcker, förmånguider, trätningsmaterial. Alla dessa måste vara tillgängliga.

PDF-tillgänglighet

  • Använd taggade PDF-filer med en logisk läsordning
  • Säkerställ att alla bilder har alt-text
  • Använd verklig text (inte skannade bilder av text)
  • Definiera dokumentspråk och titel
  • Testa med en skärmläsare (Adobe Acrobat:s tillgänglighetskontroll är en utgångspunkt, men manuell testning är väsentlig)

Bildpresentationer och trätningsmaterial

  • Använd bildlayouter (inte friform-textrutor) så att skärmläsare följer en logisk läsordning
  • Lägg till alt-text till alla visuella element
  • Säkerställ tillräcklig färgkontrast
  • Tillhandahåll talaranteckningar som ett alternativt textberättande
  • Spela in ljud/video med textning

Formulär och enkäter

  • Använd tillgängliga formulärbyggare (Microsoft Forms, Google Forms är rimligt tillgängliga; testa andra innan de distribueras)
  • Använd aldrig PDF-formulär som kräver att användaren skriver ut, skriver för hand och skannar

Steg 5: Gör intern kommunikation tillgänglig

E-post

  • Använd semantisk HTML i e-postmallar (rubriker, listor, alt-text för bilder)
  • Undvik att skicka kritisk information endast som bifogade bilder
  • Tillhandahåll rena textwebbversioner

Intranät

  • Applicera samma WCAG 2.2 AA-standarder som din karriärwebbplats
  • Säkerställ att sökfunktionen fungerar med skärmläsare
  • Gör dokumentarkiv navigerbara via tangentbord

Slack, Teams och chattplattformar

  • Uppmuntra användningen av alt-text på bilder som delas i kanaler, där din plattform stöder det
  • Använd trådar istället för långa ostrukturerade konversationer (lättare för kognitiv tillgänglighet)
  • Aktivera och främja textning i videosamtal
  • Säkerställ att kritiska meddelanden också publiceras i textformat, inte endast som video eller ljud

Testningsverktyg

VerktygTypKostnadBäst för
axe DevToolsWebbläsartilläggGratis tillägg / Betalda nivåerAutomatiserad skanning för WCAG-överträdelser
WAVEWebbläsartillägg (WebAIM)Se WebAIMVisuell tillgänglighetsutvärdering
LighthouseInbyggd i Chrome DevToolsGratis (öppen källkod)Prestanda- och tillgänglighetsgranskning
NVDASkärmläsareGratisManuell testning på Windows
VoiceOverSkärmläsareGratis (macOS/iOS)Manuell testning på Apple-enheter
Pa11yCLI / CI-verktygGratis (öppen källkod)Automatiserad testning i CI/CD-pipelines
SortSiteSkrivbordsprogramBetaldFöretagsomfattande webbplatsskanning

Testningsprocess

  1. Automatiserad skanning med axe eller Lighthouse — fångar bara en del av problemen, så förlita dig aldrig enbart på det
  2. Manuell tangentbordstestning — navigera på varje sida med endast Tab, Enter, Mellanslag och piltangenter
  3. Skärmläsartestning — testa med NVDA (Windows) eller VoiceOver (macOS) som minimum
  4. Användartestning — rekrytera funktionshindrade användare för att testa riktiga ansökningsflöden

Vanliga misslyckanden och åtgärder

Vanligt misslyckandeWCAG-kriteriumÅtgärd
Etiketter på formulär saknas1.3.1, 4.1.2Lägg till `<label>-element med for`-attribut
Otillräcklig färgkontrast1.4.3Öka kontrasten till 4,5:1 minimum
Ingen synlig tangentbordsfokusindikator2.4.7Lägg till synliga `:focus`-stilar i CSS
Bilder utan alt-text1.1.1Lägg till beskrivande `alt`-attribut
Automatisk uppspelning av ljud (längre än 3 sekunder)1.4.2Ta bort autoplay eller tillhandahåll en paus/stopp eller volyumkontroll
Saknade sidtitlar2.4.2Lägg till unika `<title>`-element
Otillgängliga anpassade widgets4.1.2Använd ARIA-roller och tangentbordshanterare
Text kan inte förstoras till 200%1.4.4Använd relativa enheter och flexibla behållare
Innehål reflödar inte vid 320 CSS px bredd (400% zoom)1.4.10Använd responsiv CSS-layout

Slutsats

Digital tillgänglighet för HR-system är inte ett engångsprojekt — det är ett ständigt åtagande. Granska dina nuvarande system, åtgärda de mest kritiska barriärerna först, testa regelbundet med verklig assistive teknik och håll dina leverantörer ansvariga. Varje förbättring gör din arbetsplats mer inkluderande och din talangpool större.

Partager cet articleLinkedInXWhatsApp