Integrated Project: Multi-Page Responsive Website

Integrated Project: Multi-Page Responsive Website

This lesson is your capstone for the HTML, CSS, and JavaScript course. You will independently build a complete, working website from a client brief, validate it against professional standards, and explain your technical decisions out loud. Every skill you have practiced — semantic markup, responsive layout, JavaScript interactivity, accessibility, and code quality — comes together here.

Understanding the Client Brief

A client brief is a short document that describes what a business needs: the purpose of the site, the audience, the pages required, and any content or feature requests. Read the brief carefully before writing a single line of code. Identify the required pages (home, about, contact), any specific interactive features, and any visual or brand constraints. Treat the brief as a contract: deliverables that are missing cost points on the rubric.

Planning Before Coding

Professional developers plan before they build. Sketch a rough wireframe for each page showing where the header, navigation, main content, and footer will sit. Decide early whether Flexbox or CSS Grid — or a combination — best fits each section. Grid works well for two-dimensional page layouts; Flexbox is often better for one-dimensional rows or columns such as navigation bars or card rows. Write your choice down so you can explain it during the defense.

Create a simple file structure before touching VS Code:

```

project/

index.html

about.html

contact.html

css/

styles.css

js/

main.js

images/

```

Consistent file naming and folder organization are part of code quality and will be evaluated.

Semantic HTML5

Use elements for their meaning, not just their appearance. Every page needs a `<header>`, `<nav>`, `<main>`, and `<footer>`. Use `<article>` or `<section>` to group related content, and `<aside>` for supplementary material. Every image must have a descriptive `alt` attribute. Heading levels (`<h1>` through `<h3>`) must follow a logical hierarchy — do not skip from `<h1>` to `<h4>`. Proper semantics improve both accessibility and Search Engine Optimization (SEO).

Responsive CSS Layout

Your site must look correct on mobile, tablet, and desktop widths. Use a mobile-first approach: write base styles for small screens, then add `@media` queries for larger breakpoints (common widths are 600 px and 960 px). Avoid fixed pixel widths for containers; use percentages, `max-width`, or CSS Grid's `fr` units. Test by dragging the browser window narrower in Chrome DevTools and by using the device toolbar.

JavaScript Interactivity

You must include at least one JavaScript interactive feature. The contact page is a natural place for form validation — check that required fields are filled in and that the email field contains an `@` symbol before allowing submission. Use `addEventListener` to attach event handlers rather than inline `onclick` attributes; this keeps your HTML and JavaScript separated.

You must also display data using the Fetch API. A common approach is to fetch a public JSON endpoint (such as a placeholder posts API) and render the results into the DOM using `document.createElement` and `appendChild`. Always handle the fetch Promise with `.then()` and `.catch()` so the page degrades gracefully if the network request fails.

Accessibility and Lighthouse

Run Lighthouse in Chrome DevTools on each page. Aim for scores of 90 or above in Accessibility and Best Practices. Common fixes include: adding `<label>` elements linked to every form input with matching `for` and `id` attributes; ensuring color contrast meets WCAG AA ratios; providing a `lang` attribute on the `<html>` element; and making sure interactive elements are keyboard-reachable with visible focus styles. A score of 90+ in Lighthouse accessibility is not a guarantee of full compliance, but it is a strong baseline.

W3C Validation

Paste each page's HTML into the W3C Markup Validation Service (validator.w3.org) and resolve all errors and warnings before submission. Common errors include unclosed tags, duplicate `id` attributes, and block elements nested inside inline elements. Validation errors can also cause unexpected rendering bugs across browsers.

Code Quality and Commenting

Comment your code at the section level, not on every line. A comment above a CSS Grid block explaining the column structure, or above a JavaScript function explaining what it does, is appropriate. Use consistent indentation (two or four spaces — pick one and stick with it). Remove commented-out dead code before submission. Variable and function names should be descriptive: `submitButton` is clearer than `btn2`.

The Project Defense

You will present your site live for five to ten minutes. Prepare to explain at least three technical decisions — for example, why you chose Grid over Flexbox for the home page layout, how your event listener is structured, or why you placed a particular landmark element where you did. Practice answering "why" questions, not just "what" questions. The instructor will ask two follow-up questions; respond calmly and refer to your code if you need to.

Workspace and Data Safety

Though web development involves no physical hazards requiring PPE or lockout/tagout procedures, you do have professional responsibilities. Never commit real personal data (passwords, API keys, private user information) to your project files or a public repository. Use placeholder data in forms. Save your work frequently and maintain a backup copy; losing work to an unsaved file is avoidable. Keep your browser and VS Code extensions updated to avoid known security vulnerabilities.