Loading
What we have built, what we know is not right yet, and where to tell us when something does not work for you.
Last updated
. This is the version in force. Anything we change appears here with a new date.
01
We want this site to work for everyone who lands on it, including people using a keyboard, a screen reader, voice control, or a browser with JavaScript switched off.
We refer to the Web Content Accessibility Guidelines, version 2.1, at level AA. Nobody has audited us against them, and we have not run a formal test, so we do not claim to meet them. What follows is what we have built and what we know is missing.
02
Every link, button, and control shows a clear outline when you reach it with a keyboard. That outline appears for keyboard users specifically, so it is there when it is needed without cluttering the page for everyone else.
If your device asks for reduced motion, we honour it. Animations and transitions stop, the smooth-scrolling engine is never started at all rather than merely slowed down, and page transitions fall back to a plain fade.
If JavaScript does not load, content that would have animated into view is shown anyway rather than being left invisible, and the booking calendar falls back to a plain link.
The interactive parts carry the roles and states a screen reader needs: the comparison toggles behave as a radio group, the showcase behaves as tabs, menus report whether they are open and close on Escape, breadcrumbs announce the current page, and the step-by-step panel announces when its content changes.
Where meaning is carried by an icon alone, such as a tick or a cross in a comparison table, there is text behind it for screen readers. Decorative graphics, including the animated background and the three-dimensional panel, are hidden from screen readers rather than announced as noise.
Each page has one main heading, headings run in order, images carry alternative text, and the page language is declared so a screen reader picks the right voice.
Every page begins with a skip link, so a keyboard user can jump straight past the navigation to the content.
03
The booking calendar is supplied by Calendly and runs inside a frame we do not control. We cannot set its description and we cannot guarantee how it behaves with assistive technology.
The sections of a page are not individually labelled, so a screen reader cannot jump between them by name.
The mobile menu closes on Escape but does not trap focus while it is open.
We have not tested with a real screen reader across more than one browser, and nobody who depends on one has reviewed the site for us.
04
The site uses a single light colour scheme, chosen rather than offered as a toggle. We checked the text colours against their backgrounds by calculation and they meet the AA contrast threshold for body text, with the small uppercase labels sitting closest to the line.
That is arithmetic, not an audit, and it does not cover every combination on every page.
05
If any part of this site is difficult or impossible for you to use, write to stomejiwebcreators@gmail.com and tell us what happened and what you were using at the time. We will fix what we can, and say plainly when something is not ours to fix.
If the booking calendar is the part you cannot use, say so in that email and we will arrange a time with you directly.