Digital Accessibility for HR Teams: Making Recruitment and Workplace Systems WCAG Compliant
Introduction
If your career site, application forms, or internal systems are not accessible, you are excluding qualified candidates and employees with disabilities — and you may be violating the law. The Web Content Accessibility Guidelines (WCAG) 2.2 Level AA is the internationally recognised standard, and it is referenced by the ADA (US), the Equality Act (UK), the European Accessibility Act (EU), and accessibility legislation in Canada, Australia, and beyond.
This guide gives HR teams a concrete, actionable roadmap to make recruitment and workplace systems accessible.
Step 1: Audit Your Career Site
Your career site is the front door to your organisation for every candidate. An inaccessible career site sends a clear message to disabled applicants: you are not welcome here.
WCAG 2.2 AA Checklist for Career Sites
Perceivable
- All images have meaningful alt text (decorative images use empty alt attributes)
- Videos have captions and audio descriptions
- Colour contrast meets minimum ratios (4.5:1 for normal text, 3:1 for large text)
- Content is readable at 200% zoom without horizontal scrolling
- Information is not conveyed by colour alone
Operable
- All functionality is available via keyboard (Tab, Enter, Space, Arrow keys)
- Focus indicators are visible and distinct
- No keyboard traps exist (users can always Tab away from any element)
- Pages have skip-navigation links
- Users have enough time to complete tasks (or can extend time limits)
- No content flashes more than three times per second
Understandable
- Page language is declared in the HTML
- Form labels are programmatically associated with inputs
- Error messages are clear and specific (e.g., "Email address must include an @ symbol" rather than "Invalid input")
- Navigation is consistent across pages
Robust
- Pages validate against HTML standards
- Custom widgets use ARIA roles, states, and properties correctly
- Content works with current assistive technology (screen readers, magnifiers, voice control)
Step 2: Make Application Forms Accessible
Application forms are where most accessibility failures occur. Common problems and their fixes:
Labels and Instructions
- Failure: Placeholder text used as the only label. Screen readers may not announce placeholder text consistently.
- Fix: Use visible `
elements associated with each input viafor/id` attributes.
Error Handling
- Failure: Errors displayed only in red text next to the field, with no programmatic association.
- Fix: Use `
aria-describedbyto link error messages to fields. Provide an error summary at the top of the form. Usearia-invalid="true"` on fields with errors.
Keyboard Navigation
- Failure: Custom dropdown menus and date pickers that only work with a mouse.
- Fix: Use native HTML `
` elements where possible. For custom widgets, implement full keyboard support following the WAI-ARIA Authoring Practices.
File Uploads
- Failure: Drag-and-drop-only resume upload with no alternative.
- Fix: Always provide a standard file input (`
`) alongside any drag-and-drop interface.
Progress Indicators
- Failure: Multi-step forms that do not indicate current position or allow backward navigation.
- Fix: Use `
aria-current="step"` and provide clear step counts (e.g., "Step 2 of 4"). Allow users to navigate back to previous steps without losing data.
Step 3: Configure Your ATS for Accessibility
Applicant Tracking Systems (ATS) generate many of the pages that candidates interact with. Common ATS accessibility issues:
- Auto-generated job listing pages may lack heading structure. Work with your ATS vendor to ensure H1/H2/H3 tags are used correctly.
- Apply-with-LinkedIn or similar one-click features may not be keyboard accessible. Test thoroughly or provide a manual alternative.
- CAPTCHA on application forms blocks screen reader users. Use invisible reCAPTCHA or alternative verification methods.
- Session timeouts during long applications penalise users who type slowly. Extend or remove timeouts, or warn users before timeout and allow extension.
Action item: Request a VPAT (Voluntary Product Accessibility Template) or an Accessibility Conformance Report (ACR) from your ATS vendor. If they cannot provide one, consider switching to a vendor that takes accessibility seriously.
Step 4: Create Accessible Onboarding Documents
New hires receive a flood of documents: contracts, handbooks, benefits guides, training materials. All of these must be accessible.
PDF Accessibility
- Use tagged PDFs with a logical reading order
- Ensure all images have alt text
- Use real text (not scanned images of text)
- Define document language and title
- Test with a screen reader (Adobe Acrobat's accessibility checker is a starting point, but manual testing is essential)
Slide Decks and Training Materials
- Use slide layouts (not free-form text boxes) so that screen readers follow a logical reading order
- Add alt text to all visual elements
- Ensure sufficient colour contrast
- Provide speaker notes as an alternative text narrative
- Record audio/video with captions
Forms and Surveys
- Use accessible form builders (Microsoft Forms, Google Forms are reasonably accessible; test others before deploying)
- Never use PDF forms that require the user to print, handwrite, and scan
Step 5: Make Internal Communications Accessible
- Use semantic HTML in email templates (headings, lists, alt text for images)
- Avoid sending critical information only as image attachments
- Provide plain-text alternatives
Intranet
- Apply the same WCAG 2.2 AA standards as your career site
- Ensure search functionality works with screen readers
- Make document repositories navigable by keyboard
Slack, Teams, and Chat Platforms
- Encourage the use of alt text on images shared in channels (Slack and Teams both support this)
- Use threads rather than long unstructured conversations (easier for cognitive accessibility)
- Enable and promote captioning in video calls
- Ensure critical announcements are also posted in text format, not only as video or audio
Testing Tools
| Tool | Type | Cost | Best For |
|---|---|---|---|
| **axe DevTools** | Browser extension | Free (basic) / Paid (pro) | Automated scanning for WCAG violations |
| **WAVE** | Browser extension | Free | Visual accessibility evaluation |
| **Lighthouse** | Built into Chrome DevTools | Free | Performance and accessibility auditing |
| **NVDA** | Screen reader | Free | Manual testing on Windows |
| **VoiceOver** | Screen reader | Free (macOS/iOS) | Manual testing on Apple devices |
| **Pa11y** | CLI / CI tool | Free (open source) | Automated testing in CI/CD pipelines |
| **SortSite** | Desktop application | Paid | Enterprise-wide site scanning |
Testing Process
- Automated scan with axe or Lighthouse — catches ~30–40% of issues
- Manual keyboard testing — navigate every page using only Tab, Enter, Space, and arrow keys
- Screen reader testing — test with NVDA (Windows) or VoiceOver (macOS) at minimum
- User testing — recruit disabled users to test real application flows
Common Failures and Fixes
| Common Failure | WCAG Criterion | Fix |
|---|---|---|
| Missing form labels | 1.3.1, 4.1.2 | Add ``<label>`` elements with ``for`` attributes |
| Insufficient colour contrast | 1.4.3 | Increase contrast to 4.5:1 minimum |
| No keyboard focus indicator | 2.4.7 | Add visible ``:focus`` styles in CSS |
| Images without alt text | 1.1.1 | Add descriptive ``alt`` attributes |
| Auto-playing video | 1.4.2 | Remove autoplay or provide pause control |
| Missing page titles | 2.4.2 | Add unique ``<title>`` elements |
| Inaccessible custom widgets | 4.1.2 | Use ARIA roles and keyboard handlers |
| Content reflow failure at 200% | 1.4.10 | Use responsive CSS layouts |
Conclusion
Digital accessibility for HR systems is not a one-time project — it is an ongoing commitment. Audit your current systems, remediate the most critical barriers first, test regularly with real assistive technology, and hold your vendors accountable. Every improvement makes your workplace more inclusive and your talent pool larger.