Accessibility
Accessibility
What standard this site is tested against, how it is tested, what passed, and what automated testing cannot tell you.
Conformance status
GEOhandbook aims to conform to WCAG 2.2 Level AA, the W3C standard referenced by most accessibility legislation, including the European Accessibility Act and the UK public sector accessibility regulations.
The current status is partially conformant. Every automated check the site is tested against passes, but as set out below, automated checks alone are not sufficient evidence of full conformance, so claiming “fully conformant” would overstate what has actually been verified.
How this site is tested
Testing uses axe-core, Deque’s open-source accessibility engine, run against the built HTML in a headless Chromium browser. The rule set covers the wcag2a, wcag2aa, wcag21a, wcag21aa and wcag22aa tags.
Sixteen pages are tested — the home page, the guide, playbook and checklist, the three engine pages, the article index, the glossary, three individual articles, and the about, editorial, privacy and disclosure pages — at three viewport widths: 1280px, 768px and 375px. That is 48 page-and-viewport combinations per run. Viewport width matters because several failures found during the last audit appeared only at 375px, where content becomes horizontally scrollable.
The most recent audit, on 20 September 2026, returned zero violations across all 48 combinations. It also returned results the tool could not decide, which were measured by hand — the section below explains why that distinction matters more than the headline number.
What the last audit found and fixed
The audit was not a formality. It found four real defects, all now fixed:
| Issue | WCAG criterion | What was wrong |
|---|---|---|
| Insufficient contrast | 1.4.3 Contrast (Minimum) | Article dates and read times were #8a92a1 on the site’s off-white, a ratio of 2.82:1 against the 4.5:1 required for small text. 112 elements. |
| Insufficient contrast | 1.4.3 | The brand orange used as text gave 2.79:1–3.1:1, failing even the 3:1 large-text floor. The orange is now reserved for borders and rules, with a darker variant for text. |
| Scrollable region not keyboard accessible | 2.1.1 Keyboard | Wide comparison tables and overflowing code blocks could be scrolled with a mouse but not reached by keyboard, so a keyboard-only reader could see the left edge of a JSON-LD example and never read the rest. |
| Link with no discernible text | 2.4.4 Link Purpose | A heading link announced nothing to a screen reader, caused by the markdown renderer auto-linking a bare brand name inside the heading anchor. |
| Insufficient contrast on the home page headline | 1.4.3 | The accent word in the main headline measured 2.29:1–2.59:1 against the gradient behind it, below the 3:1 large-text minimum. Notably, the automated tool did not report this — see below. |
The contrast failures are worth dwelling on, because they are the most common failure on the web — present on 79.1% of home pages in WebAIM’s 2025 survey of the top million sites (WebAIM Million). They are also the easiest to introduce by accident, since a colour chosen for how it looks in a mockup carries no warning that it fails a ratio.
Why the tool missed the biggest one
The home page headline failure is the most instructive result of the audit, because it is the largest text on the site and the tool passed it.
axe-core reports contrast only when it can determine what is behind the text. The headline sits on a gradient painted by a CSS pseudo-element, so instead of a pass or a fail the tool returned “background colour could not be determined” for 13 elements and moved on. Those results land in an incomplete bucket that is easy to never look at, since a summary count of violations shows zero.
Resolving it meant rendering the page, sampling the actual pixels behind the glyphs, and computing the ratio by hand against the WCAG relative luminance formula. The measured result was a clear failure on the site’s most prominent text.
The lesson generalises: “no violations” is not the same as “no problems”, and any contrast claim about text over a gradient, image or overlay needs a manual measurement behind it.
Known limitations
Automated testing is a floor, not a ceiling. Deque, who build the tool used here, are explicit that automated checks catch roughly 57% of accessibility issues (Deque), and WebAIM makes the same point in stronger terms: automated tools cannot detect most issues that depend on meaning rather than markup (WebAIM).
Specifically, the following have not been verified on this site:
- No testing with real assistive technology. The site has not been navigated end-to-end with JAWS, NVDA, VoiceOver or TalkBack. A page can pass every automated check and still be confusing to hear.
- No testing by people with disabilities. No user testing has been carried out.
- Alternative text quality is unverified by machine. Automated checks confirm that an
altattribute exists, not that it describes the image usefully. This site currently contains no content images, which sidesteps the issue rather than solving it. - Reading order and link-text sense in context are judgement calls no tool makes reliably.
- Contrast over gradients and images is not machine-verifiable, as above. The instances on this site were measured manually, but a future design change could reintroduce one without any automated check objecting.
- Third-party advertising. Pages carry Google AdSense units. The markup of an ad is served by Google at request time and is outside this site’s control, so ad content is excluded from the conformance claim above.
Deliberate design choices that help
- Body text is set in a single column with a constrained measure, and the layout is responsive down to 320px without horizontal page scrolling.
- Colour is never the only carrier of meaning.
- The site is server-rendered static HTML. It does not require JavaScript to read, so it degrades gracefully and works with text browsers and reader modes.
- Dark mode follows the
prefers-color-schemesystem setting rather than a bespoke toggle, and both themes are contrast-tested. - Headings follow a strict order with no skipped levels, so heading navigation works.
Reporting a barrier
If you hit something on this site you cannot use, email hello@geohandbook.io and describe the page and what happened. Include the assistive technology and browser you were using if you can. Accessibility reports are treated the same way as factual corrections under the editorial policy: acknowledged, and either fixed or explained.
This statement was last reviewed on 20 September 2026. It is reviewed whenever the site’s templates or colour tokens change.