Accessibility
Profusia aims to meet the Web Content Accessibility Guidelines (WCAG) 2.2 at level AA. It does not meet that standard everywhere yet. This page says what has been done, what does not work yet, and how to tell us about a barrier.
About this page. It describes, in plain words, how Profusia works on the date at its foot. It is a description, not a contract or a warranty. Our Terms of Service and, where it applies, our Data Processing Addendum are still drafts for attorney review; once they are in force, they set out our commitments to customers and govern if anything here conflicts with them. Until then, the only commitments we make to a customer are those in an agreement signed by both of us. When the way we work changes, we update this page promptly and its date moves.
What has been done
Readable grey text, in light and dark
The grey colours used for captions, hints and secondary text were changed on 30 September 2026 — darkened in the light theme and lightened in the dark one — so that each clears 4.5:1 against Profusia's own page backgrounds. Some text on a site's own pages and in Workspace settings still falls short — see below.
The bar and side rail on a site's pages are checked against that site's colours
A site can choose its own palette, so the quiet text in the top bar and the side rail on a site's pages is computed for that palette when the page is served, and held to at least 4.6:1 against every background it appears on. The content of the page keeps the colours its owner chose.
Keyboard
Notifications and Personal settings open with focus inside them, close with Escape and return focus to where you were. The menus that a right-click opens also open from the keyboard (the ⋯ button on a row, or the keyboard's menu key), take focus, move with the arrow keys and close with Escape. In a project, the number keys switch views, J and K walk the cards while a card is open, and the Tree and Abacus views move with the arrow keys.
Phones and small screens
The screens members work in are checked at a 393-pixel phone width before each release: nothing scrolls sideways, the controls a finger needs are at least 44 pixels square, and working panels take the whole screen.
Pictures you can read without seeing them
The drawn views (the Depth map, and a project's Map, Flow, Tree and Abacus) are built from page elements and SVG rather than a bare canvas, so a screen reader and the browser's own find can reach what they show.
Less movement when you ask for it
When your device is set to reduce motion, the slide between modules and the animations on menus and panels are switched off.
What does not work yet
These were checked against the product on 2026-10-09. Each comes off this list when it is fixed.
Changing a card's status needs a mouse
In Projects, the status menu opens from the keyboard but does not take focus, so its choices are out of reach without a mouse or a finger. Until that is fixed, an assistant you have connected can change a status for you (ask it to move the card).
Detail panels do not take keyboard focus
When a document's or a card's detail panel opens, focus stays behind it on the page, and closing the panel does not return focus to where you were.
Some changes are not announced to screen readers
Short confirmations such as a saved change or a new status appear on screen for a few seconds but are not read out. The rows in some lists (Docs, Projects, Live and Workspace settings) also put a button inside another clickable control, which some screen readers announce confusingly, and a few hidden elements on a site's own pages can still take keyboard focus.
Some text is still below the contrast minimum
Our automated check still finds some low-contrast text on a site's own pages and in Workspace settings. The blue that marks the item you are on, on its pale-blue highlight, measures about 4.4:1, just under 4.5:1. A workspace's own accent colour is not checked for contrast when it is chosen.
Choosing files on the upload page
Picking individual files on the upload page needs a mouse or a drag. Its “Choose a folder instead” button works from the keyboard.
What you publish is served as written
Documents and pages that you or your assistant publish are served as they were written. Profusia does not check them for accessibility or rewrite them, so their headings, image descriptions and colours are the author's.
Browsers we have not tested
Our automated checks run in Chromium, the engine behind Chrome and Edge, including at phone width. Profusia has not yet been checked in Safari (on a Mac or an iPhone) or in Firefox.
How this was assessed
This is our own assessment. The screens members work in are run through an automated checker (axe-core, using its WCAG 2.1 A and AA rules) before each release, alongside checks written for this product: contrast computed per site palette, the phone-width rules above, and keyboard checks on the menus and Notifications. The checker stops a release when a new kind of problem appears; the known ones listed above are recorded and can only shrink. No independent accessibility audit has been done, and there is no published Accessibility Conformance Report (VPAT) yet.
The statement describes that assessment as it stood on the date shown; it is not a warranty or a certification of conformance. The accessibility of documents and pages that you or your assistant publish is the publisher’s responsibility.
Telling us about a barrier
If something in Profusia gets in your way, write to support@profusia.ai. We aim to reply within five business days, and where we cannot fix a barrier quickly we will offer reasonable help to get the task done another way — for example by walking you through it, or, if you invite us into your workspace for the purpose, by doing it with you. It helps to know the page, what you were trying to do, and what you were using: the browser, and any screen reader, magnifier or other assistive technology.