LessonLesson 33 of 34

Debug HTML with evidence: source, DOM, network, and focus

Use a repeatable diagnostic workflow to solve broken paths, parser repairs, missing form values, and inaccessible interactions.

Advanced5 min readLearn · Practice · Review

Published by HTML Code Runner · AI-assisted material · Independent editorial review pending · Editorial policy

On this page

Learning objectives

Separate source defects from runtime changes; inspect resource requests; reduce a problem to a small reproducible case.

Prerequisites

Read document structure, links, forms, and accessibility. Open browser developer tools.

Start with an observable failure

Describe the problem in terms another person can reproduce: the image fails only on the deployed page, the form omits the selected topic, or the menu cannot be closed with a keyboard. Record the URL, browser, action sequence, expected result, and actual result. A precise report narrows the search more effectively than repeatedly changing unrelated code.

Confirm that you are editing and viewing the same file or deployment. Reload with an appropriate cache strategy and inspect the response. A stale stylesheet, cached HTML page, or different document root can make a correct edit appear ineffective. Avoid clearing every setting blindly; identify which resource is stale.

Use the right inspection surface

View source shows the delivered HTML. The Elements panel shows the parsed and possibly script-modified DOM. If a paragraph unexpectedly ends before a nested container, check the content model and parser repair. If an element appears only after a click, inspect the script that inserted it. These are different causes and need different fixes.

The Network panel reveals requested URLs, status codes, content types, timing, and redirects. A broken image may be a case-sensitive filename mismatch, a relative-path error, a blocked request, or an HTML error response returned with status 200. Check the actual response instead of guessing from the icon.

The Console exposes script errors and security-policy messages. Fix the earliest relevant error first; one missing element can stop a script before later controls are initialized. Security restrictions such as CSP or sandbox policies are deliberate boundaries. Adjust them only when a required capability has been justified, not as a general debugging shortcut.

Inspect semantics and successful controls

For a form, inspect each control’s name, value, disabled state, type, and form owner. A visible input without a name is not included as a named entry. Unchecked checkboxes and disabled controls are commonly absent. A button outside the form may need an explicit form association. The visual arrangement alone does not determine submission membership.

For keyboard problems, follow focus with Tab and Shift+Tab and inspect which element actually receives it. A click handler on a div does not provide native button behavior. Positive tabindex values can create surprising order, while a hidden overlay can intercept pointer events or leave focus behind the visible interface.

Reduce the page to the smallest example that still fails. Remove unrelated CSS and scripts, then add them back deliberately. A small reproducible case makes specification checks, browser comparisons, and peer review much more effective.

Working example

<form id="search-form">
<label for="query">Search catalogue</label>
<input id="query" name="q" type="search" value="gardening">
<button type="submit">Search</button>
</form>
<p id="debug-output" role="status"></p>

Another example

<!-- Incorrect nesting: the parser closes p before div. -->
<p>Opening information<div>Tuesday to Saturday</div></p>

<!-- Correct structure. -->
<div><p>Opening information</p><p>Tuesday to Saturday</p></div>

Expected output

The live example displays the named form value locally instead of navigating. The nesting comparison should be inspected in developer tools: the incorrect source produces a repaired tree that differs from the author’s apparent nesting.

Common mistakes

Do not assume a 200 response contains the expected resource. Do not fix every symptom with !important. Do not disable all security policies to make an embed work. Do not treat an inaccessible click-only control as a CSS problem.

Accessibility and browser notes

Include the accessibility tree in debugging. A visible label may not be associated with its input, and a decorative icon may become an unwanted accessible name. Verify the computed relationships and then test the actual interaction.

Practice

A field is visible and editable, but its value is missing from submission. Write the first four properties you would inspect and fix a field that has only an ID.

Review the solution and reasoning
<label for="topic">Topic</label>
<input id="topic" name="topic" type="text">

Inspect name, disabled state, form ownership, and the type’s successful-submission behavior. Adding a name fixes the shown defect, but a complete diagnosis still verifies that the control belongs to the submitted form and is not disabled.

Related lessons

Specifications and further reading

One more skill in your toolkit.

Finished the explanation and exercise? Save your progress.