Accessibility statement

Capybari is committed to making capybari.com usable by everyone, including people who navigate with a keyboard, use a screen reader, need larger text, prefer reduced motion, or use high-contrast settings.

This statement covers capybari.com, the public website. It does not yet cover the signed-in application at app.capybari.com — see Known limitations.

Our target

We are working to WCAG 2.2 Level AA. We have not commissioned an independent audit, so we describe this as a target we build against and test for, rather than a certification we hold. When that audit happens we will publish the findings here, including the ones we fail.

What we have implemented

Every item below is implemented on this site today and can be verified.

Structure and semantics

• Semantic HTML throughout: one main landmark, labelled nav regions for the primary navigation and footer, real headings in order, real lists, and real table markup with scope on header cells.
• Accordions and the mobile menu are built from native details and summary, so they work with assistive technology and with JavaScript disabled.
• A skip link is the first focusable element on every page and becomes visible when it receives focus.

Keyboard

• Every interactive element is reachable and operable by keyboard.
• The desktop navigation opens on click as well as hover, so it is not a pointer-only affordance.
• Escape closes any open menu and returns focus to the control that opened it.
• aria-expanded is kept accurate on every disclosure control.
• Focus is never trapped, and focus order follows visual order.

Visible focus

• A single focus treatment is used site-wide: a 2px outline in the brand accent with a 3px offset.
• It has been checked against every background colour the site uses, in both themes.
• Focus styling is never removed — only replaced.

Colour and contrast

• Body text meets or exceeds 4.5:1 in both light and dark themes; large text and interface components meet or exceed 3:1.
• The one low-contrast token (--fg-subtle, ~3.1:1) is restricted by rule to decoration and input placeholders, never to body text or labels.
• No information is conveyed by colour alone. Status is always carried by an icon and a word as well as a colour.

Motion

• Every animation on the site is disabled under prefers-reduced-motion: reduce, including scroll reveals, the hero entrance, and the progress indicator in the product mockup.
• Nothing autoplays with sound. Nothing flashes. No animation moves more than 12px.
• With all motion switched off, no content is hidden and no meaning is lost — the reveal effects are additive only, and content is visible by default when JavaScript is unavailable.

Text and zoom

• Type is set in fluid units and reflows to a 320px viewport with no horizontal page scrolling.
• The layout survives 200% browser zoom and 400% text-only zoom.
• Wide content — comparison tables, code samples — scrolls inside its own container rather than forcing the page sideways.
• No text is set in an image.

Forms

• Every field has a real, programmatically associated label. Placeholders are examples, never substitutes for labels.
• Errors are announced through a live region, described in words rather than colour, and identified per field with aria-invalid.
• Required fields are marked in the label; optional fields are marked explicitly rather than left ambiguous.
• Nothing has a time limit.

Images and product visuals

• The product mockups are built from live HTML rather than screenshots. Each carries one considered description of what it shows on the wrapper, and its decorative internals are hidden from the accessibility tree — so a screen reader gets a single coherent sentence instead of forty disconnected fragments.
• Decorative graphics are hidden with aria-hidden.
• Icons are hidden from assistive technology unless an icon is the only content of a control, in which case the control carries a label.

Independence from third parties

The site loads no third-party scripts, fonts, or trackers. Nothing on the page can be broken by a vendor changing their code, and no consent banner interrupts navigation.

Known limitations

We would rather list these than let you discover them.

1. The signed-in application has not been fully audited. This statement covers the marketing site. Accessibility work on app.capybari.com is ongoing, and we are not yet in a position to claim AA for it.
2. No independent audit has been carried out. All testing to date has been internal — keyboard traversal, screen reader spot checks, automated checking, and contrast verification against the token set.
3. The uptime bars on the status page are decorative. Each row's uptime figure is given as text, and the bars carry a summary label, but the per-day detail they show visually is not exposed individually.
4. Some third-party content we link to is outside our control, including community platforms and code hosting.
5. We have not tested with every combination of browser and assistive technology. Testing has concentrated on current versions of Chrome, Firefox and Safari with VoiceOver and NVDA.

Reporting a problem

If any part of this site is difficult or impossible for you to use, please tell us. You do not need to know why it is failing or what the standard says — a description of what you were trying to do is enough.

• Email: accessibility@capybari.com
• Contact form: capybari.com/contact

We commit to:

• acknowledging your report within two working days;
• telling you what we found and what we intend to do within ten working days;
• giving you the information another way in the meantime, if that is what you need.

We will not ask you to prove the problem or to test a fix unless you offer.

If we do not resolve it

If you are not satisfied with our response, you can escalate to the Equality Advisory and Support Service (EASS) in the United Kingdom, or to the equivalent body where you live.

PLACEHOLDER: confirm the correct escalation route and any statutory wording required for the jurisdictions Capybari operates in before launch.

Keeping this honest

This statement is reviewed whenever the design system changes materially, and at least twice a year. If we ship something that regresses accessibility, the fix is treated as a defect rather than an enhancement.