accessibility

this statement covers www.getcrosscode.dev: the landing page, the docs, and the sign-in, join, and device pages. it does not cover the crosscode cli, the daemon, or the mcp server, which are terminal programs and inherit whatever your terminal and screen reader already do.

the standard we aim at

wcag 2.2, level aa. that is what we test against and what we fix to.

where we actually are

partially conformant. every page passes the automated checks described below, and the checks we could run by hand pass too. we have not run this site with a screen reader end to end, so we cannot claim full conformance, and we are not going to claim it.

what we have verified, on the landing page, all twelve docs pages, and the sign-in, sign-up, join, and device pages, in the case of the last four, in every state they can render, including their error states:

• no axe-core violations at wcag 2.2 aa, plus axe's best-practice rules, in a real browser and in the test suite.
• every page on the site, including the password-reset and cli-login pages, has a skip link that points at its <main>. every page scanned has one <h1> and heading levels that do not skip.
• all text meets 4.5:1 contrast (3:1 for large text) against the background actually composited behind it. interactive control borders (input boxes, button outlines) meet 3:1.
• no horizontal scrolling at a 320px-wide viewport, or at 200% zoom.
• every clickable target is at least 24×24px, except links sitting inside a sentence, which wcag exempts.
• tab order follows the document order. there are no positive tabindex values and no focus traps. focus is drawn as a 2px white outline, which is 21:1 against the page.
• form fields have real labels. sign-in and password-reset errors are announced through a live region rather than being written into a hidden element, and the fields are marked aria-invalid when a submission fails. errors are conveyed in words, not by colour.
• the animated diagram on the landing page has a pause button and stops entirely under prefers-reduced-motion.

known limitations

these are real, and we would rather list them than let you find them.

1. no screen reader pass. we checked the accessibility tree the browser exposes to assistive technology, which is what a screen reader reads from, but we have not driven the site with voiceover, nvda, or jaws from start to finish. something can be correct in the tree and still be awkward to hear.
2. no pass by a disabled user, and no third-party audit. everything below was done by the person who wrote the site.
3. one theme. the site is dark only. there is no light theme, and we have not tested windows high contrast / forced-colors mode at all.
4. code blocks have no name. wide code samples scroll sideways and are keyboard focusable so you can scroll them with the arrow keys, but they announce as an unnamed region rather than "code sample, bash".
5. the sign-in journey was tested as markup, not as a journey. github sign-in cannot complete yet (see the limitations page), so the signed-in, terminal-bound, and invite-accepted screens were audited as the markup those states render, not by walking through them for real.
6. automated testing finds a minority of problems. axe-core detects perhaps a third to a half of wcag failures. zero violations means zero violations of the rules it can check, not zero problems.
7. two pages were only checked structurally. /auth/reset.html and /auth/cli.html build themselves from scripts that need live credentials to run at all, so they were checked for skip link, language, and title, and their form markup matches the sign-in form that was scanned, but they have not been through axe-core as rendered.
8. we do not target level aaa, and there is no plan to.

tell us about a barrier

email support@getcrosscode.dev. say what page you were on, what you were trying to do, and what you use: the browser, the screen reader, the magnification, whatever is relevant. a description of what went wrong is enough; you do not need to know which wcag criterion it was.

what happens then:

• we acknowledge within 5 working days.
• if the barrier stops you installing crosscode or signing in, we aim to fix it or give you a working alternative within 30 days, and tell you if that is going to slip.
• anything else goes on the list. we will tell you whether it is queued or declined, and why, rather than leaving you without an answer.

crosscode is a one-person project. that is not an excuse for a barrier, but it is the reason the promise above is 5 days and 30 days rather than something faster.

how this was assessed

• last assessed: 6 august 2026.
• assessed by: {{PROVIDER_NAME}}, self-assessment.
• automated tool: axe-core 4.13, run at tags wcag2a, wcag2aa, wcag21a, wcag21aa, wcag22aa and best-practice. run two ways: in a real chromium browser against every built page, and in the repository's test suite (apps/docs-site/src/a11y.test.ts) against every page and every state the sign-in, join, and device pages can render. the suite runs on every pnpm test, so a regression fails the build rather than waiting for the next audit.
• manual checks: contrast computed from the browser's own resolved colours against the composited background, for every text node on every page; reflow at a 320px viewport and at 200% zoom; target sizes measured from live layout; tab order and focus styling read from the dom and the stylesheet; the accessibility tree inspected on the sign-in, join, and device pages.
• not done: screen reader testing, forced-colors testing, and any testing with assistive technology other than the browser's own accessibility tree.

the next assessment is due whenever the site's markup changes materially, and the regression suite runs in the meantime.

before this takes effect

fill these in:

• {{PROVIDER_NAME}}: the legal name of the individual who publishes crosscode, used above under "assessed by".

view raw markdown · generated from docs/accessibility.md at build time, do not hand-edit this page.