HTML Basics for Testers

Why it matters

Two pages can look identical and behave differently. A "button" built from a <div> may work with a mouse but not with the keyboard or a screen reader, the software that reads a page aloud to blind and low-vision users; a label that is not tied to its field leaves the field without a name for screen reader users; a link may point to the staging server. These defects are invisible on screen and obvious in the markup.

HTML is also the shared language of testers, developers and automation. "The label has for="mail" but the input’s id is email" gets fixed faster than "clicking the label does nothing", and UI automation later finds elements by their roles, labels and attributes.

Elements, tags and attributes

Most elements have a start tag, content and an end tag: in <a href="/pricing">See pricing</a>, "See pricing" is the content between the start tag and the end tag </a>. Elements nest like boxes, such as <li> items inside a <ul> list. Void elements such as <input>, <img> and <br> have no content and no end tag.

Attributes sit in the start tag as name="value" pairs. Three details matter on every page:

• id names one element and must be unique in the page; labels, #fragment links and many locators (the queries automated tests use to find an element) point to it.
• Boolean attributes such as required and disabled are on when present and off only when absent: disabled="false" still disables the field.
• Characters with a meaning in HTML are written as character references, usually called entities: < displays < and & displays &. Seeing & on screen means the text was encoded twice.

Try it: HTML Entity Decoder

The skeleton of every page

Every HTML document has the same skeleton. <!DOCTYPE html> asks for standards mode; without it, browsers fall back to an old "quirks" mode that changes the layout. <html> wraps everything, and its lang attribute states the language; Arabic pages add dir="rtl". <head> describes the page and is not displayed; <body> holds what the user sees.

• <title>: shown in the tab and in search results, and announced first by screen readers; every page needs its own descriptive title (WCAG 2.2 criterion 2.4.2).
• lang: screen readers use it to choose the pronunciation (criterion 3.1.1).
• <meta charset="utf-8">: a missing or wrong encoding is a classic cause of garbled Arabic and Hindi text.
• <meta name="robots" content="noindex">: keeps the page out of search engines; right on staging, a serious defect on a public production page.
• <meta name="viewport"> tells phones to lay the page out at their own screen width; without it, they show a shrunken desktop layout. <link rel="stylesheet"> and <script src> load the CSS and JavaScript, so a wrong path there breaks the styling or the behaviour.

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width, initial-scale=1">
  <title>Track your order | Example Store</title>
  <meta name="description" content="Check where your order is.">
  <link rel="stylesheet" href="/styles.css">
  <script src="/app.js" defer></script>
</head>
<body>
  <header>...logo and menu...</header>
  <main>...the content of this page...</main>
  <footer>...contact and legal links...</footer>
</body>
</html>

Semantic elements: meaning, not looks

A semantic element says what its content is: <header>, <nav>, <main> and <footer> mark regions of the page, <h1> to <h6> mark headings, <ul> marks a list, <button> an action and <a href> a link. <div> and <span> mean nothing; they are boxes for layout and styling.

CSS can make a <div> look exactly like a button, but a real <button> comes with behaviour: it is reached with Tab, activated with Enter or Space and announced as a button by screen readers. A clickable <div> gets none of this unless a developer adds it by hand. Likewise, big bold text in a <div> looks like a heading but is missing from a screen reader’s list of headings.

• Anything that acts on click should be a <button>, or an <a href> if it goes to another page.
• Images need alt: a short description if they carry information, alt="" if they are decorative.

Forms and links in the markup

A <form> sends its fields to the address in action with the HTTP method in method: post puts the data in the request body, while get, the default, puts it in the URL, where it ends up in browser history and server logs. Each field is sent as its name plus its value; a field without a name is not sent at all.

A link is an <a> with an href: a full URL, a path such as /help, a fragment such as #faq that goes to the element with id="faq", or a scheme such as mailto:. The attributes of fields and links give you test ideas straight away:

• type (email, number, date…) sets the browser’s built-in checks and the keyboard or picker shown on phones.
• required, minlength, maxlength, min, max and pattern are rules to test, and their limits give you boundary values. Anyone can remove them, so the server must check the same rules. Note that minlength alone does not reject an empty field.
• A <label> gives a field its accessible name, the name a screen reader announces for it, when its for equals the field’s id or when it wraps the field; then clicking the label also focuses the field.
• A <button> without a type inside a form is a submit button.
• <input type="hidden"> is invisible on screen but editable by the user, so the server must not trust its value.

Try it: Validation Test Generator Try it: URL Parser

Worked example: reading the source of a sign-up form

To see the HTML the server sent, press Ctrl+U in Chrome, Edge or Firefox on Windows and Linux, or type view-source: before the address. The source is the document before JavaScript changed it; the live page is in DevTools, covered in later lessons. Minified source, squeezed onto a few long lines, becomes readable in an HTML formatter. Many single-page applications (SPAs), which build the page with JavaScript, send an almost empty <body>, so their source shows little.

This sign-up form looks fine on screen. Its source does not:

• method="get": the email and password would travel in the URL. Expected: post.
• The Email <label> has no for and does not wrap the input, so the field has no accessible name.
• for="pass" does not match id="password": the same defect.
• type="text" for an email: no email keyboard on phones and no browser format check.
• minlength="12" without required: an empty password passes the browser check. Test 0, 11 and 12 characters and ask for the maximum.
• The hidden plan is free: on a test environment you are allowed to test, change it in DevTools and submit. The server, not the page, must decide the plan.
• <button>Cancel</button> has no type, so it submits the form. Expected: type="button".
• "Create account" is a <div>: it cannot be reached with Tab and is not announced as a button.

<form action="/signup" method="get">
  <label>Email</label>
  <input type="text" id="email" name="email" required>

  <label for="pass">Password</label>
  <input type="password" id="password" name="password" minlength="12">

  <input type="hidden" name="plan" value="free">

  <button>Cancel</button>
  <div class="btn-primary" onclick="createAccount()">Create account</div>
</form>

Try it: HTML Formatter

Frequently asked questions

References

• HTML Living StandardWHATWGThe HTML language, including named character references (entities) and the parsing rules browsers follow.
• Web Content Accessibility Guidelines (WCAG) 2.2W3C · 2024The W3C Recommendation that defines the testable success criteria for accessible web content, organised under four principles and three conformance levels (A, AA, AAA).
• HTML: HyperText Markup Language — MDNMDN Web Docs (Mozilla)MDN's reference and guides for HTML elements and attributes — the semantic structure a page is built from, which tests and assistive technology rely on.
• Client-side form validation — MDNMDN Web Docs (Mozilla)Built-in and scripted form validation in the browser, and why it helps users but never replaces validation on the server.