Careers Website Accessibility Audit Guide 2026: automated results for 60 employers and a 10-point manual test

We ran automated accessibility checks on the home page and one job page of 60 large employers' careers websites, then wrote the manual test script that finds what automation cannot. Use both to find and fix what stops candidates applying.

• Summary
• Why it matters
• Automated data
• 10-point manual test
• Fix list
• Limitations
• FAQ

Executive summary

1. We ran automated accessibility checks (Lighthouse, which uses the axe-core engine) on the home page and one job page of 60 large employers' careers websites on 30 October 2026. The median Lighthouse accessibility score was 96 out of 100, and 50 of 60 sites averaged 90 or higher.
2. A high score hid a lot of failures. Only 9 of 60 sites (15%) had no failing scored check on either page, and 23 of 120 pages (19%) were clean. The median page had 1 failing scored check(s) (checks that count towards the Lighthouse score; the visible-label check, which does not, is reported separately).
3. The most common failures were visible labels that do not match accessible names (53% of sites), text colour contrast (42%), heading order (33%) and touch target size under WCAG 2.2 (32%).
4. Sector differences were small: median scores ran from 92 to 97 across five sector groups, each with 10 to 14 sites.
5. Automated tests cannot judge whether alt text is meaningful, whether a form makes sense with a screen reader, or whether keyboard use is workable. This guide therefore includes a 10-point manual test script and a fix list you can run in an afternoon.

Why careers website accessibility matters

A careers website is where candidates search, read and apply. If a candidate cannot use a keyboard-only journey, read the text, or complete the form with assistive technology, they cannot apply. Accessibility problems are also usability problems for everyone, for example on a phone in sunlight or with one hand free.

WCAG 2.2 became a W3C Recommendation on 12 December 2024. It adds nine success criteria to WCAG 2.1 and removes 4.1.1 Parsing. WCAG 2.2 is designed to be backwards compatible with 2.0 and 2.1, so meeting 2.2 also meets the earlier versions.

What the automated data shows

Most common automated failures

Each bar shows the share of sites with at least one failure of that check on the home or job page. Visible-label mismatches are reported by Lighthouse but do not count towards its score, and target size is a WCAG 2.2 check.

A high score is not the same as no failures

Lighthouse weights failing checks by user impact, so a page with several lower-weight failures can still score above 90. Use the score to compare over time, and use the failures list to fix things.

Sector view

The 10-point manual test script

Allow about 90 minutes. Test the home page, a job search, a job page and the full application, on desktop and on a phone.

1. Keyboard only. Use Tab, Shift+Tab, Enter, Space and Escape through the whole journey. You must be able to reach and operate everything, and never get trapped. (WCAG 2.1.1, 2.1.2)
2. Visible focus. The element with focus must always be visible and not hidden behind sticky headers or cookie banners. (WCAG 2.4.7, 2.4.11)
3. Skip link, headings and landmarks. A skip-to-content link works, headings run in a sensible order, and the page has clear regions. (WCAG 2.4.1, 1.3.1, 2.4.6)
4. Zoom and reflow. Zoom to 200% and then to 400% (or 320 pixels wide). Nothing is lost or overlaps and there is no two-way scrolling. (WCAG 1.4.4, 1.4.10)
5. Colour and contrast. Check text, buttons, links and text over images or video. Normal text needs 4.5:1, large text 3:1, and links must not rely on colour alone. (WCAG 1.4.3, 1.4.1)
6. Images, video and audio. Meaningful images have useful alt text and decorative ones have none. Recruitment videos have captions and a transcript. (WCAG 1.1.1, 1.2.2)
7. Names of links and buttons. Read links and buttons out of context. 'Apply now' repeated twenty times needs more context. The visible label should be part of the accessible name. (WCAG 2.4.4, 2.5.3, 4.1.2)
8. Forms and errors. Every field has a visible label, required fields are marked, errors say what is wrong and how to fix it, and nothing times out without warning. (WCAG 1.3.1, 3.3.1, 3.3.2, 2.2.1)
9. Account, login and repeated entry. Candidates should not have to re-enter information they already gave in the same process, and sign-in should not rely on solving a puzzle or remembering a code with no alternative. (WCAG 3.3.7, 3.3.8)
10. Screen reader and touch targets. Search for a job and start an application using VoiceOver, TalkBack or NVDA. On a phone, check that buttons and links are at least 24 by 24 CSS pixels or have enough spacing. (WCAG 4.1.2, 2.5.8)

Fix list

1. Text contrast: Set a colour palette that meets 4.5:1 for body text and 3:1 for large text and interface controls, and check text on images and video.
2. Touch target size: Make buttons, filters and pagination at least 24 by 24 CSS pixels, or space them so they meet the exception.
3. Heading order: Use one H1 and nest headings in order; do not choose headings for their size.
4. Accessible names: Make the accessible name of a link or button contain its visible text, and add context to repeated 'Apply' links.
5. Alt text and media: Write alt text that says what the image conveys; mark decorative images as decorative; caption videos.
6. Forms: Use real labels, helpful errors, and do not ask for the same information twice.
7. Zoom: Do not disable pinch zoom (maximum-scale and user-scalable) in the viewport tag.
8. Keyboard and focus: Keep focus visible, avoid focus traps in modals and cookie banners, and use native elements before custom ones.
9. ARIA: Use ARIA only where native HTML cannot do the job, and keep roles and attributes valid.
10. Process: Add accessibility to your definition of done, re-test on every template change, and publish an accessibility statement with a way to report problems.

Frequently asked questions

Related reading

Sources

• W3C, Web Content Accessibility Guidelines (WCAG) 2.2, 12 December 2024: w3.org/TR/WCAG22
• EUR-Lex, Accessibility of products and services (summary of Directive (EU) 2019/882): eur-lex.europa.eu/EN/legal-content/summary/accessibility-of-products-and-services.html
• Chrome for Developers, Lighthouse accessibility score (weighting based on axe user impact): developer.chrome.com/docs/lighthouse/accessibility/scoring
• Original data: Happydance Lighthouse 12.8.2 runs on 68 careers websites, 30 October 2026.

Appendix A: all automated checks with a failure