Back to Subject

Unit 2: Semantic HTML and Forms

CSE326 — Internet Programming 7 min read

I. Orientation: Semantics, Structure and the Accessibility Contract

HTML5 (W3C Recommendation, October 2014; now maintained as the WHATWG HTML Living Standard) shifted authoring away from presentational markup toward meaning. A <div class="header"> tells a browser nothing; a <header> tells it, and every assistive technology and search crawler reading it, what the region is. Every topic in this unit rests on the same contract: markup declares meaning, CSS declares appearance, and the accessibility tree is derived automatically from the former.

  • Semantic element: an element whose name describes the role of its content rather than its rendering — <article>, <nav>, <time>. Contrast <b> and <i>, which are presentational survivors retained for typographic convention only.
  • Non-semantic element: <div> (block) and <span> (inline) — generic containers carrying no meaning; used only when no semantic element applies.
  • The accessibility tree: a parallel structure the browser builds from the DOM, exposing each node's role, name, state and value to screen readers via platform APIs (MSAA/UIA on Windows, AX on macOS).
  • Implicit ARIA role: every semantic element ships with one for free. <nav> → role="navigation", <main> → role="main", <button> → role="button". This is why "use the right element" beats "add ARIA".
  • Content model: HTML5 replaced block/inline with categories — flow, phrasing, sectioning, heading, embedded, interactive. <p> accepts phrasing content only, so a <div> inside a <p> is invalid.
  • Document outline: derived from <h1>–<h6> and sectioning elements; screen-reader users navigate by heading far more than by reading linearly.

II. Semantic HTML Elements

The vocabulary of meaning

A. The sectioning and grouping vocabulary

Semantic elements divide into sectioning elements (which create outline entries) and text-level elements (which annotate phrases).

  • <article>: independently distributable content — a blog post, a comment, a product card. Test: would it still make sense syndicated in an RSS feed alone?
  • <section>: a thematic grouping, normally requiring a heading. <section> without a heading is usually a misused <div>.
  • <nav>: major navigation blocks only. A footer's three legal links need no <nav>; the primary menu does.
  • <aside>: tangentially related content — pull quotes, sidebars, related links.
  • <header> / <footer>: scoped to their nearest sectioning ancestor. An <article> may hold its own <header> with byline and <time datetime="2026-08-04">.
  • <figure> / <figcaption>: binds an image, diagram or code listing to its caption programmatically.
  • Text-level: <em> (stress emphasis) vs <i> (alternate voice, e.g. taxonomic names); <strong> (importance) vs <b> (keywords without importance); <mark>, <abbr title="…">, <code>, <time>.
HTML
<article>
  <header><h2>Semantic Markup</h2>
    <p>By A. Rao · <time datetime="2026-08-04">4 Aug 2026</time></p>
  </header>
  <p>HTML5 introduced <abbr title="Accessible Rich Internet Applications">ARIA</abbr>-mapped elements…</p>
</article>

B. Page Structure and Layout

A page's skeleton should be readable as an outline with CSS disabled.

  • <main>: exactly one per document, holding content unique to that page; must not be nested in <article>, <aside>, <header>, <footer> or <nav>. It is the target of "skip to content" links.
  • Canonical skeleton: <body> → <header> (banner) → <nav> → <main> → <aside> → <footer> (contentinfo).
  • Landmarks: banner, navigation, main, complementary, contentinfo, search, form. Screen readers offer a landmark rotor; a <div>-only page presents an empty rotor.
  • Disambiguating repeats: two <nav> elements need distinguishing names — <nav aria-label="Primary"> and <nav aria-label="Breadcrumb">.
  • Heading hierarchy: one <h1> describing the page, then descending without skipping levels. <h1> → <h3> signals a missing section to a rotor user.
  • Layout belongs to CSS: Grid places <main> and <aside> visually; order and grid-area change visual order only — DOM order still governs tab and reading order, so avoid divergence.

III. Forms and Form Controls

Collecting and validating user input

A. Forms and Form Controls

A form is a container that serialises named controls into a request.

  • <form> attributes: action (endpoint URL), method (get appends a query string, for idempotent searches; post puts data in the body, for state changes), enctype (multipart/form-data is mandatory for <input type="file">), novalidate (suppresses native validation).
  • The name attribute: only named controls are submitted. name="email" with value a@b.com serialises as email=a%40b.com; id is for label binding and CSS, not submission.
  • Controls: <input>, <textarea> (sized by rows/cols, value is its text content), <select> with <option>/<optgroup> and multiple, <button> (type="submit" is the default inside a form — set type="button" for JavaScript-only buttons), <datalist> for suggestion lists, <output> for computed results.
  • Grouping: <fieldset> + <legend> groups related controls; the legend is announced with each radio in the group, which is the only reliable way to name a radio set.
  • Labels: explicit <label for="id"> or wrapping. A label enlarges the click target and gives the control its accessible name.
HTML
<fieldset>
  <legend>Delivery speed</legend>
  <input type="radio" id="std" name="ship" value="standard" checked>
  <label for="std">Standard (5 days)</label>
  <input type="radio" id="exp" name="ship" value="express">
  <label for="exp">Express (24 hours)</label>
</fieldset>

B. Input Types and Attributes

The type attribute selects a control's UI, on-screen keyboard and validation algorithm.

  • Text-like: text, email (validates one @), url, tel (no validation — pattern it yourself), password, search.
  • Numeric and temporal: number (with min, max, step), range (slider), date, time, datetime-local, month, week.
  • Other: checkbox, radio, file (accept=".pdf,image/*", multiple), color, hidden.
  • Attributes:
    • Constraint: required, min, max, minlength, maxlength, step, pattern (an anchored JS regex).
    • Behavioural: placeholder (a hint, never a label substitute — it vanishes on focus), autocomplete="email" (WCAG 1.3.5 relies on it), readonly (submitted) vs disabled (not submitted), autofocus, inputmode="numeric".

C. Form Validation Basics

Constraint validation runs in the browser before submission and exposes state to CSS and JavaScript.

  • Order: on submit, the browser checks each control; the first invalid one is focused and shows a native bubble; submission is blocked.
  • ValidityState: input.validity exposes valueMissing, typeMismatch, patternMismatch, rangeUnderflow, rangeOverflow, tooLong, stepMismatch, and valid.
  • Custom messages: input.setCustomValidity("Passwords must match") marks the control invalid until called with "".
  • Styling: :required, :invalid, :valid, and :user-invalid — the last only matches after interaction, avoiding red borders on an untouched form.
  • Client vs server:
    1. Client-side: instant, no round trip, improves UX — but trivially bypassed via devtools or curl.
    2. Server-side: authoritative; the only defence against injection and tampering. Client validation is a convenience, never a security control.
HTML
<label for="pin">6-digit PIN</label>
<input id="pin" name="pin" type="text" inputmode="numeric"
       pattern="\d{6}" required aria-describedby="pinHelp">
<p id="pinHelp">Exactly six digits.</p>

IV. Tables and Data Representation

Marking up two-dimensional relationships

A. Tables and Data Representation

A table encodes data whose meaning depends on the intersection of a row and a column — never page layout.

  • Structure: <table> → <caption> (the table's accessible name, first child) → <thead>/<tbody>/<tfoot> → <tr> → <th>/<td>.
  • scope: <th scope="col"> and <th scope="row"> tell a screen reader which cells a header governs. Without it, "42" is announced bare; with it, "Rainfall, June, 42".
  • Complex tables: id on headers plus headers="h1 h2" on cells handles irregular spans; prefer splitting into simpler tables.
  • Spanning: colspan / rowspan; <colgroup>/<col> for column-wide styling.
  • Responsive tables: wrap in a scrollable container with overflow-x:auto and tabindex="0" so keyboard users can scroll it, rather than restacking cells and destroying header association.

V. Accessibility

Designing for the full range of users

A. Accessibility Fundamentals

Accessibility means the interface is operable by users with visual, motor, auditory or cognitive impairments, using keyboards, screen readers or switch devices.

  • Accessible name: computed in order — aria-labelledby, then aria-label, then <label>/alt/<caption>, then contents.
  • Alt text: alt describes function, not appearance (alt="Search" on a magnifier icon); decorative images take alt="" to be skipped.
  • Keyboard operability: every interactive element must be reachable by Tab and triggered by Enter/Space. <div onclick> fails both; <button> gets them free.
  • Focus visibility: never outline: none without a replacement :focus-visible style.
  • ARIA rules: no ARIA is better than bad ARIA; do not change native semantics (<button role="heading">); aria-live="polite" announces asynchronous validation errors.

B. Accessibility Standards

WCAG 2.1 (W3C Recommendation, June 2018) is the reference standard, organised under four principles and three conformance levels.

  • POUR: Perceivable (1.1.1 non-text content), Operable (2.1.1 keyboard, 2.4.7 focus visible), Understandable (3.3.2 labels or instructions), Robust (4.1.2 name, role, value).
  • Levels: A (minimum), AA (the legal target of the EU Web Accessibility Directive and Section 508), AAA (rarely required site-wide).
  • Contrast: 4.5:1 for normal text and 3:1 for large text (≥18.66px bold or ≥24px) at AA — 1.4.3.
  • WAI-ARIA 1.2: supplies roles, states and properties for widgets HTML lacks, e.g. role="tab" with aria-selected.

C. Responsive Content Structuring

Responsive design begins in the markup: source order and element choice determine what CSS can do at any breakpoint.

  • Viewport meta: <meta name="viewport" content="width=device-width, initial-scale=1">; omit it and mobile browsers assume a ~980px canvas and shrink everything.
  • Responsive images: srcset with w descriptors plus sizes lets the browser pick by resolution; <picture> with <source media="…"> handles art direction — a cropped portrait on narrow screens.
  • Mobile-first source order: author the DOM in logical reading order and rearrange with Grid, so a linearised narrow view remains coherent.
  • Fluid units: rem for type (respects the user's browser font size, unlike px), %/fr/minmax() for layout, clamp(1rem, 2.5vw, 1.5rem) for fluid scaling.
  • Touch targets: WCAG 2.5.5 advises a minimum of 44×44 CSS pixels — a concern for tightly stacked checkbox lists and inline links.
  • Preferences: @media (prefers-reduced-motion: reduce) and (prefers-color-scheme: dark) respond to OS-level accessibility settings.
Previous
Unit 1
Next
Unit 3