Change log

Accessibility at Quorum Plus

Last reviewed: [date]. Current as of Quorum Plus v[version].

Our commitment

We build Quorum Plus so every teammate, founder, and contributor can use it. That means designing for people who use screen readers, keyboard-only navigation, voice control, screen magnification, captions, high-contrast modes, or any combination.

We work to the Web Content Accessibility Guidelines (WCAG) 2.2, Level AA. Some areas of the product target Level AAA where the cost is reasonable. Where we don't yet meet the standard, we say so on this page.

What we've built in from the start

Accessibility isn't a feature we bolted on. It's baked into how we write stories, design screens, and ship code:

• Every shipped story includes a specific accessibility acceptance criterion. One cross-cutting rule across the build: nothing ships without at least one a11y check tied to what changed.
• Plain-language copy. We write for a grade 9 reading level or below across the product. Technical terms appear where they need to; jargon doesn't.
• Keyboard-first interaction. Every control reachable by mouse is reachable by keyboard. Focus indicators are always visible. Tab order matches visual order.
• Screen reader support. Semantic HTML throughout. Meaningful labels on every interactive element. ARIA attributes where native HTML falls short.
• Color contrast. Text meets WCAG 2.2 AA contrast ratios (4.5:1 for body text, 3:1 for large text and essential UI). We don't rely on color alone to convey meaning.
• Motion respect. We honor prefers-reduced-motion. Transitions and animations have reduced-motion alternatives.
• Form clarity. Fields have visible labels, inline validation, and error messages that say what broke and how to fix it. Not "invalid input."
• Alt text on every meaningful image. Decorative images are marked as decorative so screen readers skip them.
• Content structure. Headings are used in order. Lists use list markup. Tables include row and column headers.

Scope

This statement covers quorum.app and the Quorum Plus web application at app.quorum.app (or wherever your workspace lives). It does not cover:

• Third-party services we use inside the product. Stripe (payment), Supabase (auth and data), and similar providers run inside their own iframes or services. Their accessibility is tracked by their own statements. We've chosen providers with strong accessibility track records and will switch if that changes.
• External links. When we link to partner documentation, public research, or integrated tools (Figma, for example), those properties have their own accessibility posture.
• AI-generated content inside your workspace. The structure we render around AI output (headings, navigation, alt text for generated diagrams) is accessible. The content generated by the agents is shaped by the prompts you and your team write and may need review for your own accessibility needs.

Known limitations

We're a small team. We ship fast, and we audit as we go. These are areas we know need more work:

• Screen reader coverage of the agent transcript. The conversational pipeline transcript includes dense nested content and dynamic updates. We've tested with NVDA and VoiceOver on macOS and iOS; we're still improving the experience on JAWS and on Android TalkBack.
• Keyboard shortcuts. We have a first-pass shortcut map. Documented shortcuts are in the product settings. A full shortcut inventory and conflict audit with common assistive-tech shortcuts is in progress.
• Complex visualizations. The three-pillar filter board, journey maps, and sprint boards render information in two dimensions. They're keyboard navigable and screen-reader labeled. The experience is best described as "usable, not yet excellent." We have a structured pass planned that converts every board view into a linear alternative reachable by keyboard shortcut.
• Automated captioning of screen recordings. Any user-generated screen recording attached to a story lives inside Quorum Plus without auto-captions yet. We recommend authors add their own captions or transcripts for now. Auto-captioning is planned.

If you hit a barrier we haven't listed here, tell us (see below). Your report changes the priority order.

Third-party service posture

The services that run inside Quorum Plus and their accessibility statements:

• Stripe (payment, billing): stripe.com/accessibility
• Supabase (authentication, data): supabase.com — accessibility policy listed in their public documentation.
• Google Sign-In (OAuth): Google's accessibility commitments cover this flow.
• Apple Sign-In (OAuth): Apple's accessibility guidelines cover this flow.

We review these providers annually as part of our own audit cycle. If a provider's accessibility regresses, we evaluate alternatives and switch when the cost-benefit lines up.

VPAT

We maintain a Voluntary Product Accessibility Template (VPAT) that documents our conformance against WCAG 2.2 Level AA in detail. Enterprise customers can request the current version by emailing accessibility@quorum.app. The VPAT is refreshed whenever a major release lands.

Audit cadence

• Every story ships with an accessibility acceptance criterion verified in code review.
• Every release runs an automated axe-core scan across the pages that changed. Scan failures block the release.
• Every major release includes a manual screen-reader pass using NVDA (Windows), VoiceOver (macOS), and VoiceOver (iOS).
• Every year we commission a third-party audit against WCAG 2.2 AA. Findings become work in the sprint board within 30 days of the audit.

Tell us

If something in Quorum Plus isn't working for you, please reach out:

• Email: accessibility@quorum.app
• In-product: Any page has a "Report an accessibility issue" link in the footer. That form goes straight to the team.
• Response time: We acknowledge every report within two business days and commit to a fix timeline within five business days.

We read every report. Reports shape what we build next.

Legal notice

This statement reflects our best understanding of our current accessibility posture. It's not a guarantee of perfect conformance in every edge case. When we fall short, we say so (see "Known limitations" above). When you tell us we've fallen short and we didn't know, we add that to the list, prioritize, and fix.

If you believe Quorum Plus falls short of the standards described here and you haven't been able to get help through the channels above, you can contact accessibility@quorum.app directly.

Version log (for internal reference; not published on the live page)

Implementation notes (for internal reference; not published)

• The [date], [version], and email-address placeholders need filling in before publish. accessibility@quorum.app is the proposed address and matches the pattern of product email conventions; James to confirm.
• "Report an accessibility issue" footer link referenced in the Tell Us section is a new feature commitment. That link needs to be built and wired to a form (or mailto) before this statement goes live.
• VPAT reference assumes the VPAT is actually produced. Per NFR-A6 that's committed but not yet drafted. Block publish on VPAT v0.1 existing.
• Audit cadence claims ("every story," "every release," "every year") are commitments. Publishing them publicly locks us to delivering them. Confirm we have the automation (axe-core CI) and process (annual third-party audit) in place or in the plan before publish.
• "Grade 9 reading level" — this statement itself should be checked against Flesch-Kincaid. I've aimed for it in drafting; a pre-publish pass with a readability tool would confirm.
• If we decide to add a public shortcut list or a dedicated "keyboard shortcuts" help page, link it from the Known Limitations section where we mention shortcuts.