Start with working HTML

An interactive interface starts with actions users can understand before your script runs. Use a link for navigation, a button for an action, and a form control for submitted input. Those choices give you keyboard behavior, focus, names, and familiar browser conventions without extra code.

Our continuing project is a small project board. A task title links to its page. “Add task” opens an interface. “Save” submits data. They may look similar after CSS, but they do different jobs. A clickable div hides that distinction and makes you recreate keyboard activation, focus styling, disabled state, and accessibility semantics.

<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 the explicit type="button". The default type of a button associated with a form is submit, so an interface button can accidentally submit a nearby form. State the type when the button does not submit.

Do not suppress focus outlines. Make :focus-visible fit your design while keeping it easy to see. Then reach every action with Tab and activate buttons with Enter and Space. Links activate with Enter and still support opening in a new tab.

The useful no-JavaScript baseline depends on the product. A server-backed Add task link could navigate to a full form. A local-only demo may simply show the board and explain that editing needs JavaScript. Progressive enhancement means preserving the useful core, not pretending every feature can work without code.

Build the markup above in a plain HTML file. Disable JavaScript, follow the project and task links, then enable JavaScript and log clicks on the Add task button. If Space scrolls the page instead of activating your control, you probably used a generic element instead of a button.