1Internet, Web, client-server, HTTP/HTTPS and URLs

Textbook chapters 1, 2

The Internet and the World Wide Web are not the same thing

The Internet is the wiring of the world: cables, radio links, routers and billions of connected devices, plus the rules (protocols) that move data between them. It is a network of networks: your phone joins the home router, the router joins an Internet service provider, and providers join bigger networks across the globe. No single company owns it and no single computer is it.

• Data travels in small packets, each labelled with its destination address; routers pass them on like road junctions.
• TCP/IP holds it together: IP addresses and moves packets; TCP makes sure they all arrive in order.

The World Wide Web (the Web, WWW) is one service that runs on top of the Internet: web pages written in HTML, joined by hyperlinks, fetched with HTTP and named by URLs. HTML, HTTP and URLs were invented together at CERN in 1989-91, long after the Internet began. Many other services share the same roads but are not the Web, because they use their own protocols and are not made of web pages.

Client and server: who asks, who answers

Every web visit is a conversation between two programs. This is the client-server model. The client asks; the server answers.

What the server sends back is a response: a status code plus the content, usually HTML for a page or JSON for data (sometimes an image or PDF). It is text, not a picture of the page; the browser interprets and draws it.

HTTP and HTTPS

HTTP = HyperText Transfer Protocol. It is the protocol used to exchange web requests and responses: a fixed set of rules for how a request and a reply are worded, so any browser can talk to any server. In HTTP/1.1, the version shown here, the messages are plain text (newer HTTP/2 and HTTP/3 pack the same requests into binary frames):

Browser sends:
GET /timetable.html HTTP/1.1
Host: www.citycollege.org

Server replies:
HTTP/1.1 200 OK
Content-Type: text/html

<!DOCTYPE html><html lang="en"> ...

• GET asks for a resource; POST sends data (such as a form) in the body.
• Status codes by first digit: 2xx success (200 OK), 3xx redirect, 4xx client error (404 Not Found), 5xx server error.

The request-response cycle, step by step

1. Click: the user clicks a link or types a URL.
2. (DNS lookup: the browser turns the domain name into an IP address.)
3. Request: the browser (client) sends an HTTP request to that server.
4. Server processes: it reads a file, or runs code and queries its database.
5. Response: it sends back a status code and the content (HTML or JSON).
6. Render: the browser draws the page, requesting each CSS file, image and script the HTML mentions (unless already cached).

Reading a URL part by part

A URL (Uniform Resource Locator) is the address the browser requests. Read it like a postal address: how to deliver, which building, which room, plus a note.

https://lib.citycollege.org/books/find.html?title=html&year=2026
|       |                  |               |
|       |                  |               +-- query string (extra data)
|       |                  +-- path (which file)
|       +-- domain (which server)
+-- protocol (how to fetch)

An absolute URL has the protocol and domain and means the same thing anywhere; a relative URL such as find.html is completed by the browser from the current page's address.

2HTML5 document structure, head vs body, meta tags, elements and attributes

Textbook chapters 3, 4, 5, 11, 12

The skeleton, the doctype and the root element

Every HTML5 page starts with the same skeleton. Learn it once and reuse it in every file.

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <title>Hostel Mess Menu</title>
</head>
<body><h1>This Week's Menu</h1></body>
</html>

• Line 1, <!DOCTYPE html>, tells the browser to use the modern HTML5 parsing rules (standards mode). It is a declaration, not an element, and has no closing tag. Case does not matter: <!doctype html> works too. Leave it out and the browser drops into quirks mode, copying 1990s layout rules, so spacing and box sizes go subtly wrong.
• <html> is the root element: the single container that holds everything else. It has exactly two children, <head> first and then <body>. Head and body are siblings inside html, so neither is the root. The doctype sits above html but is not an element at all, so it cannot be the root either.
• lang="en" on html declares the language the content is written in (hi = Hindi, pa = Punjabi). Screen readers use it to choose the right pronunciation; browsers use it to offer translation and to pick spell-check and hyphenation rules. It does not translate the page, restrict fonts or stop anyone typing other characters.

The browser reads the page as a tree

The browser does not keep your file as one long string, a flat list of separate tags, or a grid of rows and columns. It parses the markup into a nested tree of elements, called the DOM (Document Object Model). Every element is a node with one parent and possibly children; CSS and JavaScript work by walking this tree, and DevTools (F12, Elements panel) shows it.

html
 +-- head
 |    +-- meta
 |    +-- title
 +-- body
      +-- h1

Because it is a tree, nesting must be clean: last opened, first closed. <p><em>hi</em></p> is right; <p><em>hi</p></em> crosses over and forces the browser to guess.

Head or body: one question decides

The head holds metadata, information about the page; nothing in it is drawn on the page. The body holds everything the reader sees or uses. Ask one question: is it drawn on screen? Yes means body; information about the page means head.

<script> may go in either place: in the head with defer (so it waits until the page is parsed), or just before </body>. It is never drawn, so it is the one common exception to the rule.

The three meta tags to know

<meta> is a void element (no closing tag) that supplies one piece of metadata. Each of these three has exactly one job:

• charset is not about fonts (fonts are CSS font-family), not about phones (viewport) and not the search summary (description). Put it first in the head.
• The description is not shown in the browser tab (that is the title) or as a heading on the page (that is h1). It is not invisible either: people read it on the search results page, where a good one wins the click. Engines sometimes show other text from the page instead.

The title element versus the h1 heading

<head><title>Library Timings | Central Library</title></head>
<body><h1>Library Timings</h1></body>

Elements versus attributes

<abbr title="Cascading Style Sheets">CSS</abbr>

Global attributes can be applied to almost any element: id (a unique name for one element), class (a reusable group name), style, title (tooltip), lang, hidden and data-*. Most other attributes belong to one family of elements:

So for an attribute that works on almost any element, choose a global one such as id; href, src and action are tied to links, embedded files and forms.

Block-level and inline elements

Block-level elements start on a new line and stretch across the full width, stacking like bricks. Inline elements flow inside a line of text and take only the width of their content, like one bold word in a sentence. CSS can change either, but these are the defaults.

<div> and <span> carry no meaning: div is the generic block container and span the generic inline one, for a few words inside a line.

<p>Last date: <span class="due">31 March</span> for fee payment.</p>

The span lets CSS colour just the date without breaking the line. Usually inline goes inside block. The main exception is <a>, which in HTML5 may wrap block content such as a whole card. A <p>, however, can never contain a <div>, so the browser closes the paragraph early.

Repairing a broken fragment

<h2>Canteen Menu<h3>
<img src="thali.jpg">
<a>Order online</a>

<h2>Canteen Menu</h2>
<img src="thali.jpg" alt="Veg thali with rice, dal and roti">
<a href="order.html">Order online</a>

3Text formatting, headings and lists

Textbook chapters 6, 7, 12

Headings build the outline, not the font size

HTML has six heading levels, <h1> (highest) to <h6> (lowest). They are the page's contents list: h1 the title, h2 the chapters, h3 the sections inside a chapter. Bigger text is only a side effect. Screen-reader users jump from heading to heading, and search engines read headings to learn what the page is about.

• Exactly one h1 per page, naming the page's main topic. Not one per paragraph, not "as many as look nice", and never none: headings are structure, not decoration. A second h1 is not a syntax error, but it blurs which topic is the main one.
• Do not skip levels. After h1 comes h2, then h3. Jumping from h1 straight to h4 leaves holes in the outline that screen-reader users and search engines both rely on.
• Never pick a level for its size. Want a smaller subheading under an h2? Use h3 and shrink it with CSS.

<h1>City Public Library</h1>
<h2>Timings</h2>
<h3>Weekend hours</h3>
<h2>Membership</h2>

Meaning versus looks: strong/b and em/i

Logical (semantic) elements say what text means; physical (presentational) elements only say how it looks. Both families exist in HTML5 and look identical on screen, so choose by meaning: a screen reader can act on meaning, never on "make this bolder".

<p><strong>Warning:</strong> unplug the iron after use.</p>
<p>Our new model is the <b>Nova X</b>.</p>
<p>The tiger is <i>Panthera tigris</i>.</p>

The rest of the formatting kit

Three kinds of list: ask "does the order matter?"

<dl>
  <dt>Browser</dt>
  <dd>A program that fetches and shows web pages.</dd>
  <dt>Server</dt>
  <dd>A computer that stores pages and sends them on request.</dd>
</dl>

• The browser numbers an ol by itself; never type "1." yourself.
• "The items are related" is no reason for ul: steps are related too, but their order is the information.
• Numbers are no reason for a table. Tables are for grids of data in rows and columns.
• A description list never uses li. Its children are dt and dd pairs.

Numbering an ordered list: type, start, reversed

Memory rule: the case you type is the case you get. Capital I gives capital Roman numerals; small i gives small ones. <li value="10"> sets one item's number, and later items continue from it. Bullet shapes on a ul are changed with CSS (list-style-type), not with type.

<ol type="I">
  <li>Introduction</li>
  <li>Survey</li>
  <li>Findings</li>
</ol>  <!-- shows I. II. III. -->

Nesting a list inside a list

Only li elements may sit directly inside a ul or ol. Loose text, a p, or a whole second list placed straight inside the list is invalid. An li, however, can hold anything, including a complete sub-list. So a sub-list goes inside the li it belongs to: after that item's text, before its closing tag.

<ul>
  <li>Fruits
    <ul>
      <li>Mango</li>
      <li>Guava</li>
    </ul>
  </li>
  <li>Vegetables</li>
</ul>

4Hyperlinks, images and link text (SEO)

Textbook chapters 8, 11, 12

The anchor element and where href can point

A link is an <a> (anchor) element. Its href attribute (hypertext reference) holds the destination; the words between the tags are the clickable link text. No href, no link. Do not confuse it with <link>, which sits in the head and attaches resources such as a stylesheet or the tab icon; it never makes anything clickable.

<a href="#timetable">Jump to the timetable</a>
<!-- ...a long page... -->
<section id="timetable">
  <h2>Timetable</h2>
</section>

Email and phone links: mailto: and tel:

Two special schemes hand the click to another app on the visitor's device:

• mailto: opens the visitor's email program with a new message to that address.
• tel: lets a phone user dial the number with one tap. Include the country code (+91 for India).
• sms: also exists, but it opens a text message rather than a call.

<a href="mailto:office@school.example">Email the office</a>
<a href="tel:+911234567890">Call the office</a>

Opening a new tab safely: target and rel

• target="_blank" opens the link in a new tab (the default, _self, reuses the tab). Use it sparingly: the new tab has no Back history, so the visitor cannot press Back to return to your page.
• rel states the relationship between this page and the linked one. Rule: whenever a new tab shows an outside or untrusted page, pair it with rel="noopener noreferrer".
• noopener: the new page cannot reach back through window.opener and control your tab (for example, quietly swapping it for a fake login page). noreferrer: the new site is not told which page the visitor came from.

<a href="https://shop.example.net" target="_blank"
   rel="noopener noreferrer">Visit the partner shop (opens a new tab)</a>

Link text that names the destination

Screen-reader users often call up a list of every link on the page; "click here, more, here, »" tells them nothing. Search engines also read link text as a label for the page it points to. So link text should say where the link goes or what it gets you, and make sense on its own.

The image element: src and alt

<img> is a void element (no closing tag). Treat two attributes as mandatory: src, the resource location (a relative path or a full URL), and alt, a meaningful text alternative. In short: src says where the file is, alt says what the image means.

<img src="images/lab.jpg"
     alt="Students soldering circuits in the electronics lab"
     width="600" height="400" loading="lazy">

alt does three jobs: a screen reader speaks it, the browser shows it in place of a picture that fails to load, and search engines use it to index the image. Other jobs belong to other attributes and elements:

To make an image a link, put the img inside an a. Its alt then becomes the link text, so it should name the destination.

Writing alt text for each kind of image

Imagine reading the page to a friend over the phone: whatever you would say in place of the picture is its alt text.

So a printer icon on a print button gets alt="Print": that is what pressing it does.

Responsive images: srcset, sizes and picture

A phone on mobile data should not download the huge photo a desktop monitor needs.

• srcset lists several image files, each with its real width (400w means 400 pixels wide). The browser picks the one that suits the screen's size and sharpness.
• sizes tells the browser how wide the image will be displayed, which it needs to make that choice.
• src remains the fallback for browsers that ignore srcset.

<img src="hall-800.jpg"
     srcset="hall-400.jpg 400w, hall-800.jpg 800w, hall-1600.jpg 1600w"
     sizes="(max-width: 600px) 100vw, 600px"
     alt="Convocation hall on graduation day">

<picture> goes further: several <source> elements, each with a condition (a media query or a file type), plus an <img> inside as the required fallback. The browser uses the first source that matches.

5SVG graphics

Textbook chapter 9

Raster versus vector: why a logo should be SVG

A JPG or PNG is a raster image: a grid of coloured pixels. Enlarge it and the browser has to invent pixels that were never stored, so edges turn blurry or blocky. An SVG (Scalable Vector Graphics) file stores drawing instructions instead, such as "circle, centre here, this radius, orange". The browser redraws those instructions at whatever size is needed, so the picture remains crisp however far you zoom and on any size of screen.

Photo versus knitting pattern: enlarge a photo and you see grain; knit the pattern in thicker wool and you get the same design, bigger and just as neat. So logos, icons and diagrams are SVG; photographs stay JPG.

Use it as a file (<img src="badge.svg" alt="Robotics Club">) or inline as an <svg> element that CSS and JavaScript can style. Inside inline SVG, end every shape with />; an unclosed shape swallows the shapes after it.

The canvas: width, height and viewBox

• width and height set how big the drawing appears on the page.
• viewBox="min-x min-y width height" defines the drawing's own grid of units (its coordinate system): the graph paper every shape is measured on. The browser then maps that grid onto the rendered size.
• The origin (0,0) is the top-left corner and y grows downward, unlike school graphs.
• Anything outside the viewBox is clipped: silently not drawn, no error.
• preserveAspectRatio (default xMidYMid meet) decides how the grid is fitted and centred when the proportions differ.

<svg viewBox="0 0 200 100" width="400">
  <rect x="0" y="0" width="100" height="50"/>
</svg>

The basic shapes and their attributes

Every shape has its own vocabulary. Ask first: is it measured from a corner, from a centre, or from two endpoints?

<rect x="20" y="10" width="80" height="40" rx="8"/>
<circle cx="150" cy="30" r="20"/>
<ellipse cx="220" cy="30" rx="30" ry="15"/>  <!-- wide oval -->
<ellipse cx="290" cy="30" rx="15" ry="30"/>  <!-- tall oval -->
<ellipse cx="360" cy="30" rx="20" ry="20"/>  <!-- perfect circle -->

Wrong vocabulary is not an error message; the browser simply ignores attributes a shape does not understand. A circle written with x and y keeps its default centre (0,0), so only a quarter of it peeps out of the top-left corner. A rect given cx, cy and r has no width or height, so nothing appears. An ellipse ignores r; without rx and ry it has no size.

<line x1="10" y1="80" x2="250" y2="80"/>                 <!-- invisible -->
<line x1="10" y1="80" x2="250" y2="80" stroke="teal"/>  <!-- visible -->

<polyline points="10,90 50,10 90,90" fill="none" stroke="red"/>  <!-- open ^ -->
<polygon  points="10,90 50,10 90,90" fill="none" stroke="red"/>  <!-- closed triangle -->

Give a polyline fill="none": the default fill is black, which would colour the wedge between its points.

Painting: fill and stroke

Memory hook: fill is paint poured inside; stroke is the pen line around the edge. So fill paints the interior and stroke paints the edge line, never the other way round. Neither sets size, transparency or rotation. Both take any CSS colour; fill="none" makes a shape hollow.

<circle cx="60" cy="60" r="40"
        fill="none" stroke="crimson"
        stroke-width="3" stroke-dasharray="12,4"/>

The path language: M, L, H, V, Q, Z

<path> can draw anything. Its d attribute is a list of commands, each a letter followed by numbers.

Uppercase letters are absolute: "go to this point on the grid". Lowercase letters are relative: each number is an offset from where the pen is now. Lowercase is valid, is used in a path's d attribute, and normally lands somewhere different from the uppercase version.

<path d="M10 90 L50 10 L90 90 Z"/>    <!-- absolute -->
<path d="M10 90 l40 -80 l40 80 z"/>   <!-- relative: same triangle -->

Text, groups and accessibility

• <text x="40" y="90">Lab 3</text> places a label; <g> groups shapes so they move or are styled together.
• Inline SVG has no alt attribute: give it role="img" plus aria-label, or aria-hidden="true" if purely decorative.

6Multimedia: audio, video and iframes

Textbook chapter 10

Native media in HTML5

Before HTML5, playing sound or film needed a plug-in such as Flash. Now the browser plays media itself and supplies the play button, volume and progress bar. <audio> and <video> follow one pattern:

• The element itself is paired: it always needs its closing tag.
• One or more <source> children (void) point at the media files.
• Optional <track> children (void) add captions.
• Text between the tags is shown only by a very old browser that does not understand <audio>/<video> at all. If no source format is playable, a modern browser shows an empty player instead, not the text. Audio and video have no alt attribute, and there is no <fallback> element.

<audio controls preload="none">
  <source src="anthem.mp3" type="audio/mpeg">
  <source src="anthem.ogg" type="audio/ogg">
  Sorry, your browser cannot play this audio.
</audio>

For audio that carries information (a lecture, an announcement), also provide a transcript.

The playback attributes

<video controls width="480" poster="fest-still.jpg">
  <source src="fest.mp4" type="video/mp4">
  Your browser cannot play video.
</video>

source and track

Browsers do not all decode the same formats. Several <source> children are a shortlist, not a playlist: the same film saved in different formats. The browser reads them top to bottom and plays the earliest one in the list that it is able to decode, ignoring the rest. The type attribute lets it skip an unplayable file without downloading it.

<video controls>
  <source src="trailer.webm" type="video/webm">
  <source src="trailer.mp4"  type="video/mp4">
</video>

<track> attaches timed text from a WebVTT (.vtt) file: kind (subtitles, captions, descriptions, chapters), srclang, label (the name in the player menu) and default. It is void and goes after the sources. Subtitles never come from <caption> (tables) or <source> (media files), and there is no subtitle element.

<track src="talk-en.vtt" kind="captions" srclang="en" label="English" default>

iframe: a window into another page

An inline frame embeds a whole separate document, with its own URL, inside yours: a map, a video player, a payment form, a dashboard. What loads inside it is not part of your page's DOM.

<iframe src="https://maps.example.org/embed?q=library"
        width="600" height="260"
        title="Map showing the central library"
        loading="lazy"></iframe>

The width and height attributes take whole numbers of pixels only. For a full-width frame use CSS, for example the stylesheet rule iframe { width: 100%; }, not width="100%".

Embedding responsibly

Embedding is a trade. The other site's scripts run in your visitor's browser, so a third-party frame can drop cookies, follow your visitors from site to site, and make your page load more slowly. Habits that limit the damage:

• Embed only from trusted sources, and add loading="lazy" so off-screen frames cost nothing.
• Use sandbox to grant only what the widget needs. An empty sandbox blocks scripts, forms and pop-ups, so a widget that dies after you add it has lost its scripts: add allow-scripts.
• Use allow to switch on fullscreen or camera only where needed.
• A big site that shows a blank frame is refusing to be framed (an X-Frame-Options or Content-Security-Policy header). Nothing in your HTML overrides it; use the site's official embed address, such as a video site's /embed/ link.

7Semantic elements and page structure

Textbook chapters 13, 14

What "semantic" means

Definition. A semantic element is one whose name describes the meaning and purpose of its content. <nav> says "these are navigation links"; <footer> says "this is closing information". A non-semantic element such as <div> or <span> says nothing about its content: it is just a box.

On screen, <div class="header"> and <header> look the same: both are plain block boxes. The difference is for machines:

• Screen readers announce semantic regions as landmarks, so a blind user jumps with one key to the main content, menu or footer. On an all-div page they must hear the whole menu on every visit.
• Search engines tell real content apart from repeated boilerplate.
• Developers read the page structure from the tag names alone.

<!-- just boxes: no meaning -->
<div class="menu">...</div>
<div class="content">...</div>

<!-- same look, now a map machines can read -->
<nav>...</nav>
<main>...</main>

The seven page-structure elements

Rules for main: A page should have one main element, and never more than one visible main (extra ones must carry the hidden attribute). It must not sit inside <article>, <aside>, <header>, <footer>, <nav> or <section>, because it is the dominant content of the whole document. Site-wide repeats (logo, menu, copyright) stay outside it. By contrast, <section>, <article> and <div> may appear as often as the content needs.

nav: wrap the whole group once

<nav> marks a navigation region, not a single link. Put one <nav> around the whole group, usually around a list of links. Main menus, breadcrumbs, pagination links and a table of contents are each a group of links, so each gets its own <nav>. When a page has two or more, give each an aria-label so a screen reader can tell them apart.

<nav aria-label="Breadcrumb">
  <ol>
    <li><a href="/">Home</a></li>
    <li><a href="/shoes/">Shoes</a></li>
    <li><a href="/shoes/running/" aria-current="page">Running</a></li>
  </ol>
</nav>

section, article, aside or div?

Ask these questions in order:

1. Would the block still make sense on another website or in a news feed? <article>.
2. Related to the main content but removable without loss? <aside>.
3. A themed part of this page with its own heading? <section>.
4. None of these; it exists only for CSS? <div>.

A "related stories" sidebar is an <aside>: extra content next to the story. It is not the site's navigation (<nav>), not the closing information (<footer>) and not the introduction (<header>).

Every section should have a heading. The heading lets assistive technology summarise the section and lets users jump between sections by heading. The page renders and takes CSS perfectly well without one; the heading is for meaning, not display. If a block has no natural heading, it was probably never a section: use a <div>.

div is still right as a generic styling wrapper with no meaning of its own: a grid container, a card shell, a box for a background colour. It is the wrong choice for anything a semantic element already describes, such as a copyright notice (footer), the main menu (nav) or a blog post (article).

Assembling the page skeleton

A page is a tree: <html> holds the invisible <head> and the visible <body>; the body holds the regions, in reading order; CSS arranges them into columns later.

<body>
  <header><h1>City Library</h1> <nav>...</nav></header>
  <main>
    <section><h2>New arrivals</h2>
      <article><h3>Review: a mystery novel</h3>...</article>
    </section>
    <aside><h2>Events this week</h2>...</aside>
  </main>
  <footer>&copy; 2026 City Library <address>12 Mall Road</address></footer>
</body>

• Page header: logo or site title and usually the main nav (header > nav).
• Where articles and asides go: in the usual skeleton they sit inside the main region. Never inside <head> (metadata only) and not inside the page header or footer. (A site-wide sidebar placed beside main is also valid, but asides about the page content belong in main.)
• Page footer last: copyright, contact details in <address>, small print. This is closing information, not a related extra (aside), not a link group (nav) and not a themed block (section).
• Repeats: <header> and <footer> may appear again inside an article (byline on top, tags below). Only main is limited: never more than one visible main per page.
• Headings follow regions: one h1 in the page header, an h2 per section, an h3 per article.

8Accessibility: POUR, WCAG, ARIA and keyboard access

Textbook chapters 15, 20

What web accessibility is

Web accessibility is the practice of building sites that people with visual, auditory, motor or cognitive disabilities can perceive, understand, navigate and use. In short: nobody is locked out.

• Visual: blind users hear the page through a screen reader (NVDA, JAWS, VoiceOver, TalkBack); low-vision users zoom or magnify.
• Auditory: deaf users need captions and transcripts.
• Motor: some users cannot hold a mouse and use only the keyboard, a switch or voice control.
• Cognitive: clear language, consistent menus and helpful error messages.

It helps everyone: captions on a noisy bus, good contrast in sunlight, keyboard shortcuts for power users. Most of it is simply correct HTML: lang, real headings, alt text, labels, landmarks and native controls.

WCAG and its conformance levels

WCAG stands for Web Content Accessibility Guidelines, the international standard published by the W3C through its Web Accessibility Initiative (WAI). Versions: 2.0 (2008), 2.1 (2018), 2.2 (2023); each later version adds criteria to the earlier one (2.2 also dropped one obsolete rule, 4.1.1 Parsing). Structure: 4 principles (POUR), then guidelines, then testable success criteria, each given a level.

Levels are cumulative: AA means every A and every AA criterion passes. When a policy says "WCAG 2.x compliant" it almost always means Level AA. India's RPwD Rules 2017 require government sites to follow GIGW, which adopts WCAG 2.1 Level AA; the US Section 508 and the EU's EN 301 549 also point to WCAG Level AA.

POUR: the four principles

Keyboard access and tabindex

Many users never touch a mouse. Tab moves to the next control, Shift+Tab to the previous one, Enter follows a link or presses a button, Space toggles a checkbox or presses a button, and the arrow keys move inside radio groups and menus. Native links (<a href>), buttons and form controls are focusable and keyboard-operable for free; a <div onclick> is not. Never remove the focus outline without a replacement. A skip link at the top (<a href="#main">Skip to main content</a>) lets keyboard users bypass the menu.

<div class="seat" tabindex="0">Seat 14B</div>
<!-- Tab now stops here, in source order.
     Enter and Space still need a script. -->

ARIA: role, aria-label, aria-hidden and the first rule

ARIA (WAI-ARIA, Accessible Rich Internet Applications) is a W3C set of HTML attributes that tell assistive technology what an element is, what it is called and what state it is in, where plain HTML cannot say it. ARIA changes what is announced, never how the element behaves: role="button" on a <div> makes a screen reader say "button", but the div still ignores Enter and Space and is not in the Tab order.

<button aria-label="Search"><svg aria-hidden="true">...</svg></button>
<button><svg aria-hidden="true">...</svg> Print</button>

The first button has no visible text, so aria-label names it "Search". In the second, the word Print already names the button, so the decorative printer icon is hidden to stop it being read as noise.

9Forms, input types and validation

Textbook chapters 16, 17, 18

The form element: where and how the data travels

A <form> collects what the user enters and sends it to a server. When the submit button is pressed, the browser takes every control that has a name, pairs that name with the current value (name=value) and sends the pairs. Exceptions: disabled controls, unticked checkboxes and unchosen radios send nothing, and only the button that was pressed is included. Two attributes on the form decide the journey:

• action = where: the URL the form data is sent to. Leave it out and the form submits to the current page.
• method = how: get (the default) or post.

<form action="/library/renew" method="post">
  <input type="hidden" name="book" value="B-204">
  <button>Renew</button>
</form>

Result: book=B-204 goes to /library/renew, inside the request.

name, id, value and the label

A label is linked to its control when the label's for value matches the control's id exactly (not its name, class or type). Wrapping the control inside the label also works. Then clicking the label focuses the box, and screen readers read the two together.

<label for="roll">Roll number</label>
<input type="text" id="roll" name="rollno">

The label finds the box through id="roll"; the server receives rollno=....

Choosing the right control

<fieldset>
  <legend>T-shirt size</legend>
  <label><input type="radio" name="size" value="s"> S</label>
  <label><input type="radio" name="size" value="m"> M</label>
  <label><input type="radio" name="size" value="l"> L</label>
</fieldset>

<label for="msg">Your complaint</label>
<textarea id="msg" name="msg" rows="4"></textarea>

<label for="labs">Labs you will attend</label>
<select id="labs" name="labs" multiple>
  <option>Physics</option><option>Chemistry</option><option>Workshop</option>
</select>

Input types worth knowing

One element, <input>, becomes a different control for each type.

Buttons: which one submits?

<button type="submit">Book seat</button>  <!-- sends the form -->
<button type="reset">Clear</button>       <!-- restores starting values -->
<button type="button">Show map</button>   <!-- does nothing without JavaScript -->

• No type written? Inside a form, a button with no type is a submit button (submit is the default).
• <input type="submit"> also submits.
• A link such as <a href="#"> only navigates (here, to the top of the page); it never submits.

Built-in validation attributes

HTML5 constraint validation: attributes describe a valid value; on submit the browser checks them all. If one fails, it stops the submission, focuses the first bad field and shows a message. No JavaScript needed.

An empty box passes both minlength and pattern: they only judge a value that is actually there. That is why they are paired with required.

<label for="sub">Subject code</label>
<input id="sub" name="sub" required pattern="[A-Z]{2}[0-9]{3}"
       title="Two capital letters then 3 digits, e.g. CS101">

Type cs1 and the browser blocks the form; its message shows the title text as the hint about the expected format. The title is not the server's key (that is name), not a default value (that is value) and no replacement for a <label>.

What type="email" really checks

Browsers follow the HTML Living Standard: one or more allowed characters (letters, digits and symbols such as . + _ -, but no spaces), one @, then a domain made of one or more labels of letters, digits and hyphens, separated by dots. A dot after the @ is allowed but not required.

For a stricter rule, add a pattern; it is checked on top of the email check:

<input type="email" name="mail" required
       pattern=".+@.+\..+" title="Use a full address such as name@college.edu">

Now user@campus is blocked, because the pattern demands a dot after the @.

Client-side versus server-side validation

Client-side checks are the guard at the gate: quick and polite, but they can be walked past. Server-side checks are the lock on the door.

10Tables and data representation

Textbook chapter 19

When to use a table, and what each part does

Use a table only for tabular data: information whose meaning comes from its position, where a row meets a column. A bus timetable (stop by time), a fee chart (course by year), a results sheet (team by event). If you only want boxes side by side, that is layout, and layout is CSS's job (see the last part of this section).

Why group rows at all? CSS can style the heading section differently from the body, a long table's heading rows can repeat on every printed page, and screen readers can tell heading rows from data rows.

The correct order, in one example

Children of <table> go in this order: caption, then colgroup (optional), then thead, tbody, tfoot.

<table>
  <caption>Canteen prices</caption>
  <thead><tr><th scope="col">Item</th><th scope="col">Rs</th></tr></thead>
  <tbody>
    <tr><th scope="row">Samosa</th><td>15</td></tr>
    <tr><th scope="row">Tea</th><td>10</td></tr>
  </tbody>
  <tfoot><tr><th scope="row">Both</th><td>25</td></tr></tfoot>
</table>

Browsers draw no borders by default; add them in CSS (th, td { border: 1px solid #999; }), not with the old border attribute. If you leave out <tbody>, the browser quietly adds one.

Merging cells: colspan and rowspan

• colspan="n": the cell stretches sideways across n columns.
• rowspan="n": the cell stretches downwards across n rows.

Both go on a <td> or <th>, and n counts grid cells, not pixels. Like knocking down a wall between two rooms: one bigger room, so the plan stops showing two.

Counting rule: every row must add up to the table's column count, spans included. The row below a rowspan cell leaves that cell out, because the slot is already filled from above.

<!-- 3 columns: Department | Lab | Day -->
<tr><th rowspan="2">Physics</th><td>Optics</td><td>Mon</td></tr>
<tr><td>Mechanics</td><td>Thu</td></tr>
<tr><td colspan="3">All labs close at 5 pm</td></tr>

<colgroup> and <col> sit after the caption and before thead, and let you give a whole column a width or background without repeating it on every cell.

Tables a screen reader can read

A sighted reader glances up to the column heading and left to the row heading. A screen reader reads one cell at a time, so the markup must say which headings belong to each value. Done right, a cell is announced as "Relay, Blue House, 38", not a bare "38". Three tools:

1. Use th for every heading cell, column and row headings alike; td is only for values.
2. Put scope on each <th> to say which cells it labels.
3. Add a <caption>, so the user hears what the table is about before hearing dozens of numbers.

<table>
  <caption>Sports day: points by house</caption>
  <tr><td></td><th scope="col">100 m</th><th scope="col">Relay</th></tr>
  <tr><th scope="row">Red House</th><td>42</td><td>30</td></tr>
  <tr><th scope="row">Blue House</th><td>35</td><td>38</td></tr>
</table>

For complex tables with two levels of headings, give each <th> an id and list them on the data cell: <td headers="relay blue">. scope handles simple tables; headers handles the rest.

Never use a table for page layout

Before CSS, whole pages were built inside tables: a row for the banner, cells for the menu and articles. Today that is wrong. Layout tables hurt accessibility and block responsiveness; tables are meant for tabular data only.

• Accessibility: a screen reader may announce "table, 2 columns" and read out row and column positions that mean nothing (browsers try to guess layout tables, but the guess is unreliable).
• Responsiveness: a table's grid does not reflow into one column on a phone unless extra CSS tears the table apart; left alone, the cells stay side by side, squeezed or scrolling sideways.
• Meaning: the markup claims the page is data when it is not.

The modern way is semantic regions (<header>, <nav>, <main>, <aside>, <footer>) arranged with CSS Flexbox or Grid.

If you inherit a layout table you cannot rewrite (old HTML emails are the classic case), <table role="presentation"> tells assistive technology to ignore its data meaning. It changes nothing on screen: it does not hide borders, make the table sortable or make the cells stack on a phone.

11Responsive content structuring

Textbook chapter 21

What responsive means

A responsive page is one HTML document that adapts to whatever screen shows it, from a 360-pixel phone to a wide monitor: text reflows, columns stack, images shrink. There is no separate mobile site. Think of water: it takes the shape of any glass you pour it into. Three things work together:

1. HTML with a clean, logical structure (this section);
2. CSS media queries that rearrange it for each screen width (Unit 3);
3. images and videos that can scale.

The viewport meta tag

Mobile browsers were built when the Web was all desktop pages. So, by default, a phone pretends its screen is about 980 pixels wide, lays the page out at that width, then zooms out to squeeze it onto the small screen. The result is a miniature desktop page whose text is too small to read without pinching. One line in the <head> stops the pretending:

<meta name="viewport" content="width=device-width, initial-scale=1.0">

• width=device-width: lay the page out at the device's real screen width.
• initial-scale=1.0: open at 100% zoom, not zoomed out.

Without it, CSS media queries also measure the fake 980-pixel width, so phone-only styles never switch on. That is why the viewport tag is the one meta tag that phones need to show a page at its real size.

Mobile-first and logical source order

Mobile-first means you start with the smallest screen, then add improvements as screens get bigger: first a single column that works on a phone; when there is more room, CSS adds a second column, then a third. Working the other way (desktop-first: shrinking a big design down) gives cramped, compromised phone pages. Mobile-first also forces good priorities: only the important content fits a small screen, so you decide what matters first. It does not mean "desktop only", and it has nothing to do with print layouts.

The single-column phone view is simply the HTML in the order it was written. So logical source order is the foundation: header, navigation, main content, related content, footer. Get the order right and the page already works on a phone before any CSS exists; screen readers and search engines read it in that order too.

<header>Tech fest</header>
<nav>Events | Register</nav>
<div class="cols">
  <main>Schedule and venues</main>
  <aside>Sponsors</aside>
</div>
<footer>Organising team</footer>

On a phone these simply stack. Later, one CSS rule puts main and aside side by side only when there is room, without touching the HTML:

@media (min-width: 700px) {
  .cols { display: flex; }
}

Flexible, scalable media

A 1600-pixel photo shown at its full 1600 pixels overflows a 390-pixel phone and drags the whole page sideways. In a responsive page, images and videos must be able to shrink and grow with the box that holds them; they are never locked to a pixel width wider than a small screen. The standard CSS rule:

img, video { max-width: 100%; height: auto; }

• max-width: 100%: never wider than the box it sits in.
• height: auto: the height follows, so the picture keeps its shape instead of stretching.

Keep writing width and height attributes on <img>: they tell the browser the image's proportions so the page does not jump while it loads, and the CSS above still lets it shrink.

Shrinking a huge file still downloads the huge file. srcset lists several sizes, sizes says how wide the image will appear, and the browser picks the smallest file that is still sharp. <picture> can even give phones a differently cropped image.

<img src="gate-800.jpg" alt="College main gate" width="800" height="450"
     srcset="gate-400.jpg 400w, gate-800.jpg 800w, gate-1600.jpg 1600w"
     sizes="(max-width: 600px) 100vw, 800px">

A wide data table cannot become one column without losing its meaning, so let it scroll inside its own box while the page stays still: wrap it in <div class="scroll-x"> and give that class overflow-x: auto in CSS.

Habits that help and habits that hurt

Testing: in Chrome press F12, then Ctrl+Shift+M for device mode, and drag the width; then try a real phone, because emulators do not reproduce touch or slow networks. A page passes when no sideways scrollbar appears at any width, text is readable without zooming, images fit and every control can be tapped.