A practical guide for HR teams to audit and improve the accessibility of career sites, application forms, ATS platforms, onboarding documents, and internal communications against WCAG 2.2 AA standards.
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 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 `` 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
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 (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.