Applying for a job is a complete process, and WCAG's rule about processes is absolute. Where a page is one of a series presenting a process, every page in that series has to conform for any page in it to conform. Your careers page and your applicant tracking system are in the same series whether or not they are on the same domain.
Which means an evaluation that stops at the Apply button has evaluated the easy half. The listing is a content page with a search on it, and content pages are where accessibility work usually lands first, so it is often in decent shape. The application is a multi-step form with an upload, a parser, conditional questions and a submission, run by a vendor, and it is where somebody actually gets stuck.
Where the Handoff Happens, and Why It Matters
The transition takes one of a few shapes and each changes the test plan, so establish which one you have before anything else.
- A link to a vendor subdomain, which is the common case. Different template, different components, different focus behaviour, and a reader who has just arrived somewhere that looks like it should be your site.
- An iframe inside your page, where the application form is embedded. Your page, your conformance claim, somebody else's markup, and everything on our third-party scripts page applies.
- A hosted careers site, where even the listing belongs to the vendor and your own site only links to it.
- An email application, which sounds like a dodge and is sometimes the most accessible route anybody offers.
Record the shape, because it decides who fixes what. A finding on a vendor subdomain is a finding you escalate rather than fix, and a report that mixes it into your team's backlog produces a list nobody can deliver.
The Application Journey, Step by Step
This is the artifact. Eleven steps, and the middle column is the one to settle first, because it is what makes the engagement possible.
| Step | What the tester needs | What tends to go wrong |
|---|---|---|
| Search and filter listings | Nothing | Result counts never announced, filters that lose the reader's place |
| Read a listing | Nothing | Job descriptions pasted in with broken heading structure |
| Follow the Apply route | Nothing | Focus does not move, or the new context is never announced |
| Create or sign in to an account | A test account, or permission to create one | Signup is outside the authentication criterion, and everything else still applies |
| Upload a resume | A test file | The custom wrapper around the file input, and progress nobody hears |
| Review what the parser extracted | A resume with awkward formatting | The most underrated screen in the journey, covered below |
| Answer conditional questions | Knowledge of which answers branch | Revealed fields that are never announced, and a changing number of steps |
| Answer demographic questions | Nothing | Usually a separate section with its own components and its own bugs |
| Review before submitting | Nothing | Whether the review screen is reachable and whether values can be corrected there |
| Submit | An approved test vacancy | Whether the confirmation is announced or only rendered |
| Check application status | A submitted test application | A portal nobody has ever audited, because nobody gets that far in a test |
The Parsed Resume Screen Is a Form, Not a Convenience
The step everyone skips is the one where the system shows you what it read out of your CV and asks you to check it. It looks like a nicety. It is a form full of pre-filled values that were generated by software, presented for correction, and it fails in ways ordinary forms do not.
The values arrive wrong in interesting ways. Dates parsed into the wrong fields. A job title split across two entries. An employer name in the role field. A reader who cannot see the layout has to work out which of thirty pre-filled inputs are wrong, which means each one needs a real label and a sensible order, and the correction has to be possible in place rather than by starting again.
And when the parse goes badly, applicants retype their entire work history. That is where Redundant Entry becomes relevant, because its scope term is process rather than session and W3C says a process can cross domains. A value the applicant already supplied should be auto-populated or available to select, and browser autofill does not count, because the obligation sits on the content rather than the user agent.
One Precise Fact About the Account Step
Applicant portals almost always make people create an account, and the authentication rule has a boundary here that changes what gets reported.
Accessible Authentication covers authenticating existing users. Account creation is outside it. So a signup step that asks you to solve a puzzle is not a failure of that criterion, while the same puzzle on the sign-in screen next week is. Account recovery is inside the criterion too, which matters because applicants come back to check a status months later having forgotten everything.
None of which makes signup unregulated. Labels, error identification, input purposes and the rest all apply, and our sign-in worksheet covers the states worth reaching on the authentication side.
Sampling a Journey Rather Than a Set of Pages
Conditional questions make an application form a branching structure, and no evaluation walks every combination. WCAG-EM gives the practical instruction. Where a sampled page sits inside a process, include the process's starting point, record at least the default sequence through to completion, and record the branch sequences that are commonly accessed and critical to completing it.
Default sequence plus critical branches. Not every branch, which is the promise nobody can keep, and not one happy path, which is the promise too many reports quietly make. Write down which branches were followed and the report can be reproduced.
It is worth remembering what WCAG-EM says about itself here. It is a Group Note published in July 2026, not a normative requirement, and it records that most evaluations using it are sampled and therefore do not produce a WCAG conformance claim at all. They produce findings, which is what a hiring team needs anyway.
Testing Without Applying for a Real Job
This is the part that has to be agreed before anything starts, and it is not difficult, it is just always forgotten until the day.
- An approved test vacancy, ideally unlisted, so submissions do not reach a hiring manager and do not enter a real pipeline.
- Synthetic applicant data. Made-up names, a mailbox the team controls, a fabricated work history. Nobody's real employment record goes into a test.
- Test resume files in the formats you accept, including one deliberately awkward enough to make the parser struggle.
- A cleanup agreement, so test applications are removed afterwards and nobody finds them in a report next quarter.
- A named contact at the vendor, because half the findings will be theirs and an escalation route agreed in advance saves weeks.
Never send a genuine application as a test. It wastes a recruiter's time, it pollutes your data, and it makes the evaluation something your hiring team resents rather than something they asked for.
One honest limit
We audit and never repair, so this is not an offer to change your applicant tracking system, and much of what a report like this finds belongs to your vendor rather than to you. It is also a technical evaluation and not employment-law advice, so nothing in it says anything about hiring discrimination or your obligations as an employer. Scope it at contact or read what the careers and applications audit covers.