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, published by the W3C, is the current version of the standard, and Level AA is the benchmark most organisations aim for. It is increasingly written into regulation: UK public sector bodies must meet WCAG 2.2 AA, and the US Department of Justice's 2024 ADA Title II rule makes WCAG 2.1 Level AA the technical standard for state and local governments' web content and mobile apps.

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)
• Text can be resized up to 200% without loss of content or functionality, and content reflows without two-dimensional scrolling at a width of 320 CSS pixels (equivalent to 400% zoom on a 1280px-wide screen)
• 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 use well-formed, semantic HTML (WCAG 2.2 marks the old 4.1.1 Parsing criterion as obsolete and removed, but clean markup still helps assistive technology)
• 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 `<label> elements associated with each input via for/id` attributes.

Error Handling

• Failure: Errors displayed only in red text next to the field, with no programmatic association.
• Fix: Use `aria-describedby to link error messages to fields. Provide an error summary at the top of the form. Use aria-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 `<select>` 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 (`<input type="file">`) 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 can block screen reader users and people with cognitive disabilities. Use verification methods that do not rely on a visual or cognitive puzzle, and note that WCAG 2.2 Success Criterion 3.3.8 (Accessible Authentication) restricts cognitive function tests in login steps.
• 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 an Accessibility Conformance Report (ACR) — a completed VPAT (Voluntary Product Accessibility Template) — 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

Email

• 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, where your platform supports it
• 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

Testing Process

1. Automated scan with axe or Lighthouse — catches only part of the issues, so never rely on it alone
2. Manual keyboard testing — navigate every page using only Tab, Enter, Space, and arrow keys
3. Screen reader testing — test with NVDA (Windows) or VoiceOver (macOS) at minimum
4. User testing — recruit disabled users to test real application flows

Common Failures and Fixes

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.