Learn Frontend Part 2: HTML, Semantic Markup and Accessibility

HTML is the foundation every frontend is built on, and doing it well is about more than making things appear on screen. Semantic HTML tells browsers, search engines and assistive technologies what each part of the page means. That gives you better accessibility, better SEO and less JavaScript, which is why senior frontend interviews increasingly ask about it.

This is Part 2 of the Learn Frontend series. We cover the document structure, semantic elements, forms, accessibility essentials, and the HTML features that affect performance and SEO.

1. The structure of an HTML document

Every page starts with the same skeleton. The <head> holds metadata the user does not see directly; the <body> holds the content.

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width, initial-scale=1">
  <title>Order Summary | MyShop</title>
  <meta name="description" content="Review your order before checkout.">
  <link rel="stylesheet" href="/styles.css">
  <script src="/app.js" defer></script>
</head>
<body>
  <header>...</header>
  <nav aria-label="Main">...</nav>
  <main>
    <h1>Order Summary</h1>
    <article>...</article>
  </main>
  <footer>...</footer>
</body>
</html>

• <!DOCTYPE html> switches the browser into standards mode.
• lang tells screen readers which language and pronunciation to use.
• The viewport meta tag is essential for responsive pages on mobile (Part 4).
• defer on scripts downloads them in parallel and runs them after parsing, so they do not block rendering.

2. Semantic elements: say what things are

A <div> says nothing about its content. Semantic elements describe their role, and assistive technologies use them as landmarks to jump around the page.

Use headings <h1> to <h6> as an outline, not for font size: one <h1> for the page title and no skipped levels. Screen reader users often navigate a page by its headings alone.

3. Forms done right

Forms are where accessibility and user experience matter most.

• Every input needs a <label> connected with for and id (or by wrapping). Clicking the label then focuses the input, and screen readers announce it. A placeholder is not a label.
• Use the right type: email, tel, number, date, password. Mobile keyboards adapt and the browser validates for free.
• Built-in validation attributes such as required, minlength, pattern and min/max give instant feedback before any JavaScript runs. Always validate again on the server.
• Group related controls (such as radio buttons) in <fieldset> with a <legend>.
• Add autocomplete values like email or current-password so browsers and password managers can fill fields.

<form action="/subscribe" method="post">
  <label for="email">Email address</label>
  <input id="email" name="email" type="email" autocomplete="email" required>

  <fieldset>
    <legend>How often should we write?</legend>
    <label><input type="radio" name="freq" value="weekly" checked> Weekly</label>
    <label><input type="radio" name="freq" value="monthly"> Monthly</label>
  </fieldset>

  <button type="submit">Subscribe</button>
  <p id="status" aria-live="polite"></p>
</form>

4. Accessibility essentials

Accessibility (a11y) means people using screen readers, keyboards only, magnification or voice control can use your site. It is also a legal requirement in many countries and improves usability for everyone.

• Text alternatives: meaningful images need alt text describing their purpose; decorative images get alt="" so screen readers skip them.
• Keyboard access: everything clickable must be reachable with Tab and usable with Enter or Space. Native <button> and <a href> do this automatically; a clickable <div> does not.
• Visible focus: never remove focus outlines without a clear replacement style.
• Colour contrast: body text needs a contrast ratio of at least 4.5:1 against its background (WCAG AA), and information should not rely on colour alone.
• ARIA, carefully: the first rule of ARIA is not to use it when a native element exists. Use it to fill gaps, for example aria-expanded on a menu button, aria-live for status messages, or aria-label for an icon-only button.

5. HTML features for performance and SEO

• Script loading: a plain <script> blocks parsing. defer runs scripts in order after parsing; async runs each as soon as it downloads, in any order (good for independent scripts like analytics).
• Images: set width and height to prevent layout shifts, use loading="lazy" for images below the fold, and serve sizes with srcset and sizes.
• Resource hints: <link rel="preload"> for critical fonts or the hero image, preconnect for important third-party origins.
• SEO: a unique <title> and meta description per page, one clear <h1>, descriptive link text (not "click here"), and Open Graph tags for social sharing previews.

These connect directly to Core Web Vitals, covered in Part 9.

Practice problems

Practise these tasks on a page you have built or on any website using DevTools.

1. Rewrite a page built entirely from div elements using header, nav, main, article and footer.
2. Navigate a site using only Tab, Shift+Tab, Enter and Space. Note anything you cannot reach.
3. Run a Lighthouse accessibility audit and fix the top three issues it reports.
4. Build a signup form with labelled inputs, email and password types, required fields and a fieldset for options.
5. Turn on your operating system's screen reader (Narrator, VoiceOver or TalkBack) and listen to a page's headings list.
6. Add width, height and loading="lazy" to images on a page and compare layout shift in DevTools.