Review a generated page before you trust it

A generated Harbor Ledger home page can look finished in a desktop screenshot and still hide the price under a sticky header on a phone. Start with the brief's question order, then open the rendered page. Do not score the agent's explanation. W3C's Easy Checks say a few checks can show whether accessibility was considered at all, and that a page can pass those checks and still have serious barriers. Use them as a start. This guide's worked defect is a teaching example. It is not a test that was run against a deployed Harbor Ledger site, because that company is fictional.

At a 390 × 844 px viewport, the fictional page stacks the headline, then a full-width photograph, then the $89 price, then the button. The photograph is 720px tall, so the price and the button sit below the first screen. The desktop order had the price beside the headline. The phone order answered 'what does the room look like?' before 'what does this cost?' The correction is to stack headline, who it is for, price, and button first, and to place the photograph after that stack. The photograph's brief still applies. It does not earn the top of the phone page by being large.

Easy Checks asks you to set the mouse aside and tab through links, buttons, and fields. You should reach every control, leave every control, see where focus is, and find no trap. On the Harbor Ledger example the call button is a link to a form. Tab order should reach it after the skip link and the navigation, not after a decorative image that was given a tabindex. Visible focus can be a ring using the existing --accent. If focus is only a color change that disappears into the green button, add a ring. The Easy Checks page points at WCAG 2.1 contrast guidance of at least 4.5:1 for normal-size text. Check the price against the page background, not against a mock.

The call form needs a visible label for name, email, and the question 'what do you want handled each month?' A placeholder is not a label. Submit it empty and read the error. The error should say which field failed and should not clear the fields that were valid. Easy Checks notes that an error shown only by turning a label red fails people who cannot see that color. If the generated form has no error text, that is a defect even when the inputs look aligned. Fix the text and the association before you adjust margins.

Every informative image needs alt text that matches its job. The kitchen-table photo's alt can be 'Laptop and invoices on a kitchen table.' A decorative divider gets an empty alt attribute. Check heading order, form labels, accessible names, keyboard use, focus visibility, and text alternatives. Iter0 also uses one h1 per page as a house convention so the main page topic is easy to identify. A bold div that looks like a heading and is not marked up will not show in a heading outline. Easy Checks describes that failure. Look at the heading outline as well as the font size.

Record the full viewport, browser or device, 100% zoom, page state, and capture date. Then write the defect, the correction, and what you rechecked. For the example: 390 × 844 px, signed out with no banners or dialogs, price below a tall image, moved the price and button above the image, and rechecked that the desktop row still shows the price. Leave a blank row for the keyboard check if you have not done it. If you tested only a width, describe the content order instead of claiming what appeared before scrolling. A procedure you have not run on your own page is still a checklist, not evidence that your page passed.