Standards and Accessibility
We design for the person with the least confidence, the oldest device and the weakest connection, because that is usually who gets left out.
Technology that only works for confident users has failed at its job. Accessibility is not a feature we add at the end if there is budget left. It is a requirement we design to from the first wireframe, and it makes the product better for everyone, not only for the people it was strictly required for.
We build to WCAG 2.2 Level AA. In practical terms, that means everything works by keyboard alone, contrast is sufficient for people with limited vision, text can be enlarged to twice its size without breaking the page, form fields are properly labelled for screen readers, and nothing relies on colour alone to convey meaning.
Automated tools catch only some accessibility problems. The rest need a person. We run automated checks continuously, then test manually using a keyboard only, and again with a screen reader. Findings are documented and fixed before launch, not logged as future improvements.
We build to UK GDPR and the Data Protection Act 2018. That shapes design decisions: we collect the minimum necessary, we separate consent for different purposes, we set retention periods deliberately, we control access by role, and we log access to sensitive records. Your organisation owns its data and can export it.
Encryption in transit and at rest, role-based access control, secure development practice, and dependency monitoring are standard on everything we build. Where an engagement requires formal penetration testing or specialist assurance, we will say so and arrange it rather than pretend it is covered.
The strongest thing we can offer on this subject is the page you are reading. This site is built to the standard described above and tested the way described above. Our accessibility statement sets out our conformance position, known issues and how to report a problem.
Read our accessibility statement