Accessibility statement
What we target, what we have actually built, what we know is still imperfect, and how to tell us when this site gets in your way.
- Target: WCAG 2.2 Level AA
- Checked on every build
- Reviewed 16 August 2026
The standard we aim at
Our target for this website is WCAG 2.2 Level AA. We treat that as the working minimum rather than a badge: the point is that the site is usable with a keyboard, with a screen reader, at a large text size, on a small screen, and without waiting on anything from a third party.
We have not commissioned a third-party accessibility audit and hold no certification or accreditation. Nothing on this page should be read as one. What follows is what we have implemented and test ourselves.
What has been built
- Semantic structure. Every page uses real landmarks
— a banner, a single
main, a content-info footer — and exactly oneh1, with headings that descend in order and describe the section they open rather than decorating it. - A skip-to-content link. The first thing a keyboard reaches on every page jumps straight past the navigation into the main content.
- Visible focus. Every focusable element takes a clear two-pixel focus ring with an offset, in both themes. We have not removed default focus styling anywhere.
- Keyboard-operable navigation. The mega menu opens
and closes from the keyboard, exposes its state through
aria-expanded, closes on Escape and returns focus to the trigger, and closes when focus leaves it. The mobile drawer is an ordinary disclosure with the same contract. - Text contrast verified against AA thresholds in both the light and the dark theme — not sampled by eye, but computed for every visible text node against its real painted background.
- Touch targets of at least 44 by 44 pixels for buttons and standalone links, so a control is reachable with a thumb rather than a fingertip aimed carefully.
- No horizontal scrolling at 390 pixels wide. The page body never scrolls sideways at phone width; anything genuinely wide, such as a reference table, scrolls inside its own container.
- Reduced-motion support. When your system asks for reduced motion, every reveal animation and transition is disabled outright, not merely shortened. Nothing on this site moves on its own, autoplays, or flashes.
- Content renders fully with JavaScript disabled. Scripts enhance the page — the theme toggle, the menu, the scroll reveals — but the text, the links and the figures are all present in the served HTML. Nothing is hidden behind a script that must run first.
- A self-hosted typeface. The single variable font is served from this origin and preloaded, so text renders without a request to a third party, without a blocking round trip, and without a flash of invisible text.
- Respect for your text size. Type and spacing scale from relative units, so browser zoom and an enlarged default font size reflow the page instead of clipping it.
- Meaningful alternatives. Figures that carry information expose an accessible name describing what they show, and decorative marks — the numerals on a step spine, arrows on links — are hidden from assistive technology so they are not read aloud as noise.
What is checked automatically
Several of the claims above are enforced rather than asserted. An automated gate runs against every build of this site, loads each page in a real browser and fails the build if any of the following is true:
- a page has anything other than exactly one
h1; - any visible text falls below the AA contrast ratio for its size — checked in the light theme and again in the dark theme, at desktop and at 390 pixels wide;
- the page body scrolls horizontally at 390 pixels wide, outside a container that is explicitly allowed to scroll;
- the page produces a console error or a failed request;
- the page renders substantially empty with JavaScript disabled;
- the skip link or the
mainlandmark is missing.
Tap targets under 44 pixels are reported on every run and reviewed before release. An automated gate catches regressions, not every barrier — it cannot judge whether a heading is a useful heading, or whether an alternative text is a useful description. Those we review by hand.
Known limitations
Two things we know are imperfect. We would rather list them than let you discover them.
- Dense diagrams. The technical figures on the feature pages are inline SVG with text alternatives, so they are announced and they scale with zoom rather than blurring. But some of them carry genuinely dense relationships — a fusion pipeline, an entity web, a decision-and-evidence chain — and a short alternative cannot fully replace what the picture shows. Where that is true we have written the same information in prose nearby; if you find a figure whose meaning is not available in text, tell us and we will write it out.
- Wide reference tables. A few tables — the quota comparison, the route map, the storage inventory — have more columns than a phone can show. They scroll horizontally inside their own container rather than shrinking to illegibility or forcing the page sideways. That is a deliberate trade-off, and it still means more work on a small screen than on a large one.
This statement covers this marketing website. The signed-in Memory OS application is a separate surface and is not in scope here; if you need an accessibility assessment of the application for a procurement process, write to us and we will answer honestly about where it stands.
Reporting a barrier
If any part of this site is difficult or impossible for you to use, please write to support@pcnaid.com. It helps if you can tell us the page, what you were trying to do, and what assistive technology, browser and operating system you were using — but a one-line message is entirely welcome, and we would rather have that than nothing.
We aim to acknowledge every report within five business days, tell you what we intend to do, and give you a way to get the same information in the meantime.
Scope and review date
Related: privacy policy · terms of service · cookies and local storage.