Accessibility Statement

My commitment

This site is built to conform to the Web Content Accessibility Guidelines (WCAG) 2.2 at Level AA, and I test against that standard. Accessibility is ongoing work, and I welcome reports of anything that falls short (see “Reporting a problem” below).

Conformance status: fully conformant with WCAG 2.2 Level AA for the public website and the client portal. That covers every page you can reach without signing in: the home, services, pricing, guides, industry, booking, estimate, contact, FAQ, about and legal pages, the sign-in page, and the example concept sites under /showcase. It also covers the client portal (dashboard, projects, quotes, billing, documents, messages, settings and the steps for getting started), and the private links clients are sent for project briefs, contracts and feedback. The admin area, which only I use, is not covered.

What's built in

How I test

On 12 June 2026, I scanned every public page with automated checks (axe-core) in the light and dark themes, at desktop width and at 320 pixels wide, and checked the states that only appear when you interact: the booking form, the chat and accessibility menus, the mobile menu and form errors. I also ran scripted keyboard checks on every page (a visible focus indicator, focus never hidden behind fixed elements, and no keyboard traps), checked text against the WCAG text spacing overrides, and checked text placed over photos against the pixels actually rendered behind it. Automated checks also run as part of my own test suite, so a change that breaks an accessible pattern is caught before it reaches this site.

I checked the client portal the same way while signed in. The getting-started steps and the private brief, contract and feedback pages need real accounts and payments, so I rendered the actual pages with sample data and ran the same checks on them. I also clicked through the interactive parts of the signed-in portal in a real browser, using the keyboard as well as the mouse: the accessibility menu, the account menu, the mobile menu, the quote decline dialog, the message type tabs, the avatar picker, the invite form in settings, the credential delete confirmation, the file upload form on the documents page. I checked that each one has a name, that focus moves into it and back out again, that Escape closes it, and that it works at a narrow phone width. That turned up two problems, which are now fixed. After pressing Delete on a saved credential, keyboard focus was dropped, and the buttons did not say which credential they applied to. On the upload form, a rejected file was not announced by a screen reader, focus was dropped when you removed a file from the list, nothing confirmed that files had been sent, and the remove buttons were very small.

I have also worked through the site by hand with VoiceOver on macOS in Safari, including the booking calendar, and fixed what that turned up: each calendar day is now read out as a full date, and days you cannot book are skipped.

Limits of that testing

• Automated and scripted checks cannot judge everything, such as whether a label makes sense or a reading order feels natural. My hands-on screen reader testing so far is VoiceOver on macOS in Safari only. I have not tested with NVDA, JAWS or TalkBack.
• The form where you enter card or bank details on the payment steps is Stripe's own Checkout, embedded in the page, and the screen for signing a contract is provided by SignWell. I have labelled the areas they sit in, but I do not control their accessibility. If either gives you trouble, contact me and I will take the payment or the signature another way.
• Contracts and other documents are sent as PDFs, and I have not checked those files for accessibility. I can send any document in another format on request.
• In the client portal I have not clicked through every state in a browser. The getting-started steps were checked by scanning rendered pages and reviewing the code, not by working through them by hand. I did not send a real file through the documents form, so the upload progress and failure messages were checked in the code and in automated tests only. I loaded Stripe's embedded payment form and opened its Direct Debit option, but I did not test it with the keyboard or a screen reader. I did work through the private brief, contract and feedback pages by hand, but I stopped short of submitting their forms, so what happens after you press Accept or Submit was checked in the code only.
• The call-booking calendar on my booking page is a custom date and time picker, so it is the part I would most like people using other assistive technology to try. If it gives you trouble, contact me using the details below and I'll book the call with you another way.

Reporting a problem

If you hit a barrier anywhere on this site, whether or not it is listed above, I want to know. Tell me the page and what happened, and I'll look into it.

Or use the contact form.

Changes to this statement

I update this statement when my testing or the site changes. The dates at the top show when the site was last audited and when this statement was last updated.