Accessibility

PrayerGroup.Live targets WCAG 2.2 Level AA. Building an accessible web application doesn’t cost much in 2026; not doing it would just be lazy. What this page used to say is that we meet it and test it on every release — which was a commitment we had not built anything to keep. Below is where we actually stand, with the date, and what is still unchecked.

Where we stand

As of September 15, 2026: the color palette is measured automatically on every build — every text color against every background it can land on, against the 4.5:1 floor. The rendered pages are audited separately, with axe and HTML_CodeSniffer against the live site, weekly.

That audit has now run, and it found things. Nine of the fourteen public pages were clean under both checkers — no missing labels, no unnamed controls, no broken heading order, no missing landmarks, no contrast failure. Four pages carried the same real failure: the small dot separating the links at the top of the About pages was drawn at half strength and did not clear 4.5:1. It is decoration, it is now a full palette color, and screen readers no longer announce it. One page, How it works, is described below.

Three other things were fixed in the same pass. A button that opens the reaction picker pointed screen readers at something that wasn’t there. Four full-height screens were sized in a unit that lets a mobile browser’s toolbar cut off the bottom of the page. And the box you write a prayer in used to seize focus the moment the page opened, which pushed a screen reader past the heading and past the line telling you who can see the post.

The audit itself was wrong before it was useful, which is worth saying plainly. It was pinned to a version of its contrast checker from 2021 that cannot read the color format this site is built in, so it had been reporting every color as unmeasurable rather than as measured — and it was set to check two pages at a time, which meant one page failing to load ended the run after three of fourteen. Both are fixed, and the run above is the first that actually covered every page.

The weekly job is now configured to check the same pages in Spanish, and — this is the larger change — the screens a member actually uses: sign-in, sign-up, the board, writing a post, and both halves of your account. The signed-in pass uses a dedicated test account. If its credentials are missing, the job fails rather than quietly claiming those screens were checked.

Two contrast failures were found and fixed on September 12, 2026: our own wordmark in the footer, which was painted in a background color and came out at 1.10:1 against a 4.5:1 floor, and secondary text on muted backgrounds at 4.31:1. Both were found by a person looking at the page, which is the reason the build measures the palette now.

Why it’s ours, not borrowed

Two reasons, both about who we’re actually for.

Many of the people this is built for are older. They may not see as well as they used to, and their hands may not be as precise. A tap target that’s a little too small, or text a little too faint, is not a minor issue for them — it’s the difference between using this and not.

And many are on the far end of a thin connection: a shared phone, a village signal, a prepaid plan running low. So the whole thing has a graceful, essentially text-based fallback. If the connection is bad, you still get the words. That’s the part that matters.

What we build toward

• Everything is built to work with a keyboard alone, and with a screen reader.
• Text can be enlarged to 200% without anything breaking or disappearing.
• Color is never the only way something is shown.
• Nothing moves, flashes, or times out on you while you’re writing.
• There are no images to fail to load. It’s text.

What we don’t meet yet, or haven’t checked

• Target size (SC 2.5.8) has not been measured. The automated tools do not check whether every control is large enough to hit reliably. This needs a person and a ruler, and it is not scheduled yet.
• Contrast inside the example post cards is unverified. On How it works, the checker returns twenty-two “cannot determine” results for text inside the cards, all on the same kind of element. Nothing is known to be wrong there, but we cannot say that contrast was measured successfully. This is under investigation.
• A post’s own page is not in the automated audit. Its address contains the post identifier, so a reliable test first has to create or locate a suitable post without depending on content that may later be removed. It is checked by hand for now.
• The staff screens are not in the automated audit. They require an administrator’s sign-in and include states the member test account cannot reach. They are checked by hand for now.
• The signed-in audit depends on a dedicated test account. The job is configured to check sign-in, sign-up, the board, writing a post, and both account panes, but it cannot run that pass without its account credentials. A missing credential makes the job fail visibly; it never turns an omitted pass into a clean result.
• No full keyboard journey has been checked by a person. The automated audit can identify many keyboard and focus errors, but it does not prove that a person can complete every task in a sensible order without a pointer.
• No screen-reader testing has been done by someone who uses one. The automated tools find only a fraction of the barriers a real screen-reader user can find.
• Automated checks are a floor, not a pass. A clean run means that the tools found nothing wrong in the states they reached. It does not mean every requirement was tested or that no barrier remains.

This list is what we know of. An empty entry would mean we don’t know of anything — not that there isn’t anything. Tell us.

If something is in your way

Email hello@prayergroup.live with “accessibility” in the subject, and say what you were trying to do and what stopped you. A person reads it and answers, and if it’s a real barrier it goes to the front of the queue. We’d rather fix a barrier than be told our policy is nice.