Accessibility Statement

Last updated: August 15, 2026

1. Scope and standard

This statement covers the RegSecure session application at app.regsecure.com and the website at regsecure.com, including the offline evidence verifier at regsecure.com/verify. The target standard is WCAG 2.1 Level AA.

2. Conformance status

Partially conformant. RegSecure meets most of WCAG 2.1 Level AA. Sections 4 and 5 set out where it does not, and where we have not tested enough to say. We would rather write that down than claim coverage we cannot evidence.

The last review of the client-facing session flow finished on 9 August 2026, and the changes from it are in production. It used automated checking together with hands-on keyboard and screen-reader testing. Since 15 August 2026 the automated conformance, reflow and keyboard checks run in continuous integration, so they are exercised on every change rather than at review time.

3. What is implemented, and how far it has been verified

Two words are used below, and they mean different things. Verified means someone exercised the behaviour by hand, or it is measured directly by a check that runs on every build. Implemented means the code is written to specification but nobody has confirmed it with the assistive technology it is meant for.

Keyboard operation Verified

A complete client session was carried out keyboard-only in Chrome on 9 August 2026, covering joining, identity verification, document review and signing. No keyboard traps were found. The key-backup and recovery journey is additionally driven keyboard-only by an automated test on every build, from setup through five file downloads to the settings status.

Focus management in dialogs Verified

Every dialog in the application uses one shared focus implementation. Focus moves into the dialog when it opens, stays inside it in both directions while it is open, and returns to the control that opened it on close. When that control no longer exists by the time the dialog closes, focus moves to a stable anchor instead of being lost; that case was found by our own testing on 15 August 2026, fixed the same day, and is now asserted by an automated test. Escape closes any dismissible dialog.

Spoken verification words Verified

The four-word safety code used to confirm identity is read aloud in full by the screen reader. Section 4 explains why this one matters more than the rest.

Announcements at session events Verified

Joining, identity verification, recording start and stop, document transfer, signing, and a participant dropping out are each announced once through a live region. Confirmed with VoiceOver in Safari on macOS.

Continuously changing values Verified

The recording clock and the session clock are deliberately left out of announcements, because announcing a value every second interrupts continuously. A screen reader can read the elapsed time on demand instead, in words.

Colour contrast Verified

Every text and interface colour pairing in the session flow is measured against 4.5:1 for normal text and 3:1 for large text and interface components. All pairings pass. The measurement runs on each build, so a regression fails the build instead of reaching production.

Automated conformance checks Verified

The client flow and the website report zero automated violations at WCAG 2.1 Level A and AA. These checks run in continuous integration on every change, so a regression fails the build. Automated checking only covers part of what matters, which is why the hands-on testing above was done as well.

Reading and navigation order Verified

The identity-verification prompt comes first in the reading and tab order, so it is reached straight away rather than after the rest of the interface. Headings and landmark regions are used throughout.

Touch targets and small screens Verified

Controls in the session flow are at least 44 px on their smaller edge. A full session was completed on a physical iPhone in Safari on 9 August 2026.

Text alternatives and form labels Implemented

Interface icons carry text alternatives, or are hidden from assistive technology where they are decorative. Form fields have programmatically associated labels.

Reduced motion Implemented, not hand-verified

The interface honours the prefers-reduced-motion system setting and suppresses animation and transitions when it is set. We have not confirmed this with someone who relies on the setting.

High contrast and forced colours Implemented, not hand-verified

Styling for the forced-colors media query, which covers Windows High Contrast Mode, is in place. It has not been tested on Windows.

Zoom and reflow Verified

Layout behaviour between 200% and 400% browser zoom (WCAG 1.4.10) is asserted by an automated check on every build, across two root font sizes, and was re-verified on 15 August 2026 including the newest dialogs. At 320 px equivalent width every dialog scrolls internally with all actions reachable.

Captions for live video Not available

Sessions have no automatic captioning. See section 5.

4. The identity-verification step

Before video and audio are released, both participants compare a four-word safety code shown on each of their screens, and say out loud that they match. This is the step that makes an intercepted session detectable, and it is performed by speaking.

An earlier version announced that verification was required and told the participant to read the four words aloud, without ever speaking the words. Screen-reader testing caught it. The announcement now includes the words themselves, paced as separate items, so a participant who cannot see the screen has everything needed to do the comparison. An automated test asserts the words are present in what actually gets announced, so this cannot quietly regress.

5. Known limitations

Document display. A shared document is drawn to a canvas for review, so its text is not exposed to a screen reader from inside the session. A “View PDF” control opens the same file in the browser’s own PDF viewer, which does expose the text. That is the accessible route to reading a document, and we think it is not prominent enough. Making it easier to find is an open item.

Live captions. Video sessions have no automatic captioning, so a live session is not accessible to a participant who is deaf or hard of hearing without a separate arrangement. Browser speech recognition has been considered. It is not consistently available across browsers, and the versions that send audio to a server would break the guarantee that session content never leaves the participants’ devices. This is a real gap rather than an oversight, and we do not have a good answer for it yet.

Real-time video. A live consultation is visual and time-dependent by nature. The controls around it are operable without sight. The video itself is not described.

Screen readers we have not tested. NVDA and JAWS on Windows have not been exercised at all. VoiceOver on iOS has not been tested either. The iPhone testing referred to above was functional testing, not screen-reader testing.

No independent audit. No third party has assessed RegSecure for accessibility. Everything on this page is our own testing.

Screen readers and browsers differ in how they present the same markup, so building to specification does not by itself guarantee a good experience with any particular one. That is the reason this page separates what is implemented from what has been verified.

6. Deliberate exceptions

A few dialogs will not close on Escape, and that is intentional rather than an oversight. If the safety codes do not match between participants, meaning the session may be intercepted, everyone is shown a full-screen alert that requires an explicit choice. The prompt that asks a professional to set up key recovery can only be left through an explicit “Not now, I accept the risk” action. And the export dialog asks for confirmation before closing while evidence files remain undownloaded. Each of these represents a decision that should not be dismissible by reflex, and each still traps and restores focus like every other dialog.

7. Feedback and contact

If you hit an accessibility barrier in RegSecure, we want to hear about it, including barriers not listed above. Write to contact@regsecure.com.

It helps if you say what you were trying to do, which assistive technology and browser you were using, and what happened. We aim to reply within 5 business days.

8. Enforcement and complaints

If our response does not resolve the problem, you can raise it with the relevant authority in your jurisdiction. In the United States that is the Department of Justice for ADA complaints. In the European Union it is your national enforcement body under the European Accessibility Act.

9. Ongoing work

The next things on this list are testing with NVDA on Windows and VoiceOver on iOS, and making the accessible route to document text easier to find. Contrast and structural checks already run on every build, so those regressions fail before release. New features are reviewed for accessibility as they are built rather than afterwards.