A disabled candidate who can't complete your application form doesn't email to complain. They close the tab and apply somewhere else, and you never learn you lost them. Careers page accessibility is the quiet part of inclusive hiring that most diversity statements skip over: you can write the most welcoming job description in the world, but if a screen reader can't read the apply button or a keyboard user gets trapped in a date picker, the door is still closed.
For HR and recruiting teams, this isn't only an ethics question. An applicant tracking system (ATS) that fails WCAG quietly filters out qualified people, and in the EU the European Accessibility Act now sets a WCAG 2.2 AA baseline for in-scope digital services. This guide covers the specific, fixable problems on careers pages and job boards: forms, PDFs, keyboard traps, and the errors that send good candidates away.
The application form is where most candidates are lost
The form is the highest-stakes screen on your careers site, and it's where accessibility failures hurt most because there is no workaround for a candidate who can't submit. Start with the fundamentals that screen reader and keyboard users depend on.
- Every field needs a real, programmatically associated
<label>. Placeholder text disappears on focus and is not a substitute. A field labelled only by a grey placeholder fails WCAG 1.3.1 and 3.3.2. - Required fields must be announced, not just shown with a red asterisk. Use
aria-requiredand a text marker, never colour alone (1.4.1). - Group related inputs (a name split into first/last, or a set of radio buttons) inside a
<fieldset>with a<legend>so the relationship is announced. - Tap and click targets must be at least 24 by 24 CSS pixels under WCAG 2.2's new 2.5.8 Target Size (Minimum), which matters for mobile applicants using switch controls or with limited dexterity.
- If you use a CV upload, the file input must be reachable and operable by keyboard, and the accepted formats stated in text, not implied by an icon.
Error handling is the other half of the form. When a candidate misses a field, WCAG 3.3.1 requires you to identify the error in text, 3.3.3 requires a suggestion for fixing it ('Enter a phone number including area code', not just 'Invalid'), and 4.1.3 Status Messages requires that the error be announced to assistive technology via a live region rather than appearing silently. WCAG 2.2 also adds 3.3.7 Redundant Entry, so don't force applicants to re-type information they already gave you earlier in the flow. For the full field-by-field pattern, see our guide to accessible forms.
Accessible PDFs: job descriptions and application packs
Recruiting runs on PDFs: the detailed job description, the benefits summary, the role pack a hiring manager exports from Word. A PDF that looks fine on screen is often completely opaque to a screen reader, and this is one of the most common careers-page failures.
A PDF is accessible only if it is tagged. Tags give the document a reading order and structure, the same way HTML headings and landmarks do. An untagged or scanned-image PDF is just a picture of text and fails WCAG 1.1.1 and 1.3.1 outright. Before you publish a role pack, check that it has a logical heading structure, real selectable text (not a scanned image), a set document language for 3.1.1, alt text on any diagrams or org charts, and a tab order that follows the visual order.
The good news is that most recruiting PDFs originate in Word, where you can fix the structure at the source: use the built-in heading styles, add alt text, and export with document structure tags for accessibility enabled rather than printing to PDF. Our PDF accessibility guide explains tagging, export settings, and remediation. Where you can, publish the job description as a plain HTML page too. HTML is more accessible by default, easier to keep in sync, and better for SEO than a buried PDF.
No keyboard traps, ever
Many candidates with motor or visual disabilities never touch a mouse. They navigate entirely by keyboard: Tab to move forward, Shift+Tab back, Enter and Space to activate. WCAG 2.1.2 (No Keyboard Trap) is unambiguous: if focus can move into a component, it must be able to move out using only the keyboard. Careers pages break this constantly, and the usual culprits are predictable:
- Custom date pickers for 'available start date' that capture focus and offer no keyboard escape.
- Embedded third-party ATS widgets and iframes that swallow the Tab key and never return it.
- Modal dialogs ('Are you sure you want to leave?') that don't manage focus correctly, or trap it permanently with no Escape.
- Cookie banners and chat widgets that sit on top of the form and can't be dismissed by keyboard.
Two newer WCAG 2.2 criteria reinforce this. 2.4.11 Focus Not Obscured (Minimum) means the element you've tabbed to can't be fully hidden behind a sticky header or floating chat bubble, a frequent problem on long application forms. And 3.2.6 Consistent Help asks that help mechanisms appear in a consistent place, so applicants who get stuck always know where to find a way out. The test costs nothing: put the mouse aside and complete your own application by keyboard from start to submit. Watch that a visible focus indicator (2.4.7) follows you the entire way. Our keyboard accessibility guide details the focus-management patterns that prevent traps.
The legal baseline HR should know
You don't need to become a compliance expert, but recruiters should know the floor. The technical standard almost everywhere is WCAG, and 2.2 Level AA is the current target. In the EU, the European Accessibility Act applies from 28 June 2025 and points to WCAG 2.2 Level A and AA through the EN 301 549 standard. In the US, the ADA names no specific WCAG version, but 2.1/2.2 AA is the de-facto benchmark, and the Revised Section 508 standard requires WCAG 2.0 AA for federal agencies. In Canada, Ontario's AODA references WCAG 2.0 AA and the federal Accessible Canada Act adds its own requirements. Employment non-discrimination law sits on top of all of this and reaches the hiring process directly.
Two practical implications for HR. First, your third-party ATS is your responsibility from the candidate's point of view, so ask vendors for an accessibility conformance report (VPAT) and make it a procurement requirement, not an afterthought. Second, always provide an accessible alternative route to apply, a monitored email or phone line, so that a single broken widget never fully blocks someone. To map the obligations, see ADA vs WCAG vs EAA.
A quick audit you can run this week
You can pressure-test your careers page in an afternoon without specialist tooling. Work through it in this order:
- Run an automated scan on the careers and application URLs to catch contrast, structure, and labelling issues fast. You can scan a page free with AccessScan to get a prioritised list before you touch code.
- Complete one full application by keyboard only, watching for traps and a visible focus ring throughout.
- Open the same flow with a screen reader (VoiceOver or NVDA are free) and confirm every field, button, and error is announced.
- Check colour contrast on body text and form fields against 4.5:1 (3:1 for large text and UI components) using a contrast checker.
- Open every linked PDF and confirm it's tagged, has real text, and reads in a logical order.
- Walk the published checklist end to end with our accessibility checklist.
Inclusive hiring is a pipeline problem, and the website is the top of the funnel. Fixing the careers page won't fix everything downstream, but it stops you from silently filtering out disabled candidates before anyone in HR ever sees their name. That's the cheapest, highest-leverage diversity work most teams haven't done yet.