Accessibility Statement

The standard we aim at

We aim to meet Web Content Accessibility Guidelines (WCAG) 2.1, Level AA. We are not claiming full conformance: the checks described below found real gaps, some of which are fixed and some of which are still open. This is a working statement, updated as we fix things, not a certificate.

What we’ve actually fixed

Following a site-wide accessibility check, we made these specific fixes:

• Search was completely unreachable on the homepage and the module-browse page — by mouse or keyboard — because the control that holds it was hidden along with the rest of the page header. We restored it so the header stays visually out of the way but the search control itself is reachable and usable again.
• Muted grey text was too low-contrast to read reliably on 50 pages (every module’s index page, plus the “How IoTClass Works” guide pages) — measured at roughly 3.6:1 against a white background, short of the 4.5:1 AA minimum for normal text. We darkened it to over 5:1 without changing anything else about the design.
• 15 animation and simulation pages had no top-level heading at all — the heading was present in the markup but hidden by a display rule with nothing put in its place, so screen-reader users navigating by heading had no page title to land on. We restored it as an accessible (but visually unchanged) heading on all 15.
• Character “guide” colours used as text were often too light to read. Each module page names its character guide (for example “Your guide: Radio Remi”) in that character’s brand colour. We measured all 21 uses of these colours as text and found 9 fell short of AA — the worst at 1.30:1, effectively invisible pale-yellow-on-white. We darkened the text specifically for those 9, while leaving each character’s original brand colour untouched everywhere else it’s used (borders, icons, badges, artwork). All 21 now meet or exceed 4.5:1.
• Image alternative text: across the curriculum, the great majority of images carry meaningful alternative text rather than a blank or filename-only description (roughly 97–98% of around 5,500 image references, per our most recent full sweep) — the remainder is a known, tracked gap, not a blind spot.
• The interactive quiz and embed components used throughout the curriculum — knowledge checks, matching quizzes, ordering quizzes, label/hotspot quizzes, and the video/simulation embed — were tested with real keyboard interaction, not just by reading the source. Every one of them is fully operable by keyboard alone, uses real buttons and form controls rather than mouse-only drag targets, and announces results and state changes to screen readers as you use it.

What we know is still imperfect

We would rather tell you what’s broken than imply everything is fine:

• The module-browse page (/landing/) still has no visible page title of its own — the standard page heading is deliberately hidden for its custom layout, and we haven’t added a replacement yet.
• The pattern behind the 15 fixed animation/simulation pages above may affect roughly 289 further animation pages. Each one needs an individual check before we can safely apply the same fix, and that check isn’t finished.
• A handful of brand-colour contrast shortfalls remain on the homepage and module-browse page (a couple of category labels and the “Module N” badges) — found, not yet corrected.
• We embed two third-party services directly in chapters: Wokwi hardware simulations and YouTube videos. We don’t control their accessibility. Where we use them, we try to provide a text description of what the simulation does and to favour videos with captions, but we can’t guarantee the embedded experience itself meets AA — that depends on the third party.
• Our checks so far are automated scanning (axe-core) plus scripted real-keyboard-event testing. We have not yet done manual testing with actual screen-reader software (NVDA, JAWS, VoiceOver, or similar), so there may be real-world screen-reader issues our automated checks didn’t catch.

Reporting a barrier

If you run into something that doesn’t work with the technology you use, please tell us. It genuinely helps to include:

• the page URL
• the browser and/or assistive technology you were using
• what you expected to happen, and what happened instead

Send reports to admin@iotclass.org. We aim to acknowledge every report within 5 working days, and to fix the problem — or explain why we cannot and what we will do instead — within 30 days.

Related policies

• Privacy Policy
• Terms of Use
• Cookie Notice

We’re not finished, but we’d rather show real progress and real gaps than a polished claim that doesn’t hold up. Thank you for helping us find what we’ve missed.