Accessibility.

We aim to meet WCAG 2.2 Level AA across the Holy platform — the administrative application, each church’s public website, the member portal and our mobile apps. WCAG 2.2 AA is also the technical standard behind EN 301 549, which the European Accessibility Act applies to services offered to consumers in the EU.

We moved our target from WCAG 2.1 AA to 2.2 AA in August 2026, and we are honest below about where we are still working.

• ·Accessibility rules are enforced by our linter on every change — a component that ships an inaccessible pattern fails the build, not a review.
• ·Automated accessibility checks (axe-core) run against our shared interface components in the ordinary test suite, and the deploy is blocked if they fail.
• ·The sign-in and sign-up pages are scanned against WCAG 2.2 AA on every pull request in continuous integration.
• ·We use accessible component primitives (Radix UI) so keyboard behaviour, focus management and ARIA semantics come from a maintained library rather than being hand-rolled per screen.
• ·Interface text, forms and errors are built for screen readers: labels are programmatically associated with their fields, and validation messages are announced rather than only shown in colour.

We would rather tell you what is not done than imply everything is:

• ·Automated scanning in continuous integration currently covers the sign-in and sign-up pages, and the shared interface components every screen is built from. Other screens are not yet scanned automatically on every change.
• ·Automated tools catch roughly a third of accessibility issues. Several WCAG 2.2 criteria — including drag alternatives, help placement and not re-asking for information you already gave us — need human review. A recorded manual keyboard and screen-reader audit has not been completed yet.
• ·Our Accessibility Conformance Report (VPAT 2.5 format) is published at /accessibility/acr. It is a draft grounded in automated evidence: rows a human audit has not yet covered are marked as such rather than claimed.
• ·We have not completed an independent third-party accessibility audit.
• ·Churches control much of what appears on their own public site — including images, colours and written content. We provide accessible defaults and the ability to add descriptive text to images, but a church’s own choices affect the result.

If any part of Holy is difficult or impossible for you to use, please tell us — we treat it as a defect, not a feature request. Email support@holyplatform.com with the page or screen, what you were trying to do, and the assistive technology you use if that is relevant.

• ·We aim to acknowledge accessibility reports within 3 business days.
• ·We will tell you what we found and when we expect to fix it, rather than closing the report silently.
• ·If something blocks you today, tell us and we will look for a way to get you unstuck while the fix is built.
• ·Our conformance report is at /accessibility/acr; we can supply it in the VPAT document format for procurement.

This statement reflects our own assessment of Holy, combining automated testing and developer testing. A recorded manual keyboard and screen-reader audit is still to come, and the statement has not been validated by an external body.

See also our Security & trust page. We review this statement whenever our accessibility target or testing changes.