Accessibility statement
The target is WCAG 2.2 at level AA, on every page. This says what is checked automatically each time the site changes, where it falls short today, and how to tell us about a barrier we have not found.
The target, and where it stands
The standard is the Web Content Accessibility Guidelines, version 2.2, level AA: the level most public bodies and procurement questionnaires ask for.
The site is partially conformant. Most pages and tools are built to meet it and are held to part of it by the checks below; the applications that are a drawing surface are not, for the reasons in known gaps. Nobody independent has assessed it, and it has not been tested end to end by somebody who uses a screen reader every day. If you do, and something stops you, we want to know.
What is checked on every change
Three checks load the real pages in a real browser and measure them. They run with the site's other checks whenever a change is pushed, and the numbers in this table are read from the scripts themselves by the build, so they are the ones actually enforced:
| Check | What it holds the site to | Where |
|---|---|---|
contrast.mjs | Text at least 4.5:1 against the colour actually behind it, and large text (24px, or 18.66px at weight 700) at least 3:1. It measures the computed colours of real elements in a browser, not the values written in the stylesheet. | Every page in the default colourway, light and dark; and the key pages and applications in all 13 colourways, light and dark. |
tap-targets.mjs | Every control a finger can touch is at least 44 by 44 CSS pixels, measured on the screen rather than read from the stylesheet. | Every page, in a browser set up as an iPhone 13. |
named.mjs | Every box you can type into has an accessible name: a label, an aria-label, an aria-labelledby that resolves, or a title. A placeholder does not count. | Every page, at 1280 and 390 pixels wide. |
Alongside them:
- Motion. When your system asks for reduced motion, movement on the site becomes a short fade or nothing, and a check fails any animation that does not come from the shared tokens that make this work.
- The sizes people use. The front door, the suites, the main applications and a sample of tools and guides are opened at phone, tablet and desktop sizes, and fail if a page scrolls sideways or a field is small enough that a phone zooms in on it.
- Colour is a choice. Thirteen colourways, each light and dark, all held to the contrast rule above. One is High contrast: black on white, or white on black, with every edge and field border drawn at 4.5:1 or more and a wider focus ring.
- Comfort and access, in Settings. A larger text size that grows the words and keeps the layout, so a phone still needs no sideways scroll; Atkinson Hyperlegible, a typeface many readers with dyslexia find easier, kept on this site and fetched only when chosen; compact or comfortable spacing; motion on or off whatever the system says; dates day, month or year first and a 24- or 12-hour clock across the Workspace. Each is in place before the page is drawn, and in every tab. Ctrl K reaches most of them from any page.
comfort-test.mjschecks each where it lands. - Read aloud. Alt+Shift+A reads what is selected, on any page, and with the setting on a Read aloud button sits beside a selection. Only voices on your device are used: a browser's online voices would send the words away to be spoken.
- The keyboard alone.
keyboard-test.mjsopens every application and presses Tab through it, and fails on a stop that cannot be seen, shows no focus ring or has no name, on a toolbar Tab never reaches, and on anything that holds the focus with no way out. Where an editor keeps Tab for itself, as a document, a note, a plan or the Photo Editor's picture do, Esc then Tab leaves it; in Sheets, F6, as in Excel. - Paper. Every page prints in dark ink on white, without the site around it, whatever the colourway or mode;
print-test.mjsprints all of them in dark mode to be sure. - A way past the bar. Every page starts with a link that skips to its main content, visible when it has keyboard focus.
What automated checks cannot tell you: whether a page reads in a sensible order, whether a description of a picture is a good one, and whether everything that changes on screen is announced. Those need a person, and are where we most expect to be told something.
Known gaps
- The Photo Editor. The picture is drawn on a canvas, which a screen reader sees as one image. The menus, panels and layer list are ordinary controls, and the menus carry the usual keyboard shortcuts, but painting, selecting and retouching need a pointer, and there is no text alternative for what is on the canvas.
- The Engineering Suite. The 3D view is drawn with WebGL, and sketching a profile or picking a face needs a pointer. The feature tree and the forms that set each feature are ordinary controls; the part itself cannot be read aloud.
- Foundry, the Engineering Suite's 2D drawings. The same: the sheet is a canvas, drawn with a pointer, with its commands and properties in ordinary controls.
- Colourways beyond the default. Every page is measured in the default colourway, light and dark. The other eleven are measured on the key pages and the applications, not on every one of the several hundred tools.
- Language. Every page is in English only.
What the checks themselves reported at their last full run, on 29 September 2026, and is not yet fixed:
- Tap targets. On a phone, the row of application links on the Workspace page and the links to each section at the top of keyboard shortcuts are 20 to 32 pixels tall, and the name box in the Engineering Suite is 36 pixels wide, all under the 44 pixel floor.
- Names. Every box you can type into has one: the check found none without.
Fixed since that run: the small grey notes on the Photo Editor's start screen, under recovered work and the templates, which measured 2.73:1. They are now set in the full text colour, and on 1 October 2026 every piece of text on the start screen, in the Photo Editor's library and in its contact sheet dialog measured at least 4.5:1 in all twelve colourways, light and dark.
Tell us about a barrier
Write to Hello@ObscuraOS.com, or use the support page, which puts the page, your browser and the site's version into the message for you and shows you all of it before anything is sent. It helps to say which page, what you were trying to do, and what you use to do it: a screen reader, a magnifier, voice control or the keyboard alone.
A barrier that stops somebody using a tool is treated as a fault in the tool, not a request for a feature. If you need what a page says in another form, ask, and we will send it.
This statement was written on 28 September 2026 and last revised on 1 October 2026, and is revised when the checks or the gaps change.