Four statements about this site, written as facts about the build rather than as assurances. Each says what has been checked, by what, and what has not.
A course that teaches you to ask "what does this claim actually establish" should be able to answer that about itself.
Accessibility
Target. WCAG 2.2 Level AA, where applicable.
What is checked automatically, on every build.
scripts/check_accessibility.py runs as part of make test and fails the build,
so the site cannot be published while it is red. It checks:
- colour contrast for 65 text and interface colour pairs, in both the light and dark schemes, against the 4.5:1 and 3:1 thresholds;
- a
langattribute and a non-empty<title>on every page; - heading structure: no empty headings, the first is an
h1, and levels follow the document's structure; - a
<main>landmark to skip the header with, and no duplicate element ids; - alt text on every image, and alt text that says something rather than repeating a file name;
- link and control text that means something out of context, and a text alternative on anything that has none;
- an alt-text description and reduced-motion handling in every animation source, the units' own and the shared closing and unused opening (the script prints how many it checked);
- reflow at 320px, under the release gate.
Every page in site/ and the generated build/site/ is checked on each run,
and the script prints how many.
What that does not establish. A green result is not a conformance claim, and the script says so in its own output. Automated checking covers the part of accessibility that is decidable by a program, which is a minority of it. In particular these have not been done:
- reading every alt text and animation description against what is actually on screen — a machine can see that alt text exists, not that it is true;
- tabbing through each page to confirm focus order follows reading order and nothing is reachable only by mouse;
- listening to a unit page and a self-check with a screen reader, including a wrong answer and its feedback;
- zoom to 200% and reflow at 400%;
- checking the units in both colour schemes, and Unit 18 in its gothic register.
This list is not a summary of the script's manual checklist — it is that checklist, which the script prints at the end of every run.
Those are on the release checklist in TODO.md and are not yet complete. Until
they are, the honest statement is: the automated checks pass; the manual ones
have not been run.
Alternatives that already exist. Every unit's video has a readable page that covers the same material — neither is a summary of the other. Every animation has a still image and a text description, and holds a meaningful final frame when reduced motion is requested. Every route through the course can be completed without running any code.
If something is unusable for you, the address on the authors page reaches a person. That is the fastest way to get it fixed, and a specific report — which page, which browser, what happened — is worth more than a general one.
Privacy
Nothing you do here leaves your browser. There are no accounts, no analytics, no tracking, and no server that receives your work. The site is static files.
What is stored, and where. One key in your browser's local storage, once you turn local progress on:
ai-literacy-record:v1
It holds your chosen route and learning path, which activities and checkpoints you have marked done, your checkpoint answers and attempt counts, a name if you typed one for the completion record, and whether you have dismissed the storage notice. Nothing else. You can read it in your browser's developer tools. Like anything in local storage, it can also be read by scripts this site serves, by browser extensions you allow to read pages, and by anyone who uses the same browser profile. No script in this site sends it anywhere.
Two things sit outside that record. If you use the switch between light and
dark, your choice is kept under a second key, theme, and nothing else is in
it. If you choose a route on the hub without turning local progress on, the
route travels in the address of the pages you open from there, as
?route=short and the like: it is not stored anywhere, and it is gone when you
open the site afresh.
What that means practically. The record is tied to this browser, this profile and this device. It is lost if you clear site data, use private browsing, reset the browser, or lose the machine. It does not follow you to another computer. This is why the progress page offers a portable backup, and why it is worth taking one.
Your control over it. Export it as a file, import it here or on another browser, or delete it — all from the progress page, without asking anyone.
No outbound requests. The published pages load no fonts, scripts, styles,
images or media from any other host — every asset is served from the site
itself. This has been checked against the built site rather than assumed: no
external script or style tag, no @import, no external url() in the
stylesheets. You can confirm it rather than believe it: open your browser's
network tab and reload a unit page.
Two things are worth naming precisely, because "no outbound requests" is the kind of claim that quietly acquires exceptions.
- There are external links, and links are not requests: they fetch nothing until you click them. The repository link in the footer is on every page, and the reference list links to the sources it cites — that is the point of a reference list.
- The completion-record and activity-log PDFs are generated in your browser, by a library bundled with the site rather than loaded from elsewhere. Nothing is sent anywhere to produce them, and the file is written by your browser to wherever you choose to save it. The logo on the completion record travels the same way: it is encoded into a script the site serves, so producing the record fetches nothing, even from this site.
What this course cannot promise. If you take an activity to a hosted AI service, that is a different system with its own terms, and what you paste into it leaves your device. Unit 13 is about exactly that, and this statement covers only this site.
Working offline
The site is designed to work without a network connection once you have it.
What works offline. All unit pages, activities, readings, the glossary and reference material, every animation, the self-check in the browser, and your progress record. The lab's Python route uses only the standard library and makes no network requests at any point.
What does not. The unit videos are hosted on YouTube and open in a new tab, so they need a connection. The reading covers the same material, so no route depends on being online.
Two ways to have it locally. Download the site package and open it from
disk, or clone the repository — the link is in the footer — and run make site.
One caveat, and it is a real one. Browsers restrict local storage for pages opened directly from a file rather than served over HTTP. Progress may not persist across sessions that way. If you are working offline for any length of time, serve the folder locally instead — any static file server will do — or take a portable backup at the end of each session.
How the videos are made
The narrators are three synthetic voices designed for this course, each shown
on screen as a drawn robot. No person speaks in the videos, and no voice was
recorded from or cloned of anyone. Each is made from a written description. The
only real voice they have been measured against is that of the person responsible
for the course (see the authors page): speaker similarity
0.05-0.13 to those recordings, against 0.83 between two recordings of that person
(docs/audio-production-handbook.md in the source). The three have different jobs
-- one carries the explanation, one reports what a check showed, one asks what a
learner would -- which is a way of presenting the material, not a claim about who
or what made it. Every word they say is the published script of the unit, the
same text as the transcript.
What that statement is worth. It is provenance, and you cannot check it from the video. What you can check is what the video says: the reading carries the same content with its sources, and the checks in each unit run without the video at all.
The completion record is not a certificate in the checkable sense. It records what this browser marked as done and whatever name was typed into it. Unit 17 uses it as the example of a declaration.