Accessibility

The standard we work to

Our target is the Web Content Accessibility Guidelines (WCAG) 2.2 at Level AA, for the public site and the signed-in workbench. A target is what we design and test against. It is not a statement that every page meets it, and we have not had that assessed.

What is tested automatically, and how often

Every pull request, and every change merged to the main branch, runs our continuous integration. It builds the product, starts it against a disposable database and drives it in a Chromium browser. As part of that run:

• The axe-core accessibility engine checks its rules tagged WCAG 2.0, 2.1 and 2.2, Levels A and AA, on every public page, every sign-in and account recovery page, and the evidence request link page when the link is missing or not recognized. The page list is read from the same route inventory as the sitemap, and a test fails when a page is added without being scanned.
• Each of those pages is scanned in the light and dark themes, at a phone width (390 pixels) and a desktop width (1440 pixels).
• Signed-in pages are scanned the same way: the case list, a populated case on every workspace tab with its Incident panel open, the evidence request link a recipient opens, and the Settings sections, including API keys, single sign-on, client environment and contacts, and delivery destinations.
• Selected pages are checked at 200% text size for content that is cut off or forces sideways scrolling.
• Keyboard paths are tested: the skip link, moving between tabs with the arrow keys, and that menus and dialogs close with Escape and return focus to the control that opened them.
• A separate check computes the contrast ratio of every text color in the design system against its backgrounds.

When any of these checks fails, the pull request is marked as failing.

What automated testing cannot tell you

Automated rules find only some kinds of barrier. They can tell that a button has a name, not whether the name makes sense; that text has enough contrast, not whether a page reads in a sensible order with a screen reader. A page that passes every automated check can still be hard or impossible for some people to use.

These have not been done:

• No manual audit with a screen reader (such as NVDA, JAWS, VoiceOver or TalkBack) has been done.
• No third-party conformance evaluation has been done.
• We do not have an Accessibility Conformance Report (ACR) or a VPAT. We will not publish one until a manual audit has been done, because one written from automated scans alone would say more than we know.

Known limitations

• Downloaded reports (HTML, Markdown, PDF and Word) are not checked for accessibility. The HTML report uses headings and tables; PDF tagging and Word structure have not been reviewed.
• The entity graph in a case is a visual diagram. The entities are also listed in the Table view, which is the default and the view to use with a screen reader; in the graph, each entity is a button, and selecting one lists its connections as text. The diagram itself has not been reviewed with a screen reader.
• The conditional model tools under a case (the assumption checker, source map and research instruments) are experimental and are scanned only in parts.
• Payment and subscription pages are hosted by Stripe, and identity provider sign-in pages by your own provider. We do not test those pages.

Tell us about a barrier

If something in NEMUQU is hard or impossible for you to use, email support@nemuqu.com. Tell us the page, what you were trying to do, and the browser and any assistive technology you use. Do not send incident evidence. We will reply to say what we plan to change, if anything; no response time is guaranteed. The support page has the other ways to reach us.

Last updated 2026-10-16.