About the unverified marks on this pageFigures tagged unverified are PACE-local estimates that could not be confirmed against any published source, so they are labelled rather than quietly presented as fact. Every other factual claim on this page — statutes, standards codes, gene biology, primary-source citations — was independently checked; the full claim audit, including what came back wrong, lists every claim with its source.
Try it Tuesday · 90 minutes
Run this next week
90 minutes. Minutes 0–15: students write one measurable learning objective for a concept they teach. Minutes 15–45: they generate an interactive module with the accessibility-constrained prompt. Minutes 45–90: they run the embedded a11y-audit demo (or a manual checklist) against their module, documenting every failure — keyboard traps, contrast below 4.5:1, motion that ignores the reduced-motion setting — and fixing what they can in the room. The deliverable is the audit log: what the AI shipped broken and what the student caught, which is where the professional skill lives.
The full assignment
Make it 3D print · laser cut
A tactile manipulative for a concept students currently teach with a diagram. The design constraint that makes this a real assignment: it has to work for a learner who cannot see the diagram.
Build it AI chat · no code
A working interactive module built in one sitting, then run against an accessibility checklist. The audit is where the learning is. Most AI-generated interfaces fail keyboard navigation and contrast on the first pass, and finding that is the skill.
Try the demo · runs offline
Learning Design & Technology demo
Interactive demo — “a11y-audit”. It cannot be printed; run it in a browser at https://el3vate.vercel.app/demos/a11y-audit/index.html
This demo runs entirely offline against canned data — no keys, no network, safe on conference wifi.
4 weeks, realistically
The 4-week version
- Wk 1Choose one concept and write the learning objective before touching a tool; the objective gets peer-reviewed for measurability. Design the tactile manipulative of that same concept for a learner who cannot see the diagram.
- Wk 2Submit the tactile-manipulative fabrication file at the start of the week so it is cut in parallel. Build the digital module with AI; ship a rough version fast.
- Wk 3Accessibility audit against WCAG basics: keyboard only, contrast, screen reader, reduced motion. Document every failure and fix it.
- Wk 4User test both versions with three learners outside the class. Revise once. The revision log is the deliverable.
Starter prompt & what the model actually did
The prompt, run for real
Build a single self-contained HTML page that teaches this concept interactively: [concept]. The learner is [describe them]. Requirements: it must be fully operable by keyboard alone, meet WCAG AA contrast, respect prefers-reduced-motion, and work on a phone. After you build it, list every accessibility decision you made and every place you are uncertain whether it passes.
Here's a compact, self-contained page. Save as `bill-to-law.html`.
```html
<!doctype html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>How a Bill Becomes Law in Hawaiʻi</title>
<style>
:root{--bg:#fff;--fg:#1a1a1a;--accent:#005a9c;--done:#0b6b3a}
*{box-sizing:border-box} body{margin:0;font:1rem/1.5 system-ui,sans-serif;color:var(--fg);background:var(--bg);padding:1rem}
h1{font-size:1.4rem} ol{list-style:none;padding:0;display:flex;flex-wrap:wrap;gap:.5rem}
li button{width:100%;text-align:left;padding:.75rem;border:2px solid var(--accent);border-radius:8px;background:#fff;color:var(--fg);font:inherit;cursor:pointer}
li button[aria-current="step"]{background:var(--accent);color:#fff}
li.done button{border-color:var(--done)}
.panel{margin-top:1rem;padding:1rem;border:2px solid var(--accent);border-radius:8px}
.nav{margin-top:1rem;display:flex;gap:.5rem}
.nav button{padding:.6rem 1rem;font:inherit;border:2px solid var(--accent);background:var(--accent);color:#fff;border-radius:8px;cursor:pointer}
.nav button:disabled{opacity:.5;cursor:not-allowed}
:focus-visible{outline:3px solid #d40000;outline-offset:2px}
@media(min-width:600px){li{flex:1 1 30%}}
@media(prefers-reduced-motion:no-preference){.panel{transition:opacity .2s}}
</style>
</head>
<body>
<h1>How a Bill Becomes a Law in the Hawaiʻi State Legislature</h1>
<p>Select a step, or use Previous/Next. Arrow keys move between steps.</p>
<ol id="steps" role="list"></ol>
<div class="panel" id="panel" tabindex="-1" aria-live="polite"></div>
<div class="nav">
<button id="prev">Previous</button>
<button id="next">Next</button>
</div>
<script>
const steps=[
["Introduction","A legislator introduces the bill; it gets a number and a first reading."],
["Committee","The assigned committee holds a public hearing and votes to pass, amend, or hold it."],
["Floor Vote","The full chamber (House or Senate) debates and votes on second and third readings."],
["Other Chamber","The bill crosses over and repeats the process in the other chamber."],
["Conference","If versions differ, a conference committee reconciles them."],
["Governor","The Governor signs it, vetoes it, or lets it become law without a signature."]];
let i=0;
const ol=document.getElementById("steps"),panel=document.getElementById("panel");
const prev=document.getElementById("prev"),next=document.getElementById("next");
steps.forEach((s,n)=>{
const li=document.createElement("li");
const b=document.createElement("button");
b.textContent=(n+1)+". "+s[0];
b.addEventListener("click",()=>go(n));
b.addEventListener("keydown",e=>{
if(e.key==="ArrowRight"||e.key==="ArrowDown"){e.preventDefault();go(Math.min(i+1,steps.length-1),true)}
if(e.key==="ArrowLeft"||e.key==="ArrowUp"){e.preventDefault();go(Math.max(i-1,0),true)}});
li.appendChild(b);ol.appendChild(li);});
function go(n,focusTab){
i=n;
[...ol.children].forEach((li,x)=>{
const b=li.querySelector("button");
b.setAttribute("aria-current",x===i?"step":"false");
li.classList.toggle("done",x<i);
if(focusTab&&x===i)b.focus();});
panel.innerHTML="<h2>"+steps[i][0]+"</h2><p>"+steps[i][1]+"</p>";
prev.disabled=i===0;next.disabled=i===steps.length-1;
}
prev.onclick=()=>{go(Math.max(i-1,0));panel.focus()};
next.onclick=()=>{go(Math.min(i+1,steps.length-1));panel.focus()};
go(0);
</script>
</body>
</html>
```
Accessibility decisions I made:
- Native `<button>`s throughout, so Tab/Enter/Space work for free.
- Roving arrow-key navigation between steps; `aria-current="step"` marks the active one.
- `aria-live="polite"` panel announces content when it changes; Prev/Next move focus into it.
- Visible non-color focus ring (`:focus-visible`), and step state conveyed by text ("done" isn't color-only since the panel text carries meaning).
- Colors chosen for AA: `#1a1a1a` on white and white on `#005a9c` both exceed 4.5:1.
- `prefers-reduced-motion` gates the only transition; responsive flex layout works on phones.
- `lang="en"`, proper heading order, correct ʻokina in "Hawaiʻi".
Where I'm uncertain it passes:
- I have not run a contrast checker — `#005a9c` white text and the `#d40000` focus ring against white are close to the 3:1/4.5:1 lines and should be verified.
- Arrow-key stepping is a custom pattern; real screen-reader/AT testing (VoiceOver, NVDA) is needed to confirm the live region and `aria-current` announce as intended.
- The completed-step green border is decorative only; fine as-is, but I'm assuming no user relies on it alone.
- Touch target sizes look adequate but weren't measured against the 44px guideline.
- Genuinely accessible build: native buttons, aria-current, focus managementUnusually strong — the model used real semantic controls and roving arrow-key navigation rather than div-click handlers, so much of the keyboard story actually works.
- Honest uncertainty: 'I have not run a contrast checker... should be verified'It flagged the exact claims it could not stand behind — the audit-first mindset the assignment teaches, modeled by the tool itself.
- We ran the numbers: #1a1a1a on white = 17.40:1, white on #005a9c = 7.14:1, #d40000 on white = 5.53:1Every contrast claim in this output holds, and the model's own hedge — that these were 'close to the 3:1/4.5:1 lines' — was wrong in the safe direction; none of them is close. The lesson survives intact and gets sharper: the model asserted 'both exceed 4.5:1' having measured nothing, and happened to be right. A student cannot tell a lucky assertion from a checked one by reading it, which is why the audit log, not the claim, is the graded artifact.
- Untested touch-target size against the 44px guidelineNamed as unmeasured — a real failure mode on phones the student should verify on a device.
Assessment
Rubric
| Criterion | Weight | What it assesses |
|---|---|---|
| Objective measurability | 15% | The learning objective states an observable, assessable behavior. |
| Audit completeness | 35% | Keyboard, contrast, screen-reader, and reduced-motion are each checked and results recorded, not assumed. |
| Failure diagnosis | 30% | Each failure is explained in terms of the learner it excludes, not just the rule it breaks. |
| Remediation | 20% | Fixes actually resolve the flagged failures on re-test. |
What this replaces
Swapping it into a real course
Replaces
The instructional-design project submitted as a storyboard or static prototype.
What is lost
The full ADDIE-style documentation and storyboard fidelity.
What is gained
Students confront a working artifact and its real accessibility failures instead of a diagram of one; the grade rewards catching what AI generation breaks, which storyboards never expose.
Where AI is bad at this
The failure your students should catch
AI-generated interfaces look polished and fail the basics: div-based click handlers with no keyboard operability, color choices below WCAG contrast, and animations that ignore prefers-reduced-motion — and the model will assure you it 'meets WCAG AA' without having tested anything. That confident accessibility claim, unbacked by a real audit, is the specific failure a learning designer must learn to distrust.
Budget & logistics
What it costs to run
- Instructor prep1.5 hours
- Class time90 minutes
- Per-student cost$0 for the Tuesday version; roughly $5–12 per student in print or cut stock unverified for a tactile manipulative in the four-week build.
- Fabrication file dueFirst day of Week 2 — submit the tactile-manipulative fabrication file; it is a parallel artifact of the concept chosen in week 1 and need not wait for the week-3 audit. PACE quotes 7–10 business days (up to 14 calendar days), so it clears before week-4 user testing.
- Calendar dependencyThe digital build and audit need no lead time. The tactile manipulative is defined by the week-1 concept, independent of the digital module, so its file goes in at the start of week 2 and the up-to-14-calendar-day turnaround clears before week-4 user testing.
Three sizes
Scale it to the time you have
One session
The 90-minute build-then-audit session producing an audit log; no fabrication.
4 weeks
The seeded four-week plan: peer-reviewed objective, fast AI module, accessibility audit and fabrication file, then user testing both versions with outside learners.
One semester
A full design cycle — objective, AI-built module, iterated accessibility audits, a fabricated tactile version usable by a learner who cannot see the diagram, and user testing with three outside learners.
Reserved · live build
This space is intentionally empty. During the Day 8 session it will be filled in live — fill the liveBuild field in content/learning-design.json and rebuild.
Tell us what happened
Run it, then say how it went
If you try this — the 90-minute version, the prompt, any part of it — send back what you tried and what happened, especially anywhere the model was confidently wrong. That is the material the next session is built from.
Email feedback on Learning Design & Technology →
Opens a draft in your mail client, already addressed and titled. No form, no account, nothing to sign up for.