Review loop: generate, check, refine

Shipping a static site is not one perfect prompt. It is a loop: generate a slice of work, check it against criteria you already believe in, then refine with a targeted follow-up. Professionals sound calm about this because they document what they asked and what they changed— not because they never make mistakes.

This lesson ties together Module 03 (review checklist for HTML/CSS), Module 05 (semantics and readable structure), and Lesson 02 (prompts with acceptance criteria).

Introduction

Stopping “when it looks fine on my laptop” is how accessibility and maintenance debt appear. Stopping “when Lighthouse is green” without thinking can still miss keyboard traps—so the loop uses automation plus manual checks. The goal is risk reduction each cycle, not perfection in one shot.

Think in rounds. Round one might be rough structure; round two, contrast and focus; round three, copy and edge cases. If you try to fix everything in one prompt, you often regress something else. Smaller loops win.

The core loop in three beats

1. Generate — Ask for one scoped change (new section, fix nav, adjust heading levels) with constraints from your brief and Lesson 02.
2. Check — Run the Module 03 checklist on the result: semantic landmarks, heading order, links, images, focus, contrast at a glance.
3. Refine — Prompt with specific diffs: “Change h3 under Services to h2; leave CSS classes unchanged.”

Repeat until acceptance criteria from your brief are met—or until you consciously change the brief (scope change), which you note in writing.

Example — three-round table

Round	Issue found	Prompt fix (shape)	Re-verify
1	Missing <main>; content in anonymous wrappers	“Wrap all primary content between header and footer in <main>; do not change visible text.”	View source: single <main>; tab order still logical.
2	Two <h1> elements	“Keep one h1 only—the page title; downgrade the second to h2 and adjust CSS selectors if needed.”	Outline reads: one h1, then h2s.
3	Links styled with low contrast	“Darken --link to meet readable contrast on --bg; keep underline on hover.”	Visual check + quick Lighthouse pass locally if tools available.

Each round narrows the problem. Compare that to one prompt: “Fix all accessibility”—which invites random edits and broken layout.

When to stop

Stop when:

• Your written acceptance criteria pass, and
• You have done at least one keyboard pass (Tab through links/buttons), and
• You are not introducing new issues in the same file without noticing.

“Tired” is not a criterion. If you are tired, save, commit or copy a backup, and resume with a short checklist so you do not skip steps.

Professional tone and honesty about AI use

Document lightly for yourself: date, what you asked, what you changed by hand. You do not need a novel—bullet points suffice. This habit helps in workplaces where audit trails matter and helps you six months later when the site breaks and you forget which prompt created the hero section.

Honesty about AI use is not self-shaming. It is clarity: “Draft generated with [tool]; structure verified against our checklist; copy edited by me.” Many courses and employers care that you exercised judgement.

Merge conflicts with your own brain

Sometimes you like how something looks while the checklist says it fails—for example, a decorative heading implemented as bold paragraph text. The loop is where you decide: either change the markup to match meaning, or admit you are choosing aesthetics over access and accept the risk. For this course’s capstone, choosing failure on accessibility is choosing NS. Name the trade-off in your notes so you cannot pretend you “did not know.”

Pair review (optional but powerful)

If you have a peer, five minutes of “tab through my page and tell me where you get lost” finds issues Lighthouse might not voice clearly (confusing nav labels, vague link text). Peer review is not a replacement for your checklist; it is extra signal.

Why review matters for accessibility

Evaluate means you can name why something passes or fails:

• “Fails because headings skip from h1 to h4.”
• “Passes because nav uses a list of links and focus is visible.”

If you cannot name it, you are not done checking—you are guessing.

Practice

Task A — Your personal loop

Write a numbered checklist of at least five steps you will run every time you merge AI output into your capstone. Include at least:

• One step that references structure (headings, landmarks).
• One step that references interaction (keyboard or focus).
• One step that references verification (open in browser, or Lighthouse on deploy later).

Task B — Table practice

Draw a three-row table (on paper or in your editor) for a fictional issue: e.g. “images missing alt.” Fill in: issue → prompt fix → re-verify. Use your words.

Task C — Short reflection

In six to eight sentences, answer: What is the danger of skipping the check step and only generating new prompts when something “feels off”? Tie your answer to users (not only to grades).

Task D — Link to Lesson 01

Open your brief from Lesson 01. Under Must-haves, circle items that map to checklist items from Module 03. If any must-have has no matching check, add one sentence to your brief or to your personal loop so nothing important is forgotten.

Key takeaways

• Small generate–check–refine cycles beat mega prompts that rewrite everything.
• Module 03 checklist + Module 05 semantics literacy = your safety net.
• Documenting prompts and edits is professional and future-proof.

What’s next

Next up: Capstone alignment: what you will submit