Skip to content
suparbase
Accessibility

The shape we're in, in plain English.

Last updated 2026-05-17. We aim for WCAG 2.2 Level AA across every authenticated page and every public marketing page. We're close but not perfect - this page is honest about both.

The standard we target

WCAG 2.2 Level AA across the entire product surface - the marketing site, the sign-in flow, the connections workspace, the data grid, the AI chat, the SQL playground, the admin panel, and the billing pages. The detailed conformance posture against every relevant criterion lives in our VPAT 2.5 Rev, which is the document procurement officers ask for.

What works well today

  • Keyboard navigation reaches every interactive control. We use semantic <button>, <a>, and native form elements throughout - there are no click-only<div>s.
  • Focus is always visible. A 2px accent-coloured ring on:focus-visible follows every interactive element, with explicit ring styling on dialogs, dropdowns, and form controls.
  • Skip-to-content link on every page - tab once from the address bar to jump past the header and nav.
  • Modals, menus, and tooltips are built on Radix UI primitives, which ship with focus traps, escape handling, focus return, and correct ARIA roles by default.
  • Form fields have visible labels, programmatic label association, inline error messages with role="alert",aria-invalid on bad fields, andaria-describedby linking the field to its hint.
  • Autocomplete hints on every email, password, and URL field, so password managers and browsers can fill correctly.
  • Reduced motion is honoured. Page transitions, footer particles, and the landing hero animations all disable when the user has prefers-reduced-motion: reduce set.
  • Dark + light themes with high-contrast text (≈18:1 for primary text in both modes) and explicit prefers-color-scheme fallback.
  • Text resizing to 200% works without horizontal scroll or content cut-off - all sizing uses relative units.
  • Screen-reader announcements for toast notifications and AI chat output, via aria-live regions.
  • Language of page declared on the root <html lang="en">.
  • Accessible authentication: no cognitive function tests (no CAPTCHAs requiring puzzle-solving). Sign-in uses email + password with browser autocomplete, or GitHub OAuth. (WCAG 2.2 - 3.3.8)
  • No drag-only interactions: every action that uses pointer movement (selection, navigation, editing) has a click or keyboard equivalent. (WCAG 2.2 - 2.5.7)
  • Redundant entry avoided: forms don't ask users to re-enter information already supplied earlier in the same flow. (WCAG 2.2 - 3.3.7)
  • Target sizes ≥ 24×24 CSS pixels: every interactive control - including the filter-chip remove, inline-edit confirm / cancel, and password-eye toggle - now clears the minimum hit area. (WCAG 2.2 - 2.5.8)
  • Consistent help: a single /contact form is linked from the footer, every legal page, and every help surface, in the same position. (WCAG 2.2 - 3.2.6)
  • Status messages: skeleton loaders, the “Refreshing schema” spinner, and async form submits expose aria-busy / role="status" so screen readers announce loading without stealing focus. (WCAG 2.2 - 4.1.3)
  • Body-text contrast: every text token - including de-emphasised microcopy - now meets the 4.5:1 ratio against its background in both light and dark themes. (WCAG 2.2 - 1.4.3)
  • Table headers: comparison and pricing tables now ship explicit scope="col" on every column header. (WCAG 2.2 - 2.4.6)

Where we're still partial

These are real gaps we've audited and are tracking. They're listed in the VPAT as "Partially Supports" with the same notes you'll see here.

  • Non-text contrast on resting borders: input field outlines at rest are a hairline (≈1.5–1.7:1) and only meet the 3:1 threshold on focus / hover. Visible enough in practice; below spec on paper. A planned token bump will fix this without breaking the visual hierarchy. (WCAG 2.2 - 1.4.11)
  • Color-contrast verification: ratios above were computed by inspecting our CSS custom properties, not measured with an automated tool like axe-core or Lighthouse. We plan to do a measured run before each release; if you're relying on this for procurement, please run your own audit against the live site.

What doesn't apply

Suparbase doesn't ship any audio, video, captions, audio descriptions, or time-based media. The WCAG criteria covering those are marked "Not Applicable" in our VPAT.

How to report an issue

If you hit an accessibility problem - anything from "this contrast is too low" to "my screen reader can't find the submit button" - please send us a note via our contact form and pick “Support” as the topic. We aim to acknowledge within two business days and ship a fix within ten for anything below WCAG 2.2 AA. Include:

  • The page or flow where you saw the issue (URL is great).
  • The assistive technology you're using (screen reader + version, keyboard-only, etc.).
  • What you expected vs. what happened.

Assistive technologies we've tested with

Code-level review against WCAG 2.2 AA across every major page. Live testing has been spot-check rather than systematic - primarily VoiceOver on macOS with Safari and keyboard-only navigation across all flows. Customers using NVDA, JAWS, TalkBack, or VoiceOver on iOS may notice gaps we haven't caught; please report them.

Conformance status

Substantially conformant with WCAG 2.2 Level AA. The overwhelming majority of criteria are fully supported; two remain partial (see above), and several criteria are “Not Applicable” only in the trivial sense that nothing applies (no media). The VPAT 2.5 has the full criterion- by-criterion breakdown.

Document references

VPAT 2.5 Rev (full conformance report)
WCAG 2.2 specification
Section 508 (US federal accessibility standard)
VPAT 2.5 template (ITI Council)