Browser Developer Tools, Debugging, and Accessibility Auditing

Browser Developer Tools: Your Daily Workshop

Every modern browser ships with a built-in set of diagnostic tools called DevTools. In Chrome, open them with F12 or right-click any element and choose Inspect. Firefox DevTools work almost identically and serve as a useful cross-browser check. DevTools are non-destructive when used in the browser window—changes you make there do not touch your actual files unless you copy them out. Always save your working edits to a permanent stylesheet or script before closing the browser.

The Sources Panel: Debugging JavaScript

The Sources panel is where you debug JavaScript. It shows all scripts loaded by the page and lets you pause execution at any line using breakpoints. Click the line number in the Sources panel to set a breakpoint. When the browser reaches that line, execution pauses and you can inspect the current value of every variable in scope.

Once paused, use the four control buttons:

• Resume (F8) — continue running until the next breakpoint.
• Step Over (F10) — execute the current line and pause on the next one, without stepping into called functions.
• Step Into (F11) — follow execution inside a function call.
• Step Out (Shift+F11) — finish the current function and return to the caller.

The Scope pane on the right shows local and global variables live. Hover over any variable in the code to see its current value. The Call Stack pane shows which functions called each other to reach the current point—useful when a bug originates several levels deep.

Three common bug types you will encounter:

1. Undefined variable reference — a variable is used before it is declared or is misspelled. The console shows `ReferenceError`. Set a breakpoint before the error line and check variable names in the Scope pane.

2. Incorrect selector — `document.querySelector()` returns `null` because the CSS selector does not match any element. Log the return value or hover over it while paused.

3. Off-by-one loop error — a loop runs one iteration too many or too few, often because `<` was written as `<=` or the starting index is wrong. Step through the loop iteration by iteration to watch the index variable change.

Always add a brief code comment explaining what the bug was and how you fixed it. Comments serve as documentation for yourself and teammates.

The Elements Panel: Live CSS Editing

The Elements panel shows the live DOM tree on the left and the CSS rules for the selected element on the right. Click any element in the panel, then edit property values directly in the Styles pane. You can:

• Click a value (such as a color or font size) and type a new one.
• Check or uncheck a rule to toggle it on and off.
• Add a new property by clicking at the end of a rule block.

All edits are temporary. As soon as you reload the page they disappear. When you reach the target appearance, use the Changes drawer (three-dot menu → More tools → Changes) or simply copy the rule text and paste it into your external `.css` file.

The Network Panel: Analyzing Requests

The Network panel records every HTTP request the browser makes—HTML, CSS, JavaScript, images, fonts, API calls. Key columns to read:

• Status — 200 means success; 404 means the file was not found; 301/302 means a redirect.
• Size — the actual bytes transferred; large files slow page loads.
• Time — milliseconds to receive the response.

Filter by type (JS, CSS, Img) to focus on one category. Click any request row to see its Headers, Preview, and Timing breakdown.

Lighthouse: Accessibility and Performance Auditing

Lighthouse is an automated auditing tool built into Chrome DevTools (also available as a CLI). Open the Lighthouse tab, choose the categories you want (Performance, Accessibility, Best Practices, SEO), select Mobile or Desktop, then click Analyze page load. Lighthouse loads the page in a controlled environment, measures dozens of metrics, and returns a score from 0 to 100 for each category.

Performance scores reflect metrics such as Largest Contentful Paint (how long until the main content is visible) and Total Blocking Time (how long scripts block user interaction). Common issues include unoptimized images, render-blocking scripts, and large JavaScript bundles.

Accessibility scores are based on the WCAG (Web Content Accessibility Guidelines) checklist. Common flags include missing `alt` text on images, insufficient color contrast between text and background, form inputs without associated labels, and missing landmark roles.

For each flagged issue, Lighthouse explains why it matters and links to documentation. When you write your action list, state the issue, the element or file it affects, and the specific fix—for example, "Add `alt="Company logo"` to the `<img>` tag in the header" is actionable; "fix images" is not.

Accuracy and Safety Notes

DevTools edits live only in memory. Never assume a browser-side change has been saved. Before closing a session, copy all working CSS or JS edits into your source files and verify the page still works after a hard reload (Ctrl+Shift+R). When sharing screenshots of audit results, include the URL and date because scores change as the page or Lighthouse versions change. Accessibility is not optional—WCAG compliance is referenced in US federal accessibility law, so treating audit findings as real defects to fix, not suggestions to ignore, is professional practice.