Accessibility statement

This is the EqualWeb Academy's own accessibility statement. The Academy teaches how to build accessible web content, so we hold this site to the same standards it teaches. Every page here is meant to be a worked example: if we ask you to give inputs real labels, expose status in text, and keep the keyboard path clear, then this site has to do the same. This statement sets out what that commitment means in practice, how we build, where the honest limits are, and how to tell us when we fall short.

Conformance status

The EqualWeb Academy targets WCAG 2.2 Level AA, and reaches Level AAA where doing so is feasible without harming the learning experience. The site is built as a reference implementation: the markup, styles, and behaviour you see are intended to be the same techniques we recommend, not a separate "marketing" build that quietly cuts corners. Conformance is an ongoing effort rather than a one-time certificate — we re-check as pages change.

In short

Semantic HTML first with ARIA only to fill gaps; visible focus indicators; light, dark, and high-contrast themes; reduced-motion and forced-colors support; full keyboard operability; right-to-left mirroring; reflow at 320 CSS px and 400% zoom; status never conveyed by colour alone; and WCAG 2.2 minimum touch targets — all verified with automated axe-core checks across every page.

What we do

The measures below are the concrete techniques applied throughout the site. They are the same practices the lessons describe, so each one is something you can inspect in the source of any page.

  • Semantic HTML first. Native elements carry the structure, roles, and states; ARIA is added only to fill genuine gaps, never to paper over the wrong element.
  • Visible focus indicators. Every interactive control shows a clear :focus-visible outline, so keyboard users can always see where they are.
  • Light, dark, and high-contrast themes. A theme switcher offers system, light, dark, and high-contrast modes, each meeting contrast requirements.
  • Reduced motion respected. Animation and transitions back off when the user has set prefers-reduced-motion.
  • Forced colours supported. The interface remains usable under Windows High Contrast and other forced-colors modes.
  • Full keyboard operability. Everything is reachable and usable with the keyboard alone, in a logical order, with no focus traps.
  • Logical properties throughout. Layout uses logical (not physical) CSS properties, so the UI mirrors correctly in right-to-left languages such as Hebrew.
  • Content reflows. Pages reflow with no loss of content or function at 320 CSS px width and at 400% zoom, without two-dimensional scrolling.
  • Status is never colour alone. Success, warning, and error states pair colour with text, an icon, or a shape, so meaning survives for colour-blind users.
  • Touch targets meet the minimum. Interactive targets satisfy the WCAG 2.2 minimum size, with adequate spacing.

Technical approach

The Academy is a deliberately buildless, framework-free static site. It is plain HTML, CSS with custom properties for theming, and small amounts of progressive-enhancement vanilla JavaScript loaded with defer. There is no bundler, no transpiler, and no client-side framework: view-source on any page is the real, shipped code.

Because there is no build step, every example you copy is genuine, runnable HTML — what you read is what runs. We verify the site with automated axe-core checks across every page in the light, dark, and high-contrast themes, and we run keyboard-behaviour tests on the interactive widgets (the theme switcher, the mobile navigation, tabbed examples, and copy buttons) to confirm focus order, activation, and the absence of traps.

Known limitations

Honesty is part of the standard, so here are the trade-offs we know about.

  • Intentionally "bad" examples are inert. The lessons show inaccessible anti-patterns on purpose, but every such example is rendered as escaped, non-live code. It is text on the page, not running markup, so it never affects this site's own accessibility.
  • Some illustrative code references placeholder assets. A few code samples point at example file names or stand-in images to keep the snippet focused; these placeholders are illustrative and are not live functionality.
  • Web fonts load from Google Fonts. Typefaces are requested from Google Fonts with a system-font fallback, so if the fonts are unavailable offline the site still renders legibly in the local system font.

Feedback

If you find something on this site that is hard to use, confusing for assistive technology, or simply wrong, we want to hear about it — reports from real users are the fastest way we improve. Please tell us what page you were on, what you were trying to do, and what got in the way, along with the browser and assistive technology you were using if you can.

Contact us

Email the EqualWeb team at accessibility@equalweb.com, or visit equalweb.com. We aim to acknowledge accessibility reports and work with you on a fix.

This statement applies to the EqualWeb Academy demonstration site.