Independent analytics field guide · sources dated on every pageNo vendor affiliation · how this site works
Statement reviewed 9 August 2026

An accessible reading experience is part of the work.

This site aims to meet WCAG 2.1 Level AA. Below is what was actually tested, what passed, what is known to be imperfect, and how to tell us if something blocks you.

Target standard

Web Content Accessibility Guidelines (WCAG) 2.1, Level AA — the benchmark referenced by both the EN 301 549 European standard and common United States practice. This is a statement of intent and current test results, not a certification, and no third party has audited it.

How this site was tested

Automated and manual checks run as part of the release process rather than as a one-off exercise:

  • axe-core runs against the homepage, a product spotlight, and a tool route. The most recent run reported no critical, serious, or moderate findings.
  • Lighthouse accessibility audits run against production. The most recent homepage and spotlight runs scored 100.
  • Keyboard-only passes confirm that navigation, the mobile menu, every tool form, the analytics consent panel, and all links are reachable and operable without a pointer.
  • Responsive checks at 390×844, 768×1024, and 1440×900, verifying that content reflows without horizontal scrolling.

What the site does deliberately

  • A skip link to main content is the first focusable element on every page.
  • Body text is set in Atkinson Hyperlegible, a typeface designed by the Braille Institute to increase character distinction for low-vision readers.
  • Visible focus styles are present on every interactive element.
  • Every page declares its language, uses one h1, and keeps heading levels in order so screen-reader navigation is predictable.
  • Body text meets or exceeds the 4.5:1 contrast minimum, and layout does not shift as fonts and images load.
  • Editorial images carry descriptive alternative text; images that are purely decorative are hidden from assistive technology instead of being given filler descriptions.
  • The animated signal graphic on the homepage can be paused, and it respects the operating-system reduced-motion preference.
  • Every tool works without JavaScript frameworks, submits nothing, and reports its result as text that a screen reader can read.

Known limitations

Stating these is more useful than claiming perfection:

  • Automated tools catch a minority of real accessibility barriers. No assistive-technology user testing has been commissioned for this edition.
  • The site has not been tested against every combination of screen reader and browser. Reports about a specific pairing are genuinely useful.
  • Source ledgers link to external vendor, standards, and regulator pages. Those sites apply their own accessibility practices, which this project does not control.
  • Some data-dense tool output relies on reading order rather than a formal table structure; improving that is on the list.
No overlay widget

This site does not use an accessibility overlay, plugin, or “accessibility widget.” Those products do not make a site conformant, and they frequently interfere with the assistive technology a visitor already relies on. Accessibility here is handled in the markup and styling instead.

Reporting a barrier

If something on this site prevents you from reading a guide or using a tool, email privacy@slicky.click — that is the single contact address for this site and it reaches a person. Describing the page, your browser, and any assistive technology in use makes a fix much faster. There is no form to fill in and no account required.

Accessibility fixes are treated like factual corrections: they are made directly, and material changes are noted in therevision log.