Skip to content

Trust

Accessibility at RealUptime

Our target is WCAG 2.1 AA across every product surface. This page states plainly what conforms today, what does not yet, and how to reach us if something does not work for you.

Effective August 31, 2026

Conformance status

RealUptime partially conforms to WCAG 2.1 Level AA. Partially conforms means some parts of the content do not fully conform to the accessibility standard. It does not mean most of the product is inaccessible. The sections below name what we checked, what holds up, and what still needs work, rather than claiming a blanket pass.

How this audit was done

The August 31, 2026 pass was a manual code and rendered-output review. It covered the public status pages, the free outage pages, and the authenticated dashboard chrome (navigation and forms). We checked those surfaces against WCAG 2.1 AA success criteria: semantic landmarks, heading order, form labels, link and button names, image alternative text, color contrast, keyboard reachability and focus visibility, ARIA on interactive components, reduced motion, and that status is never conveyed by color alone.

The audit was not run through an automated scanner (axe, Lighthouse, or similar). It did not include a live screen-reader or assistive-technology testing session.

Our test suite renders components to static markup rather than a browser DOM (see the comment on renderAsyncToStaticMarkup in app/_test/render-async.tsx for why). That rules out jest-axe or a comparable automated accessibility test without adding a new jsdom-based harness alongside the existing one. We made that tradeoff deliberately for this pass, and it is listed as a known gap below.

What conforms today

  • Public status pages, outage pages, and dashboard chrome use real semantic landmarks (main, nav, header), and every navigation region has an accessible name.
  • Status is never carried by color alone. Every colored status dot, cell, or badge on the public status page and the outage pages ships a text label, or an aria-label, naming the state beside it. A colored shape alone is never enough.
  • The three status colors (operational, degraded, down) clear 4.5:1 contrast against canvas, surface, and their own soft backgrounds in both light and dark mode.
  • Form fields use visible <label> elements, never placeholder text alone, and required fields carry both a visual marker and an accessible “required” announcement.
  • Every interactive element receives a visible focus ring; it is never removed without an equivalent replacement.
  • Every image carries alternative text, and decorative icons are hidden from screen readers.
  • Animation (the brand mark's loading pulse, the “Featured on” marquee) stops under prefers-reduced-motion.
  • The dashboard's dialogs (the command palette, the keyboard-shortcuts overlay) trap and restore keyboard focus correctly, inherited from the underlying Radix UI primitive.

Known gaps

Found in the August 31, 2026 audit. Listed here rather than left to be discovered:

  • Fixed in this pass, noted for the record: the public status page's two hand-rolled dialogs did not move keyboard focus into the dialog on open, trap Tab within it, or restore focus to the triggering button on close (WCAG 2.4.3, Focus Order). The two dialogs are the “Subscribe to updates” method picker and the incident “Copy as image” fallback. Both now behave correctly. The dashboard's own dialogs were already correct because they use a different, Radix-backed implementation.
  • No automated accessibility testing is wired into the toolchain. Biome's lint preset catches a class of static defects on every commit: missing alt text, unlabeled SVGs, and some ARIA misuse. Nothing currently runs axe or an equivalent check against rendered output. Nothing has been verified with a live screen reader.
  • Audit scope was three surfaces, not the whole product. This pass covered public status pages, outage pages, and dashboard chrome (navigation and forms) only. Marketing pages, docs, and the internal staff console (Uplink) were not re-audited here. An earlier design pass (docs/design/ui-audit.md) covers some of that ground. That pass predates this WCAG-specific review and was not written against the WCAG success criteria directly.
  • Custom interactive widgets were spot-checked, not exhaustively swept. The focus-management gap above was found by checking every hand-rolled role="dialog" in the audited surfaces. Other custom widgets (tooltips, expanders, tab pickers) were reviewed individually rather than through a systematic sweep. A similar behavioral gap could exist somewhere this pass did not look.

Feedback and contact

If you use assistive technology and hit a barrier anywhere on RealUptime, including a customer's status page we host, tell us. Email support@realuptime.io with the page URL, what you were trying to do, and the assistive technology or browser you were using. We aim to acknowledge within three business days, the same commitment published on our security page for vulnerability reports.