Web development module 4: accessible, fast and online

Day 43 — Why accessibility

Goal: understand what accessibility means, for whom, and why it concerns you.

Theory (20 min)

Accessibility (a11y in the jargon — "a", eleven letters, "y") means building pages usable by everyone: blind or low-vision people who navigate with a screen reader (software that reads the page aloud), people who cannot use a mouse and do everything by keyboard, people who struggle with low contrast, people whose connection or machine is slow — and, on a day of fatigue or an arm in a cast, you.

The figure that changes the perspective: the WHO estimates that over a billion people live with a disability. But accessibility is not charity for a minority: an accessible page is a better-built page — clearer by keyboard, better understood by search engines, more readable in sunlight on a phone. The good practices of these six sessions benefit 100 % of visitors.

The good news: HTML is accessible by default. A heading is a heading, a button is a button, a label is linked to its field — screen readers understand all of it effortlessly, because you have used the right tags since day 3. Accessibility breaks when you hijack HTML (a div pretending to be a button) or forget it (an image without alt). This module is therefore mostly a deepening of what you already do, not a new discipline.

The reference rules are the WCAG (Web Content Accessibility Guidelines), with three conformance levels: A, AA, AAA. Aim for AA: it is the level most laws require.

Practice (30 min)

1. Run the keyboard experiment: open your me.html page, put the mouse away, and navigate with Tab (next element), Shift+Tab (previous) and Enter (activate). Success criterion: you reach and activate every link and every field — and you can SEE which element is active (a focus outline).
2. Close your eyes and keep going for thirty seconds. Frustrating? Welcome to the daily life of a screen-reader user when a page is poorly built.
3. If your system has a built-in screen reader (Narrator on Windows, VoiceOver on macOS with Cmd+F5), turn it on for five minutes on your page and listen to what it announces: the headings, the landmarks, your fields' labels.
4. In the notebook: list three moments where the experience snagged — those are your first accessibility defects, you will repair them this week.

Agent tips: "list the accessibility problems of this HTML" gives an honest first pass. Trap: it cannot TEST (no keyboard, no screen reader) — it reads, it does not live the page. Proof: redo the keyboard walk yourself; the problems it cites must match what you lived.

Recap (10 min)

Three lines: what a screen reader is, whom accessibility benefits, what the WCAG are. Then redo the Tab walk on a page you like, eyes open.

Day 44 — Semantic HTML: landmarks

Goal: use landmarks and heading hierarchy as an outline a machine can read.

Theory (20 min)

On day 12 you met header, nav, main, footer and their cousins. Today, see what a screen reader does with them: it offers the user navigation shortcuts — "list of landmarks" (jump straight to the main content, to the menu), "list of headings" (the table of contents), "list of links". A sighted user scans a page in a second; these lists are the equivalent for someone who cannot see. Without landmarks, there is only one reading mode: everything, in order, from the top.

Hence three concrete rules:

• One single <main> per page, holding the content — not the global header, not the footer.
• A heading hierarchy with no gap: h1 then h2 then h3, never h1 → h4 because "h4 looks nicer" (size is set in CSS; the tag carries meaning).
• If a page has several <nav>s (main menu + breadcrumb), name them: <nav aria-label="Main"> — the screen reader will announce "Main navigation" instead of two indistinguishable "navigation"s.

Home test, no tool: reread your page reading ONLY the headings. If the story makes sense, your structure is good. That is exactly what the screen-reader user hears.

Practice (30 min)

1. Open the inspector on your page and check your landmarks: one header, one nav, one single main, one footer. Repair what is missing.
2. Run the headings test: write down on paper only your h1, h2, h3 in order. Does the outline hold? A skipped level? Fix the tag, and adjust the size in CSS if the rendering changes.
3. Success criterion: your page has a single h1, no skipped level, and the four landmarks.
4. If your page has several navs, name them with aria-label.
5. Run the W3C validator again: zero errors.

Agent tips: "check this page's heading hierarchy: [paste]" is reliable — it is text, it can read it. Trap: it may confuse looks with structure ("use an h4 here, more discreet"). Proof: the outline YOU wrote on paper must stay coherent after its review.

Recap (10 min)

Three lines: what navigation shortcuts are, the three rules, the headings test. Then run the headings test on a news site.

Day 45 — Alt texts and explicit links

Goal: write good alts and good link texts — the two most cost-effective accessibility reflexes.

Theory (20 min)

Day 7's alt deserves a whole session, because it is the most widespread defect on the web. The method: ask yourself what the image brings at this exact spot. Three cases:

• Information image (article photo, diagram): describe the information. "A cat" is weak; "a ginger cat asleep on a backlit keyboard" carries what the image carries.
• Image-link or image-button: the alt states the DESTINATION or the ACTION, not the picture: "Back to home", not "blue arrow".
• Decorative image: alt="" — empty, but present. Without the attribute at all, some screen readers read the file name aloud.

Forbidden: starting with "image of" or "picture of" (the screen reader already announces "image"), and long paragraphs: an alt rarely exceeds one sentence.

Same logic for links: the link text must suffice, out of context. Test: a screen reader can list all the links of a page. "Read more", "click here", "link" — the list says nothing. "Read the contrast guide" stands alone. And never wrap a whole paragraph in a link: a sentence is a comfortable maximum.

Practice (30 min)

1. Review every image of your pages: for each, classify it (information / action / decorative) and rewrite its alt by its case's rule.
2. Review every link: read ONLY the link texts of the page, out loud. Each must announce its destination. Fix the "click here"s.
3. Success criterion: both tests pass — alts describe the contribution, links describe the destination.
4. Reverse drill: take three images from a news site, cover the screen and have someone read you the alts (or read the source yourself). Which ones suffice on their own?

Agent tips: "suggest an alt for each image of this HTML, given its context in the page" — paste the HTML AND describe each image; it cannot see them. Trap: without a description, it writes "illustrative photo". Proof: day 7's closed-eyes test remains your judge.

Recap (10 min)

Three lines: the three alt cases, the two forbiddens, the link-list test. Then rewrite a bad alt from memory into a good one.

Day 46 — Accessible forms and visible focus

Goal: make your forms announceable by a screen reader and the focus always visible.

Theory (20 min)

Your forms already have linked labels (day 9) — that is 80 % of the work. What remains:

• Visible focus. When navigating with Tab, the active element wears an outline. Years of design saw stylesheets do outline: none because it was "ugly" — stripping keyboard users of any landmark. The modern rule: never remove the outline without replacing it; better, beautify it with :focus-visible, which only applies to keyboard navigation: a:focus-visible { outline: 3px solid var(--accent); outline-offset: 2px; }.
• Error messages in text. A field turned red is not enough: someone who cannot tell red sees nothing. The error is written: "Invalid address: the @ is missing", next to the field.
• Instructions before the field. "8 characters minimum" is read BEFORE typing, not after the error.
• required and type are your allies: <input type="email" required> gives native, announced validation, for free.

Practice (30 min)

1. Add the :focus-visible rule to your CSS, reload, navigate with Tab: success criterion: at every Tab, you clearly see which element is active, including your buttons and your dark-mode toggle.
2. In your form, add required to the first-name field and a type="email" to the email field. Submit empty: the browser shows a native message, in the right place, in the user's language.
3. Add a textual error message to day 38's JavaScript validation: instead of doing nothing when the field is empty, display "First name is required" in a <p> next to the field (and clear that message when input becomes valid).
4. Test the whole flow by keyboard only: fill, make a mistake, read the error, fix, submit.

Agent tips: "make this form accessible: labels, text errors, visible focus" is a good order. Trap: it may replace the outline with a subtle color change, invisible in sunlight. Proof: the Tab test with squinted eyes — the focus must jump out.

Recap (10 min)

Three lines: why you never remove the outline, what an accessible error message is, what required and type give. Then test the form with Tab without notes.

Day 47 — Contrast and keyboard navigation

Goal: measure your colors' contrast and guarantee everything works by keyboard.

Theory (20 min)

Contrast is the luminance ratio between text and its background, from 1:1 (invisible) to 21:1 (black on white). The WCAG level AA requires 4.5:1 for body text and 3:1 for large text (headings of 24 px and more). Medium grey on white, the darling of mockups, is almost always below the bar — measure, do not guess: the inspector shows the ratio when you click a color swatch, and the WebAIM Contrast Checker computes between two color codes.

Second rule of the day: everything doable with a mouse is doable by keyboard. Native elements provide: a <button> is reachable with Tab and activates with Enter AND Space; an <a> activates with Enter. The trap is the div disguised as a button: a <div onclick=...> is neither reachable nor activatable by keyboard, and silent to a screen reader. The golden rule: if it can be clicked, it is a button or an a.

And your own JavaScript can break the keyboard: a menu that only opens on mouse hover is closed to Tab users. Check every interaction you add.

Practice (30 min)

1. Measure your color pairs (text/background, accent/background, text/card) in the WebAIM Contrast Checker, in light AND dark mode — the two themes are measured separately.
2. Fix what fails by tuning your variables: darken a text, lighten a background. Success criterion: all your text/background pairs pass AA.
3. The grand keyboard test of your whole page: reach and activate every link, button, field, the theme toggle; add a task, delete one — all with Tab and Enter.
4. Note every keyboard-impossible interaction and repair it (the culprit is almost always a div pretending to be a button).

Agent tips: "do these two colors pass WCAG AA?" is a computation, not an opinion — the agent computes a ratio, but check it on WebAIM: it can slip in the multiplications. Proof: the ratio measured by the tool, not the announced one.

Recap (10 min)

Three lines: the 4.5 and 3 thresholds, the div-button rule, what to test with Tab. Then re-measure a fixed color from memory of the threshold.

Day 48 — ARIA: when (not) to use it

Goal: know what ARIA is, and above all when to skip it.

Theory (20 min)

ARIA (Accessible Rich Internet Applications) is a set of HTML attributes that describe to assistive technologies what HTML alone cannot express. Examples: aria-label (a name for an element without text, like a "×" button), aria-expanded="true" (this panel is open), aria-current="page" (this link is the current page in the menu).

The first rule of ARIA, official and to learn by heart: "Do not use ARIA if a native HTML tag does the job." A <button> is a button; a <div role="button" tabindex="0"> tries to reinvent it and will always forget something (keyboard, focus, announcement). ARIA adds information; it NEVER adds behavior — role="button" does not make a div keyboard-clickable, it only describes it.

Three legitimate uses at your level:

• aria-label on a button whose only content is a symbol ("×", an icon): <button aria-label="Close">×</button>;
• aria-current="page" on the menu link pointing to the current page;
• naming a landmark when there are several (day 44).

The rest (trees, tabs, dialogs) will wait until you build complex components — and there, battle-tested libraries do better than home-grown ARIA.

Practice (30 min)

1. Add aria-current="page" to the navigation link matching the current page, on each of your pages (plus a bit of CSS: [aria-current="page"] { font-weight: bold; } — the attribute doubles as a selector).
2. If your todo list has "×" buttons, give them an aria-label="Delete this task" — generated in the JavaScript, at createElement time.
3. Success criterion: inspect your buttons: every button without readable text has an aria-label, and every page marks its current link.
4. Div-button hunt: reread your code — is every element reacting to clicks a real <button> or <a>? If not, convert — it is almost always shorter than the ARIA imitation.

Agent tips: "add the necessary ARIA to this component" is a dangerous order: models sprinkle. Trap: three ARIA attributes where one native tag suffices. Proof: demand the justification of EACH attribute — "which native tag would have done this?"; if the answer names one, use it.

Recap (10 min)

Three lines: ARIA's first rule, the three legitimate uses, why role is not enough. Then add aria-current from memory on a fresh page.

Day 49 — Performance: images

Goal: measure a page's weight and reduce the images' share, the web's heaviest line item.

Theory (20 min)

Performance is measured in bytes and seconds. Every visitor downloads your whole page — and images usually outweigh everything else combined: a smartphone photo is 3 to 8 MB, where a full HTML page with CSS and JS fits in a few dozen KB. On an average mobile connection, 5 MB means several seconds of blank screen, and half the visitors gone.

Three gestures suffice at your scale:

• Resize: displaying an image 400 px wide? Save it 400 px wide (or 800 for dense screens), not 4000. The file explorer or a free tool like Squoosh (in the browser, nothing to install) resizes and compresses by drag and drop.
• Pick the format: JPEG or WebP for photos, PNG for images with transparency or text, SVG (vector, tiny weight) for logos and icons.
• Lazy loading: <img loading="lazy"> tells the browser to download the image only when it approaches the screen. Free, native, on every image not visible at opening.

Measure before and after, always: the dev tools' Network tab shows the page's total weight at the bottom. It is your scale.

Practice (30 min)

1. Open the Network tab, reload your page, note the total weight and each image's.
2. Run your heaviest image through Squoosh: resize to its real display size, convert to WebP, compare the weights.
3. Replace the file, add loading="lazy" to the images below the fold. Success criterion: reload with the Network tab open: total weight has dropped, and the lower images only load as you scroll (watch the requests arrive progressively).
4. Note in the notebook: weight before / after. This measure → fix → re-measure reflex is the professionals' one.

Agent tips: "which image optimizations for this page?" — paste the HTML and each image's weight. Trap: it may advise complicated tooling (srcset, CDN) before simple resizing. Proof: the before/after measurement in YOUR Network tab, not its estimates.

Recap (10 min)

Three lines: the three gestures, which format for which use, where to read total weight. Then compress another image from memory.

Day 50 — Performance: scripts and measuring

Goal: understand what slows loading and audit a page with Lighthouse.

Theory (20 min)

After images, scripts. On day 29 you put your <script> at the end of the body so the HTML exists before it. The defer attribute lets you move it back into the head with the same guarantee: the browser downloads the script in parallel with the HTML and only runs it once the page is read:

<script src="script.js" defer></script>

Both placements are valid; defer is the modern form. What matters: never block the page's display waiting for a script.

Then, measure rather than guess. Lighthouse, the audit built into Chrome's and Edge's developer tools (Lighthouse tab, or Ctrl+Shift+P then "Lighthouse"), grades the page from 0 to 100 on four families: performance, accessibility, best practices, SEO — and above all, it LISTS the problems precisely, with the line or file at fault. On Firefox, the Network tab and the accessibility inspector cover the essentials.

The professional reflex: run the audit BEFORE touching the code (otherwise you will not know what your fix changed), read the problems in the order given, fix the first one, run again.

Practice (30 min)

1. Move your script tag into the head with defer, reload: everything must work exactly the same (if not, find out why — usually a script assuming the body is already read).
2. Run Lighthouse on your page (navigation, default mode). Success criterion: you can read your four grades and unfold the first listed problem.
3. Fix the first performance problem AND the first accessibility problem it reports (often: a contrast, an alt, an image without dimensions).
4. Run the audit again: the grades move. Note before/after in the notebook.
5. Also note: grades shift slightly between audits (network, machine) — watch the order of magnitude, not the tenth of a point.

Agent tips: "here is my Lighthouse report: [paste the problem list] — explain the first one and propose the minimal fix" works well. Trap: do not ask it to guess the grade; ask it to explain a MEASURED problem. Proof: rerun Lighthouse after the fix — the grade moves or not; it does not lie.

Recap (10 min)

Three lines: what defer does, Lighthouse's four families, the measure-fix-measure reflex. Then rerun an audit blind: do you know where to click without searching?

Day 51 — Git: snapshotting your work

Goal: initialize a Git repository and record your first versions (commits).

Theory (20 min)

Git is software that photographs your working folder at chosen moments, and keeps every photo: you can return to any of them, compare, understand what changed. Each photo is called a commit, with a message saying why ("add the contact page"). The folder tracked by Git is called a repository.

It is the developer's life insurance: breaking something is no longer serious — the previous photo exists. And it is the gate to publishing: GitHub, tomorrow, is a server hosting Git repositories.

Three commands make 90 % of daily life (typed in the terminal, inside the project folder):

git init                          # turns the folder into a repository (once)
git add .                         # stages all files for the photo
git commit -m "first page"        # takes the photo, with its message

git status shows at any time what changed since the last photo; git log --oneline lists the photos. The terminal is on today's program: "Terminal" or "Command Prompt" on Windows, "Terminal" on macOS and Linux — and the cd command to enter the folder (cd Documents/devweb).

Practice (30 min)

1. Install Git if needed (git-scm.com/downloads), then check: git --version.
2. Introduce yourself to Git (once and for all): git config --global user.name "Your Name" and git config --global user.email "your-email-here" — the name signs every commit.
3. In the terminal, enter a freshly created capstone folder (it will host your final project) and run git init.
4. Copy your pages into it, then git add . and git commit -m "first site files". Success criterion: git log --oneline shows your commit.
5. Change a file, run git status (it sees the change), git add ., a second commit. git log shows two. Change again, and this time do not commit: git diff shows the lines changed since the last photo.

Agent tips: "explain what git status is telling me: [paste the output]" is a good early reflex. Trap: never let an agent type git in your place this month — the gesture must enter through YOUR hands. Proof: git log shows YOUR commits, in YOUR terminal.

Recap (10 min)

Three lines: what a repository is, a commit, the add/commit difference. Then make a third commit without notes.

Day 52 — GitHub: publishing your repository

Goal: create a GitHub account, create a repository there, and push your code to it.

Theory (20 min)

Git is local: your photos live in your folder. GitHub is a server hosting Git repositories: online backup, access from anywhere, and — tomorrow — free static site hosting. The free account covers this whole path.

The vocabulary: push sends your local commits to GitHub; pull fetches what is online. A public GitHub repository is readable by everyone — never put a password, a key or personal data in it. Your static site only holds HTML, CSS and JS anyway, public by nature.

To push, GitHub must know it is you: the website password no longer works for Git. Two simple paths: create a personal access token (in GitHub settings: Settings → Developer settings → Personal access tokens → Tokens (classic), tick the "repo" scope), which Git will ask for instead of the password; or install GitHub CLI (gh), whose gh auth login command does the handshake in the browser. The detailed walkthrough lives in the GitHub documentation — keep it at hand, screens evolve.

Practice (30 min)

1. Create your account on github.com (free).
2. Create an empty repository, ticking nothing (no README: you are pushing an existing one). Suggested name: my-site.
3. Connect your folder to the repository: git remote add origin https://github.com/YOUR-NAME/my-site.git then git push -u origin main (if your branch is called master: git branch -M main first).
4. Success criterion: refresh the repository page on GitHub: your files are there, with your commit message.
5. Make a change, commit, push again (a plain git push is enough from now on): GitHub shows the new commit.

Agent tips: "my push is refused with this error: [paste]" — GitHub authentication errors are its classics. Trap: NEVER paste your token into a prompt, even to a local agent: paste the error message alone. Proof: the push succeeds on YOUR side; the token stays in your password manager.

Recap (10 min)

Three lines: local vs remote, push and pull, what never goes into a public repository. Then redo a commit + push without notes.

Day 53 — GitHub Pages: the site online

Goal: publish your site at a real URL with GitHub Pages.

Theory (20 min)

GitHub Pages is GitHub's free static site hosting: it takes a repository's files and serves them over HTTP. "Static" means: no server computing anything — HTML, CSS and JS files served as-is. Exactly what you have been writing since day 2.

Going online: on the repository page, Settings → Pages → "Deploy from a branch", pick the main branch, folder / (root), Save. A minute or two later, your site is live at https://YOUR-NAME.github.io/my-site/. Every later git push updates the site by itself — your first continuous deployment.

Two details that matter: the home file MUST be named index.html at the root (that is what the server serves for the folder address); and your internal links must be relative (href="contact.html", never href="file:///home/..." nor a path starting with / — your site lives in the /my-site/ subfolder of the address). That is why we learned relative links on day 6.

Practice (30 min)

1. Make sure your home page is named index.html and your internal links are relative. Commit, push.
2. Enable Pages as above, wait a minute, open the address. Success criterion: your site displays at its public address, styles and images included, and page-to-page navigation works online.
3. If the style is missing: the Network tab will show a 404 on style.css — almost always an absolute path or a case typo (Style.css vs style.css: a Linux server tells uppercase apart; your Windows may not).
4. Change a heading, commit, push, wait a minute, reload with Ctrl+F5 (cache-free reload): the change is live.
5. Share the address with someone. Your work is on the web.

Agent tips: "my GitHub Pages page shows HTML without style" — the agent will answer "path or case", and it will be right nine times out of ten. Trap: it may suggest rewriting everything with absolute paths — that would break /my-site/. Proof: the Network tab, the quoted 404, the file's case on GitHub.

Recap (10 min)

Three lines: what a static site is, index.html's role, why relative links. Then write your site's URL at the top of the notebook.

Day 54 — Finishing touches: favicon, meta, 404

Goal: add the details that make a finished site: tab icon, description for search engines, 404 page.

Theory (20 min)

Three details separate "a file that works" from a polished site:

• The favicon, the small tab icon: a favicon.ico file (or a declared PNG/SVG) at the root: <link rel="icon" href="favicon.svg" type="image/svg+xml">. SVG makes a sharp icon in a few bytes — a simple emoji or initial in a colored square is enough.
• The meta description: the sentence search engines and share previews show under your title: <meta name="description" content="Portfolio of …, beginner web developer: projects, background, contact.">. One honest sentence, unique per page.
• The 404 page: GitHub Pages serves a 404.html file at the root when the requested address does not exist. A home-made error page ("this page does not exist — back to home") beats the server's raw screen.

While in the <head>: check that every page has its own <title> — the tab's name, the search result's title, and the first thing a screen reader announces.

Practice (30 min)

1. Create a simple favicon.svg (a square of your accent color with your initial as SVG text), declare it in every page's head.
2. Add the meta description to every page, with a sentence specific to each.
3. Create 404.html: same structure as your pages, a clear message, a link home.
4. Commit, push. Success criterion: the icon shows in the tab online, and a fake address of your site displays your 404.
5. Reread every page: a unique title, a unique description, the favicon. Finishing is a matter of checklist, not talent.

Agent tips: "generate a simple favicon.svg: #1e5fa8 square, centered white letter A" — the agent writes readable SVG. Trap: check it has put no <script> inside. Proof: open the SVG in the browser — you must see the icon, and its content must fit in a few readable lines.

Recap (10 min)

Three lines: the three details, where each lives, what GitHub Pages does with a 404.html. Then add a meta description from memory.

Day 55 — Capstone 1: the site plan

Goal: design your final project: a three-page personal site, on paper first.

Theory (20 min)

The capstone (end-of-path project): a three-page personal site — Home, Projects, Contact — built by reuniting the whole path. It is the site you will show; it will replace or enrich what you already have online.

Today, not a line of code: we design. A project that starts at the keyboard with no plan ends in a dead end; a project that starts with a pencil finishes.

Today's deliverable, on paper or in your digital notebook:

1. The page plan: for each of the three pages, its sections and their order (e.g. Home: short intro, three featured projects, contact call).
2. The wireframe: each page drawn as labelled rectangles — one rectangle per section, no color, no real text. The wireframe freezes the STRUCTURE before the style.
3. The list of reusable components: the header/nav and the footer will be IDENTICAL on all three pages — copy them, do not reinvent them; the "project" card will repeat three times.
4. The JavaScript feature: ONE, chosen: a menu that opens/closes on mobile, a project filter by tag, or the dark/light toggle. One only, well done.

Practice (30 min)

1. Write the plan of the three pages and draw the three wireframes.
2. List the files to create: index.html, projects.html, contact.html, style.css, script.js, the images.
3. List the finished site's criteria: three linked pages, responsive (readable on a phone), accessible (hierarchical headings, alt, visible focus, AA contrasts), the JS feature, online on GitHub Pages, with a README.
4. Success criterion: you can explain your site in two minutes to someone, plans in hand.

Agent tips: "here is my three-page site plan: [paste] — what is missing, what is too ambitious for three days?" is an excellent use: an outside eye on YOUR plan. Trap: it will propose extra pages and animations. Proof: hold your scope — three pages, one feature.

Recap (10 min)

Three lines: why plan before code, what a wireframe is, your chosen JS feature. Sleep on it; tomorrow we build.

Day 56 — Capstone 2: building the pages

Goal: build the three pages: shared semantic structure, content, styles.

Theory (20 min)

Today's method: structure first, then content, then style. In detail:

1. The template page: build ONE complete page — the skeleton, the header/nav, the footer, the linked CSS, the variables, the font, the grid. It is your master.
2. Duplicate it into index.html, projects.html, contact.html, then adapt each one's main. Header and footer identical to the character: navigation must sit at the same place on every page — an accessibility rule as much as a comfort one.
3. Content first, ugly: fill the three pages with text and images without polishing. An ugly site with its real content can be fixed; a pretty empty site goes nowhere.
4. Style afterwards: cards for the projects, responsive grid, accessible contact form.

Commit after each working step (template, three pages, content, style): four rollback points beat one.

Practice (30 min)

1. Build the template page in your capstone folder, duplicate it into three pages.
2. Fill each main according to yesterday's plan.
3. Apply the style: the project card grid, the accessible form with labels and text errors.
4. Success criterion: the three pages can be visited locally through their links, read on a phone (device mode), and the W3C validator reports no error on any of them.
5. Commit at each step — check with git log --oneline: at least three commits today.

Agent tips: do not delegate the building — it is the exam. But: "proofread this page and list the gaps against the good practices we saw (semantics, alt, contrasts)" at the end of the session. Trap: it will re-fix what is not broken. Proof: accept only defects quoted with their line.

Recap (10 min)

Three lines: the template-duplication method, why content before style, your commits of the day. Tomorrow: the page reacts.

Day 57 — Capstone 3: the JavaScript feature

Goal: add the interactive feature chosen in the plan, keyboard-accessible.

Theory (20 min)

One single feature, well done, respecting the whole path. Three options, three already-learned mechanics:

• The mobile menu: a "Menu" button (a real <button> with aria-expanded) that shows/hides the navigation under 600 px. Mechanics: classList.toggle on the nav + a CSS class that hides it. Accessibility pitfall: the button must stay visible and announce its state.
• The project filter: tag buttons ("site", "script", "design") that only show the cards carrying the tag. Mechanics: each card has a data-tag, the filter walks the cards and hides the non-matching ones.
• The dark/light toggle with localStorage (day 41).

The data-* attributes deserve a word: they are free attributes, invented by you, to stick information onto an element: <article class="card" data-tag="site">. JavaScript reads them with element.dataset.tag. The clean bridge between HTML and JS.

Practice (30 min)

1. Build the chosen feature, step by step, testing in the browser between each.
2. For the filter: at least three cards, at least two tags, an "All" button that shows everything again.
3. Success criterion: the feature works with mouse AND keyboard (Tab to the button, Enter, the result displays), with no page reload.
4. Commit when it works, then reread: your state handling looks like the todo list — change the data, re-render.
5. If you are behind schedule, remember the golden rule: trim here, never on tomorrow's deploy or audit.

Agent tips: if you are stuck: "here is my HTML and my JS, the filter hides nothing, what is wrong?" — paste both files. Trap: the offered full rewrite. Proof: ask for "the smallest possible fix, line quoted".

Recap (10 min)

Three lines: your feature, its mechanism, what data-* enabled. Then test it one last time by keyboard.

Day 58 — Capstone 4: the audit

Goal: audit the whole site: accessibility, responsive, performance, before going online.

Theory (20 min)

Before publishing, we audit — as one proofreads a text before sending it. The grid, entirely drawn from your path:

1. Validation: every page through the W3C validator, zero errors.
2. Structure: one h1 per page, no skipped level, landmarks in place.
3. Keyboard: every page fully usable with Tab/Enter, focus visible everywhere.
4. Alt and links: every image has its right alt, every link makes sense alone.
5. Contrast: AA in light AND dark mode.
6. Responsive: device mode, three sizes (phone, tablet, desktop), no horizontal scrolling.
7. Performance: Lighthouse on every page; resized images, lazy on the lower ones.

Work page by page, one fixed problem at a time, re-measuring after each fix. Keep the list in the notebook: every defect found is one more skill, not a fault.

Practice (30 min)

1. Run the seven points on your three pages, in order, into the notebook: point by point, OK or the defect noted.
2. Fix every defect found, starting with the blockers (keyboard, contrast) before the comforts.
3. Success criterion: the seven points pass on all three pages, and Lighthouse shows 90+ in accessibility on each.
4. Last test, the hardest: have someone who has never seen the site navigate it. Watch without helping. Note every hesitation: those are your last defects.
5. Commit: "audit: contrasts fixed, alts completed, focus visible".

Agent tips: "here is my Lighthouse report and my checklist, in which order should I fix?" — a good use for triage. Trap: the agent will rank by technical ease, not impact. Proof: the ranking rule is yours — blockers (keyboard, contrast) first.

Recap (10 min)

Three lines: the seven points, the fixing order, what the user test revealed. Tomorrow: the world.

Day 59 — Capstone 5: deploy, document, wrap up

Goal: publish the final site, write its README, and take stock of the path.

Theory (20 min)

Last day: two professional gestures, then the wrap-up.

The README: the README.md file at the repository root is the first thing read on GitHub. The Markdown format is text with a few conventions (# Title, ## Section, - list, [text](url)). An honest README for a first site: what it is, the live address, the technologies (HTML, CSS, JavaScript — no framework, and that is a pride), how to run it locally (open index.html), what you learned. Five well-written lines beat a wall of text.

Deployment is already learned: push, and Pages serves. The last check happens ONLINE, not locally: yesterday's audit on the public URL, phone in the other hand.

And the wrap-up: you started from a blank page. You know how the web carries a page, how HTML structures it, how CSS dresses it, how JavaScript makes it react, how to make it usable by everyone, how to measure it, version it and publish it. The logical next step: rebuild a small project with no guide, or take this site's Python path to learn automation.

Practice (30 min)

1. Write the README.md, commit, push, check it displays on the repository page.
2. Open the public URL and rerun the quick audit: three pages, navigation, the JS feature, device mode, a fake address for the 404.
3. Final success criterion: your site is online, the three pages connect, it passes the audit's seven points, and the README says what it is.
4. Check off the path home page's checklist, in full, without cheating.
5. Share the address. Then in the notebook: the hardest session, the one you are proudest of, what you will build next month.

Agent tips: "proofread this README as someone discovering the repository: what is missing to understand and run the project?" is the ideal last-day delegation. Trap: it will write a pompous README for you. Proof: hand the link to someone — if they understand and open the site, the README is good.

Recap (10 min)

Three lines: what a README is, the difference between testing locally and online, your next project. The path is over — the site is online.