Read the document beneath the design
A page can look polished while its structure creates problems. A large paragraph may resemble a heading, a placeholder may resemble a label, and a row of bold cells may resemble table headers. The browser needs actual relationships in the markup to expose those meanings consistently. This lab helps you notice a selected set of structural issues before moving on to visual and assistive-technology testing.
Paste a complete HTML document and choose Inspect markup. The inspector parses a copy in an isolated document, reports targeted findings, and provides an explanation for every result. It does not run scripts from your submission or send the HTML to an external service. The results are local to this page and are not stored as a published example.
Check the structure, then use the findings to improve your document.
These targeted checks inspect markup only. They do not replace HTML conformance validation, a screen reader test, or a security review.
What the checks can tell you
The document checks look for a standards-mode declaration, a language declaration, a nonempty title, a main region, and an explicit heading sequence. These are useful starting points for reviewing structure. The one-h1 recommendation is an editorial convention in this course, not a claim that every document with two h1 elements is invalid.
The relationship checks inspect duplicate IDs, simple local fragment targets, image alt attributes, basic label associations, and table captions and headers. An image with alt="" passes the attribute-presence check because an empty alternative can be correct for decoration. You still need to decide whether the image is decorative. Similarly, a label may exist while its wording remains confusing. Automated presence checks cannot settle those decisions.
The legacy check identifies a small set of obsolete elements often found in copied examples. It does not enumerate all obsolete attributes or browser extensions. Use the reference directory and a conformance checker when auditing a large inherited site.
A useful review workflow
- Start with the complete document, including head metadata.
- Run the checks and investigate every review item.
- Read the headings, labels, and link names without visual styling.
- Test the rendered page with a keyboard, at narrow widths, and with text enlarged.
- Inspect the accessibility tree and test the important journeys with assistive technology.
- Run an HTML conformance checker and resolve its errors in context.
Try a deliberate failure
Delete the label from the sample and inspect again. The control-name check should flag the email input. Restore the label, then change for="email" to for="address" while keeping the input ID unchanged. The visible words are still present, but the relationship is broken. This makes a useful distinction: visual proximity does not create a programmatic label association.
Next, duplicate the email ID on another element. The ID check should report a review item even if the page still renders. A duplicated ID can make relationships ambiguous, and different consumers may resolve the target differently. Repair the source rather than relying on the appearance of the preview.
Limits and further verification
This tool is a learning aid, not a complete HTML validator, accessibility certification, or security scanner. It does not compute CSS visibility, contrast, the full accessible-name algorithm, network behavior, browser compatibility, or server-side validation. Passing every check means the selected rules passed against the parsed source. It does not mean the whole document is correct.
Browsers repair some malformed HTML while parsing. That can produce a plausible tree even when the original source violates a content model. A conformance checker examines rules this lab intentionally does not implement. Keep the original source, the parsed DOM, and the rendered interface in view as three related but different things.
W3C Nu HTML Checker · WHATWG HTML Living Standard · Practice with coding challenges