Consolidating the quality practices that belong at every stage of web development — accessibility, performance, validation, and debugging across HTML, CSS, and JavaScript
Before you publish a website, you need to know whether it actually works — not just whether it looks finished on your screen, but whether real users can read it, navigate it, understand it, and use it regardless of how they access the web. This chapter consolidates the quality practices that belong at every stage of web development.
You will learn what accessibility means and why it matters, how to evaluate semantic structure and landmarks, how to support keyboard navigation and screen readers, how to check color contrast and alternative text, how to make forms accessible, how to measure and improve basic performance, how to validate HTML and debug CSS and JavaScript, how to test across browsers and devices, and how to use a quality checklist before you ship any project. Quality is not a final step you add at the end. It is a habit you build across the entire course.
A student finishes a five-page website. It looks correct on her laptop, in her preferred browser, with her mouse in hand. Is the site finished? What would you need to check before you could honestly answer "yes" — and who, besides the student herself, might use this site in a way she has not yet tested?
By the end of this chapter, you should be able to:
aria-label for multiple navigation regions; writing meaningful link text:focus-visible; skip navigation linksWhen students first build websites, quality usually means one thing: does it look right on my screen? That is a reasonable starting point. But professional web development uses a much broader definition of quality, and understanding that definition is part of becoming a serious developer.
A quality website works correctly. The HTML is valid and well-structured. The links go where they are supposed to go. The images load. The JavaScript runs without errors. The forms accept input and give feedback. The CSS lays out the page as intended. These are baseline requirements.
A quality website is accessible. Users who rely on keyboard navigation, screen readers, magnification tools, or alternative input devices can use it. Users who have low vision, color blindness, motor impairments, or cognitive differences can understand and navigate it. Accessibility is not a feature for a small group of people. It is a baseline requirement for public information on the web.
A quality website performs reasonably well. Pages load in a reasonable time. Images are appropriately sized. Files are not unnecessarily large. The experience does not feel slow or broken on a modest internet connection or an older device.
A quality website is testable and verifiable. You can check it in multiple browsers. You can resize it and test it on small screens. You can navigate it with a keyboard. You can run a validator and see no critical errors. You can open the console and see no unresolved errors.
A quality website is maintainable. The code is readable. The files are organized. Someone returning to the project after weeks away can understand what each file does and why.
This chapter brings all of these ideas together. Some of them have appeared in earlier chapters. Here you will see them as a unified system: the set of professional habits that separate a careful, published website from a rough draft that happens to be online.
Quality is not a final step you add at the end of a project. It is a habit you build across the entire development process — the same way the running project in this course has grown one careful layer at a time since Part I.
Accessibility means building websites that people can use regardless of how they perceive and interact with the web. Some users read websites visually using a mouse. Some users listen to websites using screen readers that convert text to speech. Some users navigate websites using only a keyboard because a mouse is difficult or impossible for them to use. Some users magnify pages to several times their default size. Some users use voice control software. Some users have cognitive differences that make dense or confusing layouts harder to follow.
None of these users are edge cases. According to estimates from the World Health Organization and web accessibility research, more than one billion people worldwide live with some form of disability. Many more experience situational impairments: someone holding a phone in bright sunlight may struggle with low-contrast text. Someone with a broken wrist may be navigating by keyboard temporarily. Someone in a noisy environment may have their phone on mute and need captions for any video content.
Accessibility on the web is guided by the Web Content Accessibility Guidelines, usually abbreviated WCAG. These guidelines are organized around four core principles, often remembered using the acronym POUR.
Perceivable. Information must be presentable to users in ways they can perceive. Text that cannot be read by a screen reader because it is embedded in an image with no alt text is not perceivable. Video with no captions is not perceivable to a deaf user.
Operable. Interface components and navigation must be operable. A button that can only be activated by a mouse click, not by pressing Enter or Space on a keyboard, is not fully operable. A page that automatically plays a flashing animation without a way to pause it may not be safely operable for users with photosensitive conditions.
Understandable. Information and the operation of the interface must be understandable. Error messages that say only "invalid input" without explaining what went wrong are not understandable. Navigation that changes position unexpectedly between pages makes a site harder to understand.
Robust. Content must be robust enough to be interpreted by a wide variety of user agents, including assistive technologies. This is largely about writing valid, semantic HTML that browsers and screen readers can parse correctly.
WCAG guidelines come in three conformance levels: A (minimum), AA (standard for most public websites), and AAA (enhanced). This textbook introduces concepts that support Level A and Level AA conformance, which together represent the professional baseline for accessible web development.
Accessibility is not just a professional obligation. In many countries and contexts, building inaccessible websites that exclude disabled users creates legal risk under disability rights legislation. More importantly, accessibility is a matter of inclusion. The web was designed to be universal. Building inaccessible websites contradicts that founding intention.
The most powerful accessibility tool available to HTML authors costs nothing and requires no extra code: writing semantic HTML correctly from the beginning.
When you use <h1> through <h6> properly, screen readers announce heading levels to users who navigate by jumping between headings. When you use <nav> for navigation, <main> for main content, <header> for the page header, <footer> for the page footer, and <aside> for supplementary content, screen readers expose these as landmarks that users can jump between directly. When you use <button> for buttons and <a> for links, keyboard and screen reader behavior is automatic and correct.
When you use <div> for everything and rely on CSS classes to style content, none of that structural meaning reaches the browser's accessibility tree. A div that looks like a heading is just a div. A div that looks like a button is just a div. A span that looks like a link is just a span.
The single most commonly broken accessibility pattern on beginner web projects is heading order. Review the rules:
<h1> per page. It should contain the primary topic of the page.<h2> may follow <h1>. An <h3> may follow <h2>. An <h3> should not follow <h1> without an intervening <h2>.<h2> to <h4> because the <h4> default size looks right to you.<h1>Learning Resources</h1>
<h2>Web Development</h2>
<h3>Beginner Articles</h3>
<h3>Video Tutorials</h3>
<h2>Programming</h2>
<h3>Python Basics</h3>
<h3>JavaScript Fundamentals</h3><h1>Learning Resources</h1> <h3>Web Development</h3> <!-- wrong: skips h2 --> <h3>Programming</h3> <!-- wrong: no parent h2 -->
Landmark elements give users of assistive technology a way to jump directly to the part of the page they need. The core landmarks are:
| Element | Landmark Role | Purpose |
|---|---|---|
<header> | banner | Site header with branding and navigation |
<nav> | navigation | Navigation links |
<main> | main | Primary content of the page |
<aside> | complementary | Supplementary or related content |
<footer> | contentinfo | Site footer |
<section> | region (with label) | Distinct content region |
A page with correct landmark structure allows a screen reader user to hear "navigation landmark," "main landmark," and "footer landmark" and jump between them instantly, rather than listening to every element in sequence from the top.
If you have multiple <nav> elements on a page (such as a primary navigation and a footer navigation), give each one an aria-label attribute to distinguish them:
<nav aria-label="Primary navigation"> <!-- main nav links --> </nav> <nav aria-label="Footer navigation"> <!-- footer links --> </nav>
Links must make sense when read in isolation. Screen reader users often browse pages by listing all links, which means "click here" and "read more" are meaningless without the surrounding paragraph.
<!-- Not accessible: link text gives no information --> <a href="lessons.html">Click here</a> to visit the lessons page.
<!-- Accessible: the link text describes the destination --> <a href="lessons.html">Visit the lessons page</a> <!-- Also acceptable: wrap meaningful text --> <p>The <a href="lessons.html">web development lessons</a> are available in the resources section.</p>
If a link opens in a new tab using target="_blank", consider warning users. A screen reader user who follows a link and then tries to go back may be confused to find themselves on a new browser tab. A simple pattern is to add visually hidden text or an icon with a label:
<a href="https://example.com" target="_blank"> External resource <span class="sr-only">(opens in new tab)</span> </a>
The .sr-only class hides text visually but keeps it available to screen readers:
.sr-only {
position: absolute;
width: 1px;
height: 1px;
padding: 0;
margin: -1px;
overflow: hidden;
clip: rect(0, 0, 0, 0);
white-space: nowrap;
border: 0;
}Color contrast describes the difference in luminance between text and its background. When contrast is too low, text becomes difficult or impossible to read for users with low vision, color blindness, or simply anyone reading a screen in bright ambient light.
WCAG defines contrast ratio requirements:
Contrast ratios are expressed as a comparison between two luminance values. A ratio of 1:1 means identical colors (no contrast). A ratio of 21:1 is the maximum (pure black on pure white, or vice versa).
Some common contrast failures:
To check contrast ratios, use a contrast checker tool. Several are freely available online. You input two colors and receive the contrast ratio, along with a pass or fail indication for different text sizes.
Example contrast checks: #767676 on #ffffff → 4.48:1 (passes AA for large text, fails for normal text) #555555 on #ffffff → 7.46:1 (passes AA and AAA for all text) #ff0000 on #ffffff → 3.99:1 (fails AA for normal text) #000000 on #ffffff → 21:1 (passes all levels)
Color should never be the only means of conveying information. A form that shows errors only by turning the border red is inaccessible to users with color blindness — approximately 8% of men and 0.5% of women have some degree of red-green color blindness.
Always pair color with a second signal:
<!-- Relying on color alone — not accessible --> <input type="text" class="error"> <!-- The red border is the only error indicator -->
<!-- Accessible: color plus an error message --> <input type="text" class="error" aria-describedby="name-error"> <p id="name-error" class="error-message"> Please enter your full name. </p>
Charts that distinguish data series only by color need labels, patterns, or other visual differences that work without color perception.
The alt attribute on <img> elements provides a text alternative for images. Screen readers read the alt text aloud. Search engines use it to understand image content. When an image fails to load, the alt text appears in its place.
Writing good alt text requires thinking about what purpose the image serves.
Informative images should describe what the image shows. Be specific and concise. Do not start with "image of" or "photo of" — screen readers already announce that content is an image.
<!-- Too vague --> <img src="chart.png" alt="chart">
<!-- Better: describes what the chart shows --> <img src="chart.png" alt="Bar chart showing monthly page views from January through June, peaking in April at 12,400 views">
Decorative images that add visual interest but carry no information should use an empty alt attribute. This tells screen readers to skip the image entirely rather than announcing the filename.
<!-- Decorative image — skip it --> <img src="divider-pattern.png" alt="">
Functional images such as icons that act as buttons or links need alt text that describes the function, not the appearance:
<!-- Describes function, not appearance --> <a href="search.html"> <img src="search-icon.png" alt="Search"> </a>
Complex images such as diagrams, graphs, and charts may need more than a short alt text. Use a longer description in the surrounding content, a figure caption, or a linked description page.
<figure>
<img
src="site-structure-diagram.png"
alt="Diagram of a five-page website structure"
aria-describedby="diagram-description"
>
<figcaption id="diagram-description">
The home page links to four secondary pages: About, Lessons, Resources, and Contact.
The Lessons page also links to three individual lesson pages.
</figcaption>
</figure>Video content should have captions that convey spoken dialogue and important sounds. Most video hosting platforms support caption tracks.
Audio content that conveys meaningful information should have a text transcript.
Background audio that plays automatically should have a mechanism to pause or stop it. Automatically playing audio can interfere with screen readers and is disorienting for many users.
Forms are among the most critical and most commonly inaccessible parts of web pages. Every form control — every input, textarea, select menu, checkbox, and radio button — must be programmatically associated with a visible label.
The <label> element associates a description with a form control. Screen readers announce the label when focus enters the control. Clicking a label also moves focus to the associated control, which enlarges the interactive target area.
Associate labels using the for attribute on the label and a matching id on the input:
<!-- Correct: label is associated with the input --> <label for="email">Email address</label> <input type="email" id="email" name="email">
<!-- Not accessible: placeholder is not a label substitute --> <input type="email" placeholder="Email address">
Placeholder text disappears when a user begins typing. It also typically has low contrast by default. Never use placeholder as the sole label for an input.
Error messages must be programmatically connected to the inputs they describe. Using aria-describedby links an element to a description by matching IDs:
<label for="username">Username</label> <input type="text" id="username" name="username" aria-describedby="username-error" aria-invalid="true" > <p id="username-error" class="error-message" role="alert"> Username must be at least 4 characters. </p>
The role="alert" attribute causes screen readers to announce the error message immediately when it appears in the DOM, without requiring the user to navigate to it.
Setting aria-invalid="true" on the input signals to screen readers that the current value is invalid, giving the user programmatic information beyond the visual styling.
When you have a group of related inputs — such as a set of radio buttons or checkboxes — wrap them in a <fieldset> with a <legend> that names the group:
<fieldset>
<legend>Preferred contact method</legend>
<label>
<input type="radio" name="contact" value="email"> Email
</label>
<label>
<input type="radio" name="contact" value="phone"> Phone
</label>
<label>
<input type="radio" name="contact" value="mail"> Mail
</label>
</fieldset>Without the fieldset and legend, a screen reader user hears each radio button option without knowing what question they are answering.
Mark required fields using the required attribute. This causes browsers to validate the field before submission and tells screen readers the field is required. You can also provide a visible indicator:
<label for="full-name"> Full name <span aria-hidden="true">*</span> <span class="sr-only">(required)</span> </label> <input type="text" id="full-name" name="full-name" required>
The aria-hidden="true" attribute hides the asterisk from screen readers (who do not need the visual convention) while the .sr-only span provides a text equivalent.
If you use an asterisk convention, explain it at the top of the form:
<p>Fields marked with <span aria-hidden="true">*</span> <span class="sr-only">an asterisk</span> are required.</p>
Performance and accessibility are related. A page that takes thirty seconds to load on a slow mobile connection excludes users who do not have fast broadband. A page heavy with unoptimized images downloads unnecessary data. Performance is a form of inclusion.
Research consistently shows that users abandon slow-loading pages. Studies from Google and others find that as page load time increases from one second to three seconds, the probability of a user leaving the page increases significantly. The acceptable threshold for a web page to feel fast is roughly two to three seconds on a typical connection.
For students building portfolio sites, educational pages, and club websites, performance is unlikely to be a crisis. But understanding the basic sources of slowness is part of professional practice.
Images are typically the largest files on most web pages. Common image performance mistakes include:
Resize images to the largest size they will actually appear. If an image appears at 800 pixels wide on your page, there is no benefit to saving it at 3000 pixels wide. You are asking users to download three times as much data.
| Format | Best For |
|---|---|
| JPEG | Photographs and complex images with gradients |
| PNG | Images with transparency; simple illustrations with flat colors |
| SVG | Icons, logos, and illustrations that should scale to any size |
| WebP | Modern format with better compression than JPEG or PNG for many images |
Compress images before saving. Most image editing tools let you export at different quality levels. For photographs, a quality setting of 70–80% in JPEG typically produces a visually acceptable result at roughly half the file size of 100% quality.
Use width and height attributes on <img> elements. When the browser knows the image dimensions before the image loads, it can reserve space in the layout and prevent the page from jumping around as images finish loading. This jumping, called layout shift, is both annoying and measurable as a performance problem.
<!-- Provide width and height to prevent layout shift --> <img src="images/hero.jpg" alt="Students working on web projects" width="1200" height="600">
JavaScript that runs while the page is loading can slow down how quickly the page appears to users. The defer attribute on a script tag tells the browser to download the script in the background but wait until the HTML is fully parsed before running it:
<!-- Script runs after HTML is parsed — does not block rendering --> <script src="js/main.js" defer></script>
Using defer is a simple habit that avoids one common source of page slowness.
The Network panel in browser developer tools shows every file the browser downloads to load a page, along with each file's size and download time. Open Developer Tools, click the Network tab, and reload the page. Look for:
The browser's Lighthouse tool (available in Chrome and Edge Developer Tools under the "Lighthouse" tab) provides an automated performance audit. It scores the page on performance, accessibility, best practices, and SEO, and gives specific recommendations for improvement. Running Lighthouse on a project before submission is a useful habit.
Quality work requires debugging skill. No developer writes perfect code on the first try. Knowing how to read errors, trace behavior, and isolate problems is what separates productive developers from frustrated ones.
Missing closing tags. Many HTML errors come from forgetting to close an element. If a <div> is never closed, everything after it may become its child, breaking layout and accessibility.
<!-- Missing closing tag causes layout problems --> <section> <h2>About This Site</h2> <p>This is a learning resource for web development students. <!-- </p> is missing — browser may auto-close it, but behavior is unpredictable --> </section>
Incorrect nesting. Elements must be closed in the reverse order they were opened.
<!-- Incorrect nesting --> <strong><em>Important text</strong></em>
<!-- Correct nesting --> <strong><em>Important text</em></strong>
Wrong attribute syntax. A missing quotation mark, a typo in an attribute name, or a missing equals sign all cause silent failures.
<!-- Missing quote causes unpredictable behavior --> <img src=images/photo.jpg alt="Photo of the library">
<!-- Correct --> <img src="images/photo.jpg" alt="Photo of the library">
The W3C HTML validator at validator.w3.org accepts a URL, uploaded file, or pasted HTML and reports any validation errors and warnings. Running the validator on every page before submission is a quality practice. Validation errors are not always catastrophic — browsers are forgiving and will attempt to render invalid HTML — but they reveal real problems in your document structure, and some will cause subtle layout or accessibility failures that are difficult to diagnose otherwise.
Typos in property names or values. CSS silently ignores declarations it does not understand. If you write colour: red in a browser that does not recognize colour, the rule is silently discarded with no error.
/* Typo — this declaration is silently ignored */ font-weitgh: bold;
/* Correct */ font-weight: bold;
Selector targeting the wrong element. If a style is not applying, the first question is: does the selector actually target this element? Use the Elements panel in Developer Tools to click on an element and see all styles applying to it. Look for:
Cascade and specificity conflicts. A rule that seems correct may be overridden by a more specific rule elsewhere. Inspect the element in Developer Tools and look at the cascade — the list of all matching rules, in the order they apply, with overridden rules visually crossed out.
Box model surprises. If an element is larger or smaller than expected, open the computed styles in Developer Tools and examine the box model diagram. Check whether box-sizing is what you expect, and check whether margins are collapsing unexpectedly.
Responsive layout failures. If a layout breaks at certain viewport widths, use the responsive preview in Developer Tools to simulate different screen sizes. Check whether your media queries are written correctly, whether breakpoints match the actual points where layout needs to change, and whether units are consistent.
ReferenceError. You are trying to use a variable or function that does not exist or has not been declared yet.
Uncaught ReferenceError: submitForm is not defined
Check spelling, check whether the function is declared in the correct scope, and check whether the script file is linked correctly.
TypeError. You are trying to perform an operation on a value that does not support it — most commonly, calling a method on null or undefined because a DOM selection failed.
Uncaught TypeError: Cannot read properties of null (reading 'addEventListener')
This means document.querySelector(...) returned null — it did not find the element. Check whether the selector is correct and whether the element exists in the HTML at the time the script runs.
SyntaxError. A JavaScript syntax error prevents the entire script from running. Check the console message carefully — it usually includes a line number and a description of what went wrong.
Uncaught SyntaxError: Unexpected token '}'
This often means a missing opening brace, a missing parenthesis, or an unclosed string.
The browser console is your primary JavaScript debugging tool. Use console.log() to print values at key points in your program:
function calculateTotal(price, quantity) {
console.log('price:', price, 'quantity:', quantity); // check inputs
const total = price * quantity;
console.log('total:', total); // check result
return total;
}console.log() is temporary debugging code. Remove it before publishing your final project.
Setting breakpoints. The Sources panel in Developer Tools allows you to pause JavaScript execution at any line by clicking the line number to set a breakpoint. When execution pauses, you can inspect the current value of every variable in scope. This is more powerful than console.log() for complex logic.
Checking event listeners. If an event listener does not seem to be firing:
click, not Click)defer or placed at the end of the body so the DOM exists when the script runsNo website exists in isolation. Users access the web with different operating systems, different browsers, different screen sizes, and different input devices. Testing in only one browser on your development machine gives you an incomplete picture of how your site behaves for real users.
Modern browsers — Chrome, Firefox, Edge, and Safari — share strong support for HTML5, CSS3, and modern JavaScript. For most of the web features taught in this textbook, behavior is consistent across these browsers. Older browsers and some mobile browser variants may differ.
At minimum, test your project in two different browsers before submission. If you have access to a mobile device, test there as well. The responsive preview in Developer Tools simulates different screen sizes, but it does not replace testing on an actual device because touch interaction, viewport behavior, and rendering can differ.
When testing across browsers, look for:
Use the responsive preview tool in Developer Tools to test your layout at a range of widths. Test at:
Look for content that overflows horizontally, text that becomes unreadably small, touch targets that are too small to tap accurately (the recommended minimum touch target size is 44×44 CSS pixels), and navigation that becomes unusable on small screens.
<!DOCTYPE html> is present<html lang="..."> has a correct language attribute<meta charset="UTF-8"> is present<meta name="viewport" content="width=device-width, initial-scale=1"> is present<title> contains a meaningful, unique page title<h1> per page<main> wraps the primary content<nav> is used for navigation<header> and <footer> are present where appropriate<section> and <article> are used for meaningful content divisions<nav> elements have distinct aria-label attributes<img> has an alt attributealt="")width and height attributes<label> using for and idrequired attribute<fieldset> and <legend>console.log() statements used for debugging have been removeddefer or placed before </body>aria-label values for repeated landmarks, and meaningful link text cost nothing and prevent common accessibility failures.aria-describedby and role="alert"; grouped controls need <fieldset> and <legend>.width and height to prevent layout shift, and deferring scripts are simple, high-value habits. The Network panel and Lighthouse reveal performance problems before users encounter them.console.log(), and breakpoints in the Sources panel.alt attribute of <img>, that describes the image content or function for screen readers and users who cannot see the image.aria-label, aria-describedby, and aria-invalid that add accessibility information to HTML elements when native semantics are insufficient.<script> that tells the browser to download the script in the background and execute it after the HTML is fully parsed.querySelector or similar methods return null because the specified element does not exist in the document, often causing a TypeError in JavaScript.<legend> to label the group for accessibility.<main>, <nav>, <header>, or <footer> that defines a major region of the page and can be navigated to directly by screen reader users.width and height on <img> elements.null.Answer these questions before beginning the full review activities. They check basic understanding, not deep analysis.
<label> and a placeholder?alt="" and a missing alt attribute?outline: none on focusable elements removes the only visual signal that tells keyboard users where they currently are on the page. This is a genuine accessibility failure, not a style preference. Use :focus-visible to style a clear, attractive focus indicator instead of removing it.<label> is. A visible, programmatically associated label is required; a placeholder may supplement it but never replace it.aria-describedby, and ideally aria-invalid="true" and role="alert" so the problem is communicated in more than one way.Read each code example and answer the questions that follow.
<nav> <a href="index.html">Home</a> <a href="about.html">About</a> <a href="lessons.html">More Info</a> <a href="contact.html">Get in Touch</a> </nav>
* {
box-sizing: border-box;
margin: 0;
padding: 0;
}
a:focus,
button:focus,
input:focus {
outline: none;
}outline: none do to these elements when they receive keyboard focus?<label>Email</label> <input type="email" name="email" placeholder="[email protected]"> <label>Password</label> <input type="password" name="password">
const button = document.querySelector('.submit-btn');
button.addEventListener('click', function() {
console.log('Button clicked');
});<button class="submit-button">Submit</button>
<img src="team-photo.jpg"> <img src="decorative-border.png" alt="decorative border image"> <img src="logo.svg" alt="">
alt attribute entirely?Examine the following page outline. Identify every heading order problem and explain why each one is an error. Then write a corrected heading structure.
<h1>Student Learning Site</h1> <h3>Web Development</h3> <h4>HTML Basics</h4> <h4>CSS Fundamentals</h4> <h2>Programming</h2> <h4>Python Overview</h4> <h3>JavaScript Fundamentals</h3>
Review the following form and list every accessibility problem you can identify. Write a corrected version of the form.
<form>
<input type="text" placeholder="Your name" required>
<input type="email" placeholder="Email address" required>
<div>
<input type="radio" name="topic" value="html"> HTML
<input type="radio" name="topic" value="css"> CSS
<input type="radio" name="topic" value="js"> JavaScript
</div>
<button type="submit">Send</button>
</form>The following page uses no semantic landmark elements. Rewrite it using appropriate landmarks and semantic elements. Add any necessary attributes.
<div class="header">
<div class="nav">
<a href="index.html">Home</a>
<a href="about.html">About</a>
<a href="contact.html">Contact</a>
</div>
</div>
<div class="content">
<div class="article">
<div class="title">Introduction to HTML</div>
<div class="text">HTML gives structure and meaning to web content.</div>
</div>
</div>
<div class="footer">
<div class="small">© 2025 Student Learning Site</div>
</div>A student writes this CSS rule to make paragraph text larger, but nothing changes on the page:
p {
font-sise: 1.2rem;
}A student writes this JavaScript to show a welcome message when a button is clicked:
const btn = document.querySelector('#welcome-button');
btn.addEventListener('click', function() {
document.querySelector('#message').textContent = 'Welcome!';
});The HTML contains:
<button class="welcome-button">Say Hello</button> <p id="message"></p>
The page loads, and clicking the button produces this console error:
Uncaught TypeError: Cannot read properties of null (reading 'addEventListener')
A student's page shows a broken image icon instead of the photo. The HTML reads:
<img src="Images/team-photo.jpg" alt="The learning resources team">
The project folder structure is:
learning-site/
index.html
css/
main.css
images/
team-photo.jpgA student's page looks correct on a laptop screen but on a phone screen, a section of content extends horizontally off the page, causing a horizontal scrollbar to appear.
A student's page loads slowly. Opening the Network panel in Developer Tools shows these file sizes:
index.html 12 KB css/main.css 8 KB js/main.js 4 KB images/hero.jpg 3,400 KB images/about.jpg 220 KB images/logo.png 18 KB
Explain the purpose of the defer attribute on a <script> element. Why is it a good habit for most external script files? Under what circumstance would you not want to use defer?
Using a color contrast checker (your instructor will provide access to one, or you may use any freely available online tool), check the following color combinations and record the contrast ratio and WCAG AA pass/fail result for normal body text:
#888888 on background #ffffff#333333 on background #ffffff#ffffff on background #0055aa#ffff00 on background #ffffff#000000 on background #ccccccFor each combination that fails, suggest an adjusted color that would pass.
These questions draw on skills from throughout the textbook.
<b> and <strong>? Which one carries semantic meaning for accessibility?lang attribute on the <html> element do? Why does it matter for accessibility?display: none and the .sr-only visually hidden pattern? When would you use each one?<nav> elements: one for the primary site navigation and one for a table of contents within an article. What should you add to distinguish them for screen reader users?aria-invalid="true" on an input is useful even when the input already has a red border applied by CSS.target="_blank" on a link to an external resource. What accessibility consideration applies, and how can it be addressed?role="alert" attribute? In which situations from Chapter 24 would you use it?max-width: 800px on the body element to constrain the layout width. What additional property might be needed to center the body horizontally on wide screens?Select one of your previous mini-projects from Part III, Part IV, or Part V of this course. Perform a complete quality review using the chapter's checklist and the audit tasks practiced in this chapter.
Submit the revised project files and the revision summary.
Chapter 30 is the capstone chapter. You will prepare a complete final website for review, cleanup, and — where possible — publication. Chapter 30 covers final file organization, testing links and paths across all pages, understanding hosting options, domain names at an introductory level, what deployment involves, version control at a beginner level, backups and maintenance, documenting a web project, and the final published website as a portfolio artifact. Everything you have learned across this course comes together in Chapter 30.