Accessibility

Our commitment

Crane— this site and the app — aims to meet the Web Content Accessibility Guidelines (WCAG) 2.2 at level AA. We don't claim it's fully accessible yet. Below is what we've checked, what we haven't, and what we know isn't right.

What's been tested, and passed

Every page of this site, sign-in and sign-up, and every screen of the app — facts, lanes, importing, a new posting, the questions step, the documents and where each line comes from, editing, versions, interview prep, the fact hygiene report, applications and outcomes, “what's working”, and your account. The app's screens were checked filled with fictional data, not a live account.

• axe-core 4.14, against every WCAG 2.0, 2.1 and 2.2 rule at levels A and AA: no violations on any page or screen, both as it loads and after opening its panels, questions, reports and menus.
• Keyboard: on every page and screen, Tab reaches every control, in order, with a visible focus outline that has at least 3:1 contrast against what's around it, and nothing traps focus. Every page has a “Skip to content” link first. Disclosures and accordions say whether they're open.
• Target size (WCAG 2.2, 2.5.8): every control is at least 24 by 24 pixels, apart from links inside sentences, which the rule exempts. Buttons and fields are 44 pixels tall; some small controls inside the app (like “Edit” beside a title) are between 24 and 44.
• Reflow: no page or screen scrolls sideways at 320 pixels wide.
• Motion: with “reduce motion” turned on, no animation or transition runs anywhere — checked on every page and screen, not just assumed from the stylesheet.
• Color contrast: every text color, placeholders included, has at least 4.5:1 contrast against every background it's used on, and the edges of fields and buttons at least 3:1. Disabled buttons are faded on purpose; WCAG doesn't require contrast for controls that can't be used.
• Announcements: status changes are read out without moving focus — progress while something is written, whether lines were flagged, saving, results arriving (the fact hygiene report, “what's working”), and your strongest lane changing as you answer questions. Errors are announced as alerts.
• Names, roles and states, in automated tests on every change: every button and field has a distinct accessible name; blocked buttons stay reachable and say why; flagged lines are marked invalid and described by their flag. On the document view, each line is a button that says how many facts it's based on and opens them.

Not tested yet — needs a person

• A screen-reader pass with VoiceOver and NVDA, end to end: signing up, importing facts, a new posting, answering questions, writing, checking where lines come from, exporting, and recording an outcome. Automated checks can't tell us how that sounds in practice; until a person has done it, we don't claim it works well with a screen reader.
• The same flow by keyboard alone, against a real account. Each screen has been checked by keyboard with fictional data; the whole journey, with real saving and loading between steps, hasn't.
• The app on real phones and tablets, with touch and with mobile screen readers.

Known limitations

• PDF exports aren't tagged: the text is real and selectable, and the file has a title and its language set, but there's no structure — no headings or lists — for a screen reader to move through. Word (.docx) and plain-text exports are the accessible choice for now.
• There's no contact address for reporting problems yet (see below).

Report a problem

A contact address for accessibility problems will be listed here before launch. Until then there's no way to reach us from this page, and we'd rather say so than show an address that doesn't work.