Accessibility Statement

Our commitment

RG INSYS LLP targets WCAG 2.2 Level AA conformance for all production work we deliver to clients and for our own website at rginsys.com. Where a client project has a higher legal or contractual requirement (for example AAA for specific success criteria, or sector-specific rules such as the EU Accessibility Act for consumer banking), we adopt that higher target and document it in the Statement of Work.

Accessibility is not a separate phase at the end of a project. It is part of the same review and CI pipeline as security and tests. We test with keyboard, with screen readers (NVDA and VoiceOver), and with automated axe-core checks on every UI change.

This site (rginsys.com)

This statement applies to rginsys.com and all sub-paths under it. The site has been assessed against WCAG 2.2 Level AA. Last full assessment: April 2026. Re-assessment cadence: half-yearly (next: October 2026), plus on any major redesign.

We aim to be honest about where this site is not yet fully conformant. Known issues at the time of writing:

Calendly inline embed. The booking widget on our contact and pricing pages is an embedded third-party iframe with its own accessibility profile that we do not control. Calendly publishes its own accessibility documentation. For users who can't or don't want to use the embed, booking is also possible via the contact form on the Contact page or by email to hello@rginsys.com — both of which are fully keyboard accessible and screen-reader friendly.
Exit-intent popup. The popup that appears if your pointer leaves the page can be dismissed with the close button (which is keyboard focusable) and with the Esc key. If you experience focus being trapped, please tell us — that would be a defect, not by design.
Decorative emoji icons. Some section headers use emoji as decorative icons (for example, the service tiles on the home page). They sit alongside semantic text that conveys the same meaning, so screen readers always have a usable label, but assistive technologies may still announce the emoji name. We are moving these to fully decorative SVGs marked aria-hidden="true" as we touch each page.
Trust bar marquee. The horizontally scrolling "Trusted by" strip on the home page does not auto-pause on hover. We are adding a pause-on-hover and pause-on-focus interaction; until that ships, the strip is purely decorative and the same content is available statically on the about page.

If you find something not on this list, please tell us — see "How to report an issue" below.

Standards we work to

Our default target is WCAG 2.2 Level AA. Depending on where your users are and what your sector requires, we also align to:

EN 301 549 — the European harmonised standard for ICT accessibility, required for EU public sector procurement and now widely referenced for private sector products too. Effectively layers additional clauses on top of WCAG 2.2.
ADA Title III — the United States civil-rights framework that applies to "places of public accommodation". Courts increasingly read this as covering web and mobile services; we treat WCAG 2.2 AA as the working standard for ADA compliance in the absence of a specific federal technical rule.
UK Equality Act 2010 — the UK domestic standard, requiring services to be accessible to disabled users. We use WCAG 2.2 AA as the technical benchmark for satisfying the "reasonable adjustments" duty for digital services.
Section 508 (United States, federal) — for clients selling into US federal government, we align to the current Section 508 refresh, which references WCAG 2.0 AA as its technical baseline.

We do not claim conformance to standards we do not test against. If your procurement form asks for a specific standard not listed above, tell us; we will either add it to the project's scope or say so honestly.

What we deliver in client projects

When you hire us to build or rebuild a product, accessibility is part of the engineering standard, not an optional add-on. Concretely, what ships includes:

🏗️

Semantic HTML first

Native elements (<button>, <nav>, <main>, <dialog>) over <div> with click handlers. ARIA is used to fill genuine gaps, not as a substitute for the right element.

⌨️

Keyboard navigation

Every interactive control is reachable, operable, and ordered logically with the keyboard alone. No keyboard traps. Skip-to-content links on long pages.

🎯

Visible focus rings

Focus indicators that meet the 3:1 contrast minimum against adjacent colours and the new WCAG 2.2 focus-appearance criterion. We do not outline:none without a replacement.

🌗

Text contrast

4.5:1 for body text (AA) as a floor. 7:1 (AAA) on critical interfaces where the client requires it. Tested with real fonts, not just hex values.

📝

Form labels & errors

Every input has a programmatic label. Error messages are associated with their input (aria-describedby), announced to screen readers, and visible — not just shown in red.

🧪

axe-core in CI

Automated axe-core accessibility checks run on every PR for client web work, blocking merge on critical and serious violations on changed screens.

Automated checks catch roughly 40% of issues. We pair them with manual keyboard and screen-reader passes on user-facing changes, and we recommend including users of assistive technology in usability research where the budget and timeline allow.

How to report an accessibility issue

If something on this site or on a product we have built for a client is hard or impossible for you to use, please tell us. We treat accessibility reports the same way we treat security reports: with urgency and without defensiveness.

Email: accessibility@rginsys.com
Acknowledgement: We aim to acknowledge your report within 5 business days.
Critical issues: Anything that blocks a Data Subject's basic access — for example, a form that cannot be submitted with a keyboard — we aim to remediate within 30 days. Less critical issues are folded into the next planned release.

To help us reproduce the problem quickly, please tell us, if you can:

Which assistive technology you use (e.g. NVDA on Windows 11, VoiceOver on iOS 17, Dragon NaturallySpeaking, switch control, magnifier).
The URL or screen where you encountered the issue.
What you were trying to do, and what happened instead.

If you would rather not email, you can also raise an accessibility concern through any of the contact channels on our Contact page — including the WhatsApp number, which routes to the same inbox.

Procurement note for public sector clients

For public sector clients in the EU, the UK, and the United States — and for private sector clients selling into government — we can provide a Voluntary Product Accessibility Template (VPAT 2.4) for any custom product we deliver. The VPAT is written against the relevant standard (Section 508, EN 301 549, or WCAG 2.2 AA directly) and is supplied as part of the project handover artefacts on request.

A VPAT is a self-disclosure document, not a third-party certification. Where independent verification is required, we co-ordinate with an external accessibility auditor of the client's choice and supply the remediation plan against the auditor's findings.

Approval status of this statement

This statement was prepared by the engineering team at RG INSYS LLP, reviewed against the model statement structure published by the W3C, and approved by the founder. It is reviewed at least half-yearly and after any material change to the site.

Last reviewed: April 2026. Next scheduled review: October 2026.

Accessibility statement