//Accessibility

Last updated September 18, 2026

Accessibility Statement

UpliftOS should be usable by people who navigate by keyboard, who use a screen reader, who need larger text or higher contrast, and who cannot rely on color to tell them what a thing means. This document says what we do about that, what we do not yet claim, and how to tell us when we have got it wrong.

1. What We Do Not Claim

We will start here, because it is the part most accessibility statements bury.

We have not had a third-party accessibility audit, and we therefore do not claim conformance with any level of WCAG, Section 508, or EN 301 549. We are not going to assert a conformance level we have not had tested. If your procurement process requires an audited conformance statement, we do not have one today — tell us, because knowing who needs it is how it gets scheduled.

What we have instead is described below, and it is a real program rather than an intention.

2. Accessibility Is Built Into the Components, Not Added to the Pages

Every screen in UpliftOS is built from one shared design system, and the accessibility behavior lives in those components. A page cannot opt out of it by accident, and a developer does not have to remember it.

  • Some accessibility requirements will not compile. An icon-only button without an accessible label is a build error, not a review comment. Several controls require an accessible name before they can be used at all.
  • Interactive components implement the documented keyboard patterns rather than approximations of them. Which pattern each control follows is written down per component — a single-select row behaves as a radio group where arrow keys move the selection, and a multi-select row behaves as a group of toggle buttons where arrow keys move focus only, because arrowing across a multi-select group that moved the selection would toggle every option it passed.
  • Keyboard access is specified, not incidental. Arrow, Home, End, Space and Enter behavior is defined per component, including for things that are easy to leave out — resizable panel dividers are focusable and nudge with arrow keys.
  • Status is never communicated by color alone. Where a component shows a state, it carries a shape or a mark as well as a color, so it survives grayscale and forced-colors mode.
  • Hand-rolling a control is against our own standard. A clickable element with no keyboard path is a defect in our design system, not a page's private choice.

3. Every Page Is Scored, Continuously

We run automated accessibility checks against our cataloged screens, and accessibility is weighted more heavily than any other category in the score.

The checks look for missing accessible labels, missing visible focus indicators, keyboard traps, images without alternative text, clickable elements with no keyboard path, form inputs with no label, and insufficient color contrast. A page that fails them shows up as a defect to fix rather than as a note nobody reads.

What automated checking cannot do, and we will not imply otherwise: it does not tell us whether a screen reader user can actually complete a task, whether our wording makes sense out of visual context, or whether a complex interaction is comprehensible. Those need people, and they are the gap between what we do today and an audited conformance claim.

4. Known Limitations

Being specific is more useful than a general apology:

  • No audited conformance level, per Section 1.
  • Automated coverage is not complete coverage. Checks run against our cataloged screens; a screen not yet in the catalog is not being scored.
  • Complex, information-dense surfaces are the hardest cases. Our builder and operations consoles carry a lot of simultaneous state. They meet the component contracts; whether they are genuinely usable by screen reader for a long task is not something we have established.
  • Applications built by our customers are their own. Where an organization builds an application on UpliftOS, that application's accessibility is theirs. Our components give them a good starting point and cannot guarantee the result — what they build on top is their responsibility, and their obligations are theirs.
  • Third-party components we embed carry their own accessibility behavior, which we do not control.

5. Tell Us

If something is not usable for you, we want to know, and you do not need to identify a standard or a success criterion.

Email [email protected] and say what you were trying to do, what stopped you, and — if you can — what you are using to browse. A person will reply. We treat an accessibility barrier as a defect, and one that blocks someone from completing a task is not a low priority.

If you need something urgently and a barrier is in your way, say so and we will find another route for you while we fix it. That is not an alternative to fixing it.

6. Assistive Technology and Browsers

We aim to work with current versions of the major screen readers and browsers, and we test with keyboard navigation and with the browser's own zoom and text-size settings. We have not certified specific combinations, so if your particular setup does not work we would rather hear about it than have you assume it is expected.

7. Changes to This Statement

We will update this statement as the program changes, and particularly if we obtain an audited conformance claim — at which point this document will say so, and say who performed the audit and when.

Questions or barriers: [email protected].

8. Related Documents