Built by someone who is losing his sight.

1 Why This Matters Here

Most accessibility statements are written by a company that has never needed one. Ours is not.

Joseph Harris, who built this platform, is colour blind and lives with macular degeneration. His eyesight is getting worse, not better. That means every low-contrast label, every pale grey caption, every button that relies on colour alone is something he runs into himself, on his own software, on a normal working day.

It also means we do not trust our eyes. Contrast on this site is calculated, not judged by looking at it. A colour either passes the ratio or it gets changed. That rule has been applied to the marketing pages, the six colour themes, and the buttons and labels inside the app.

2 The Standard We Aim For

We target WCAG 2.1 Level AA, the level most commonly referenced by law in the United States, the United Kingdom, the European Union, and Switzerland.

We want to be precise about what that claim covers, because a vague claim is worth nothing:

So: a genuine, measured, self-assessed AA effort. Not a certification, and we will not dress it up as one.

3 Seeing It: Contrast and Colour

Contrast is computed

Body text, labels, links, and button text are all checked against the WCAG contrast formula. Ordinary text needs to reach 4.5 to 1 against its background. Most of ours sits well above that, and a good deal of it clears the stricter 7 to 1 AAA threshold.

When a colour failed, we changed the colour rather than shrinking the claim. The Lemon theme is the clearest example. It began as a dark mustard because a bright lemon made white button text unreadable. Rather than settle, we split the problem: the buttons became true bright lemon with near-black text, which measures 9.08 to 1, while the accent used for small text stayed a deeper gold that still passes comfortably. The result is genuinely lemon and genuinely readable.

Colour is never the only signal

If you cannot distinguish red from green, nothing in Free Church ChMS should become unusable. Status is carried by words and icons as well as colour. An at-risk member says "at risk". A confirmed test says "Connected". A failed one shows the actual error text. Charts label their values rather than relying on you to match a swatch to a legend by hue alone.

4 Six Themes, Including Dark

Different eyes need different things. Some people need more contrast, some need less glare, and some need a particular hue to be avoided entirely. So the app ships six full colour themes, switchable instantly from the small dots under your church name in the sidebar. No reload, no settings page to hunt through.

• Default Blue. The standard palette.
• Soft Green. A vivid emerald, tuned so the accent still passes as text.
• Warm Rose. A true red rather than a washed-out mauve.
• Lemon. Bright lemon buttons with near-black text at 9.08 to 1.
• Lush Cerulean Blue. A crisp sky-cyan.
• Dark Mode. A full dark palette for tired eyes, dim rooms, and the sound booth at the back of a dark sanctuary.

Every theme was recoloured with the contrast formula in hand. In this app the accent colour doubles as text in places, so a theme cannot simply be made louder without making something unreadable. Each one was worked out so that it is both vivid and legible.

You can see all six side by side on the Themes page.

5 Text Size and Large Displays

Nothing here is locked to a fixed pixel size. Zoom the page with your browser and the layout reflows rather than cutting text off. Everything is built in relative units, so buttons and tap targets grow along with the text instead of staying small while the words get bigger around them.

We also scale up deliberately on large screens. A church that puts a dashboard on a big television in the office, or runs check-in on a wall-mounted touchscreen, gets larger type automatically at higher resolutions rather than a tiny column stranded in the middle of a huge display.

The typeface is Inter, chosen for how clearly it separates similar shapes at small sizes, and it is served from your own server rather than a font network, so it loads the same way every time and works with no internet connection at all.

6 Keyboard and Pointer

You do not need a mouse. Every link, button, form field, and menu can be reached with the Tab key and used with Enter or Space. The slide-out site menu closes with Escape.

When you move with the keyboard you get a clear focus ring, a solid outline with a soft halo behind it, so it stays visible on both dark navigation bars and light cards. It appears for keyboard users and stays out of the way for mouse users.

Help tooltips respond to keyboard focus, not just to hovering. A hover-only tooltip is invisible to anyone using a keyboard or a touchscreen, so ours are reachable by tabbing to them.

Touch targets are sized for real fingers, including hands that shake. The menu button is a full 44 pixels square, which is the size Apple and Google both recommend as a minimum.

7 Screen Readers and Page Structure

Pages are built with real headings in real order, so a screen reader can jump through the structure instead of reading everything from the top. Heading levels do not skip. Landmarks like navigation, main content, and footer are marked as such.

Images that carry meaning have alternative text. Images that are purely decorative, including the background textures and the little symbols scattered through the marketing pages, are hidden from screen readers so they are not read aloud as noise.

The site menu button announces whether it is open or closed. Form fields have labels that are actually connected to them, not just text sitting nearby.

8 Motion

Animation here is small and functional. Buttons press, panels slide, numbers count up on the dashboard. Nothing flashes, nothing blinks rapidly, and nothing moves on its own without you doing something first, so there is no seizure risk from strobing content.

If you have asked your computer to reduce motion, in Windows, macOS, iOS, or Android, we listen to that setting and the animations stop. You do not have to configure anything inside the app.

9 Where We Fall Short

Every honest accessibility statement has this section. Here is ours.

• No independent audit. Everything here is self-assessed. A paid third-party review would almost certainly find things we have not.
• Limited screen reader testing. Covered above. This is our biggest known gap.
• The application has had less formal review than the website. Same standards applied, less page-by-page verification.
• Complex data tables. Reports and analytics involve dense tables. They are navigable, but a long financial table is hard work with a screen reader no matter how well it is marked up.
• Exported PDFs. Giving statements and reports are generated in your browser. They may not carry the full tagging a screen reader needs to read them well. If you need an accessible version of a statement, the same data can be exported to Excel or CSV, which reads far better.
• Charts. Every chart has figures and plain-language readings beside it, so the information is available without seeing the graphic. The graphics themselves are not individually described.

We would rather list these plainly than have you discover them one at a time.

10 Parts We Do Not Control

If your church uses the Streaming Hub to embed a service from YouTube or Facebook, that video player belongs to them, and its accessibility is theirs. The same goes for captions on your sermon videos, which are produced by whichever platform you stream to.

We would gently encourage every church to turn captions on. Someone in your congregation is relying on them, whether or not they have told you.

11 Self-Hosting and Your Own Changes

Free Church ChMS runs on your own server, and the source is yours under the licence. That has a real accessibility benefit that hosted software cannot offer: if your church has a specific need, you are allowed to change the software to meet it.

Larger default text for a volunteer with low vision, a custom colour for a particular kind of colour blindness, a simplified page for someone who finds the full one overwhelming. You do not need our permission and you do not need to wait for a vendor's roadmap.

If you make a change that would help other churches, we would love to hear about it and fold it in.

12 Telling Us About a Barrier

If something here stops you doing what you came to do, tell us. We treat that as a bug, not as a feature request, and we do not charge to fix it, because we do not charge for anything.

If we cannot fix it quickly, we will tell you honestly how long it will take and what you can do meanwhile. We will not go quiet on you.

13 Formal Details