Accessibility

Where this site stands

The target is WCAG 2.2 Level AA.

Every page is scanned automatically against Level A and Level AA of WCAG 2.0, 2.1 and 2.2, at phone, tablet and desktop widths. That's twelve routes across three viewports, thirty-six runs in total, with each page scrolled from top to bottom first so the scan covers all of it rather than whatever happened to be on screen. That scan currently reports no violations. It lives with the site's code and is re-run before this page changes, so what you're reading was measured rather than assumed. It's run deliberately rather than by a robot watching every edit, so treat the date at the top as the date it was last true.

That's a real result and a partial one. Automated tools only catch the machine-checkable barriers, which are a minority of the ones people actually hit. Nobody who uses a screen reader daily has audited this site. So the honest summary is: it clears the automated bar for AA, several things the scanner can't see have been checked by hand and are described below, and it hasn't been independently audited. We aren't claiming certified conformance, because we haven't earned that claim.

What has been checked by hand

The automated scan is the floor. These were checked in a browser, because no scanner can see them:

Keyboard operation, one Tab press at a time, on every page. Every link, button and form field is reachable and does something when you activate it. This one matters: the home page used to announce four navigation buttons that couldn't be clicked, couldn't be tabbed to, and would have been invisible if reached. They were in the accessibility tree the whole time and the scanner scored the page perfect.

The focus indicator, measured on every stop of every page rather than sampled. There's one indicator on the whole site now, and it appears instantly rather than fading in.

The mobile menu, which now traps focus while it's open, closes on Escape, and returns focus to the button that opened it. It previously did none of those three.

Every page loaded in a browser with JavaScript switched off, including submitting the contact form.

Reduced motion, with the preference actually turned on, rather than reading the code and assuming.

Reflow at 400% zoom, with every page checked at a 320 pixel wide viewport, which is what that magnification is equivalent to. Nothing requires scrolling in two directions.

Windows High Contrast mode, which found a real problem rather than confirming a hope. In that mode the operating system discards the background colours a site sets, so the primary button, whose entire button appearance came from its gold fill, rendered as plain blue text, identical to the secondary link beside it. Two links, no way to tell which was the main action. It now carries a border that survives, and there's a test to keep it there.

Firefox and Safari, not only Chrome. The behavioural checks run on all three engines. Until September 2026 that sentence wasn't true: a setting in the test configuration meant the Firefox and Safari runs were Chrome with another browser's name on it, and every one of them passed. Run in the real engines, Firefox found text on the home page that faded to a contrast of about 2:1 while it waited for a scroll animation, and Safari found the same heading column could stay faded for good. Both are fixed, and a check now fails if the Firefox or Safari runs are ever anything other than Firefox and Safari.

Contrast

The site is a single dark theme. Against the page background: body text 17.4:1, the gold accent used for links, buttons, and the focus ring 9.5:1, and the dimmer supporting text 6.6:1. The standard asks for 4.5:1 for body text and 3:1 for large text and interface parts.

Those are computed from the colour definitions. The hero also lays text over a soft gradient, so the same measurements were taken again from the pixels actually painted on screen, which is the number that matters to a reader: body text 17.3:1, accent 9.4:1, dimmed text 6.2:1. The gradient costs about half a point at worst.

It's worth explaining one thing the scanner reports, because it looks like a gap. On the pages with a large hero it returns the contrast check as undecided rather than passed, covering between thirty and fifty-three elements depending on the width. On the plain text pages it returns none. Nothing there's failing. The scanner is declining to guess. It can't resolve a single background colour behind a blurred, layered gradient, so it stops rather than report a number it can't stand behind. Those are exactly the elements measured from the painted pixels above.

That number used to be much larger, and the reason is worth admitting. The scan didn't scroll. Everything below the first screenful was still waiting to fade in, so it was sitting at zero opacity when the scan ran, and the scanner couldn't decide anything about it, while this page said the site was scanned in full. It now scrolls each page to the bottom and waits for every animation to finish before looking. Same result, zero violations, but now that result covers the whole page instead of the top of it.

There's a second blind spot in automated scanning, and it's worth naming because it caught us. A scanner skips anything marked as hidden from assistive technology, including its contrast check, which is reasonable, since a screen reader will never reach it. But a sighted visitor still sees it. Four pages on this site carried a small block of decorative code in the top corner, marked hidden, which every scan passed without looking at. Measured from the painted pixels in September 2026 it ran between 1.4:1 and 3.9:1 against a 4.5:1 floor. It was removed rather than brightened, because it was text written to be read, and text written to be read isn't decoration. The tool that found it now runs over every page at three widths and currently reports nothing above the floor anywhere.

Keyboard and focus

Every interactive element is reachable and operable with a keyboard alone.

A skip link is the first thing you reach on any page: press Tab once and you can jump straight past the navigation to the main content.

Focus is shown with a two-pixel gold outline held three pixels clear of the element, measured at 9.5:1 against the page, which is deliberately obvious rather than a faint hint. It's the same indicator everywhere, it follows the shape of whatever it is marking, and it appears the instant focus lands rather than fading in.

Every interactive target is at least 24 by 24 pixels, which is what WCAG 2.2 asks for. The primary buttons are 44 by 44 or larger. An earlier version of this page claimed 44 pixels for everything, which wasn't true of the footer links. They were sixteen pixels tall.

Motion

If your device asks for reduced motion, this site listens. Smooth scrolling is switched off and the browser's own scrolling takes over. The scrolling marquee stops. The animation between pages doesn't run. Every hero entrance is switched off completely, not merely shortened, so headings and text are in their final position in the first frame rather than arriving into it.

The turning object on the contact page is the largest moving thing here, so it gets said plainly: with reduced motion asked for, it draws one still frame and never starts. Not slowed and not faded, never started. The same is true on a touch screen, and it isn't drawn at all on a narrow one. It's decoration, marked as such, so a screen reader never meets it either way.

That last one used to be an exception, stated on this page as a deliberate trade: the entrance was considered the strongest thing on the site and was exempted from the preference. Measured with reduced motion turned on, the headline was still animating three and a half seconds after load. The exemption is gone.

It took two attempts, and the second one is worth describing because it's the kind of thing that looks fixed. The first fix set the animations to a duration of one hundredth of a millisecond, which should land them instantly. Measured, the headline instead sat sixteen pixels below its final position for three quarters of a second and then jumped. That's still a movement, and a worse one than the animation it replaced. The reason is that an animation waiting to start still paints its starting position, and a near-zero duration does nothing about that. They're now switched off rather than sped up.

If motion anywhere on this site causes you difficulty rather than mild annoyance, please say so. That's a bug and it will be treated as one.

Without JavaScript

Every page works with JavaScript switched off. The text, the navigation, and the contact details are in the page as delivered, not assembled afterwards, and every heading paints at full size and full opacity.

The contact form works too. It validates, it tells you what is wrong in the same words it would use otherwise, it gives you back everything you had typed rather than emptying the fields, and it sends. This is checked by a test that runs the whole form twice, once with scripting and once without, and requires both to behave the same.

This section previously said the site was readable without JavaScript with one known gap. That was false. The contact page, which is the one page here that exists to be used rather than read, delivered its navigation and its footer and then a placeholder where the heading and the form should have been. The page was in the response the server sent; it was held inside a container that only a script could open. It's fixed, and it's now the thing this site is tested hardest on.

What hasn't been checked

Testing with actual assistive technology, meaning NVDA, JAWS and VoiceOver, by someone who uses it daily. This is the significant gap, and it's the one that automated scanning and careful keyboard testing can't stand in for.

The site ships in one dark theme with no light option. For some people that's easier to read and for others it's harder, and there's currently no way to choose.

Cognitive load: reading level, density, and how much motion competes for attention on the home page in particular.

If something here blocks you

Write to info@gbtn.studio and describe what happened: the page, what you were trying to do, and what you use to browse, if you're happy to say. You don't need to know the terminology or identify the standard involved.

We'll reply within five working days, and if you tell us what you needed and couldn't get, we'll send it to you directly in the meantime rather than making you wait for a fix.

This page is updated when the situation changes, including when it changes for the worse.