Accessibility Statement

Version 1.1 · 8 November 2026 · covers this website and the application at /app/

We aim for WCAG 2.2 level AA. On 8 November 2026 an automated audit of three public pages returned the highest score the tool can give, and this page reports it as exactly that: one automated result, not a claim of conformance. No screen-reader or keyboard session has been run by a person yet, so the known-barriers list is still the part to read carefully.

The automated audit, and what it measured

Run on 8 November 2026 with Lighthouse 13.6.0 against the live site, in its mobile profile — a simulated mid-range phone on a throttled 4G connection — on the three pages that carry the sales argument. The method and the full numbers are recorded in the project's status log, not summarised from memory.

Largest Contentful Paint was 0.88–0.91 s on all three pages, and the pages do not shift as they load (cumulative layout shift 0). The application at /app/ was not part of this audit — the three public pages were — so nothing here should be read as a measurement of the signed-in application.

The accessibility score is the weighted sum of automated checks, and a check that does not apply to a page proves nothing. These ran and passed:

• Colour contrast of every rendered text/background pair, at the sizes actually used — not only the design tokens listed below.
• Accessible names for links and buttons, and a valid lang on the document and on every element that carries one.
• Heading order with no level skipped, one main landmark, a focusable skip link, and a document title.
• ARIA used as specified: no invalid or misspelled attributes, none prohibited for the role, and nothing hidden from assistive technology that contains something focusable.
• Touch targets of sufficient size and spacing at the mobile viewport.
• Zoom not blocked — no user-scalable=no and no maximum-scale, so a reader can pinch to enlarge.
• List and table structure matching what the markup claims.

Ten further checks in the same audit are marked manual: the tool does not score them, because they need a person driving the browser. They are keyboard focusability of every control, logical tab order, visual order matching the DOM, focus traps, focus handling after content changes, landmark navigation, and offscreen content. Those are the next thing to do, and they sit in the barrier list below — not in this list of passes.

Contrast, measured by hand

The automated check covers the pairs that appear on those three pages. Every text/background pair in the design system was also measured directly against the WCAG formula:

The page field is not a flat colour: it carries a very low-opacity gradient and a fine grain over the base. At its warmest point, secondary text still measures 6.86:1 — above AA, just under AAA — and body text stays above 14:1 everywhere on the page.

What the markup does, beyond the audit

These are properties of how the pages are written. They are not scored by the audit, and none of them replaces the manual pass described above.

• Keyboard. Both the site and the application use native links, buttons, inputs, selects and tables — there are no custom widgets to trap focus. Content pages open with a skip link (the short sign-in and setup screens have none, because there is nothing to skip past), and focus is shown with a visible outline rather than removed.
• Motion. Animations are switched off when the operating system asks for reduced motion.
• Structure. One h1 per page, sections in heading order, tables with column headers, and a lang attribute that follows the interface language (English or Romanian).
• Announcements. Success and error messages carry role="status" and role="alert"; the current page in navigation and the selected language carry aria-current.
• Forms. Every field has a label bound to it, and required fields are marked in the markup rather than only in colour.
• Colour is never the only signal. Status badges carry text as well as colour.

Known barriers

These are real, and we would rather list them than have you find them.

• No screen-reader test, no manual keyboard pass. The automated audit is green, but it cannot say whether a control is reachable with Tab or whether a reader announces a heading usefully. Both need a person with a browser and assistive technology, and neither has happened yet. Until it does, treat “works with a screen reader” as unconfirmed.
• Error messages after a form submission. They are marked as alerts, but they arrive with a reloaded page, and some screen readers do not announce an alert that was already present when the page loaded. Keyboard focus is not moved to the message. If you submit a form and are not sure whether it worked, the message appears above the form.
• The client guide is a PDF that is not tagged. It has no structure tree or language metadata, so a screen reader cannot navigate it properly. Ask us and we will send the same content as text or in another format.
• Wide data tables on a phone. The application’s tables scroll horizontally at narrow widths instead of reflowing; the data is reachable, but it requires sideways scrolling.
• Dark interface only. There is no light theme. Contrast is high, but we recognise that some readers prefer a light background.
• No accessibility regression tests. The audit was run once, by hand, and nothing catches a new contrast or labelling mistake automatically yet.

Reporting a barrier

Write to andrei@metricahq.com with “Metrica accessibility” in the subject line. Tell us the page, what you were trying to do, and what happened — a screenshot or the browser you use helps.

You will get a reply that says what we found and what we intend to do. If we cannot fix it quickly, we will offer another way to get the information or the task done in the meantime.

How this statement is kept true

It describes the system as it is on the date above, and it changes when the system does. The automated result above is a measurement with a date on it, not a permanent grade: it is re-run after a change to the design system or the navigation, and the numbers here are replaced rather than left to age. When the manual pass lands — keyboard and screen reader — the barrier list shrinks and the ten unscored checks become results. Anything that stops being true comes off this page.