A first web page needs a clear job. For this exercise, build a page for a fictional weekend coding workshop: explain what attendees will learn, show the schedule and link to preparation instructions. That gives every design choice something to serve. A visitor should be able to find the start time without guessing which card is clickable.
Begin with a text editor and a browser. A framework can wait until you have a reason to manage repeated components or application state. The early skill is learning how the browser turns a document into something people can read and use.
Write the page before decorating it
Outline the content in plain language: workshop title, short description, date, schedule and preparation. Use one descriptive main heading for this page, followed by headings that describe its sections. Choose a heading level for the content, then set its size with CSS. MDN's HTML syntax guide explains elements, attributes and nesting.
<main>
<h1>Weekend Coding Workshop</h1>
<p>Build a small, readable web page.</p>
<h2>Saturday schedule</h2>
<ul>
<li>10:00: HTML structure</li>
<li>11:00: CSS layout</li>
</ul>
<a href="#preparation">Read preparation instructions</a>
<h2 id="preparation">Preparation</h2>
<p>Bring a laptop and a text editor.</p>
</main>This example deliberately has no registration form. A form creates questions about validation, submissions and personal information. Finish the information page first. In a full standalone document, add a doctype, language attribute, meaningful title and viewport metadata around this body content.
Make the layout survive different text
Start with one column and a comfortable reading width. Let the content choose its height. A fixed-height schedule card may look tidy with two items and cut off a third; the card should grow when the schedule changes. Try this CSS in the HTML and CSS preview:
body {
margin: 0;
font: 1rem/1.6 system-ui, sans-serif;
color: #17212b;
background: #f5f7fa;
}
main {
max-width: 42rem;
margin-inline: auto;
padding: 1.5rem;
}
a { color: #0645ad; }
a:focus-visible { outline: 3px solid #8a2be2; }Use the preview to compare spacing and wrapping. It is an HTML/CSS-only sandbox: scripts and network requests do not run there, and URL attributes such as href are removed. The example's preparation link therefore cannot navigate inside the preview. Remote images and external fonts are outside this exercise.
Resize the page, increase the browser's text zoom and replace the title with a much longer one. The schedule should remain readable without overlapping the preparation link. MDN's responsive design guide covers flexible layouts and the viewport setting; specific device names are a poor substitute for testing where your actual content stops fitting.
Check the page without a mouse
For this check, save the example in a full local HTML document and place the CSS in a style element in its head. Open that file in your browser. Press Tab until the preparation link receives focus, then activate it with Enter. Its destination should be meaningful, and the focus indicator should remain visible. Check that the link text explains its destination without the surrounding paragraph. Use links for navigation and native buttons for actions when you later add them. MDN's HTML accessibility guide explains the built-in behavior these elements provide.
Also read the page in source order. CSS can move a section visually while its keyboard or reading order stays elsewhere. Keep the first version's visual order close to the document order. For informative images, write alternative text that conveys their purpose; decorative images should not add unnecessary spoken content.
A small exercise with a visible result
- Paste the sample HTML and CSS into the lab.
- Add a third schedule item containing a long session title.
- Change the main width from 42rem to 30rem and inspect the wrapping.
- Save a full local HTML page containing the example, then use the keyboard to reach and activate its preparation link there.
The lab result should grow vertically and keep its text inside the content area. The separate local-page check should expose a visible keyboard focus state. If text disappears, inspect fixed heights or overflow rules. If the local link takes no focus, check that it is a real anchor with an href. Link navigation is intentionally unavailable in the lab preview. This is a useful first check, not a complete accessibility audit; assistive technology testing and real-device checks still belong in a finished project.