Legal

Accessibility Statement

ChurchStacks is committed to making our website and application accessible to everyone — including people with disabilities, older users, and those using assistive technologies.

Last updated: March 2026

Our conformance target

WCAG 2.1 Level AA

We target conformance with the Web Content Accessibility Guidelines (WCAG) 2.1 at Level AA — the internationally recognised standard for web accessibility. This covers perceivability, operability, understandability, and robustness.

We use automated testing tools, manual keyboard testing, and screen reader testing (VoiceOver on macOS/iOS, NVDA on Windows) during development. Accessibility is treated as a first-class requirement, not an afterthought.

Accessibility features

Keyboard navigation

All interactive elements — navigation, buttons, forms, and links — are fully reachable and operable using only a keyboard. A visible focus indicator shows where you are at all times.

Skip to main content

A "Skip to main content" link is the first focusable element on every page, letting keyboard and screen reader users bypass the navigation bar and jump straight to the content.

Screen reader support

Pages use semantic HTML — headings, landmarks, lists, and buttons — so screen readers can accurately describe the page structure. ARIA labels are added where native semantics are insufficient.

Colour contrast

Text and interactive elements meet a minimum 4.5:1 contrast ratio against their backgrounds. Our brand purple (#7c3aed) on white exceeds WCAG AA requirements.

Responsive & resizable text

The site is fully responsive. Text can be resized up to 200% in the browser without loss of content or functionality. We use relative units (rem, clamp) throughout.

Reduced motion

Users who prefer reduced motion (via the OS or browser setting) will see all animations and transitions disabled automatically. No content is hidden behind animation.

Form labels & errors

All form inputs have visible labels and descriptive placeholders. Error messages are associated with the relevant fields using aria-describedby so screen readers announce them.

Descriptive links

Links use descriptive text that makes sense out of context — we avoid "click here" or "read more" without context. Footer and navigation links are clearly labelled.

Technical approach

Semantic HTML5

Pages use <header>, <nav>, <main>, <footer>, <section>, <article>, and <aside> landmarks so assistive technologies can navigate the page structure.

ARIA where needed

We use aria-label, aria-expanded, aria-controls, aria-describedby, and role attributes where native HTML semantics are not sufficient — and no more than that.

Viewport meta tag

<meta name="viewport" content="width=device-width, initial-scale=1"> is set on every page. We do not use user-scalable=no.

Language declaration

The <html> element has lang="en" so screen readers use the correct language and pronunciation rules.

Focus management

When interactive elements like mobile menus open, focus is managed appropriately. The skip-to-content link is the first focusable element on every page.

Known limitations

We are continuously working to improve accessibility. The following known limitations are in progress:

Some third-party embeds

Certain third-party widgets (e.g. embedded calendars or payment iframes) may not fully meet WCAG 2.1 AA. We are working with vendors to address these.

PDF documents

Any downloadable PDFs linked from the site may not be fully tagged for screen readers. Contact us and we can provide an accessible alternative on request.

Assistive technology support

We test with the following browser and assistive technology combinations:

VoiceOver + Safari

macOS & iOS — primary screen reader for Apple users

NVDA + Chrome

Windows — widely used free screen reader

Keyboard only

All browsers — tab, enter, space, arrow key navigation

Browser zoom 200%

Chrome & Safari — text resize and reflow testing

Found an accessibility issue?

If you encounter a barrier on our site or app — something that prevents you from accessing content or completing a task — please tell us. We take all accessibility reports seriously and aim to respond within 5 business days.

Please include: the URL where you encountered the issue, the assistive technology you were using, and a description of the problem. This helps us reproduce and fix it quickly.