The standard
Queantic builds to WCAG 2.1 Level AA. That applies to queantic.com, to the signed-in dashboard and to the site templates we build client sites from. Where a client's own content or a third-party embed falls short of it, we say so and we quote the remediation; we do not quietly count it as conformant.
What we are not claiming, stated first
We have not had an independent accessibility audit, so we claim no conformance level and we have no Accessibility Conformance Report (ACR or VPAT) to give you. Both are in progress. If your solicitation requires an ACR at submission, we cannot meet that requirement today and would rather you knew before your committee spent an afternoon on us.
What we can give you now is this page: the standard, the method, the specifics we have implemented, and the gaps we know about. Judge the method.
How we test, every release
- Automated scanning across the whole site. Catches the mechanical failures — missing alternative text, unlabelled controls, contrast below threshold, broken heading order, form fields with no associated label.
- A manual pass using the keyboard only. Every interactive element reached in a sensible order, every focus state visible, no trap, nothing reachable by mouse that is not reachable by Tab. Scanners do not find focus-order problems; a person pressing Tab does, immediately.
- A manual pass with a screen reader. Does a control announce what it does rather than what it is called internally? Does a form error get spoken, and can the person reach it? Is a decorative image silent?
Automated scanning alone reliably finds a minority of real barriers. The two manual passes are what the rest of the standard actually consists of, which is why they are listed as steps rather than as "we also check manually".
What we have built in
These are properties of the design system rather than per-page work, which means a page cannot regress out of them by accident:
- A visible focus indicator on every interactive element — navigation, buttons, footer links, form fields — so a keyboard user gets the same affordance a mouse user has always had.
- A 44 × 44 pixel minimum for touch targets, measured at a 390px viewport. Inline links inside body text are exempt, as the standard allows; everything else is not.
- One type scale and one heading scale site-wide, so heading levels describe document structure instead of being chosen for size.
- A reading measure of about 72 characters on body text, independent of how wide the window is.
- A skip link to the main content on every page, as the first focusable element.
- No analytics JavaScript in the page at all, which removes a whole class of screen-reader interference before it can happen.
- Colour is never the only carrier of meaning in the components we ship.
Known limitations
Listed because they are true. If one of these matters to your evaluation, ask and we will tell you where it stands rather than how we feel about it.
- No independent audit, and therefore no ACR. In progress.
- Reduced-motion preferences are not yet honoured everywhere. The interface uses short transitions rather than animation, so the impact is small, but
prefers-reduced-motionis not wired up across the board and we are not going to call that done. - Third-party embeds are outside our control. A video player, an external map or a social feed added to a site brings its own accessibility behaviour with it. We will tell you which embeds are a problem before you commit to one.
- Documents are the common failure, and they are usually not ours. A perfectly accessible page carrying a scanned PDF of a budget is not an accessible budget. See the guidance below.
- Content added after launch is the client's. We make the accessible path the easy one, and we re-test on request after a large content change, but we cannot guarantee a paragraph we have never seen.
Guidance for staff who publish
Most accessibility complaints about a public-agency website are about documents and images, not about the site. Four habits remove the majority of them:
- Export to PDF, never scan to PDF. A scan is a photograph of text: a screen reader finds nothing in it, and no amount of work on the website changes that. Export from the original document instead, and keep the original.
- Use real heading styles in the source document. Heading 1, Heading 2, and so on — not bold text at a larger size. Headings are how a non-visual reader navigates a forty-page budget; bold text is not a heading.
- Describe images that carry information. One sentence of alternative text saying what the image tells the reader. A decorative photo of the town hall needs none, and should be left empty rather than described.
- Write link text that makes sense alone. "2026 budget (PDF, 1.2 MB)" rather than "click here". A screen reader can list every link on a page out of context, and a page of "click here" is unusable in that list.
Tables deserve their own line: a table used to lay out a page rather than to present data is read aloud cell by cell and makes no sense. If a layout needs columns, that is our job, not a table in the editor.
Report a problem
If any part of a Queantic site is not usable for you, tell us and we will fix it. Please include the page address, what you were trying to do, and the browser or assistive technology you were using — that last one is usually what makes a report reproducible.
What happens when you report something
- We acknowledge it within two business days.
- Within ten business days we either have it fixed, or we tell you in writing what the fix is and when it lands.
- If something cannot be fixed, we say so and offer the information another way.
For evaluators
The rest of the vendor paperwork — the security overview, the data ownership and exit statement, the sample pricing sheet and the sample agreement — is on the procurement page. What Queantic does for public agencies, including what it does not yet do, is on Queantic for public agencies.