Here's a five-minute experiment worth running before your next hiring push: unplug your mouse, open your own careers page, and try to apply for a job using only your keyboard. Tab through the listing, open the role, fill out the form, upload a resume, hit submit.
Did you make it? A lot of hiring teams don't — and they're often stunned to find out. The application widget your ATS vendor sold you as "modern" might be quietly locking out anyone who navigates by keyboard, screen reader, or switch device. And unlike a slow-loading image or an awkward font choice, this particular flaw doesn't just annoy candidates. It can turn away qualified people before they ever get a chance to be considered — which is exactly the scenario employment law was written to prevent.
The Stat: ADA Title I prohibits disability discrimination in employment, including in the application process — this is established federal law, not a new statistic. (Source: ADA.gov)
The gap between "we have an ATS" and "our ATS is usable"
Most employers assume that buying a well-known applicant tracking system (ATS) or careers-page builder automatically means accessibility is handled. It doesn't. Vendors optimize their demo flows for sales, not for screen reader users, and plenty of "modern" widgets — multi-step wizards, drag-and-drop resume uploaders, custom dropdowns, CAPTCHA gates — are built with visual polish first and keyboard/assistive-tech support as an afterthought, if it's considered at all.
That gap matters because employment law doesn't distinguish between "our vendor built it that way" and "we built it ourselves." If your application process excludes a qualified candidate because of a disability, the fact that a third-party widget caused the failure isn't a defense — it's just where the fix needs to happen first.
Why this is a legal issue, not just a UX one
ADA Title I covers the entire employment relationship, and courts and regulators have made clear that "the employment relationship" starts at recruitment — not on someone's first day. A job listing a blind candidate can't navigate, or a form a candidate with a motor disability can't complete because a button is unreachable by keyboard, is functionally a "no applicants with disabilities" sign hung on the front door, even if nobody intended it that way.
The EEOC's guidance for employers lays out employer responsibilities under the ADA in plain terms, and it's worth having your HR and recruiting leads actually read it rather than assuming legal or IT has it covered. Accessibility of the application process isn't a nice-to-have layered on top of compliance — for many employers, it is part of compliance.
If you're a federal agency or federal contractor, there's a second layer: Section 508 of the Rehabilitation Act requires that electronic and information technology — including online application systems — be accessible. Section508.gov is the authoritative source for what that standard actually requires in practice, and it's a useful reference even for private employers who want a rigorous bar to hire against.
The three most common places candidates get stuck
Based on how these systems tend to fail, the barriers almost always cluster in the same three spots — the ones mapped in the diagram above.
1. The unlabeled dropdown on the listing or filter page. Location filters, department selectors, and "sort by" menus are frequently built as custom components with no accessible name. A sighted mouse user sees "Location" printed next to it and clicks. A screen reader user tabs to it and hears nothing but "combo box" — no indication of what it does or what's currently selected.
2. The CAPTCHA with no audio or alternative option. CAPTCHAs are common on public-facing application forms to block bots, but a purely visual challenge (distorted text, "click all the traffic lights") is a dead end for blind and low-vision candidates if there's no audio version or accessible alternative. This is one of the single most avoidable dead-ends in the entire hiring funnel.
3. The resume upload widget that isn't keyboard-reachable. Drag-and-drop file uploaders look sleek, but if the only way to trigger a file picker is a mouse-driven drop zone with no keyboard-operable button behind it, keyboard and switch-device users are stuck one step before submission — often the very last step.
Any one of these can silently zero out a segment of your applicant pool. All three together, on the same form, is unfortunately common — and because each barrier fails silently, from the employer's side, there's usually no error log, no support ticket, and no signal that anything went wrong. A candidate who hits a dead end at the CAPTCHA step doesn't file a bug report; they just leave, and the position gets filled from a smaller pool than it needed to be. That silence is exactly what makes this category of issue easy to miss during a normal QA pass, and exactly why it's worth checking deliberately rather than waiting for someone to complain.
A quick audit checklist for your careers page
| Step | What to check | Fails when... |
|---|---|---|
| Job listing | Tab through filters and links using only a keyboard | A dropdown or filter has no visible focus indicator or announced label |
| Application form | Complete every field with a screen reader on | Fields have no <label>, or error messages aren't announced |
| CAPTCHA | Try the challenge with sound off / screen reader on | No audio option, no accessible alternative offered |
| Resume upload | Trigger the file picker using Tab + Enter only | Only a mouse-driven drag-and-drop zone exists |
| Submit | Confirm a success/error message is read aloud | Confirmation is visual-only (e.g., a toast that disappears) |
| Multi-step forms | Check that progress and step changes are announced | Screen reader gives no indication a new step has loaded |
- Every form field has a properly associated label
- All interactive elements are reachable and operable via keyboard alone
- Focus order follows the visual/logical order of the page
- CAPTCHA has a non-visual alternative
- File upload has a real, keyboard-operable button (not just a drop zone)
- Error and success messages are announced to screen readers, not just shown visually
Fixing it doesn't require rebuilding your ATS
The good news: most of these issues are fixable at the component level without ripping out your entire recruiting stack. Custom dropdowns can be swapped for accessible native or ARIA-compliant patterns. CAPTCHA vendors that offer audio challenges can be configured to show one. Upload widgets almost always have a hidden native <input type="file"> underneath — the fix is often just exposing a real, labeled, keyboard-focusable button that triggers it, rather than relying solely on the drag target.
The harder part is knowing which of these problems you actually have, because they're invisible if you only ever test with a mouse. That's the whole point of the five-minute experiment at the top of this article — and it's worth doing before you launch your next req, not after a candidate (or their attorney) tells you about it.
If you'd rather not comb through every form field and widget by hand, that's exactly what a proper audit is for. Get a free scan of your careers page before your next candidate hits a wall — you can start one here and find out what's actually blocking people before it becomes a bigger problem than a bad hire.