Trust Centre and Accessibility (VPAT): How zigzag Shows Its Work

The Trust Centre and the VPAT exist because "we take security seriously" is not enough. Serious users, accelerators, universities, corporate partners, and procurement teams eventually ask for specifics: who controls the data, what the lawful basis is, how long data is kept, what happens if there is a breach, and whether the product is accessible.

Zigzag splits that answer across a small set of public pages. The Privacy Policy covers what data is collected and your rights. The Trust Centre expands into the operational and compliance detail. The VPAT focuses specifically on accessibility conformance.

That separation is helpful because these are different questions. Privacy is about the rules around personal data. Trust is about the evidence behind those rules. Accessibility is about whether people can actually use the product, including with assistive technology.

The Trust Centre is the place where zigzag shows its working. It names the data controller, the Data Protection Officer, and the contact routes for data protection questions. It explains the lawful bases used for core processing activities such as operating the product, billing, AI generation, service communications, marketing, and security monitoring.

It also covers the parts that matter during due diligence: international transfer safeguards, retention schedules by data category, GDPR rights, cookies and analytics behavior, AI processing, technical security measures, breach notification, compliance documentation, and how to complain.

In other words, the Trust Centre is not just a marketing reassurance page. It is the operational detail page. If you are trying to answer a security questionnaire, understand retention logic, or explain how zigzag handles AI data transfers, this is the page that does the heavy lifting.

VPAT stands for Voluntary Product Accessibility Template. It is a standardized way of documenting how well a digital product conforms to accessibility standards, most commonly the Web Content Accessibility Guidelines, or WCAG.

A lot of founders do not encounter VPATs until they deal with larger institutions. Universities, government bodies, enterprise procurement teams, and accessibility reviewers often ask for one before approving software. They are not asking for a slogan about inclusion. They are asking for a structured conformance report.

Zigzag's VPAT says the product was evaluated against WCAG 2.1 Level AA. That is the standard many organizations expect as a baseline for modern web software.

According to the VPAT page, the assessment was not based on one automated scan. Zigzag used a mix of automated and manual methods: axe-core and Lighthouse audits, keyboard-only navigation testing, screen reader testing with VoiceOver on macOS and NVDA on Windows, color contrast analysis, reflow testing at small widths and zoom, and source-code review for semantics, ARIA, and focus management.

That matters because accessibility failures are rarely all visible from one test method. Automated tools catch some classes of issue well. Manual keyboard and screen reader testing catch many others. A serious accessibility report usually combines both, and that is what zigzag is describing here.

The VPAT also connects those practices to product behavior. For example, it describes skip links, visible focus styles, semantic HTML, labeled form controls, accessible status messages, and reduced-motion support rather than speaking only in abstract principles.

The broad conclusion on the VPAT page is positive: the report states that zigzag supports the relevant WCAG 2.1 Level AA criteria, with only minor limitations noted. That is the kind of language accessibility reviewers expect in a formal conformance report.

Just as important, the report does not pretend the product lives in isolation. It calls out known limitations where third-party services are involved, such as Auth0's hosted login experience and Stripe's hosted checkout. It also notes that some complex exported content can depend partly on the accessibility support of the third-party editor used to view it.

That kind of candor is a good sign. A useful trust or accessibility page is not one that claims perfection everywhere. It is one that makes the boundary between first-party responsibility and third-party dependency clear, and explains the remediation or monitoring plan.

If you are an early-stage founder using zigzag on your own, you may not read these pages every week. But they become very useful the moment someone asks you a diligence question. An accelerator may ask how user data is handled. A university innovation programme may ask for an accessibility statement. A corporate pilot may ask about transfers, retention, or incident response.

These pages also help internal alignment. If you have co-founders, advisors, or legal reviewers asking whether zigzag is appropriate for sensitive startup work, you can point them to public documentation rather than relying on a vague verbal explanation.

And if you are the person inside a programme responsible for approving tools, the existence of a public Trust Centre and VPAT reduces friction. It means the initial answers are already written down.

The easiest way to think about the three pages is this: the Privacy Policy explains the promises, the Trust Centre explains the operating model behind those promises, and the VPAT explains the accessibility evidence.

If your question is about collection, use, consent, deletion, or your individual rights, start with privacy. If your question is about lawful basis, security, transfers, breach handling, or compliance process, move to the Trust Centre. If your question is whether the product can be used effectively by people with disabilities or whether it meets procurement accessibility expectations, read the VPAT.

Together, those pages do something simple but important: they make zigzag easier to evaluate. That is what trust is in practice. Not a promise to trust us, but enough specific information for you to make an informed decision.