Accessibility.
This page can be more specific than the other two legal drafts, because most of what it says is checkable in the build rather than aspirational. Below: the standard we build to, what is actually implemented, what is honestly still missing, and how to tell us when we have got something wrong.
The standard we build to, and what that word means.
Praxa builds software for health systems, whose staff and patients include people who use screen readers, navigate by keyboard, need larger text, or are sensitive to motion. A tool that cannot be operated by part of the workforce it is meant to help is not finished. The same standard applies to the website that describes it.
The target for this site is WCAG 2.1 Level AA. We treat that as a build requirement rather than a retrofit: accessible markup, contrast and keyboard behaviour are part of the design system itself, which is why the claims in the next section are statements about the stylesheet rather than about intentions.
Target, not a conformance claim
There is an important difference between building to a standard and conforming to it, and companies blur the two constantly. Conformance is something an independent audit establishes. No such audit has been done here, so this page says target and will keep saying it until an audit says otherwise.
Legal obligations
Which accessibility obligations apply to Praxa — under the ADA, under Section 508 where a customer is a federal entity or acquires with federal funds, and under state procurement rules — is a legal question, and some health-system customers will ask for a conformance report as part of security and procurement review.
[PLACEHOLDER — confirm with counsel: applicable legal obligations, whether a VPAT or ACR must be produced, and the correct standard version to cite for each customer type]
Scope of this page
This statement covers the public website at praxaai.ai. The Praxa product — the operator console and the reviewer interfaces that customers use inside their own environments — is assessed separately, and the results of that work belong in the customer's documentation rather than on a marketing page.
[PLACEHOLDER — confirm with counsel and product: how product accessibility is documented for customers, and whether it must be referenced here]
Implemented, and verifiable in the build.
- 01
Semantic markup
Pages are built from real landmarks — a banner, a labelled primary navigation, a single main region and a footer — not from nested generic containers. Each page has one h1 and a heading order that does not skip levels, so a screen reader's heading list is a usable table of contents. Decorative elements, including the background grid rules and every inline icon, are hidden from assistive technology rather than announced as noise.
- 02
Keyboard navigation
Everything interactive on this site is a link or a button, reachable and operable from the keyboard in a logical order. The mobile menu is a real button that reports its expanded state, closes on Escape, and returns focus to the control that opened it. There are no custom widgets, no focus traps, and no interaction that requires a pointer.
- 03
Visible focus indicators
Focus is never removed. Every link and button draws a two-pixel outline offset three pixels from the element, in a colour chosen for contrast against the dark canvas rather than for decoration. The indicator is applied on keyboard focus so that mouse users are not shown a ring they did not ask for, and it is defined once in the shared stylesheet so no component can quietly drop it.
- 04
Contrast verified at 4.5:1
The palette was measured, not eyeballed, and each text colour carries its ratio as a comment in the stylesheet: primary body text at roughly 15.8:1 against the canvas, secondary text at 5.9:1, and the smallest muted labels at 5.3:1 — all above the 4.5:1 minimum. One near-black value is explicitly restricted to non-text use because it measures 2.2:1 and would fail. An earlier secondary grey was replaced for measuring 4.4:1, which is how a system stays honest.
- 05
Reduced-motion support
When your operating system reports a preference for reduced motion, animation and transitions are reduced to effectively nothing, the animated marker in the workflow diagrams is removed entirely, and every element that would otherwise fade in on scroll renders immediately at full opacity. The entrance animation is opt-in behind a script-added class, so a visitor with scripting disabled sees all content immediately as well.
- 06
Skip link
The first focusable element on every page is a skip link that jumps past the announcement bar and navigation to the main content. It is positioned offscreen until focused, then appears in the top-left corner with a visible background — a real control, not a permanently hidden one that keyboard users can never confirm.
Also true of this build
- Touch targets. Interactive controls are at least 44 by 44 pixels. Where a link is visually smaller than that, the target is enlarged with padding or an invisible overlay rather than by changing the design, and the stylesheet documents which approach was used where and why.
- No images. This site ships no photography and no raster graphics. Every diagram and icon is inline vector markup, which means nothing depends on an image loading, nothing carries a missing alt attribute, and everything scales without blurring.
- Works without JavaScript. All content is in the served HTML. Scripting adds the mobile menu toggle and the scroll animation, and its absence hides nothing. The animation code also fails safe: if it throws, the hidden state is removed rather than left in place.
- No horizontal scrolling. Layouts are built mobile-first and verified down to 375 pixels wide with a consistent gutter, so the page does not require two-dimensional scrolling to read a line of text.
- Readable measure. Long-form text on pages like this one is held to roughly 68 characters per line, which keeps line length in the range that is comfortable for readers with low vision and for anyone using screen magnification.
- Print output. The stylesheet forces scroll-revealed content visible when printing, so nothing is silently missing from a printed or PDF copy of a page.
What is still missing.
An accessibility page that lists only achievements is marketing. These are the gaps we know about. If you find one that is not here, section 05 is how to tell us, and it will be added.
- No independent audit. This site has not been assessed by a third-party accessibility auditor, and there is no VPAT or accessibility conformance report to share. Everything on this page is self-reported.
- Assistive-technology testing is incomplete. The site has not been walked end to end with JAWS, NVDA and VoiceOver. Structure and keyboard behaviour were built to be correct, and built-to-be-correct is not the same as tested-and-confirmed. Until that testing is done, this page will not claim conformance.
- Text is sized in pixels. Full-page zoom works correctly to 200 percent and beyond. Text-only resizing, which some browsers offer independently of zoom, has limited effect because type is specified in pixels rather than relative units. Converting the type scale to relative units is a known fix and has not been done.
- Some labels are small. Monospaced eyebrow labels and section numbers render at around 11.5 pixels. They meet contrast requirements at that size, but small text is harder to read regardless of contrast, and a larger floor would be better.
- Forced-colours modes are unverified. The design has not been checked in Windows High Contrast Mode or other forced-colours settings, and the stylesheet contains no rules specifically for them. Hairline borders and low-contrast decorative rules are the most likely casualties.
- The diagram animation has no on-page control. A small marker animates through the workflow diagrams. It stops when the browser reports a reduced-motion preference, but there is no button on the page to stop it for someone whose browser does not report that preference.
- The announcement bar returns on every page. Dismissing the bar at the top of the page lasts only until the next page load, because the site deliberately stores nothing in your browser. The privacy benefit is real; so is the cost of having to move past it repeatedly with a keyboard or screen reader.
- No in-page navigation aids on long documents. The legal pages have a contents list at the top and no persistent way back to it, which makes a long document harder to work through than it needs to be.
- The product is not covered here. Accessibility of the Praxa operator and reviewer interfaces is assessed separately from this website. Nothing on this page should be read as a statement about them.
How this site is checked.
Accessibility here is enforced at the design-system level rather than page by page. The site has one shared stylesheet, which is where focus indicators, contrast tokens, touch-target minimums and the reduced-motion rules live. A page cannot quietly opt out of them, and a regression shows up everywhere at once instead of hiding on one template.
What happens on every change
- New colour values are checked against the canvas before they enter the token set, and the measured ratio is recorded in the stylesheet next to the value.
- Pages are reviewed at 375 and 1440 pixels wide for horizontal overflow and for text that has been pushed below the contrast floor by a background change.
- Keyboard order, focus visibility and the skip link are exercised by hand on changed pages.
- Heading order and landmark structure are reviewed when a page's sections change.
What is not yet in place
Automated accessibility checks are not wired into the build, so nothing fails a deploy today on an accessibility regression. Independent testing, assistive-technology testing and a published conformance report are all still outstanding.
[PLACEHOLDER — confirm with engineering: whether automated accessibility checks are added to the build before launch, and which tool]
[PLACEHOLDER — confirm with counsel: whether an independent audit is scheduled before launch, and whether its results are published]
If something on this site blocks you, tell us.
A report from someone who actually hit the problem is worth more than an audit, and it is the fastest way for us to fix something. You do not need to know the standard, the terminology, or which guideline is involved.
What helps most
- The page you were on, and what you were trying to do.
- What happened instead, in your own words.
- Your browser, operating system, and any assistive technology you were using, including the version if you know it.
- Whether it stopped you completely or just made things harder — both are worth reporting.
Alternative formats
If information on this site is not reachable for you in the form it is published, ask for it another way and we will provide it. That includes the content of these legal pages.
[PLACEHOLDER — confirm with counsel: which alternative formats are offered, and whether a phone or relay contact must be published alongside email]
What we will do
Intent: acknowledge every report, tell you whether we can fix it, and give you either a fix or a timeline. The specific windows are left blank here on purpose — a response-time commitment should be published only once there is a process behind it that can actually meet it.
- Acknowledgement of a report. [PLACEHOLDER — confirm with counsel: acknowledgement window. Intentionally blank in this draft; no commitment has been made.]
- Substantive response with a fix or a timeline. [PLACEHOLDER — confirm with counsel: response window]
- Escalation route if the response is unsatisfactory. [PLACEHOLDER — confirm with counsel]
- Accessibility contact mailbox to publish. [PLACEHOLDER — confirm with counsel: dedicated mailbox, and whether a named owner must be identified]
Reminder
This document is a draft pending legal review and is not in force. The technical description in section 02 is accurate for the build as it stands; the commitments in this section are not yet commitments. WCAG 2.1 Level AA is a target, and this site has not been independently audited.