If you hire through a website -- a careers page, a Greenhouse job post, a LinkedIn Easy Apply listing, a Google Form, a PDF you ask people to email back -- there is a very good chance that disabled candidates are dropping out of your funnel before a human ever sees them. Not because they are not qualified. Because the application form does not work.
This is not a small problem. The U.S. Bureau of Labor Statistics puts the labor-force participation rate for people with disabilities at roughly 24%, compared with 67% for the rest of the population. A meaningful share of that gap is structural, and a meaningful share of the structural part is the application step itself: a date picker that cannot be reached with a keyboard, a CAPTCHA that demands you click pictures of buses, an "upload your resume" field with no label that screen readers can find, a multi-step wizard that loses your data when a screen reader pages back.
This article is for hiring managers, HR leads, founders, and small-business owners who are not developers but are responsible for a careers page that converts. We will cover what the law actually requires, the specific failures we see most often, how to test your own form in about ten minutes, and what to do when the form is on a platform you do not control.
The legal context, in plain English
In the United States, three layers of law apply to your job application form, even if your company is small.
ADA Title I (employment) covers any employer with 15 or more employees. The Equal Employment Opportunity Commission (EEOC) treats inaccessible application processes as a form of disability discrimination. The EEOC's published guidance is explicit: if your application "cannot be completed by an applicant with a disability without an accommodation," you are required to provide one, and you cannot use the inaccessibility as a basis for not hiring the person.
ADA Title III (public accommodations) covers any business that holds itself out as serving the public. Most federal courts now treat a public-facing careers page as falling within Title III, even if the company has fewer than 15 employees. Demand letters citing Title III violations on careers pages have been a steady part of the small-business legal landscape since 2021, and 2026 has seen a notable uptick.
Section 503 and OFCCP apply to federal contractors and subcontractors. If you do any work funded by the federal government -- including subcontracts -- your hiring process is subject to Section 503's affirmative-action obligations and the OFCCP's accessibility expectations, which lean on WCAG 2.1 AA.
In Europe, the European Accessibility Act, in force since 28 June 2025, treats consumer-facing digital services -- including the parts of your careers site that the public uses -- as in scope. Member-state regulators have begun enforcing against large employers and are working their way down to mid-market companies.
State laws layer on top: California's Unruh Civil Rights Act and FEHA, New York's State Human Rights Law, Colorado's HB21-1110, and others all create independent paths to liability that do not depend on the federal framework.
The combined practical takeaway: assume your careers page and application form have to be accessible. Assume the legal exposure is real even if you are small.
The seven failures we see in nearly every careers-page audit
These are the recurring patterns. If you have not specifically tested for them, your form almost certainly has at least three.
1. Resume upload field with no programmatic label
The "Upload your resume" control is often a styled <div> that triggers a hidden file input via JavaScript. Screen readers read it as "clickable" with no label. Keyboard users cannot tell what the control is for. The ATS company you bought this from probably has a fix in their changelog from 2023; it is just not enabled on your account.
How to fix: open the form on your own machine, press Tab until focus lands on the upload control, and listen with a screen reader (VoiceOver on Mac, Narrator on Windows). If the control is announced as "clickable" or "button" without saying what it does, file a support ticket with your applicant tracking system citing WCAG 1.3.1 (Info and Relationships) and 2.4.6 (Headings and Labels). Most ATS vendors will turn on a fix at the account level within a week.
2. CAPTCHA gating the submit button
A CAPTCHA -- "click all the pictures of crosswalks" -- on a job application is one of the highest-risk patterns in the entire industry. It locks out blind users almost completely (audio CAPTCHA is consistently below 50% intelligibility), it locks out users with cognitive disabilities, and it disproportionately filters out anyone using assistive technology that makes the page look unusual to bot detectors.
How to fix: turn the CAPTCHA off. If you have a bot problem, use a server-side bot detector (Cloudflare Turnstile, hCaptcha Enterprise's invisible mode) that does not require any user interaction. If your platform does not support invisible verification, switch to honeypot fields (an invisible field that bots fill in but humans cannot see). We have written about this in detail in Captcha Accessibility Alternatives.
3. Date pickers that cannot be reached with a keyboard
"Earliest available start date" is almost always a custom date picker. About half the ones we audit cannot be opened with the keyboard, navigated with arrow keys, or closed with Escape. A candidate who uses a switch device, voice control, or a head-tracker simply cannot complete the field.
How to fix: in the form designer for your ATS, change the date field type from "date picker" to "text input" with a placeholder format ("YYYY-MM-DD"). It is uglier. It works for everyone. If the ATS forces a picker, file a support ticket and, in the meantime, document that you accept resumes by email at an alternate address from any candidate who cannot complete the form.
4. Multi-page wizard that loses progress
Many ATSs split applications into 4 to 8 pages: contact, work history, education, voluntary disclosure, equal-employment questions. If a candidate using a screen reader pages back to fix an earlier answer, the form often resets the later pages. We have watched candidates reach the final page and lose 40 minutes of work.
How to fix: test it. Fill out your own application end to end, then page back from the last step and check whether the data on later steps survives. If it does not, escalate to the ATS vendor and, until they fix it, switch to a single-page application form.
5. Required field markers conveyed only by red color
Required fields are usually marked with a red asterisk (*) and red text. Color-blind users (about 8% of men and 0.5% of women) cannot distinguish red from black at small sizes. Screen readers do not announce color. As a result, a third of candidates with color-blindness fail validation on first submit, and a meaningful number of screen-reader users are unaware which fields are required at all.
How to fix: ensure every required field is marked with both the visible asterisk and the HTML required attribute (so screen readers announce "required"). The label text should also include the word "required" when the visual style is the only cue. Most ATSs have a "required-field accessibility" toggle in their admin -- find it and turn it on.
6. Voluntary disclosure forms that are not optional in practice
Federal contractors are required to invite applicants to self-identify as having a disability, as a veteran, and so on. The form is supposed to be voluntary. In practice, the disclosure step is often laid out so that "I do not wish to answer" is buried, the radio buttons are not in a fieldset, and the required-by-law disclaimer is unreadable to screen readers.
How to fix: rewrite the section so that "I do not wish to answer" is the first option, the disclaimer is a real <p> element with a meaningful aria-describedby link to the question, and the legal text is at least 14px with a 4.5:1 contrast ratio. The OFCCP-mandated language is published; you can paste it in directly.
7. Error messages that appear without focus or announcement
When a candidate submits with missing or invalid fields, the error messages typically appear as small red text near each field. There is no automatic focus shift, no scroll, and no role="alert" announcement. Sighted users on a phone may not notice a single short red line at the top of a long form. Screen-reader users hear nothing.
How to fix: ATS vendors generally have an account setting for this. Turn on "scroll to first error on submit" and "announce errors via aria-live region." If your platform does not support this, we have a longer walkthrough in Accessible Forms Guide covering the specific HTML and JavaScript patterns that make form errors usable for everyone.
How to audit your own application form in ten minutes
You do not need a developer to do this. You need a quiet ten minutes.
- Open your job posting in a private browsing window so you are seeing it as a candidate would.
- Apply with your keyboard only. Hit Tab from the top of the page. You should be able to reach every field, the resume upload, the submit button, and any modal or popover that opens. If the focus disappears or stops moving, you have a keyboard trap.
- Turn on your operating-system screen reader (VoiceOver on Mac: Cmd+F5; Narrator on Windows: Ctrl+Win+Enter). Tab to each field and listen. Every field should announce its label and whether it is required. Buttons should announce what they do, not just "button."
- Zoom your browser to 200% (Cmd+Plus or Ctrl+Plus). The form should still be usable. Text should not overlap; controls should not disappear; no horizontal scrolling should be required to read a single line.
- Submit the form with deliberately wrong data (an invalid email, no phone number) and watch what happens. The page should tell you what went wrong, in text, near the bad field, and announce it to assistive technology.
- Try to upload an unusual file type (a .pages file, a .odt file). The error should be helpful, not cryptic.
- Time yourself. If a form takes longer than 15 minutes to complete with keyboard and screen reader, it is functionally inaccessible to many disabled candidates regardless of whether each individual control passes audit.
If two or more of those steps fail, you have material legal and pipeline exposure. Document it, escalate it to your ATS vendor, and -- in the meantime -- publish a clear alternate path: "Candidates who experience difficulty with our application form may email careers@yourcompany.com directly. We will respond within two business days."
Platform-specific quick notes
Greenhouse, Lever, Workable, BambooHR, JazzHR: all five publish accessibility statements and ship default forms that pass most automated audits. The most common failure on each is a specific custom field or workflow added by your hiring team. Audit your custom fields.
LinkedIn Easy Apply: generally accessible. The accessibility risk is in the screening questions you write. Avoid CAPTCHAs in screening questions; phrase yes/no questions with both choices visible; do not add a video-only response requirement without a written alternative.
Indeed Apply: known accessibility issues with the resume upload step on mobile screen readers. Until Indeed ships a fix, do not rely on Indeed Apply as your sole channel.
Google Forms: improved markedly in 2024-2025. Default forms are generally accessible. The risk is in long forms and in conditional logic, which can confuse screen readers.
PDF "fillable" application forms emailed back to the company: stop using these. PDFs are notoriously difficult to make accessible to screen readers, and asking a candidate to print, fill, scan, and email is itself an accessibility barrier. Move to a web form.
Custom-built careers pages: the highest risk. If your careers page was built by an agency more than two years ago, it almost certainly has issues. Run it through a free scanner (axe DevTools, WAVE) and through the manual ten-minute audit above.
What to put on your careers page
Three short things, in addition to the form itself:
- A statement at the top of the careers page or the application form: "We are committed to providing equal opportunity to candidates with disabilities. If you need a reasonable accommodation to apply, contact careers@yourcompany.com or call (555) 123-4567 and we will respond within two business days."
- An alternate-application path so candidates who cannot use the form have a documented alternative.
- A link to your accessibility statement, or, if you do not have one yet, a short note that one is in development. We have a guide on writing one in Accessibility Statement Guide.
These three additions do not eliminate legal risk, but they significantly lower it, and they materially increase the percentage of disabled candidates who complete an application.
The bottom line
Job application forms sit at the most expensive point in the hiring funnel. You have spent money on the job ad, on the recruiter's time, on the listing fee. Losing qualified candidates at the form step because of accessibility bugs is both a legal risk and a direct hit to your hiring economics. The fixes are mostly small, mostly free, and mostly take less than a day to implement once you know what to look for.
The expensive part is not knowing.
We're building a simple accessibility checker for non-developers -- no DevTools, no jargon. Join our waitlist to get early access.
Related Reading
- Accessible Forms Guide -- The patterns that make any web form usable with keyboard and screen reader.
- Captcha Accessibility Alternatives -- Why CAPTCHAs are an accessibility hazard, and what to do instead.
- Accessibility Statement Guide -- How to write a defensible accessibility statement for your careers page or main site.
Top comments (0)