Built to be usable by everyone

Our commitment

We want everyone who visits this website to be able to use it — to read what we do, understand our services and get in touch — regardless of disability, device or how they access the web.

Accessibility is not a one-off task we completed and moved on from, and it is not a checkbox on a launch checklist. We treat it as an ongoing part of how the site is built and maintained. That means thinking about it when a section is designed, when it is coded, and again when something on the site changes.

It is also a practical matter, not only a principle. A website that is hard to use shuts people out of a business entirely. If someone cannot read our pricing, fill in our contact form or understand what we offer, then the site has failed at its job — for them, and for us.

The same standard applies to the websites we build for clients. When accessibility is considered from the start it costs very little to do well, and it usually produces a clearer, faster, better-structured site for everybody.

The standard we work to

We aim to meet the Web Content Accessibility Guidelines (WCAG) 2.2 at Level AA, the internationally recognised standard for web accessibility. We also work to the principles of the Equality Act 2010, which requires service providers to make their services accessible.

These guidelines are organised around four ideas: that content is perceivable, operable, understandable and robust. That is the lens we use when we build.

WCAG works in three levels. Level A covers the most basic barriers. Level AA is the level most commonly expected of professional websites. Level AAA is the strictest and is not realistically achievable across an entire site, so we do not claim it.

What Level AA means in practice

The guidelines are long, but a lot of Level AA comes down to a handful of practical ideas. In plain English, working to AA means we aim for:

• Text that is readable against its background. Ordinary body text should meet a contrast ratio of at least 4.5 to 1, and larger or bolder text at least 3 to 1. Very light grey text on white is a common failure and we avoid it.
• Colour never being the only way information is conveyed. If something needs attention, it is marked with text, an icon, a label or a change in wording — not simply a red border.
• Everything being operable with a keyboard alone. Anything you can do with a mouse you should be able to do with a keyboard, including menus, forms and anything that opens or closes.
• A visible focus indicator. As you move through a page with the keyboard, the element you are on is clearly outlined, so you always know where you are.
• Text that can be enlarged. The site should stay usable when text is scaled up to 200% or when the browser is zoomed, without content being cut off or controls becoming unreachable.
• Content that reflows on small screens and at high zoom. The page should adapt to a narrow viewport rather than forcing sideways scrolling for blocks of text.
• Consistent navigation and predictable behaviour. The same things generally appear in the same places, and components do not behave in surprising ways.
• Clear, helpful error messages. Forms tell you what went wrong in words you can understand, and explain how to fix it.

Meeting AA is a target we work towards across the site, not a certificate we hold. Where we know of a gap, we say so in the limitations section below.

What we have done on this site

Below are the measures in place across this website. We have listed them specifically rather than in general terms, so you can see what we mean — and so you can hold us to them.

Read together, these cover the main ways people actually browse: with a keyboard, with a screen reader, with magnification, with voice control, or with motion turned down at the operating system level.

Known limitations

We would rather tell you where we fall short than claim a perfect score we cannot back up. No website is completely free of accessibility problems, and any statement that claims otherwise — particularly from a small studio without a formal audit behind it — should be treated with suspicion. Here is what we know about.

Third-party content

Some parts of the site are supplied by other companies and sit outside our direct control. We cannot change how they are built, and we cannot guarantee they meet the same standard as the rest of the site:

• Embedded video players, such as YouTube. We can add captions to our own videos and choose the most accessible embedding options available, but the player's own controls and interface belong to the provider.
• Embedded maps, such as Google Maps. Map canvases are notoriously difficult for screen readers to navigate. Where a map matters, we also provide the address in plain text so the information is available without it.
• The cookie consent banner and any analytics scripts. These are third-party tools. We pick providers that publish accessibility information, and we would rather remove a tool than keep one that blocks people.
• Font and icon libraries, which are widely used and generally well supported, but are not ours to fix.

If a third-party element is stopping you from using part of this site, please tell us. We can often provide the same information in another way, and if a tool turns out to be a genuine barrier we will look at replacing it.

Documents and older content

We publish some documents as PDFs. A PDF that was not created with accessibility in mind is difficult for screen readers to read, and older files in particular may have missing structure, poor reading order or images without descriptions.

Blog articles and pages written before our current standards were applied may also have gaps in heading structure or image descriptions. We are working through them as we update the site, but we have not finished. If you need the content of any document in another format, ask us and we will provide it.

Other known gaps

• The decorative gradient and blur effects used in the design rely on visual rendering. Nothing conveyed by them is essential to understanding the content.
• Very old browsers and unusual or heavily modified browser configurations may not render the site as intended. We build for current versions of mainstream browsers, which is what the overwhelming majority of visitors use.
• Automated accessibility tools only catch a proportion of real problems. They cannot judge whether a description is genuinely useful or whether a heading makes sense. Our checks are a mix of tooling and human review, and there may be issues neither has surfaced yet.

Anything reported to us is logged and addressed. Where a fix will take longer than a quick change, we will tell you what we plan to do and roughly when.

Assistive technology

This site is built with standard semantic HTML, which is the most widely supported foundation for assistive technology. It is intended to work with current versions of screen readers such as NVDA, JAWS and VoiceOver, with voice control software, and with browser-level zoom and text-resizing up to 200% without loss of content or function.

In practice that means we check the site with keyboard-only navigation, with screen reader software running while we move around the pages, and in current versions of the mainstream browsers — Chrome, Safari, Firefox and Edge. We also check how the site behaves at large text sizes and at narrow viewport widths.

Being straight about testing

We are a small studio, and our testing is proportionate to that. We test thoroughly with the tools and combinations we can run ourselves, and we fix what we find. We have not commissioned an external accessibility audit and we do not hold a formal certification, so we do not display an accreditation badge. We would rather describe our process honestly than imply a level of assurance we have not paid a third party to verify.

If you use a combination of assistive technology we have not listed, we would still like to hear how you get on. Reports from real users are more valuable than any automated scan.

How we assess and review the site

Accessibility work is only useful if it keeps happening. A site that passes a check today can regress next month when a new section is added, a font is changed or a third-party script is dropped in.

Because of that, our approach is built around a few habits rather than a single event:

• Accessibility is considered while a section is being designed and built, not checked afterwards when changes are expensive.
• New pages and components are reviewed with a keyboard before they go live, and the obvious automated checks are run as part of the build.
• Colour combinations and contrast are checked when the design of a section changes, not only at the start of a project.
• We re-test the site periodically, and whenever something significant changes, to catch problems introduced along the way.
• Reports from visitors are logged and treated as findings in their own right, because they surface things tooling misses.

This statement is reviewed when the site changes in a way that affects it, and at least once a year. The date at the top of this page shows when it was last updated. If nothing has changed, we would rather leave a stale-looking date than pretend to have reviewed work we did not do.

Tell us about a barrier

If you encounter something on this website that you cannot use or access, please tell us. It is genuinely useful to hear about, and we will fix it where we can. You do not need to know anything about accessibility standards or technical jargon to report something — a plain description of what happened is enough.

It helps if you can tell us the page you were on, what you were trying to do, and what happened instead. If you know it, the browser, device or assistive technology you were using is useful too, but it is not essential. If you would rather talk it through than write it out, email us and we will arrange a call.

You can also reach us through the contact page if that is easier for you.

What happens next

Every accessibility report is read by a person, not filed away. As a typical timescale, we aim to:

• Acknowledge your report within five working days, so you know it has arrived.
• Confirm what we found and whether we agree it is a barrier.
• Tell you what we intend to do about it and, where a fix is straightforward, get it live.
• Come back to you once the change has been made, or explain honestly why it cannot be.

These are targets we work to rather than guarantees. If something is going to take longer, we will say so rather than leave you waiting.

If you are not satisfied

We would always rather hear from you first, and we will do what we reasonably can to put a problem right. But if you have raised a barrier with us and are not satisfied with how we have responded, you are not stuck with our answer.

Where a service provider has not made reasonable adjustments, you can also contact the Equality and Human Rights Commission or the Equality Advisory and Support Service, which offer general guidance on equality matters and can point you towards the right route. These bodies provide advice and information rather than resolving individual complaints directly.

Raised in that way or not, the same offer stands: if you need information from this website in an alternative format, or help completing something on it, contact us and we will sort it out with you directly.

Accessible websites for our clients

Accessibility is built into every website we design, not sold as an optional extra. If you are working with us on a website project and have specific accessibility requirements — or an existing site you are worried about — raise it with us early and we will build it in from the start.

It is part of how we build rather than a phase we add on at the end. Decisions about colour, typography, headings, form structure and navigation all affect whether a site is usable, and those decisions are made throughout a project. Retrofitting accessibility is slower, more expensive and usually less good than getting it right as you go.

It is also worth saying plainly that this is not only about compliance. An accessible site is typically a clearer, faster and better-structured site: real headings, sensible reading order, properly labelled forms and enough contrast help every visitor. Many of the improvements that help someone using a screen reader also help someone reading on a phone in bright sunlight.

What we can talk through

If you are unsure what any of this means for your project, that is a normal place to start. As part of a project, or a conversation before one, we can cover:

• What WCAG 2.2 Level AA means for your particular site, in terms of the pages and components you actually have.
• Which accessibility considerations genuinely matter for your audience, rather than treating every item on the checklist as equally urgent.
• How to write content — headings, link text, image descriptions, form labels — so it works for everyone who reads it.
• Practical steps for improving an existing website, and a sensible order to do them in.
• Practical training for your team so accessibility stays part of how you update the site, rather than something that fades after launch.

You can read more about how we work on the process page or talk it through with us directly.

About this statement

This statement describes our own website and our own approach. It is written in good faith and reflects what we believe to be true about the site at the time of the date shown at the top of the page.

It is guidance and general information, not legal advice, and it should not be relied on as a statement of legal compliance. We are not lawyers, and accessibility obligations vary depending on the organisation, the service and the circumstances. If you need advice about your own legal position, you should speak to a suitably qualified adviser.

For how we handle information more generally, see our privacy policy. If anything on this page is unclear, or you think it is wrong, please tell us — we would rather correct it than leave it misleading.