Software should be for everyone.

Our standard

We aim to meet Web Content Accessibility Guidelines (WCAG) 2.2 Level AA on every page of this site. Where we fall short, we say so below rather than pretend otherwise.

What we do well

The site is designed with accessibility in its bones:

• Semantic HTML. Headings, landmarks, lists, and form controls use real elements rather than divs dressed up with ARIA. Screen readers and assistive tools work without surprises.
• Keyboard navigation. Every interactive element is reachable and operable via keyboard. A "Skip to main content" link is the first focusable element on every page, letting keyboard users bypass the navigation.
• Visible focus states. Every focusable element receives a clear outline when reached by keyboard, never removed for visual reasons.
• Reduced motion. All animations and transitions honour the operating system prefers-reduced-motion setting. If you've asked for reduced motion, the site collapses animations to near-instant.
• Light and dark themes. The site detects your system preference and adapts. Both palettes meet WCAG contrast ratios for body text and headings.
• Descriptive link text. Links describe their destination rather than relying on "click here". Text resizes gracefully to 200% without breaking layout.
• Plain language. We aim to write at a reading level appropriate for a B2B audience without jargon for its own sake. Where we use specialist terms, we try to define them.
• Cookie consent that means it. Reject and Accept are equally prominent; rejecting genuinely loads no third-party scripts.

What we're still improving

Accessibility is never finished. Here are the things we know we could do better today:

• No third-party audit yet. We've tested manually with keyboard-only navigation, VoiceOver on macOS, and Lighthouse / axe DevTools, but we have not commissioned an external audit. When we do, we will publish the findings.
• Form testing is limited. The site has no forms today (contact is via email). When we add a form, it will be tested with a screen reader before shipping.
• Imagery descriptions. We avoid decorative imagery where possible. As we add more visual content, we will continue to ensure every meaningful image has appropriate alt text.

How we build

Accessibility is reviewed during development, not bolted on at the end. Specifically:

• Keyboard navigation tested manually on every change
• Lighthouse and axe DevTools run before each release
• Reduced-motion and dark mode tested in browser
• Components in the design system (@chaptech/ui) ship with accessibility primitives — focus states, ARIA where needed, semantic defaults — so client products inherit them

Reporting an issue

If something on this site doesn't work for you, please tell us. We treat accessibility bugs with the same seriousness as broken production code, because that's what they are.

Email hello@chaptech.co.uk with:

• The page where it happens (URL is plenty)
• What you were trying to do
• What went wrong
• The browser and assistive tech you were using, if known

We aim to acknowledge accessibility reports within two working days and triage a fix as a matter of priority.

Enforcement

The Equality and Human Rights Commission is responsible for enforcing the Equality Act 2010 in respect of accessibility. If we don't respond satisfactorily, you can contact the Equality Advisory and Support Service.

Our commitment

We treat accessibility as a craft worth getting right, not a compliance checkbox. As Chaptech grows, we plan to commission an external audit, publish the results, and run the same standard across the products we build with clients. If accessibility matters to you in your software, it matters to us — that's increasingly something we'd like to be known for.