Accessibility statement

We build CommunityFeedback to meet WCAG 2.2 Level AA across all three of our surfaces: this marketing site, the organiser dashboard, and — most importantly — the public campaign and results pages that members of the public actually use.

The public pages carry the most weight in that list. An organiser who hits a barrier in the dashboard can email us. A resident who hits a barrier on a campaign page just does not get counted, and nobody finds out.

• Every page uses real landmarks and a sensible heading order, so screen-reader users can navigate by structure rather than by reading everything.
• Everything is operable by keyboard alone, with a visible focus indicator that is not removed for aesthetic reasons.
• A skip-to-content link is the first thing in the tab order.
• Every form control has a real, visible label — not a placeholder standing in for one — and errors are announced, described in words, and tied to the field that caused them.
• Text contrast is at least 4.5:1, and interface components at least 3:1, in both light and dark themes.
• Interactive targets on public and mobile surfaces are at least 44 by 44 pixels.
• Colour is never the only way meaning is conveyed: map categories, chart series and status badges all carry a text label too.
• Motion is minimal and respects the operating system's reduce-motion preference.
• Pages reflow to 320 pixels and support 200 per cent zoom without loss of content.
• Nothing auto-plays, nothing steals focus, and no interaction is on a timer.

The pin-drop map is our signature feature and the hardest thing on the site to make accessible. A canvas you drag a marker around is, on its own, effectively unusable with a keyboard and close to meaningless through a screen reader.

So the map is never the only way to contribute. Beside every map we render there is a plain, labelled text field:

• You type an address, an intersection or a postal code — whatever you know.
• We geocode it and show you, in text, the location we matched, so you can correct it before submitting.
• You pick a category and write your comment in exactly the same controls a mouse user gets.
• The point is stored identically to a dragged pin, appears in the same results, the same charts and the same export, and carries exactly the same weight.

Three deliberate decisions about it: it is visible, not tucked behind an “accessibility options” link — plenty of sighted mouse users prefer typing an address they already know, and people on slow connections would rather not load a tile layer at all. It is on by default on every plan, including the free one. It cannot be switched off by an organiser, because a campaign that turns it off is a campaign that has quietly excluded part of its community.

Existing pins are also available as a text list, so the map’s contents can be read without the canvas.

• Keyboard-only walkthroughs of every public flow: answering a survey, placing a point by address, posting an idea, and reading a results page.
• Screen-reader passes with VoiceOver on macOS and iOS.
• Automated checks in the browser for contrast, names, roles and values.
• Zoom to 200 per cent and a 320-pixel viewport on every public page.
• Dark theme checked separately — a contrast fix in one theme is not a fix in the other.

Automated tools catch perhaps a third of real problems. The keyboard walkthrough catches most of the rest, and reports from actual users catch what neither of those does — which is why the next section exists.

Stating this plainly is more useful to you than a claim of perfect conformance:

• The map canvas itself is not fully keyboard-navigable for browsing other people's pins. The address field covers contribution, and the text list covers reading, but panning and zooming the canvas by keyboard is not there yet.
• Uploaded images — hero images, question images and respondent photos — depend on whoever uploaded them supplying alt text. We prompt for it; we cannot generate it truthfully on their behalf.
• Word clouds are decorative by nature. The same data is available as a ranked list, but the cloud itself conveys little to a screen reader.
• Chart exports as PNG carry no text alternative once they leave the product.
• We have not yet commissioned an independent third-party audit. When we do, the findings and the fixes will be published here.

We can make the container accessible. The content inside it is yours:

• Write alt text for every image you upload, describing what matters about it rather than repeating the caption.
• Keep question wording plain. Long, clause-heavy questions are an accessibility barrier as much as a response-rate one.
• Check your brand colour. If it does not contrast with white text, the page will tell you — please listen to it rather than working around it.
• Do not put essential information only in an image, a PDF or a video without a transcript.
• Offer a non-digital route as well where the consultation is statutory. A phone number or a paper form alongside the link reaches people no website reaches.

If any part of the service blocked you, tell us: hello@communityfeedback.ai. It helps enormously if you can include the page address, what you were trying to do, and the browser and assistive technology you were using — but send it even if you cannot.

We acknowledge accessibility reports within five working days and treat barriers on public campaign pages as our highest-priority bugs. If a fix will take time, we will tell you what the workaround is in the meantime rather than going quiet.

If you were trying to answer a specific consultation and cannot, the organisation running it should also offer another way to take part. Copy us in and we will help make sure they do.

This statement applies to communityfeedback.ai, the organiser dashboard, and the public campaign and results pages we host.

We consider the service partially conformant with WCAG 2.2 Level AA: most of it meets the standard, and the exceptions are listed in section 5. We reassess with every significant release and update this page when the picture changes.