Accessibility Statement
Last updated: 1 August 2026
This is an accessibility statement for AI Job Hunter: the landing site at aijobhunter.app, the desktop app, and the browser extension. It says plainly what standard we're aiming for, how close we actually are today, what's known to be broken, how that was checked, and how to tell us about something we missed.
Commitment #
Publishing this statement isn't legally required for this product — the EU Accessibility Act has a microenterprise exemption (fewer than 10 staff, under €2M turnover) that covers a solo maintainer's free app, and no US statute requires one from a private site. It's here anyway because this is a job-hunting tool, its users include disabled job seekers, and a statement next to /privacy matches how this site already treats disclosure: honestly, or not at all. This is a self-assessment, not a compliance claim or a certification.
Scope #
- Landing site — every public page at
aijobhunter.app, including this one. - Desktop app — AI Job Hunter, the Tauri app for macOS, Windows and Linux (see /download).
- Browser extension — AI Job Hunter — Job Importer for Chrome and Firefox, which injects a small import button and an optional autofill panel into job-board pages (see /privacy for what it does and doesn't send).
Standard #
The target across all three surfaces is WCAG 2.2, level AA.
Conformance status #
Partially conformant with WCAG 2.2 AA. The most recent automated scan found no violations, but zero violations isn't the same as full conformance — see Known barriers below for what's still unaudited or out of scope.
Partially conformant with WCAG 2.2 AA. The home view has no known automated violations after a recent fix round, but that coverage doesn't reach past the home view — see Known barriers below.
Not assessed. It injects a small import button and an autofill panel into third-party job-board pages; we haven't run an automated or manual accessibility scan against it. Treat it as unverified, not as passing.
Known barriers #
A first automated axe-core scan (WCAG 2a/2aa/21a/21aa/22aa rules) on 1 August 2026 found the problems listed below, alongside how each was fixed. A second scan later the same day, after the fixes, found 0 violations across all 9 landing pages and the desktop app's home view. That's not a claim of zero barriers — the rest of this section says what's still scoped out, unaudited, or otherwise open.
Both of those were one-off, manually run passes. Since then, a permanent gate (apps/landing/scripts/check-a11y.mjs) re-runs the same axe-core scan on every landing pull request and blocks the merge on any violation — this one doesn't stop repeating. Its auto-discovery found three routes neither manual pass had ever scanned (/404, /_not-found, /mission-control) and, on its first run, caught one real barrier: see /mission-control below.
0 violations across the 12 routes the permanent gate covers (/, /download, /how-it-works, /privacy, /accessibility, /creature, /world, /architecture-map, /agent-system, /404, /_not-found, /mission-control). One more public page, /benchmarks/, is deliberately excluded from the gate — see the card below, not folded into this "0 violations" figure. Four barriers found across the manual passes and the gate's own first run have since been fixed:
/creature— the four faded doodle annotations were a low-contrast grey on the paper background (2.46–2.8:1); they're now a warmer grey (#6b6459) at 4.98:1./world— the active nav pill's white-on-red text was 3.93:1; the pill background is now darkened withcolor-mix, landing at 8.54:1. Worth noting: the accent colour cycles per section, and the original scan only ever caught the red state. A manual check of the others found the blue state at 1.88:1 — a worse failure the first pass missed entirely — since fixed to 4.86:1. We're leaving this in as an honest example of what a single-state automated scan can miss./architecture-map— the#sidesidebar wasn't reachable by keyboard. It's nowtabindex="0"with a label, and the map's arrow-key pan handler skips it while it has focus, so arrow keys scroll the sidebar instead of panning the map underneath it. Confirmed by hand in a browser: focus lands on the sidebar, and ArrowDown moves its scroll position./mission-control— the row-title links inherited the page's plain accent red at 4.03:1 on the row background; scoped to the same AA-safe token.mc-badge.is-stalealready used on this exact background, landing at 5.7:1. Found and fixed by the permanent gate's first run — this page was never in scope for the two manual passes above.
/benchmarks/ is excluded from the gate, not passing it. It's generated wholesale by a third-party CI action (benchmark-action/github-action-benchmark v1.22.1, run by the benchmark job in .github/workflows/quality.yml) and overwritten on every push-to-main perf run, so a fix committed here would be silently clobbered by the next run — there is no way to fix it in this repository. As of the gate's first scan it carries two violations: color-contrast (the download button, white text on #3298dc, 3.15:1, needs 4.5:1) and html-has-lang (the page's html element has no lang attribute). It's a public page on this domain with real, disclosed barriers, not a clean bill.
0 violations at the WCAG A or AA level, in both the light and dark colour schemes (was 1 critical + 1 serious across 12 elements). What changed:
- The critical aria-allowed-attr was an
aria-expandedattribute on a roleless wrapperdivinside the sharedHoverPopovercomponent. The invalid attribute is now removed from that wrapper everywhere the component is used, not just here — and where the trigger is itself a real button, it moves onto that button instead. Two call sites wrap a non-interactive element, so they lose the attribute rather than relocating it; it was never reachable by assistive technology in those cases either way. - The 11 color-contrast elements now use the existing
text-muted-foregroundtoken (5.1:1 on white, 4.8:1 on#f8f8f8) instead of low-alphatext-foreground/30|40|55.
This fix is scoped to the home view. The renderer has roughly 1,100 text-foreground/NN usages, around 460 of them at the low-alpha steps (/30, /35, /40, /45, /55) that measure below 4.5:1 for small text. Only the home view has ever been scanned; every other view is unaudited and likely carries the same defect. This is the single most important known barrier on this page.
Two best-practice axe rules also remain here — landmark-unique (1 element) and region (5 elements). They're tagged best-practice, not WCAG A or AA, so they sit outside the standard this page targets, but "0 violations" shouldn't be read as a clean bill without mentioning them.
Exported résumé and cover-letter PDFs carry document metadata (title, author, language) but are not fully tagged to PDF/UA-1 — proper tagging (reading order, semantic structure for a screen reader) is a stated future goal, not something shipped today. Don't assume a screen reader gets a clean read of an exported PDF; the underlying content stays available and editable inside the app's own résumé and cover-letter editor, independent of how any one export renders.
What's in place #
- Reduced motion is honoured on every page. 9 landing stylesheets carry their own
prefers-reduced-motion: reduceblock, as do the two scripted experiences (app/world/scrub-engine.jsandcomponents/agent-system/hooks.ts). One more file animates without carrying its own block —how-it-works-shell.css's back-link transition — but it's always loaded on/how-it-worksalongsidehow-it-works.css, whose block covers the whole page. The remaining stylesheets are token and base files with no animation in them. - Visible focus rings. Every interactive element gets a
:focus-visibleoutline, defined independently in each page's own stylesheet — this page reusesprivacy.css, and shares themarketing-base.cssfooter baseline with /privacy and /download; the other pages define theirs separately. Ink-on-paper contrast is documented at ~12.6:1, well above the WCAG non-text-contrast floor of 3:1. - Link colour (
--red,#b02b2a) is documented at 5.25:1 on the page background — AA for 13px text. - Semantic markup — headings and lists, not styled divs pretending to be them.
- The architecture map has real keyboard support — arrow-key panning, zoom, fit, a help overlay with a focus trap, and (fixed 1 August 2026) a keyboard-focusable sidebar that scrolls on its own arrow keys instead of panning the map underneath it.
- A permanent, blocking accessibility gate for the landing site.
apps/landing/scripts/check-a11y.mjsre-runs the same axe-core WCAG A/AA scan on every landing pull request in CI and fails the build on any violation — unlike the three desktop checks below, which stay advisory. It auto-discovers every built route instead of scanning a hand-maintained list, currently covering 12 routes (all clean) plus one page it deliberately excludes with a stated reason (see Known barriers above).
Three checks exist in CI for the desktop app, and all three are advisory, not blocking today: an eslint.a11y.config.mjs jsx-a11y lint pass runs warn-only, kept separate from the strict lint that does block; an axe scan in apps/desktop/e2e/a11y.spec.ts logs findings instead of failing the build; and .lighthouserc.json sets an accessibility floor of 0.9 as a warning. None of the three currently gate a merge.
How this was assessed #
Self-assessed on 1 August 2026, in two passes. First, an automated axe-core scan of the built landing site and the desktop renderer's home view, a scripted keyboard tab-through of every built landing page (a visible focus indicator on every stop it reached and no keyboard trap — it did not reach every focusable element on every page, most likely elements sitting in inactive tab/scene panels on /how-it-works and /creature, but that wasn't confirmed), and a code review of the architecture map's keyboard handling. Then, after fixing what that pass found, a second automated re-scan of the same surfaces — independently re-verified against the fix code rather than taken on trust, and run against the desktop app in both the light and dark colour schemes — plus a manual browser check that the architecture map's sidebar actually receives keyboard focus and scrolls. There has been no third-party audit and no testing with assistive-technology users. We'll say so again if either of those changes.
Feedback #
Hit a barrier? Email [email protected] or open a GitHub issue. We aim to respond within 5 working days. If something on the site or in the app is genuinely blocking you, tell us what it is and we'll get you the content another way.
Review cadence #
We review this statement at least once a year, and whenever the site or app changes materially. If it changes, we'll bump the "Last updated" date at the top of this page and publish the revised version here.