HTML

Most frontend problems do not start in a framework or build pipeline. They start in the HTML. Bad structure makes accessibility harder, forces JavaScript to replace native behaviour, spreads CSS workarounds, and slows pages down.

These standards describe markup teams can maintain: semantic, accessible, and built for real delivery — not textbook perfection. See code formatting and style for how examples should be laid out.

Use a button when the user triggers an action on the current page. Use a link when the user moves to a URL — another page, a download, or a real in-page destination.

Bad example

<a href="#" onclick="submitForm()">
    Continue
</a>

This looks like navigation but runs script instead. Keyboard and screen-reader users get the wrong affordance, and you lose native submit behaviour including Enter-to-submit in forms.

Good example

<button type="submit">
    Continue
</button>

The control does what users and assistive technology expect. Native behaviour comes for free.

Good forms have visible labels, sensible tab order, clear instructions, and errors that connect to the right fields. Placeholders are hints — not replacements for labels.

What to include

• Visible label elements tied to inputs with for / id
• fieldset and legend for related groups (address, payment, radio sets)
• The right type and inputmode where they help keyboards and validation
• Instructions before users make mistakes, not only after
• Errors linked to fields and announced to assistive technology
• Tab order that follows the visual layout

What to avoid

Do not use placeholders as labels. They disappear when users type, often fail contrast checks, and are easy to miss. Show example text in a hint if you need it — keep the label visible.

Good example

<label for="email">
    Email address
</label>

<input
    id="email"
    name="email"
    type="email"
    autocomplete="email"
>

Fieldsets and legends

Group related controls with fieldset and describe the group with legend. This matters for radio buttons, checkbox groups, and multi-part sections such as billing or delivery — screen-reader users get context they would otherwise have to infer.

If an image does not help someone understand the content or complete a task, question whether it should be there at all.

Alt text

Describe what matters in the image — briefly and in context. Skip filler like “image of” or “picture showing”; they add noise without information.

Decorative images

When an image is purely decorative, use an empty altattribute so assistive technology skips it:

<img src="divider.svg" alt="">

That is the correct pattern, not an omission. Meaningful images still need meaningful descriptions.

Performance

At markup time, set up images so the browser can load them efficiently:

Prefer a single sensible src when one well-sized asset scales cleanly in the layout. Long srcset and hand-writtensizes strings add HTML weight; the file-size win is often negligible unless the image is shown at very different sizes or needs a different crop on small screens.

Use picture when art direction changes (for example a portrait crop on mobile and a landscape crop on desktop). Usesrcset when multiple width variants genuinely save meaningful bytes. With lazy-loaded images, sizes="auto" can let the browser pick a width without guessing media queries — check support before relying on it everywhere.

Accessibility and performance overlap here more than people expect.

Before you ship CSS or JavaScript, ask whether the page still works: Can someone read the content? Submit the form? Follow the links? If the answer is no, fix the HTML — do not patch around it in script.

JavaScript should improve the experience, not be the only reason the experience exists.