Accessibility Statement

VERA should be usable by everyone who runs a business, including people who use a screen reader, navigate by keyboard, need larger text, or are sensitive to motion. This statement describes what we have done, what we know is incomplete, and how to tell us when we have got it wrong. It is a statement of effort and intent, not a claim of certification.

Version
1.0
Effective
July 28, 2026
Last updated
July 28, 2026
Revisions
1
On this page (5 sections)
  1. 1. Conformance status
  2. 2. What is in place
  3. 3. Known gaps
  4. 4. Reporting a barrier
  5. 5. Ongoing commitment

1. Conformance status

VERA aims to meet the Web Content Accessibility Guidelines 2.1 at Level AA. We have not completed a formal third-party accessibility audit, and we have not published a Voluntary Product Accessibility Template or Accessibility Conformance Report.

We therefore describe VERA as partially conformant: parts of the product meet the standard and parts have not been evaluated against it. We do not claim full conformance, and we will not until an independent evaluation supports it.

2. What is in place

The following accessibility practices are implemented across the product.

  • Semantic structure. Pages are built from semantic HTML with landmark regions and a logical heading hierarchy, so screen reader users can navigate by heading and region rather than reading linearly.
  • Keyboard operability. Interactive elements are real buttons, links, and form controls rather than clickable containers, so they are reachable and operable by keyboard and expose the right role to assistive technology.
  • Labelled interface patterns. Tabbed interfaces, dialogs, and disclosure controls carry explicit ARIA roles and relationships, including tab and tabpanel roles with the association between them, and headings referenced as accessible names for regions.
  • Decorative graphics hidden. Icons that repeat adjacent text are marked as hidden from assistive technology so a screen reader is not made to announce them twice.
  • Color contrast. Text and interface colors are chosen against a defined palette with contrast in mind, and contrast has been a specific concern in recent navigation work.
  • Light and dark themes. The application supports light and dark themes. The choice is applied before first paint, so there is no flash of the wrong theme, which matters for people with light sensitivity or migraine triggers.
  • Responsive and zoomable layouts. Layouts reflow to small screens and to increased browser zoom without horizontal scrolling of the page, and respect device safe areas on mobile.
  • Text that scales. Typography uses relative sizing so browser and operating system text size settings take effect.

3. Known gaps

We would rather list these than let a reader assume the product has been fully evaluated.

  • No independent audit. No third-party evaluation or user testing with assistive technology users has been carried out. Our confidence is based on internal practice, not external verification.
  • Complex interactive surfaces. The infinite canvas workspace in Content Studio, drag-and-drop scheduling in the content calendar, the estimate builder's drag-to-edit interactions, and charts are the hardest surfaces to make fully keyboard and screen reader accessible, and have not been verified against the standard. Where an equivalent list or form-based path exists, it is generally the more accessible route.
  • Motion. The marketing site uses smooth scrolling and reveal-on-scroll animation. These have not been comprehensively audited against a reduced-motion preference.
  • Generated content. Images VERA generates for you do not automatically carry alternative text. If you publish them, write your own alt text. Content you enter is not checked for accessibility, and remains your responsibility when you publish it.
  • Uploaded and third-party content. Documents you upload, and interfaces rendered by third parties such as payment checkout and OAuth consent screens, are outside our control.

4. Reporting a barrier

If any part of VERA is difficult or impossible for you to use, tell us at support@myvera.io with the subject line "Accessibility". Describe what you were trying to do, the page or feature, and the assistive technology, browser, and operating system you use.

We aim to acknowledge within 3 business days and to give a plan or a fix date within 10 business days. Barriers that block a core task are prioritized above other work. If we cannot fix something quickly, we will tell you and offer a workaround where one exists.

5. Ongoing commitment

Accessibility is treated as part of building a feature rather than a later remediation pass. As surfaces are rebuilt, they are brought closer to the standard, and reported barriers are treated as defects rather than as requests.

This statement is reviewed when the product changes materially and at least annually. It was last reviewed on the date at the top of this page.

Change history

Every revision of this document, newest first. Material changes are notified to account holders before they take effect where practicable.

  1. v1.0July 28, 2026

    Initial Accessibility Statement published.

Questions about this document?

Legal and contracts: support@myvera.io. Privacy and data rights: support@myvera.io. Security reports: support@myvera.io.

Related

This document is a carefully drafted policy written against how VERA actually works. It is not legal advice, and it should be reviewed by a licensed attorney in your jurisdiction before you rely on it.