Legal
Accessibility statement
The standard CiderHQ works to, what has been built to meet it, what is known to fall short, and how to tell us about a problem.
The standard
CiderHQ is built to the Web Content Accessibility Guidelines, version 2.2, at level AA.
That is a statement of the standard being worked to, not a conformance claim. No independent accessibility audit has been carried out on this site, and no assistive-technology user testing has been commissioned. Where this statement says something has been done, it means it has been built and checked by the team; it does not mean it has been certified by anybody.
Saying so is the point. A statement that asserts conformance without an audit behind it is the commonest way an accessibility page misleads, and the reader it misleads is the one relying on it.
What has been done
Structural decisions rather than remediations. Most of these are properties of how the site is built, not fixes applied afterwards.
Structure and semantics
- Real HTML elements throughout: headings, lists, tables, definition lists and landmarks rather than styled generic containers.
- One first-level heading per page, and no skipped levels. A sub-heading that needs smaller type is rendered at the correct level and styled down, rather than being demoted to a level that would leave a hole in the outline for anyone navigating by heading.
- A skip link to the main content, which is the first thing in the tab order and becomes visible on focus.
- Landmarks on every page: a banner with the primary navigation, a main region, a footer whose link groups are each a labelled navigation region, and breadcrumbs marked as such with the current page identified.
- Page language declared as British English at the document root.
Keyboard and focus
- Everything interactive is reachable and operable by keyboard.
- A visible focus outline is applied globally and is never removed — including on buttons, links, form controls and disclosure summaries.
- The first-visit age notice is deliberately not modal and does not trap focus. It does not restrict access to anything, so trapping keyboard focus inside it would make it behave like a gate while being unable to act as one. Focus moves to its primary button when it appears, Escape dismisses it, and Tab leaves it for the page.
- The mobile navigation menu closes on navigation rather than staying open over the new page.
Content that is not text
- Diagrams are inline SVG with an accessible name and description, and every one carries a structured long description rendered as prose beneath it. A figure that works only visually is a figure some readers cannot read, and the commonest failure is a label that names a diagram without conveying it.
- Data tables have captions, column headers and row headers, so a cell can be announced with the row and column it belongs to rather than as a loose value.
- Sensory scales are shown as a graphic with a text alternative that states the reading in words, and the same value appears as text in the adjacent column of the same row.
- Colour is never the only carrier of meaning. Evidence and confidence markers carry a word as well as a colour, and so do sensory and status indicators.
Reading and viewing
- Layouts work down to a 320-pixel viewport without the page scrolling sideways. Where content is genuinely wide — a data table, a diagram — it scrolls within its own container rather than dragging the page with it.
- Text is set in relative units and reflows on zoom; nothing is sized to a fixed pixel height that would clip enlarged text.
- A reduced-motion preference is respected globally: animations and transitions are effectively disabled, and smooth scrolling is turned off.
- Light and dark themes both follow the system preference, and colour choices are made against contrast requirements in both.
- Pages are server-rendered and work with scripting disabled, including search, which is an ordinary GET form. Nothing essential depends on JavaScript.
An automated accessibility check runs as part of the build gates, alongside the data, evidence and editorial audits. It catches the mechanical faults — a skipped heading level, a table without a caption, an image without a description, a figure without a long description — and it is honest about its own limits: an automated check cannot tell whether a description is any good.
What is known to be imperfect
Recorded because a reader deciding whether to bother deserves to know before they start, not after.
- No independent audit and no user testing. Everything in the section above has been built and checked internally. Nobody using a screen reader, a switch device or magnification daily has been asked to test the site, and internal checking is not a substitute for that.
- Wide tables scroll horizontally. Several reference tables carry four or five columns and cannot be made narrow without losing information. On a small screen they scroll inside their own container, which is workable but awkward — particularly for anyone using magnification, where a horizontally scrolling region inside a page is genuinely hard to track.
- Definitions shown on hover are not available to everyone. Some terms carry a definition as a native tooltip. That is fine with a mouse or a keyboard focus, and it is not available at all on a touch screen. The definition is always available in full elsewhere — in the glossary, or in the surrounding text — but the shortcut is not.
- The first-visit notices sit over the foot of the page. The age notice, and the analytics bar where analytics is configured, are fixed to the bottom of the viewport. On a short viewport, or at high zoom, they cover more of the page than intended until they are answered or dismissed.
- Sensory scales are a compromise. The band graphic conveys a range at a glance and is announced as a single sentence. Someone reading a whole table with a screen reader gets the reading and the range in words, which is correct, but not the visual comparison across rows that the graphic gives a sighted reader.
- Long pages are long. Several reference pages — the source register in particular — are substantial documents. They are structured with headings and in-page links, but there is no on-page table of contents on every one of them yet.
Reporting a problem
If something here does not work for you, please tell us: privacy@hekno.co.uk.
What helps
- The address of the page, or enough of its title to find it.
- What you were trying to do, and what happened instead.
- What you were using — browser, operating system, and any assistive technology and its version. This matters more than it sounds: a fault that appears in one screen reader and not another is a different fault from one that appears in all of them.
There is no service-level commitment on replies. What is promised is that an accessibility report is treated as a defect rather than as feedback, and that where something is found to be broken and cannot be fixed quickly, it is added to the known-problems list above so that the next reader is told about it.
If you would rather report the underlying content problem — a description that does not convey its diagram, a table that cannot be read in order — that is equally welcome, and it goes through the same route as any other correction.
Other ways to reach us, and the rest of the legal notices, are at legal information. Content errors go through corrections.
About this statement
This statement describes CiderHQ as currently published by HEKNO LTD. It is maintained alongside the site rather than reviewed on a schedule, and it is updated when something in either list changes.