Accessibility commitment and feedback

How accessibility is approached

The public site is designed to use semantic page structure, visible focus states, a skip link, descriptive links, responsive layout and a reduced-motion path for the animated homepage. Motion is intended to explain the product-system concept, not to be required for understanding the service proposition. Visitors who prefer reduced motion should receive a usable static alternative, and the animation control is intended to make movement pausable where it is present.

Content and interaction decisions are reviewed alongside practical behaviour such as keyboard navigation, focus order, form labels, error messaging, contrast, headings, page titles, image alternatives and responsive layout. Automated checks can identify some defects; they cannot establish that a workflow is understandable or usable for every person. Meaningful accessibility review also needs human judgement and, where appropriate, feedback from people using assistive technology.

What we test and what we do not claim

For public-site changes, TechGeek aims to test the affected routes and key interactions in the release process, including responsive and keyboard behaviour where practical. The current site includes a skip link, consent controls designed as a keyboard-operable dialog, accessible labels for the enquiry flow and a reduced-motion design path. Those are implementation measures, not evidence of a complete independent accessibility audit or full conformance across all criteria.

We do not currently publish a formal WCAG conformance claim, independent audit, accessibility certificate, supported-browser matrix or comprehensive assistive-technology test report. External assets, embedded services, future pages and changes made by suppliers can introduce limitations. If a formal conformance target, audit trail or public-sector statement is required for a specific product or engagement, it should be scoped, tested and documented for that system.

Feedback and improvement

To report an accessibility barrier, email karan@techgeekuk.com. Please include the page URL, what you were trying to do, the barrier encountered, the browser or device and any assistive technology details you are comfortable sharing. This makes it easier to reproduce the problem without asking you to disclose unnecessary personal information.

Feedback is reviewed to determine whether the issue is in TechGeek-controlled content, an embedded provider, a browser-specific behaviour or a broader design requirement. Where an issue is confirmed, TechGeek may correct it, provide an alternative, document a limitation or plan it into the next suitable change. This route does not set a guaranteed response or remediation time, but it creates a clear accountability path for improving the public site.

What this page does not ask you to infer.

• 01

  This route is not a declaration of full WCAG conformance, an independent accessibility audit or a promise that every future feature will work in every environment.

• 02

  Accessibility requirements for client products, mobile apps, documents and third-party services need their own scoped evaluation; public-website practices do not transfer automatically.

• 03

  A reduced-motion setting, semantic markup or automated check is useful evidence of intent and implementation, not complete proof of accessible user experience.