Debug and Review a Complete Page

Introduction

This is the final lesson of chapter 4, aligned with course 4 of the Meta Front-End Developer pathway ("HTML and CSS in Depth"). You have learned forms, semantics, layout, states and motion. Real work now looks like this: a page exists, something is wrong, and you must find out why quickly and prove the fix. This lesson teaches a systematic method with browser DevTools, then shows how to review a whole page against an objective acceptance checklist instead of "it looks fine to me."

The principle running through the lesson: test observable behavior, not visual guesses. "The button looks centered" is a guess. "The button's bounding box is centered within a 360 px viewport, its accessible name is 'Book seats', and Tab reaches it" is evidence. The practice scenario is original: you audit the Harbor Workshops landing page against a concrete checklist.

Learning objectives

1. Use the Elements/Inspector panel to read the DOM, computed styles, the box model, and the cascade.
2. Diagnose layout bugs: overflow, collapsed heights, unexpected stacking, and specificity conflicts.
3. Use responsive/device mode and throttling to test small screens and slow networks.
4. Read the Network panel: status codes, sizes, caching, and failed requests.
5. Use the Console and Sources panels for errors and basic breakpoints.
6. Check metadata, media, and form validation systematically.
7. Run accessibility checks: keyboard, accessibility tree, contrast, automated tools.
8. Write an acceptance checklist whose items are objectively verifiable.

1. A debugging method

Random edits waste time. Use a loop:

1. Reproduce. Write down exact steps, browser, viewport size, and expected versus actual result.
2. Isolate. Find the smallest piece of HTML/CSS that shows the bug. Disable rules in DevTools one at a time.
3. Hypothesize. State a cause that makes a prediction ("the card is wider than 360 px because of a fixed width: 400px").
4. Test. Change one thing in DevTools and see whether the prediction holds.
5. Fix in the source, not only in DevTools. DevTools edits vanish on reload.
6. Verify and guard. Re-run the steps, check other sizes and browsers, and add a note or test if the bug could return.

2. Inspecting the DOM and CSS

Open DevTools with F12, Ctrl+Shift+I (Cmd+Option+I on macOS), or right-click then Inspect. Names differ slightly (Chrome and Edge: Elements; Firefox: Inspector), but the capabilities match.

Elements and Styles

• Select an element to see its rules from most to least specific. A declaration with a line through it was overridden (by specificity or order) or is invalid; invalid ones show a warning icon.
• Tick or untick checkboxes to disable declarations and watch the effect.
• Add a temporary declaration with the + icon, or edit a value with the arrow keys.
• The Computed tab shows the final value of each property and which rule supplied it. Use it to answer "which rule won?"

The box model diagram

The Styles/Layout pane draws content, padding, border, and margin with numbers. Check it when spacing is off: is the gap from padding, margin, or a gap property? Hover over elements in the DOM tree to highlight them on the page and reveal sizes.

Flexbox and Grid overlays

Elements that use display: flex or grid show a badge in the DOM tree. Click it to overlay track lines, gaps, and item sizes. This quickly shows why a grid has an extra empty column or why a flex item refuses to shrink.

Finding the element that overflows

When a page scrolls sideways, test in the Console:

// List elements wider than the viewport
[...document.querySelectorAll('*')]
  .filter(el => el.getBoundingClientRect().right > document.documentElement.clientWidth)
  .map(el => el.tagName + '.' + el.className);

Or temporarily outline everything in the Styles pane with * { outline: 1px solid red; } and look for the box that sticks out. Then fix the cause (a fixed width, an image without max-width, a long word in a flex item) rather than adding overflow-x: hidden.

Common layout symptoms and causes

3. Responsive and compatibility checks

Device mode

Toggle the device toolbar (Ctrl+Shift+M) to resize to presets or custom widths, change the device pixel ratio, and simulate touch. Check at least 320, 375, 768, 1024, and 1440 px, plus every width where your breakpoints change (test just below and just above, such as 767 and 768). Drag slowly across the whole range as well: the bugs often hide between standard sizes.

Also test:

• Text zoom to 200% (browser zoom or larger default font size): nothing should be clipped or overlap, and no horizontal scroll should appear at a 320 px wide viewport.
• Landscape orientation on phones.
• Print preview when the page might be printed.
• Dark mode and forced colors if your design supports them (DevTools "Rendering" panel emulates media features such as prefers-reduced-motion and prefers-color-scheme).

Cross-browser checks

Emulation is not the real thing. Before release, open the page in current Chrome/Edge, Firefox, and Safari, and on at least one real phone. When something differs, look up the property on MDN: its compatibility table shows support per browser and the Baseline label (widely available, newly available, or limited availability). If support is limited, use a fallback or @supports.

4. Network and performance

The Network panel lists each request: URL, status code, type, size, time, and caching.

Look for:

• Broken paths. A missing image (404) or stylesheet explains a page that "lost its styles" in production only. Relative paths like images/a.jpg and /images/a.jpg resolve differently.
• Large files. A 4 MB hero photo should be resized and compressed, served with srcset, and use a modern format.
• Blocking resources. CSS in the <head> and scripts with defer avoid blocking rendering.
• Throttling. Select a "Slow 4G" profile to feel what a mobile visitor sees; check that content appears progressively and layout does not jump.
• Cache disabled while DevTools is open: tick Disable cache to avoid being fooled by stale files, and remember that real users do cache.

Lighthouse (in DevTools or via the command line) produces a report for performance, accessibility, best practices, and SEO. Treat it as a starting point: the score does not replace manual testing, but its list of audits (image sizes, contrast, missing alt text, missing meta description) is a free checklist.

Web performance metrics worth knowing: Largest Contentful Paint (when the main content appears), Cumulative Layout Shift (how much content moves unexpectedly), and Interaction to Next Paint (responsiveness to input). Setting image dimensions, avoiding late-loading banners and loading fonts sensibly improve them.

5. Console and Sources

The Console shows errors, warnings, and your own console.log output. Red errors such as Uncaught TypeError: Cannot read properties of null or Failed to load resource: 404 tell you where to look. Warnings from the browser about forms (for example "Password field is not contained in a form") or mixed content (http resources on an https page) are also actionable.

In Sources (Debugger in Firefox) you can set a breakpoint on a line, reload, and step through code, inspecting variables. For event-driven bugs, Event Listener Breakpoints pause on click or submit. You will use this much more in the JavaScript and React chapters, but even a static page benefits when a form submit handler misbehaves.

6. Page review: metadata, media, forms

A page is more than what you see. Review these layers:

Metadata

<title>Pottery for Beginners | Harbor Workshops</title>
<meta name="description" content="A relaxed Saturday pottery class: shape a bowl, glaze it, and take it home. Ages 16 and over.">
<link rel="canonical" href="https://example.org/workshops/pottery">
<meta property="og:title" content="Pottery for Beginners">
<meta property="og:description" content="Shape a bowl and take it home.">
<meta property="og:image" content="https://example.org/img/pottery-og.jpg">
<meta name="viewport" content="width=device-width, initial-scale=1">
<html lang="en">

Check: a unique, descriptive <title> on every page; a meta description; lang on <html>; a canonical URL when the same page can be reached several ways; Open Graph tags if the page is shared; a favicon. Validate by viewing source, not just the rendered page.

Media

• Every <img> has alt (descriptive or empty if decorative), width and height.
• Sizes are appropriate; below-the-fold images use loading="lazy"; the main hero does not.
• Videos have captions or a transcript; autoplay is off or muted with controls.
• Text is not baked into images.

Forms

• Each control has a label, name, correct type, and autocomplete.
• Submit with empty, invalid, and valid values and compare with the expected message.
• Error text is announced (linked with aria-describedby, or a live region).
• Tab order follows visual order; Enter submits; focus lands somewhere sensible after an error.

Accessibility

• Keyboard only: unplug the mouse. Every link, button, and field must be reachable and operable, focus must be always visible, and there must be no keyboard trap. A "skip to content" link helps on long headers.
• Accessibility tree: the Accessibility pane shows the name, role, and state that assistive technology receives. A button with an empty name (an icon-only button without text or aria-label) is a defect.
• Contrast: DevTools shows the contrast ratio in the color picker. WCAG AA asks for at least 4.5:1 for normal text and 3:1 for large text and interface component boundaries.
• Headings: one h1, no skipped levels. Landmarks present.
• Automated tools (Lighthouse, axe DevTools, WAVE) catch roughly a third to a half of problems. They cannot judge whether alt text is meaningful or the reading order makes sense, so combine them with manual checks and, when possible, a screen reader pass (NVDA, VoiceOver).

7. Test observable behavior

Visual inspection is subjective and unrepeatable. Replace guesses with checks that anybody can repeat and that could later be automated:

In the Console you can run quick assertions:

// 1. No horizontal scroll
document.documentElement.scrollWidth <= window.innerWidth;                     // expect true
// 2. Images missing alt
[...document.images].filter(i => !i.hasAttribute('alt')).length;               // expect 0
// 3. Controls without an accessible label
[...document.querySelectorAll('input:not([type=hidden]), select, textarea')]
  .filter(c => !c.labels.length && !c.getAttribute('aria-label')).length;      // expect 0

In the JavaScript chapters you will turn such checks into automated tests with Jest, and in the React chapters into component tests with React Testing Library, which query the page the way a user (and assistive technology) does: by role, label, and text.

8. Writing an acceptance checklist

An acceptance criterion is specific, observable, and has a clear pass or fail. Compare:

• Weak: "The page works on mobile."
• Strong: "At 320 px wide there is no horizontal scrollbar, the Book button is at least 44 by 44 CSS pixels, and all text is readable without zooming."

A good checklist groups items (layout, content, forms, accessibility, performance, metadata), records the browser and viewport, and ends with who tested and the date. Items should be independent so that one failure does not hide others.

Worked example: audit the Harbor Workshops landing page

Brief. The landing page is going live tomorrow. Audit it against the checklist and report defects with evidence.

Checklist (excerpt):

1. No horizontal scroll at 320, 375, 768, 1440 px.
2. Title and meta description present and unique.
3. All images have alt, width, height.
4. Booking form: labels, native validation, error text.
5. Keyboard: every control reachable, focus visible.
6. Contrast of body text at least 4.5:1.
7. No failed requests in Network.

Step 1: layout at 320 px. In device mode, set 320 px. A horizontal scrollbar appears. Run the console snippet: it returns DIV.hero-banner. In Styles: .hero-banner { width: 100vw; padding: 0 2rem; }. 100vw plus padding exceeds the viewport (and 100vw includes the scrollbar on desktop). Hypothesis: change to width: 100% with box-sizing: border-box (or remove the width, since block elements fill their container). Test in DevTools: scrollbar gone. Fix in the source.

Step 2: metadata. View source: the <title> is "Document" and no description exists. Defect. Fix with the title and description above.

Step 3: images. The console count of images without alt returns 2. Inspect: the logo and a decorative wave. The logo needs alt="Harbor Workshops"; the decorative wave should have alt="". Network shows hero.jpg at 3.8 MB. Defect: resize, compress, and add srcset.

Step 4: form. Submit empty. The browser shows a native tooltip, but a custom error paragraph is not linked to its field. Defect: add aria-describedby. Tab order is correct.

Step 5: keyboard. Tab from the top: the first focus ring is invisible on the nav links. Inspect: a:focus { outline: none; } in reset.css. Defect: replace with a:focus-visible { outline: 3px solid #ffbf47; outline-offset: 2px; }.

Step 6: contrast. The date text #9aa5b1 on white reports 2.5:1. Defect: darken to #4b5560 (above 7:1).

Step 7: network. One 404: /img/pottery-og.jpg, referenced in og:image. The file is named Pottery-OG.jpg; the live server's file system is case-sensitive. Defect: fix the name.

Report. Seven checks, six defects, each with element, evidence, expected result, and fix. Re-run the full checklist after fixes. Why this method? Each finding is reproducible and verifiable by someone else. A casual look at the desktop layout would have caught none of the keyboard, contrast, metadata, or network problems.

Common pitfalls

• Editing in DevTools and forgetting to change the source.
• Testing only one browser or only on a fast desktop connection.
• Trusting emulation without a real device check.
• Hiding overflow instead of finding the cause.
• Treating a Lighthouse score as proof of accessibility.
• Cached files hiding a fix or a bug; test with cache disabled and in a private window.
• Case-sensitive file names that work on Windows or macOS but 404 on Linux servers.
• Checking only widths of popular devices and missing bugs between them.
• Vague acceptance criteria ("looks good") that cannot fail.
• Fixing several things at once so you cannot tell which change worked.

Exam tip: When asked how to find why a style is not applied, choose inspecting the element and reading the Styles/Computed panes (struck-through rules, specificity) over rewriting the CSS. When asked how to verify responsiveness, choose resizing across a range and checking for horizontal scroll rather than testing a single "mobile" size. When asked to verify accessibility, a correct answer includes keyboard testing, not only an automated score.

Mini case study: it works on my machine

Situation. After deployment, the Harbor Workshops page has no images and no styling on the production site, though it looked perfect locally. The Network panel on production shows styles/Main.css and several images with status 404. The project folder contains styles/main.css and images/hero.jpg. The HTML contains <link rel="stylesheet" href="styles/Main.css"> and <img src="/Images/hero.jpg">. The developer works on Windows; the server runs Linux.

Questions. (1) What is the cause? (2) How do you verify it? (3) What prevents it from returning?

Solution.

1. File names on the Linux server are case-sensitive (Main.css ≠ main.css, Images ≠ images), while Windows ignores case. The paths in the HTML do not match the real names.
2. The Network panel shows the requested URL and the 404 status. Request the correctly-cased URL directly in the browser and confirm it returns 200. After fixing the HTML, reload with cache disabled and confirm every request is 200.
3. Adopt a lowercase naming convention for files, add a check (a link checker or a simple script run in CI) that fails on missing files, and test on an environment that matches production before release.

Key terms

• DevTools: the browser's built-in developer tools.
• Computed style: the final value of a property after the cascade.
• Device mode: DevTools emulation of screen sizes, pixel ratio, and touch.
• Throttling: simulating a slower network or CPU.
• Lighthouse: an auditing tool for performance, accessibility, best practices, and SEO.
• Accessibility tree: the representation of the page given to assistive technology.
• Contrast ratio: the luminance ratio between text and its background.
• Layout shift: unexpected movement of page content while loading.
• Acceptance criterion: an observable, pass/fail condition for a feature.
• Baseline: a label summarizing how widely a web feature is supported across major browsers.

Summary checklist

• I follow a loop: reproduce, isolate, hypothesize, test, fix in source, verify.
• I read the Styles and Computed panes to find which rule wins.
• I use device mode across a range of widths, including the width at each breakpoint.
• I find the element causing overflow rather than hiding it.
• I read status codes and sizes in the Network panel and check case-sensitive paths.
• I check title, description, lang, canonical, Open Graph, and favicon in the source.
• I verify alt text, image dimensions, and appropriate image sizes.
• I test forms with empty, invalid, and valid input, and with the keyboard alone.
• I check contrast and the accessibility tree and know automated tools are not enough.
• I write acceptance criteria that are specific and observable.

Official sources

• Meta Front-End Developer Professional Certificate (opens in a new tab)
• Course 4: HTML and CSS in Depth (opens in a new tab)
• Chrome DevTools documentation (opens in a new tab)
• Firefox Source Docs: DevTools user docs (opens in a new tab)
• MDN: Debugging HTML (opens in a new tab)
• MDN: Cross browser testing (opens in a new tab)
• W3C WAI: Easy checks, a first review of web accessibility (opens in a new tab)
• web.dev: Core Web Vitals (opens in a new tab)