THE CHECKLIST
THE DEMO FORGOT.
A plain-language review that separates “the button responds” from “the product deserves trust.” These prompts are not a substitute for specialized testing when stakes rise.
Download the Field Guide ↓Before checking anything
Write down the actual task, intended audience, data handled, possible harm if incorrect, and who will maintain it. A harmless demonstration of project cards is not held to exactly the same controls as a real medical system or payment service.
Does a person understand it?
- The main task is clear before scrolling or watching an animation.
- At least one new visitor can complete the main task without explanation.
- Errors name the problem and suggest a useful way to recover.
- Empty, loading, failed and completed states are visible and truthful.
Does the rule survive input?
- Try normal, missing, unusual and adversarial inputs; record expected versus observed behaviour.
- Read the actual source, list dependencies and confirm their provenance.
- Hard-coded values, surprising conversions and assumptions are identified.
- There is a clear repair/rollback owner and recovery path.
Can different people use it?
- Every essential action works with Tab, Shift+Tab, Enter and Space as applicable.
- Forms have labels, focus is visible and dynamic feedback is announced appropriately.
- The layout works at narrow widths and large text/zoom without hiding essential controls.
- Motion can be reduced and does not block reading or completion.
Compare against WCAG 2.2. A checklist tick does not establish formal conformance.
Where does the information go?
- Every network request and third-party service has a purpose and an owner.
- No passwords, private API keys or sensitive tokens are shipped in public source files.
- If a server exists, authentication, authorization and validation are implemented server-side.
- No claims of security, privacy, SEO ranking or accessibility are made without evidence.
Read the OWASP Top 10:2025 for systemic risks; a tiny static demo is not the whole web.
Who answers after launch?
- README describes setup, files, limitations, ownership and how to change something safely.
- Test notes distinguish passed checks, failures and checks not performed.
- Assets, source, licenses and deployment configuration are preserved.
- Users can report broken links, inaccessible interactions and real errors.
Completion is not perfection.
A responsible release can have limitations. The difference is whether they are known, proportionate, disclosed and revisable. Treat the next real visitor as information, not as an obstacle to your demo.
MAKE THE WORK TESTABLE.
Use the interactive workshop to see how a single assumption changes the experience.