Accessibility Statement

We are working to conform to the Web Content Accessibility Guidelines (WCAG) 2.1, Level AA. This is the standard most commonly required by accessibility law worldwide, and the one we hold ourselves to across the platform — not just on a handful of showcase pages.

We run a real, automated audit — axe-core, driven through Playwright — against a representative set of the platform's pages: the public landing, sign-up, sign-in and password-reset pages, the public job listings and legal pages, and the signed-in dashboard, jobs, credentials, hiring, appeals, privacy, assessments, creator, skills guide, discovery game and admin pages.

Each page is scanned in three languages: English (left-to-right), Arabic (right-to-left — the direction most likely to expose a bug an English-only audit would miss), and Spanish (a second left-to-right language, to catch anything specific to text length rather than to English content). Signed-in pages are scanned both as an ordinary candidate account and, where relevant, as a platform admin.

The audit script is checked into the codebase at scripts/a11y-audit.mjs and runs with a single command, npm run check:a11y, so it can be re-run before any release rather than trusted to stay accurate over time.

As of the date above, the audit scanned 54 page/language combinations (18 distinct pages × 3 languages) and initially found three real, distinct defects:

All three defects were fixed directly in the source: text and link colours were changed to shades that meet the 4.5:1 contrast ratio WCAG 2.1 AA requires for normal-size text, every affected label was connected to its input, and both dropdown menus were given a real accessible name describing what they control.

The same automated audit was then re-run across all 54 page/language combinations and found zero violations. That result — not just this statement — is what "backed by a real audit" means here.

We want to be direct about the limits of automated testing rather than let a clean scan read as more than it is. Tools like axe-core reliably catch a meaningful slice of accessibility defects — missing labels, insufficient contrast, invalid ARIA, and similar — but by the tool's own documentation, automated checks alone can only ever catch roughly a third to two-fifths of WCAG's success criteria. They cannot judge whether an image's alt text actually describes the image, whether content reads in a sensible order to someone navigating by keyboard or screen reader alone, or whether a keyboard user can ever get trapped in part of the page.

We have not yet completed a dedicated manual pass with a screen reader (such as NVDA or VoiceOver), a full keyboard-only walkthrough of every flow, or testing with people who use assistive technology day to day. Those are real, named gaps in our current process, not ones we are hiding — closing them is separate follow-up work.

The audit script's page list grows as the platform does, and we intend to run it before shipping any change to a page it covers. As of this statement, running it is a manual step, not an automatic gate in continuous integration — this project does not yet have a CI pipeline at all, which is itself a known gap in how we ship changes, not specific to accessibility.

If you use assistive technology and run into something on Talaskill that doesn't work the way it should, we want to know about it. Contact Talaskill1@gmail.com with the page you were on and what happened, and we will treat it as a real bug — the same seriousness we would give to any other defect reported this way.