How to make your recruitment technology inclusive

You make recruitment technology inclusive by making sure every qualified person can find a role, understand it and finish the application, whatever device, ability or circumstance they bring. That means testing the careers site and the application against WCAG with automated tools, manual checks and real assistive technology, fixing what fails, and then checking again after every change.

Inclusion is decided before anyone reads an application

Most conversations about fair hiring start at the shortlist: who gets interviewed, how candidates are scored, whether a panel is balanced. All of that matters, but it comes late. A candidate who cannot use your careers site with a screen reader, or who gives up on an application because the date picker will not work with a keyboard, never reaches the shortlist. Nobody rejected them. The technology did, quietly, and nobody on your team will ever know they were there.

For frontline employers the stakes are higher than they look. Hourly roles in hospitality, retail, leisure and care draw on a wide pool of people, including many with disabilities, many who read English as a second language and many applying on an older phone with a cracked screen between shifts. An application that only works for a confident desktop user on fast broadband excludes a large part of exactly the workforce you need.

There is a legal dimension too. In the UK the Equality Act 2010 places a duty on employers to make reasonable adjustments and not to disadvantage disabled applicants, and that reaches the digital front door as much as the interview room. Public sector employers have further obligations under the Public Sector Bodies (Websites and Mobile Applications) Accessibility Regulations 2018. But treating accessibility as a compliance box misses the point: it is simply part of whether your hiring works.

How to assess what you have

Start with automated testing. Free and commercial checkers will scan your careers site and flag the common, mechanical failures quickly: missing alternative text on images, headings out of order, form fields without labels, colour contrast that is too low to read. They are a good first pass and a poor last one, because the most damaging problems are usually the ones a scanner cannot see.

Then test by hand. Put the mouse away and try to find a job and apply using only the keyboard. Can you see where the focus is at every step? Can you open and close every menu, pick a date and submit? Zoom the page until the text is twice its normal size and check nothing overlaps or disappears. Read the error messages aloud and ask whether a nervous applicant would know what to do next.

Finally, and most usefully, test with people who rely on assistive technology every day: screen reader users, voice control users, people who navigate with a switch. Their feedback is the difference between a site that technically passes and one that people can actually use. If you do nothing else on this list, do this.

Do all three on the application itself, not only on the careers site. The job pages are often fine; it is the moment the candidate clicks apply and lands in an older ATS form that things fall apart.

What to fix first

Work to WCAG 2.1 AA as a minimum. It is the standard our own careers sites are built to, and it covers the failures that exclude the most people. Within that, a practical order of work looks like this.

1. Fix the application before the marketing pages

A beautiful, accessible job page that leads to an inaccessible form achieves nothing. Every field needs a visible label, errors need to be explained in words and not only in red, and the whole thing must work on a small screen with a keyboard or a screen reader.

2. Shorten it

Length is an accessibility issue in its own right. Every extra question is another chance for a screen reader user to lose their place or for someone with a cognitive disability to run out of energy. Conversational apply asks only the questions a role needs, adapting to the job and the region, which helps every candidate and helps some a great deal.

3. Write plainly

Job titles people recognise, requirements that are real rather than aspirational, pay and shift patterns stated up front. Plain language is inclusive language, and it is also what converts.

4. Give candidates control

Some people need higher contrast, larger text or a simpler layout, and they should not have to know how to find those settings in their browser. Our accessibility widget puts contrast, font, screen reader and navigation controls in the candidate’s hands, and it installs on careers sites we did not build as well as ours. To be straightforward about it: a widget helps, but it does not make an inaccessible site compliant. The underlying site still has to be built and audited properly, and anyone who tells you otherwise is selling you a shortcut.

Keep it that way

Accessibility decays. A new campaign page, a changed form question or a third-party script can undo months of work in an afternoon. Make an accessibility check part of publishing, not an annual project. Train the people who write job adverts and build pages, because most regressions come from content rather than code. And offer a clear, human route for anyone who needs an adjustment to apply, with a named inbox or phone number that someone actually answers.

What to do next

Try to apply for one of your own roles this week using only a keyboard, and then again on a phone with the screen reader switched on. You will learn more in twenty minutes than from any report. If you want a second pair of eyes, we are happy to look at your careers site and application with you, and there is more on building hiring that people can trust in our trust in hiring collection. Get in touch whenever suits.