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-visibleoutline, 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-colorsmodes. - 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.