The Accessibility Failures Hiding in Almost Every Careers Portal

Every spring WebAIM scans the home pages of the top one million websites. After six straight years of slow improvement, the 2026 report went backward: 95.9 percent of those pages had detectable WCAG 2 failures, up from 94.8 percent, averaging 56 errors per page. The likely cause is complexity. The average home page now carries 1,437 elements, up 22.5 percent in one year.

Those are home pages, the most reviewed page any organization owns. If that’s the state of the front door, what are the odds you have an accessible job application form? It was probably built by a vendor, and it sits four clicks deep behind a “Careers” link.

That’s the page I want to talk about. It’s the one page on your site where an accessibility failure can cost somebody a job.
An accessible job application form is one a candidate can complete, start to finish, using only a keyboard or a screen reader. Most careers portals fall short on the same eight defects, and every one of them can be fixed.

Is your job application ADA compliant?

An inaccessible application form shuts a qualified person out of a job. Often it’s the same person the disability self-identification question was asking about two screens later.

The legal mechanism is worth getting right. Most web accessibility litigation is ADA Title III, about places of public accommodation. Careers portals sit mainly under Title I, which runs through the EEOC charge process. An inaccessible application usually shows up as evidence inside a failure-to-accommodate or discriminatory hiring claim, proof that the process screened someone out before a human ever saw them.

Meanwhile, WCAG has become the operative standard regardless of complaints. Section 508 applies to public-sector and contractor work. The European Accessibility Act has applied since June 28, 2025, and points to EN 301 549, which incorporates WCAG 2.1 Level AA. And WCAG 2.x AA has become the default clause in RFPs, which is why someone has probably already asked you for a VPAT.

8 accessibility defects hiding in most job application forms

Portal accessibility failures cluster into a small set of recurring defects, which makes them solvable. Every one below is a defect we found on our own jobs portal and fixed. The list comes from our own audit.

1. Controls that only look like buttons. Filters, clear-filters and share controls built as styled divs. A mouse user never notices. A keyboard user can’t reach them, and a screen reader doesn’t announce them as clickable.
2. Validation errors nobody announces. You press Submit and nothing appears to happen. The error is on screen, but it was never announced and focus never moved to it, so a screen reader user is stuck with no idea why. This is one of the most common places a qualified applicant gives up.
3. Hand-assigned focus order. Positive tabindex values sprinkled across a page, so tabbing jumps around in an order that matches nobody’s reading of the page, including the author’s.
4. Link text that lies. “Click here.” Or worse, an aria-label that contradicts the visible text, so sighted and screen reader users are effectively looking at two different pages.
5. Focus that never moves on navigation. Single-page portals swap the content and leave focus where it was. A screen reader user activates a link, arrives on a new page, and hears nothing.
6. Heading levels used as font sizes. An h4 chosen because it looked about the right size. Screen reader users navigate by headings, so a broken outline wipes out their table of contents.
7. Low-contrast required-field markers. The little red asterisk that marks a required field, at a contrast ratio that fails AA. Low contrast has been the most common detected failure in every WebAIM Million report since 2019, and in 2026 it appeared on 83.9 percent of home pages. It’s one of six categories that account for 96 percent of everything WebAIM detects.
8. Small misses: missing lang attributes, missing logo alt text and duplicate element IDs. They’re cheap to fix, and nobody testing with a mouse will ever see them break assistive technology.

How to test your careers portal for accessibility in 10 minutes

One manual test catches most of the defects above.

1. Unplug your mouse and open your careers page.
2. Apply for one of your own jobs using only the keyboard, all the way to a successful submission. Within ninety seconds you’ll know whether your filters are reachable. By the end you’ll know whether your validation errors are announced, because you’ll get stuck if they aren’t.
3. Run an automated scanner, knowing its limits: one academic study found common checkers covered just one sixth of WCAG success criteria. Treat a clean scan as the minimum.

A word about the accessibility widget in the corner of your page

If your careers site has a little floating accessibility button, I wouldn’t count on it. Per UsableNet’s midyear 2026 reporting, roughly 20 percent of companies sued over digital accessibility this year had a widget or overlay installed. In January 2025, the FTC ordered a major overlay vendor to pay $1 million over claims about what its product delivered. And the European Commission says plainly that overlays aren’t an appropriate solution unless the site itself meets the standard.

Why accessibility regresses

Here’s what nobody selling a remediation project will tell you: accessibility is never finished. You can fix every defect on this list in two weeks. Then somebody edits a template, reintroduces a positive tabindex because the tab order looked wrong on their screen, and ships it. No test goes red, and the portal stays broken until a candidate can’t apply.

That’s the same drift behind the WebAIM numbers going backward as page complexity climbed. The only fix that holds is a check that runs without anyone remembering to run it.

What we did

We audited the public jobs portal and the embeddable job widget against WCAG 2.x Level A and AA. Filters, clear-filters and share controls are now real buttons that keyboard users can reach and screen readers announce correctly. Validation errors appear in a live region that takes focus. Job links read as “Title at Company.” Focus moves to the page heading on every route change, headings form a valid outline, and required-field asterisks meet AA contrast through a themeable class, so a customer’s theme can’t accidentally break it. The lang attributes, logo alt text and a duplicate element ID are fixed.

We removed 61 positive tabindex attributes from one portal. That’s what builds up when nothing is checking.

The part I care about most is what comes next. We wrote automated checks that sweep every page of our portal for these exact defects, and they run continuously against our codebase. A separate guard compiles all thirteen portal templates and caught two real rendering defects during this work.

One surprise: the same work removed about 6 MB of JavaScript and 1.1 MB of CSS from the portal’s privacy page, because we replaced a heavy UI library with native form controls that get keyboard behavior right by default. Accessibility and performance turned out to be the same work.

Where this goes

My prediction is that within about two years, the VPAT question will move from enterprise procurement formality to mid-market RFP staple, because the EAA made accessibility a supply-chain question. Vendors who treat it as a one-off project will answer that question twice and fail the second time.

You don’t need to wait for procurement, though. Unplug your mouse and try to apply for one of your own jobs. If you reach a confirmation screen, you’re in better shape than most. If you don’t, you’ve learned something your analytics were never going to tell you.

We are a software company, not a law firm. This post describes accessibility work we did on our own jobs portal and the standards we worked against. It is not legal advice and it is not an assessment of your obligations. Talk to counsel about ADA, Section 508 or European Accessibility Act exposure specific to your organization.