In one paragraph.
We aim for WCAG 2.1 AA conformance across the site. Semantic HTML, visible focus states, keyboard navigation, contrast ratios of 4.5:1 or better for body text, reduced-motion respect, and descriptive alt text are baked in from the start. We test with keyboard and screen readers periodically. If you hit a barrier, email us and we'll fix it quickly.
1. Our commitment
Pragmatic Archive is committed to making its content accessible to everyone, including people who use screen readers, switch devices, voice control, keyboard-only navigation, high-contrast modes, browser zoom beyond 200%, reduced-motion preferences, or any combination of assistive technology.
Accessibility is not treated as a retrofit — we try to build it in from the beginning, and we treat accessibility bugs as equivalent to any other bug.
2. Standard we follow
Our target standard is the Web Content Accessibility Guidelines (WCAG) 2.1 at Level AA, published by the W3C. WCAG 2.1 AA is referenced by:
- the EU European Accessibility Act (Directive (EU) 2019/882, enforced from June 2025)
- the EU Web Accessibility Directive and the harmonised standard EN 301 549
- the UK Public Sector Bodies Accessibility Regulations 2018
- Canada's Accessible Canada Act and Ontario's AODA
- Australia's Disability Discrimination Act guidance
Where WCAG 2.2 adds additional success criteria — for example the new focus-appearance and target-size requirements — we apply those too wherever possible.
3. Conformance status
Pragmatic Archive is partially conformant with WCAG 2.1 Level AA. "Partially conformant" means that most of the content fully meets the standard, but some parts do not yet. Known exceptions are listed in section 5 below. We are not aware of any systematic Level A failures.
4. Accessibility features
Things we've done across the site:
- Semantic HTML — headings follow a proper hierarchy (one H1 per page, H2 for sections, H3 for sub-sections); landmark elements (
nav,main,aside,footer) wrap regions so screen-reader users can jump between them. - Keyboard navigation — every interactive element is reachable by Tab, in a logical order, with a visible focus indicator. The mobile navigation drawer supports Esc to close.
- Visible focus states — all focusable elements receive a 3-pixel outline in a contrasting colour when focused by keyboard.
- Colour contrast — body text passes WCAG AA contrast of 4.5:1 against its background; large display text passes 3:1. Brand colours are contrast-checked before being used for text.
- Not colour-alone — information is never conveyed by colour only. Warning signs also carry text, icons, and distinct shapes.
- Reduced motion — all non-essential animation is disabled when the reader has
prefers-reduced-motion: reduceset at the operating-system level. - Alt text for images — every meaningful image has descriptive alt text; decorative images are marked empty or
aria-hiddenso they don't clutter screen-reader output. - Form labels — every interactive form control has an associated label, either visible or via
aria-label. - Accordion components — built on native
<details>and<summary>so expand/collapse state is announced correctly by every screen reader without custom ARIA. - Zoom and reflow — content remains usable at up to 400% browser zoom without horizontal scrolling (except for data tables, which scroll horizontally on narrow viewports as WCAG 1.4.10 permits).
- Language declared — the
langattribute on the root element tells assistive tech what language to read the content in.
5. Known limitations
We're aware of the following issues, which we're working on:
- Decorative SVG backgrounds — a handful of background textures use inline SVG rather than CSS. We intend to mark them
aria-hiddenconsistently but may have missed individual cases. - Simulator component — the interactive slot simulator is visual by nature. It provides text equivalents for wins and balance state, but the spinning animation itself isn't described for screen-reader users beyond that. For the same educational purpose, the RTP calculator elsewhere on the home page is more screen-reader-friendly and we'd recommend it as an alternative.
- Chart visualisations — our history charts use SVG with aria-labels summarising the trend, but don't yet expose a sortable data table as a text equivalent. We're planning to add one.
- Emoji used decoratively — some section headers use emoji as visual accents. They're marked
aria-hiddenso they don't duplicate the adjacent text, but we'll continue auditing them.
6. How we test
Our testing mix includes:
- Automated checks — axe-core and Lighthouse accessibility audits run against every page before a release.
- Keyboard-only runs — we navigate the whole site with keyboard alone to confirm tab order, focus visibility, and that no traps exist.
- Screen-reader spot checks — VoiceOver on macOS/iOS and NVDA on Windows, against the home page, the FAQ page, the responsible-gambling page, and any new content as it ships.
- Zoom testing — content is checked at 200% and 400% browser zoom on desktop, and at typical mobile text-scale settings.
- Contrast audits — any new colour combination is checked against WCAG AA contrast ratios before going live.
Automated tools catch around 30–40% of accessibility issues at best, which is why manual testing and real user feedback remain essential.
7. Feedback and reporting barriers
If you hit an accessibility barrier on any page of this site, please let us know. Useful details in your report, in decreasing order of importance:
- The URL where you encountered the problem.
- What you were trying to do (read an article, open the FAQ accordion, take the self-assessment, etc.).
- What went wrong — focus didn't appear, a screen-reader skipped something, a button was unreachable by keyboard.
- Your assistive technology (screen reader and version, browser and version, operating system) if you can share it.
We aim to acknowledge reports within a few business days and have a fix or workaround in place within two weeks for anything that blocks essential content. For the contact address, see section 9.
8. Escalation
If you're not satisfied with how we've handled an accessibility complaint, you can escalate to the relevant national enforcement body:
- UK: Equality and Human Rights Commission (EHRC)
- EU: the national accessibility-monitoring authority in your member state (listed by the European Commission)
- Canada: Accessibility Commissioner
- Australia: Australian Human Rights Commission
- New Zealand: Human Rights Commission
9. Contact
Accessibility feedback goes to the same inbox as every other enquiry — see the contact section of our privacy policy. Putting "Accessibility:" at the start of your subject line helps us route it faster.