Accessible Development Toolkit

These stay available at every stage of the course. Use them before you prompt, after an agent reports back, and before you publish.

The Builder Loop

Every change you make to software, however small, goes round this loop. When something feels stuck, work out which step you are on.

1. Describe — You say what should exist, for whom, and how you will know it worked.
Write the instruction. Include context, behaviour, requirements, accessibility, constraints, scope and a definition of done.
2. Build — The AI agent makes the change you described.
Send the instruction and wait. Do not send a second instruction while the first is still being worked on.
3. Inspect — You find out what actually changed, in words, before you trust it.
Ask what changed and why. Check whether anything you did not ask about was altered.
4. Test — You use the software yourself and confirm your definition of done.
Carry out your own check with the keyboard, then check that what already worked still works.
5. Correct — You describe any difference between what you asked for and what you got.
Report the symptom, say what the correct behaviour is, and name what must not change.
6. Repeat — You save the working version and start the loop again with the next small change.
Save this as a known-good version, then describe the next single change.

The Recovery Loop

The Builder Loop is what you do when you are making something. This is what you do when something is not behaving as expected. Things going wrong is a normal part of building software, not a sign that you are not capable of it.

1. NOTICE — Something does not behave the way you expected.
Do this: Stop and say, in one sentence, what you expected and what happened instead. Do not change anything yet.
Where: Your own use of the project, and the Investigate section of the Build Lab.
Common mistake: Sending an instruction before you can say what is actually wrong.
2. REPRODUCE — You find out whether you can make the problem happen again on purpose.
Do this: Repeat the same actions in the same order. Note whether it happens every time, sometimes, or only after something specific.
Where: Your running project, plus a written list of the actions you took.
Common mistake: Assuming a problem you saw once will still be there after a change.
3. DESCRIBE — You write down expected behaviour and actual behaviour, plus the steps that cause it.
Do this: Use the Bug Report Builder. Describe the symptom, not your theory about the cause.
Where: Bug Report Builder.
Common mistake: Writing "it does not work", which cannot be acted on by anyone.
4. INVESTIGATE — You gather evidence before changing anything.
Do this: Read the errors, the recent changes, the structure of the page and the accessibility checks. Translate anything you do not understand.
Where: Investigate, Error Translator, Change History, Structure of what was built.
Common mistake: Treating a guess about the cause as though it were evidence.
5. CHANGE — You make one targeted attempt to correct the problem.
Do this: Give the AI developer the evidence you gathered, the behaviour you want, and a constraint saying what must not change.
Where: AI developer, with a debugging prompt built from your bug report.
Common mistake: Asking it to fix everything, which changes things you were not even worried about.
6. TEST — You repeat the scenario that failed.
Do this: Carry out your own reproduction steps again, exactly as you wrote them.
Where: Test it yourself, and your recorded testing notes.
Common mistake: Accepting the AI developer's report that it is fixed.
7. VERIFY — You confirm the original problem has gone and that the fix did not break something else.
Do this: Test the failing scenario, the normal scenario, keyboard operation, and anything the change could reasonably have touched.
Where: Verification status, and the "What else should I test?" list.
Common mistake: Checking only the thing that was broken, and missing the new problem next to it.
8. SAVE — Once the project is stable, you preserve that working state.
Do this: Mark the current state as stable, with a note saying what you tested. That becomes your Last Known Good.
Where: Mark as stable, in Change history.
Common mistake: Carrying on experimenting with no tested state to come back to.

Error Translator

Paste any error message, console output or failure text from any project, including ones you are building outside this course. You will get a plain-language reading of it and an honest statement of what it cannot tell you.

Bug Report Builder

Answer one question at a time and this produces a debugging instruction that asks for investigation before any change, protects what already works, and does not accept "fixed" without evidence.

Improve my prompt

Paste any instruction you are about to send to an AI builder, whether it comes from this course or from your own project. The coach reads your words and tells you what an implementer would still have to guess. It never rewrites your text unless you ask.

Sign in to use the coach here. Your instructions and the feedback are saved to your prompt history so you can compare versions later.

Prompt Quality Checklist

Answer these before you send an instruction to an AI agent.

What are we building?
Who is it for?
What should the user be able to do?
What should happen after each action?
What accessibility requirements exist?
What should the AI avoid changing?
How will we know the task is complete?

AI Change Review Checklist

Use this every time an agent reports that it finished something.

Ask the agent to describe what it changed, in plain language.
Check whether it changed anything you did not ask about.
Verify the new behaviour yourself, using the keyboard.
Check that the parts that already worked still work.
Confirm accessibility was kept, not traded away.
Save this as a known-good version before asking for more.

Project Planning Template

Fill this in before you write a single instruction.

Project name
The problem it solves
Who it is for
The three things a user must be able to do
Accessibility requirements
What is deliberately not in version one
The first five development tasks
How I will know version one is finished

Feature Breakdown Tool

Turn one feature into instructions an agent can execute one at a time.

Name the feature in one sentence.
List each thing the user does, in order.
For each step, say what should happen afterwards.
Mark which steps need saved data.
Mark which steps need a new screen.
Write one instruction per step, smallest first.

Deployment Checklist

Before you tell anyone the link.

The app works when opened in a fresh browser session.
Sign-in works for a brand new account.
No secret keys are visible in the browser.
The whole main flow works with the keyboard only.
Page titles describe each page.
You have a way to receive feedback.
You know how to roll back if the next change breaks it.

Something broke: recovery guide

Read this before asking an agent for another fix.

Stop. Do not send another fix request yet.
Write down what worked before and what changed since.
Reproduce the problem deliberately, and note the exact steps.
Capture the exact error text, word for word.
If two fix attempts have failed, roll back to the last working version instead.
Rebuild the request from the Bug Report Builder rather than repeating yourself.
Ask the agent to explain the cause before it changes anything.

Run this on anything you build. You can record results per project in your workspace.

Every action can be completed with the keyboard alone
Keyboard focus is always visible and never gets trapped
Controls are real buttons, links and inputs, not styled divs
Every input, button and control has a clear name
Headings start at level one and do not skip levels
Important changes are announced to screen readers
Errors are described in text and say how to fix the problem
No information is communicated by colour alone
Text contrast is sufficient in both light and dark themes
Images and diagrams have text alternatives
Text can be enlarged to 200 percent without breaking the layout
Reduced motion is respected and nothing auto-plays
Any audio or video has a transcript, and video has captions
Nothing requires looking at a preview to know whether it worked

Glossary of software terms

Front end: The part of an app a person interacts with directly, usually in a browser.
Back end: The part that runs away from the person's device: rules, storage and anything private.
Database: Organised storage that keeps information after the page closes.
API: An agreed way for two pieces of software to ask each other for things.
Hosting: A machine that keeps your app running so other people can open it.
Deployment: The act of publishing your current version so it is the one people see.
Component: A reusable piece of an interface, such as a task row or a sign-in form.
Function: A named set of steps that runs when something calls it.
Variable: A named place to keep one piece of information while the program runs.
Dependency: Someone else's code that your project relies on.
Git: A system that records every version of your project so you can compare or go back.
Version control: The practice of saving history deliberately so mistakes cost minutes, not days.
Environment variable: A secret setting kept outside your code, such as a key for another service.
Semantic HTML: Using the element that means what you intend, so assistive technology understands it.
Screen reader: Software that speaks or brailles what is on screen and how it is structured.
MVP: The smallest version of your idea that is genuinely useful to someone.
Bug: A difference between what should happen and what does happen.
Rollback: Returning to an earlier saved version that worked.