What conforms,
and what does not.
We sell a tool for proving things honestly. An accessibility statement claiming full conformance without saying what was tested would be the wrong document for us to publish. This one names the standard, the method and the gaps.
Conformance status
This website is partially conformant with WCAG 2.2 level AA. That means most of the standard is met. The parts that are not are listed below rather than left out.
We have not commissioned an independent audit. Everything here comes from our own testing, which is a weaker claim than a third-party assessment and is stated as such.
What we have done
- Contrast. Every text and background pairing in the palette is computed against the WCAG formula and meets 4.5:1 for body text in both themes. Muted text was darkened specifically to clear the threshold. It previously sat at 3.4:1 in light mode.
- Keyboard. Every interactive element is reachable and operable by keyboard, with a visible focus ring that does not rely on colour alone. A skip link is the first focusable element on each page.
- Structure. One
h1per page, headings in order with no skipped levels, landmark elements for navigation and main content, and table headers marked withscope. - Zoom and reflow. Layouts use relative units and reflow to 320px without horizontal scrolling. Wide content such as tables, the flow diagram and the tab strip scrolls inside its own container rather than forcing the page sideways.
- Motion.
prefers-reduced-motionis respected; there is no autoplaying or parallax movement anywhere on the site. - Themes. Both light and dark are designed and tested, and the viewer's own choice always wins over the operating system's.
- No dark patterns. No cookie wall, no interstitials, no content that moves or disappears while you are reading it.
How it was tested
Automated checks for heading order, landmark structure, duplicate identifiers, image alternatives, table semantics and computed contrast ratios run across every page. Keyboard navigation and both themes were checked by hand in a Chromium browser.
What we have not done: tested with real screen readers across multiple platforms, tested with voice control, or tested with disabled users. Those are the checks that find what automation misses. We would rather say so than imply coverage we do not have.
Known gaps
- No screen-reader testing. The markup is semantic and should behave, but "should" is not "verified". This is the largest gap, and the one we intend to close first.
- The ledger demonstration on the home page conveys its result through a status line that updates when you press the button. The change is announced in text, but it is not wired to a live region, so a screen reader may not read it automatically.
- Typeface choice. The display face falls back through a chain of system serifs, so exact rendering varies by platform. Legibility holds throughout, but it is not identical everywhere.
- No independent audit. Everything here is self-assessed.
The Evidarch console
This statement covers the marketing website. The product console is a separate application and has had less accessibility attention — its data-dense tables, charts and filter controls have not been audited to the same level.
If you are evaluating Evidarch and console accessibility matters for your procurement, ask us. We will tell you what we know and what we have not checked, rather than send back a completed questionnaire we cannot stand behind.
Tell us we are wrong
If something here is inaccessible, write to [email protected]. Describe what you were trying to do and what got in the way; the assistive technology and browser you were using helps but is not required.
We aim to reply within five working days with a fix, a date, or an honest explanation of why it is hard. Accessibility complaints do not go into a support queue. They go to the people who can change the code.