Digital Accessibility for HR-teams: Gør rekruttering og arbejdspladsystemer WCAG-kompatible

Introduktion

Hvis dit karrierewebsted, ansøgningsformularer eller interne systemer ikke er tilgængelige, udelukker du kvalificerede kandidater og medarbejdere med handicap — og du kan være i strid med loven. Web Content Accessibility Guidelines (WCAG) 2.2, udgivet af W3C, er den aktuelle version af standarden, og Level AA er det benchmærk, som de fleste organisationer stiler mod. Det bliver i stigende grad skrevet ind i regulering: Offentlige organisationer i UK skal opfylde WCAG 2.2 AA, og USA's Department of Justice's 2024 ADA Title II-regel gør WCAG 2.1 Level AA til den tekniske standard for statslige og lokale regeringers webindhold og mobilapps.

Denne guide giver HR-teams en konkret, handlingsbar køreplan for at gøre rekruttering og arbejdspladsystemer tilgængelige.

Trin 1: Gennemgå dit karrierewebsted

Dit karrierewebsted er indgangsdøren til din organisation for hver kandidat. Et utilgængeligt karrierewebsted sender et klart budskab til ansøgere med handicap: I er ikke velkomne her.

WCAG 2.2 AA-tjekliste for karrierewebsteder

Perceptible (Opfatteligt)

• Alle billeder har meningsfuld alternativtekst (dekorative billeder bruger tomme alt-attributter)
• Videoer har undertekster og audiobeskrivelser
• Farvekontrast opfylder minimumskrav (4,5:1 for normal tekst, 3:1 for stor tekst)
• Teksten kan skaleres op til 200% uden tab af indhold eller funktionalitet, og indholdet omrammer uden to-dimensionel scrolling ved en bredde på 320 CSS-pixels (svarende til 400% zoom på en 1280px bred skærm)
• Informationen formidles ikke kun gennem farve

Operable (Operabel)

• Al funktionalitet er tilgængelig via tastatur (Tab, Enter, Space, piletaster)
• Fokusindikatorer er synlige og tydelige
• Der er ingen tastatursfaldgruber (brugere kan altid tappe væk fra ethvert element)
• Siderne har skip-navigationlinks
• Brugerne har tilstrækkelig tid til at fuldføre opgaver (eller kan forlænge tidsgrænser)
• Intet indhold blinker mere end tre gange pr. sekund

Understandable (Forståelig)

• Sidesproget er deklareret i HTML'en
• Formularetiketter er programmatisk forbundet med indgange
• Fejlmeddelelser er klare og præcise (f.eks. "E-mailadresse skal indeholde et @-symbol" i stedet for "Ugyldig input")
• Navigation er konsistent på tværs af sider

Robust (Robust)

• Sider bruger velformet, semantisk HTML (WCAG 2.2 markerer det gamle kriterium 4.1.1 Parsing som forældet og fjernet, men rent markup hjælper stadig hjælpeteknologi)
• Brugerdefinerede widgets bruger ARIA-roller, tilstande og egenskaber korrekt
• Indholdet fungerer med aktuel hjælpeteknologi (skærmlæsere, forstørrelser, stemmestyring)

Trin 2: Gør ansøgningsformularer tilgængelige

Ansøgningsformularer er hvor de fleste tilgængelighedsfejl opstår. Almindelige problemer og deres løsninger:

Etiketter og instruktioner

• Fejl: Placeholder-tekst bruges som den eneste etiket. Skærmlæsere annoncerer muligvis ikke placeholder-tekst konsekvent.
• Løsning: Brug synlige `<label>-elementer forbundet med hver indgang via for/id`-attributter.

Fejlhåndtering

• Fejl: Fejl vises kun i rød tekst ved siden af feltet uden programmatisk tilknytning.
• Løsning: Brug `aria-describedby til at linke fejlmeddelelser til felter. Angiv en fejlopsummering øverst i formularen. Brug aria-invalid="true"` på felter med fejl.

Tastaturnavigation

• Fejl: Brugerdefinerede dropdown-menuer og datovælgere, der kun fungerer med en mus.
• Løsning: Brug native HTML `<select>`-elementer hvor det er muligt. For brugerdefinerede widgets skal du implementere fuld tastaturunderstøttelse efter WAI-ARIA Authoring Practices.

Filuploadinger

• Fejl: Kun slæb-og-slip-resuméupload uden alternativ.
• Løsning: Angiv altid en standard-filinput (`<input type="file">`) sammen med ethvert slæb-og-slip-interface.

Fremskridtsindikatorer

• Fejl: Multi-trin-formularer, der ikke angiver nuværende position eller tillader bagudnavigation.
• Løsning: Brug `aria-current="step"` og angiv klare trinantal (f.eks. "Trin 2 af 4"). Tillad brugere at navigere tilbage til tidligere trin uden at miste data.

Trin 3: Konfigurer dit ATS for tilgængelighed

Applicant Tracking Systems (ATS) genererer mange af de sider, som kandidater interagerer med. Almindelige ATS-tilgængelighedsproblemer:

• Auto-genererede jobpostningssider kan mangle overskriftsstruktur. Arbejd med din ATS-leverandør for at sikre, at H1/H2/H3-tags bruges korrekt.
• Ansøg-med-LinkedIn eller lignende one-click-funktioner er muligvis ikke tastaturbar tilgængelige. Test grundigt eller angiv et manuelt alternativ.
• CAPTCHA på ansøgningsformularer kan blokere brugere af skærmlæsere og mennesker med kognitive handicap. Brug verifikationsmetoder, der ikke er afhængige af et visuelt eller kognitivt puslespil, og bemærk, at WCAG 2.2 Succescriterium 3.3.8 (Accessible Authentication) begrænser tests af kognitiv funktion i login-trin.
• Sessiontimeouts under lange ansøgninger straffer brugere, der skriver langsomt. Forlæng eller fjern timeouts, eller advar brugere før timeout og tillad forlængelse.

Handlingspunkt: Anmod om en Accessibility Conformance Report (ACR) — en udfyldt VPAT (Voluntary Product Accessibility Template) — fra din ATS-leverandør. Hvis de ikke kan levere en, bør du overveje at skifte til en leverandør, der tager tilgængelighed seriøst.

Trin 4: Opret tilgængelige onboarding-dokumenter

Nye medarbejdere modtager en masse dokumenter: kontrakter, håndbøger, benefits-vejledninger, træningsmaterieller. Alt dette skal være tilgængeligt.

PDF-tilgængelighed

• Brug mærkede PDF'er med en logisk læserækkefølge
• Sikr, at alle billeder har alternativtekst
• Brug ægte tekst (ikke scannet billeder af tekst)
• Definer dokumentsprog og titel
• Test med en skærmlæser (Adobe Acrobat's tilgængelighedskontrol er et udgangspunkt, men manuel testning er vigtig)

Slideshows og træningsmaterieller

• Brug slideslayouts (ikke fri-form-tekstbokse), så skærmlæsere følger en logisk læserækkefølge
• Tilføj alternativtekst til alle visuelle elementer
• Sikr tilstrækkelig farvekontrast
• Angiv talenoter som en alternativ tekstfortælling
• Optag lyd/video med undertekster

Formularer og spørgeskemaer

• Brug tilgængelige formularbyggere (Microsoft Forms, Google Forms er rimeligt tilgængelige; test andre før udrulning)
• Brug aldrig PDF-formularer, der kræver, at brugeren udskriver, skriver i hånden og scannerer

Trin 5: Gør intern kommunikation tilgængelig

E-mail

• Brug semantisk HTML i e-mailskabeloner (overskrifter, lister, alternativtekst for billeder)
• Undgå at sende kritiske oplysninger kun som vedhæftelser af billeder
• Angiv plain-text-alternativer

Intranet

• Anvend de samme WCAG 2.2 AA-standarder som dit karrierewebsted
• Sikr, at søgefunktionalitet fungerer med skærmlæsere
• Gør dokumentlagre navigerbare med tastatur

Slack, Teams og chatplatforme

• Opmuntr brugen af alternativtekst på billeder, der deles i kanaler, hvor din platform understøtter det
• Brug tråde i stedet for lange ustrukturerede samtaler (lettere for kognitiv tilgængelighed)
• Aktivér og promover undertekster i videoopkald
• Sikr, at kritiske meddelelser også postes i tekstformat, ikke kun som video eller lyd

Testværktøjer

Testproces

1. Automatiseret scan med axe eller Lighthouse — fanger kun en del af problemerne, så stol aldrig kun på det
2. Manuel tastaturtest — navigér gennem alle sider kun ved hjælp af Tab, Enter, Space og piletaster
3. Skærmlæsertest — test med NVDA (Windows) eller VoiceOver (macOS) som minimum
4. Brugertest — rekruttér mennesker med handicap til at teste rigtige ansøgningsflows

Almindelige fejl og rettelser

Konklusion

Digital tilgængelighed for HR-systemer er ikke et engangsprojekt — det er en løbende forpligtelse. Gennemgå dine nuværende systemer, udbedre de vigtigste barrierer først, test regelmæssigt med rigtig hjælpeteknologi, og hold dine leverandører ansvarlige. Hver forbedring gør din arbejdsplads mere inkluderende og din talentpool større.