ACCESSIBILITY
Last Updated: 09/2026
This page is for two readers: someone deciding whether they can procure this product, and someone deciding whether they can use it. It states what we have measured, how we measured it, and what we have not checked. Where there is a gap we name it, because a gap you find yourself is worth less to you than a gap we told you about.
Conformance status
The target is WCAG 2.2 Level AA. As of this page’s date:
| Standard | Status | Detail |
|---|---|---|
| WCAG 2.2 Level A | Self-assessed | No third-party audit. Measurements and method are below. |
| WCAG 2.2 Level AA | Self-assessed | No third-party audit. Known issues are listed rather than omitted. |
| Section 508 (US) | Not formally evaluated | We have not commissioned an evaluation against the 508 refresh. |
| EN 301 549 (EU) | Not formally evaluated | No assessment against the EU procurement standard. |
| VPAT / ACR | Not published | We will not publish one written by ourselves. It follows an audit, not this page. |
“Self-assessed” is not “audited.” Self-assessed means we ran the checks ourselves against the live site and are publishing the results, including the ones we failed. Audited would mean an independent evaluator said so, and nobody has. If your process requires an accessibility conformance report from a third party, we do not have one yet — tell us and we will say honestly where that sits.
How we measure
Contrast
Every text node on a route is resolved through a 1×1 canvas rather than by parsing colour strings, because this site’s theme emits oklch() and lab() values that string parsing gets wrong. The full ancestor chain is then composited, weighted by both alpha and opacity, so a colour is judged against the ground it actually lands on rather than the one it was authored against. SVG marks are resolved through fill; reading color on an SVG <text> returns the inherited value and reports failures that are not real. Floors are 4.5:1 for text under 18.66px and 3:1 for larger or bold text.
The instrument is proved before its results are trusted: a known-bad node is planted on the page and must be caught, and the sweep must return to zero when it is removed. A tool that has never failed anything has not been shown to work.
Structure and keyboard
Landmarks, heading order, accessible names, form labelling, tab order, duplicate ids, focusable content hidden from assistive technology, link text and target sizes are checked by walking the DOM of each route.
What runs in CI, and what does not
A colour gate runs on every commit and blocks a merge, but it is deliberately partial and says so in its own source: it enforces only what is decidable from the source text. It cannot see ink that arrives by inheritance, a colour composited against an ancestor’s ground, or a hue chosen at runtime. Those need a browser, and that sweep is currently run by hand rather than in CI. A green build is therefore not the same as a measured page, and we would rather say that than let the gate imply more coverage than it has.
What we have verified
Measured on the live site across the home page, pricing, features and its six sub-pages, use cases and its ten sub-pages, security, about, whitepaper, blog and blog posts, contact, download and the comparison pages:
- Contrast: approximately 2,600 text nodes across 12 routes, zero failures against the AA floors, at both desktop and a 375×812 mobile viewport.
- Bypass blocks: a skip link on every page, resolving to a real
<main>landmark on every route. - Structure: one
<h1>per page, no skipped heading levels, andmain,nav,headerandfooterlandmarks present. - Names: no image without an
altattribute, no form control without a programmatic label, and no link or button without an accessible name. - Focus order: no positive
tabindex, no duplicateid, and no focusable element inside anaria-hiddensubtree. - Target size: interactive controls meet the 24×24 minimum. Where a control is a visually hidden input, the visible label is the target and is larger.
- Zoom: the viewport sets no
user-scalable=noand nomaximum-scale, so pinch-zoom is not blocked. - Motion: the scroll sequence on the home page and every section entry animation sit behind
prefers-reduced-motion: no-preference. Under a reduce preference the page renders static content — not content that never appears, which is the usual way this is got wrong. - Reflow: at 320 CSS px — the 400% zoom equivalent for SC 1.4.10 — no route requires two-dimensional scrolling. The two wide tables scroll inside their own container rather than moving the page.
- Link text: no link whose entire text is “click here”, “read more” or “here”.
What we have not verified
- Testing with real assistive technology. We have not run this site through JAWS, NVDA or VoiceOver with a screen-reader user. Automated checks and code review find missing names and broken structure; they do not tell you whether a page is pleasant to hear.
- Non-visual keyboard walkthroughs of the interactive demos. The prompt analyzer and the comparison table were checked structurally, not driven end to end by keyboard alone.
- Cognitive and language load. This is a technical security site and parts of it are dense. We have not assessed it against plain-language guidance.
Known issues
- The browser contrast sweep is manual. It is not yet part of CI, so it protects a release only when someone runs it.
- No audit, and so no VPAT. This is the gap that matters most for public-sector and enterprise procurement, and it is a scheduling and budget question rather than a technical one.
What this page covers
This statement covers the marketing site at promptguard.co only. It does not cover the product dashboard, the documentation site, or the desktop agent. Those are separate surfaces with separate codebases and we have not published an assessment of them. If your evaluation needs to cover the application your team would actually log into, say so and we will tell you plainly what has and has not been checked there rather than letting this page stand in for it.
Reporting a barrier, or requesting an accommodation
If something on this site blocked you, tell us at support@promptguard.co. Please include the page, what you were trying to do, and the browser and assistive technology you were using if you know them. We acknowledge within 2 business days.
If you need information from this site in another format — a document, a walkthrough, or answers to a procurement accessibility questionnaire — ask at the same address and we will provide it. We will not send you a conformance report we wrote ourselves and call it an audit.
For certification and data-handling posture, see Security & Trust.