Progressive interface foundations
Start with working HTML
Give every project-board action the correct native element before JavaScript adds convenience or visual polish.
An interactive page starts with elements the browser already understands. Use a link for navigation, a button for an action, and a form control for input you plan to submit. You get keyboard support, focus, names, and familiar behavior before you write any JavaScript.
We keep building the same small project board through this course. A task title links to its page. “Add task” opens an editor. “Save” submits data. CSS can make them look alike, but they do different jobs. A clickable div hides that difference and forces you to rebuild keyboard activation, focus styling, disabled state, and accessibility by hand.
Here is the baseline markup:
<nav aria-label="Project">
<a href="/projects/website">Website project</a>
</nav>
<main>
<h1>Website project</h1>
<button type="button" data-action="add-task">Add task</button>
<a href="/tasks/write-homepage">Write homepage</a>
</main>
Notice type="button". Inside a form, a button defaults to submit, so an interface button can accidentally post the form. State the type when the button is not a submit control.
Do not remove focus outlines. Style :focus-visible to match your design, but keep it visible. Tab should reach every action. Buttons activate with Enter and Space. Links activate with Enter and still open in a new tab when the user asks for that.
Progressive enhancement does not mean every feature works with no script. It means you keep a useful core. A server-backed “Add task” link can navigate to a full form. A local demo can show the board and explain that editing needs JavaScript.
Try this on your own project: save the markup above, disable JavaScript, follow the project and task links, then turn JavaScript back on and log clicks on Add task. If Space scrolls the page instead of activating your control, you probably used a generic element instead of a button.
Lesson completed