Ten tests that probe whether the HTML output actually works — not just "does it look different" (that's Design Diversity) but "does the page render correctly, is it accessible, responsive, does the form validate, does dark mode work, does it respect reduced motion, and are error states handled?" Open each result in a browser and inspect.
The verify step is you, in a browser, inspecting the rendered page. Each test lists specific things to check — contrast ratio, keyboard navigation, responsive breakpoint, form behavior. Use the browser's DevTools (F12) to verify. Tasks must produce self-contained .html files.
Setup
Start an Aperio server, paste the prompt, save the rendered HTML, and open it in a browser. Use DevTools to verify.
npm run start:local
# Paste prompt into chat
# Open the resulting HTML in a browser
The Tests
Task 1 — Semantic Structure
Accessible Page Shell ★☆☆☆☆
Probes: landmarks, heading hierarchy, alt text, DOCTYPE
Paste thisBuild a self-contained HTML page for a personal blog. It must have:
- A header with site title and navigation links (Home, Articles, About, Contact)
- A main content area with at least one article (heading, date, body text, an image with alt text)
- A sidebar with recent posts
- A footer with copyright info
- Use semantic HTML5 elements (header, nav, main, article, aside, footer)
- One h1, proper heading hierarchy (no level skips)
- Every interactive element must have visible :focus-visible styling
- The navigation must use
What to evaluate
View page source — are semantic elements used (header, nav, main, article, aside, footer)?
Is there exactly one h1?
Tab through — does every link/button get a visible focus ring?
Does the image have alt text?
Does the page have a proper <!DOCTYPE html> and viewport meta tag?
Result:
Task 2 — Responsive Design
No Horizontal Scroll at 360px ★★☆☆☆
Probes: flex/grid layout, relative units, max-width on media
Paste thisBuild a product listing page for a small online store. Requirements:
- A responsive grid of 6 product cards (image, name, price, add-to-cart button)
- 3 columns on desktop, 2 on tablet, 1 on mobile (360px)
- NO horizontal scroll on the body at any width
- Use CSS Grid or Flexbox — no float-based layouts
- Images must have max-width: 100%
- Use relative units (rem, %, vw) not fixed pixels for widths
- At least 44px touch targets on all buttons
What to evaluate
Resize to 360px — is there horizontal scroll on the body?
Does the grid change from 3 → 2 → 1 column at appropriate breakpoints?
Are touch targets at least 44×44px?
Do images scale down without overflow?
Result:
Task 3 — Form Validation
Validated Signup Form ★★★☆☆
Probes: required fields, input types, error messages, success state, no color-only state
Paste thisBuild a signup form page with the following fields:
- Full Name (required, min 2 chars)
- Email (required, must be valid email format)
- Password (required, min 8 chars, must include a number)
- Confirm Password (required, must match)
- A "Subscribe to newsletter" checkbox
- A submit button
Requirements:
- Client-side validation with meaningful error messages shown near each field
- Error state must NOT be conveyed by color alone — include text or icon indicators
- Success state when all fields pass validation
- Focus must move to the first invalid field on submit
- All labels must be properly associated with inputs (use label elements)
- Use aria-invalid and aria-describedby for accessibility
- Self-contained single HTML file
What to evaluate
Submit empty — do error messages appear near each field?
Enter invalid email — does it reject it with a message?
Enter mismatched passwords — does it show the mismatch?
Are errors conveyed by text, not just red borders?
Does focus move to the first invalid field?
Fill correctly — does the form show a success state?
Paste thisBuild a page with a data table of 15 imaginary employees (Name, Department, Role, Salary, Start Date). Must have:
- A search input that filters rows as you type
- Sortable columns — click a column header to sort ascending, click again to sort descending
- Table must scroll horizontally on narrow screens (within an overflow-x: auto container)
- Use proper table markup (table, thead, th, tbody, tr, td)
- Sortable column headers must be buttons with visible focus styles
- Show the current sort direction with an arrow indicator
- Display a "No results" message when the search filters out all rows
What to evaluate
Type in search — do rows filter in real time?
Click a column header — does sorting work? Does it toggle direction?
Resize narrow — does the table scroll horizontally without breaking the page?
Type something that matches nothing — does "No results" appear?
Paste thisBuild a documentation-style page that supports both light and dark modes:
- Title: "Aperio API Reference"
- 3 sections of API documentation (each with a heading, description, and a code sample)
- A sidebar with navigation links to each section
- Must respect the user's system color scheme via prefers-color-scheme media query
- Body text must maintain 4.5:1 contrast ratio in BOTH themes
- Code samples must have a distinct background in both themes
- Use CSS custom properties for all theme colors (no hardcoded colors in element rules)
- Include a small manual theme toggle button as a fallback
- Transition between themes smoothly (0.3s ease on color/background properties)
What to evaluate
Toggle system theme — does the page switch correctly?
Check contrast in both themes (DevTools → select element → color contrast checker)
Does the manual toggle work and override the system preference?
Are code blocks readable in both themes?
Result:
Task 6 — Motion Safety
Respect prefers-reduced-motion ★★★☆☆
Probes: prefers-reduced-motion, animation safety, no decorative motion
Paste thisBuild a landing page for a product launch with animations:
- A hero section with a fade-in title animation (opacity 0→1 over 1s)
- A count-up number animation (0 to 10,000 over 2s) showing "Users"
- Cards that slide up on scroll with a staggered delay
- A pulsing CTA button
Requirements:
- ALL animations must be disabled or reduced when prefers-reduced-motion is active
- Use the CSS prefers-reduced-motion media query, not JavaScript
- The page must be fully usable with motion disabled (no content hidden by animation state)
- Animations must be purely decorative — no information conveyed through motion alone
- Use will-change and transform for performant animations
- Self-contained HTML file
What to evaluate
Enable prefers-reduced-motion in DevTools — do all animations stop?
Disable it — do animations work correctly (fade, count-up, slide, pulse)?
Is all content visible and readable with motion disabled?
Are animations performant (no layout thrashing)?
Result:
Task 7 — State Handling
Empty, Error, and Loading States ★★★☆☆
Probes: async data simulation, error UI, empty state messaging, loading indicator
Paste thisBuild a dashboard page that simulates fetching data from an API. It must handle three states:
1. Loading state: Show a loading spinner while "data is fetching" (simulate with setTimeout)
2. Empty state: If the simulated data returns an empty array, show "No data available" with an illustration or icon and a "Refresh" button
3. Error state: If the simulated fetch fails (randomly, 30% of page loads), show "Something went wrong" with an error icon, a descriptive message, and a "Try again" button
4. Success state: 5 sample data rows in a simple card layout
Use JavaScript that simulates fetching (setTimeout + random Math.random() for failure). Each state must be visually distinct and informative. Use proper ARIA live regions for loading and error announcements.
What to evaluate
Reload 3–4 times — do you see all three states (loading, success, error)?
Is the loading state visible (not a flash)?
Is the error state helpful (message + retry button)?
Is the empty state informative (message + refresh button)?
Paste thisBuild an FAQ page with an accordion component:
- 6 questions and answers about "Aperio"
- Clicking a question expands the answer and collapses any other open answer
- Clicking the same question collapses it
- Must be fully keyboard accessible — Enter/Space to toggle, Tab between questions
- Use aria-expanded on the toggle button, aria-controls linking to the answer panel
- Animate the expand/collapse smoothly (max-height transition, not display: none)
- Critical: Honor prefers-reduced-motion — disable the animation
- Include a "Expand All" / "Collapse All" button at the top
- Self-contained HTML
What to evaluate
Click a question — does it open and close others?
Tab through and press Enter/Space — does keyboard toggling work?
Check aria-expanded in DevTools — does it update correctly?
Enable prefers-reduced-motion — do animations stop?
Does "Expand All" / "Collapse All" work?
Result:
Task 9 — Async Form Submission
Contact Form with Loading/Error/Success ★★★★☆
Probes: async submit simulation, disabled state during loading, timeout handling
Paste thisBuild a contact form that simulates async submission:
- Fields: Name (required), Email (required, valid), Subject (required), Message (required, min 20 chars)
- On submit: show a loading spinner on the button, disable all inputs
- Simulate a 2-second API call using setTimeout + Promise
- 80% chance of success: show green success banner "Message sent!" with a checkmark
- 20% chance of failure: show red error banner "Failed to send. Please try again." with retry button
- On success, reset the form after 3 seconds
- On failure, re-enable the form for retry (do NOT clear the user's input)
- All validation messages must use aria-live="polite" for screen reader announcements
- Button must show "Sending…" with a spinner during loading, and be disabled
What to evaluate
Submit valid form — does it show loading, then success banner, then reset?
Submit multiple times — do you eventually see the 20% error state?
On error — are the user's inputs preserved?
Is the button disabled during loading?
Are aria-live regions used?
Result:
Task 10 — Comprehensive Page
Full Page with All Quality Bar Checks ★★★★★
Probes: all quality bar items simultaneously, no regressions
Paste thisBuild a complete landing page for "Aperio" — an AI memory layer product. This page must pass ALL of the following checks simultaneously — do not skip any:
1. Semantic HTML: header, nav, main, section, footer, one h1, no level skips, proper landmarks
2. Contrast: 4.5:1 body text minimum, never convey state by color alone
3. Focus: visible :focus-visible on every interactive element, logical tab order
4. Responsive: no horizontal scroll at 360px, flex/grid layout, relative units
5. Touch targets: 44×44px minimum
6. Images: alt text on every meaningful image
7. Dark/Light mode: support prefers-color-scheme with CSS custom properties
8. Reduced motion: honor prefers-reduced-motion
9. Form: at least one form (email signup) with validation, error states, aria-invalid
10. Interactive: at least one interactive component (accordion, tabs, or modal) with full keyboard support and ARIA attributes
Design direction: modern, dark theme as default, purple/navy accent, professional SaaS feel. Self-contained HTML file.
What to evaluate
Run through all 10 checks above — how many pass?
Check each check individually with DevTools and browser inspection
Any one failure means the task fails — all 10 must pass for a Pass score
Result:
Scoring Rubric
Signal
0 = fail
1 = pass
HTML is self-contained
depends on external CSS/JS not loaded
opens directly in a browser
Semantic markup
div soup, no landmarks, heading level skips
proper elements, correct hierarchy
Accessibility
no focus styles, color-only states, missing labels
N/A — task requires a feature that isn't applicable in your testing setup.
Unlike Design Diversity (which tests aesthetic variation), this suite tests whether the varied output actually works.
A model that passes Tasks 1–3 but fails 4–10 can build basic static pages but not interactive/stateful ones.
What the Results Mean
← Your result
9–10/10
Production-ready frontend. The model produces semantic, accessible, responsive pages with proper form validation, theme support, motion safety, and error state handling. Trust it for user-facing interfaces.
← Your result
7–8/10
Strong frontend skills. Handles semantic structure, forms, and responsive design. May miss reduced-motion support, lack aria attributes, or have incomplete error states. Good for most pages with manual QA.
← Your result
4–6/10
Moderate ability. Can produce basic responsive pages but struggles with interactive components (accordions, async forms) and edge states (empty, error, loading). Review accessibility carefully.
← Your result
1–3/10
Limited frontend ability. May produce a basic HTML page with broken or missing interactive features. Not reliable for user-facing production work.
← Your result
0/10
Cannot produce working frontends. The HTML output has fundamental issues — broken layout, no interactivity, or inaccessible markup.