Most people learn HTML twice. The first time they learn the tags, build something that looks right, and conclude that HTML is the easy part. The second time — usually after a screen reader user cannot use their form, or a search engine ignores their page, or a colleague asks why the whole layout is forty nested divs — they learn what the tags actually mean. This article is an attempt to skip the gap between those two. It is not a list of elements; that list is in every reference and you do not need another one. It is about the handful of decisions in HTML that have consequences, what those consequences are, and how to tell whether you have made them well. HTML is not a programming language, and that is the point You will see this said as a put-down, usually by someone who has just discovered JavaScript. It is true and it is not an insult. HTML has no variables, no loops and no conditionals, because it is not describing behaviour. It is describing what things are. That distinction is the whole subject. When you write:

Read our refund policy.

you are not telling the browser to render some text at a certain size with some space underneath. You are telling it: this is a paragraph. Everything else — the size, the spacing, the font — follows from that, and can be changed by CSS, by the user's own settings, by a reading-mode extension, or by a screen reader that does not render anything visually at all. This is why HTML is described as a *markup* language. You are marking up meaning. The appearance is a downstream consequence, and it is the least important consumer of what you wrote. Hold on to that, because almost every mistake in this article is the same mistake: choosing an element for how it looks instead of what it means. The browser will forgive you, and that is the problem Open a page with unclosed tags, mismatched nesting, a

inside a

, or a table with no , and the browser will render it anyway. It will not show an error. It will quietly build the best document it can from what you gave it and move on. This error recovery is deliberate and it is, on balance, a good thing — the web would be unusable if a stray tag produced a blank page. But it has a side effect that catches every beginner: bad HTML looks like it works. It looks like it works in your browser, on your machine, with your eyes. What it does not do is work for the other consumers of your page, and those consumers never file a bug report: • a screen reader, which navigates by headings, landmarks and labels rather than by position; • a search engine, which reads your structure to decide what the page is about; • reader mode, which tries to find the article and throws away the rest; • a future version of your own codebase, where somebody needs to restyle something and cannot find the seam. None of these will tell you that you got it wrong. The page will simply underperform for reasons nobody connects to the markup. That is why the rest of this article is worth your time: these are the failures you cannot see from where you are sitting. Semantics: the same page, two different documents Consider two versions of the same visual layout.

Learning HTML

Start here.

And:

Our Courses

Learning HTML

Start here.

With the right CSS these render identically. Pixel for pixel, a sighted user cannot tell them apart. To everything else they are completely different documents. The first one is a flat bag of generic boxes: nothing in it says what is a heading, what is the main content, or where one item ends and the next begins. The second one is a document with a title, a main region, and an article inside it. A screen reader user on the second page can jump straight to the main content, list every heading to get an overview, and skip the navigation they have already heard on six other pages. On the first page, none of those commands do anything, because there is nothing to find. They have to listen to the page linearly, from the top, every time. A

is not wrong. It is the element that means "a grouping with no particular meaning", and sometimes that is exactly what you have — a wrapper that exists purely to hang a layout on. The mistake is reaching for it by default, so that the elements which *do* carry meaning never get used. A short, practical rule: before you type

, ask whether there is an element that says what this thing is. , , , , , , ,

, cover most cases. If none fits,

is the honest answer and you should use it without guilt. Headings are an outline, not a type scale

through

are the most commonly misused elements in HTML, and the reason is that they come with default font sizes. People pick the heading that looks the right size, which is like choosing chapter numbers based on how big the ink is. Headings are a document outline. They should nest the way a table of contents nests:

Learning HTML

Text and structure

Paragraphs

Lists

Forms

Inputs

Two rules follow, and both have real consequences: Do not skip levels. Going from

straight to

because

was too big tells assistive technology there is a missing section. Use CSS to set the size; that is what CSS is for. One `

` per page, naming what the page is about. Not the site name — the page. A search engine, a reader-mode parser and a screen reader all use it to answer "what is this?" The test for whether your headings are right is to read only the headings, in order, and ask whether they describe the page. If they read like a sensible contents page, your structure is sound. If they read like a random list of phrases, your structure is decorative. Links and buttons are not interchangeable This is the single most common mistake in production code, and it is worth understanding precisely because the fix is so cheap. A link navigates. A button acts. Browse courses
Show more Styling one to look like the other is fine — a link can look like a button, that is a visual decision. Using the wrong element underneath is not, because the behaviours differ in ways no amount of CSS restores: • A link can be opened in a new tab, bookmarked, copied, and dragged. A button cannot, because there is nothing to open. • A link is activated with Enter. A button is activated with Enter or Space. Users rely on both. • A screen reader announces them differently, and that announcement is the user's only clue about what is about to happen. "Link, browse courses" sets a different expectation from "button, show more". The worst version is
. It is not focusable, so a keyboard user cannot reach it at all; it has no role, so a screen reader does not announce it as interactive; and it does not respond to Enter or Space. It works perfectly with a mouse and is completely invisible to everyone else. If you find yourself adding tabindex, role="button" and key handlers to a
, you have hand-rebuilt badly. Use the element. Forms: the part everyone skips and every interviewer asks about Forms are where HTML stops being decorative and starts handling other people's data. They are also where the most avoidable accessibility failures live. Every input needs a label, and the label must be connected to it. Email address The for attribute must match the input's id. That connection does two things. It tells a screen reader what the field is for — without it, the user hears "edit text, blank" and must guess from context. And it makes the label clickable, which enlarges the tap target considerably on a phone. Placeholder text is not a substitute: it disappears the moment the user types, taking the only description with it, and its contrast is usually too low to read comfortably. Use the right input type. type="email", type="tel", type="number", type="date" do more than validate. On a phone they change the keyboard that appears — a numeric keypad for a phone number, an @ key for an email. That is a real improvement in the time it takes to fill your form, and it costs one word. Use `autocomplete`. The browser can fill in a name, an address, a one-time code — but only if you tell it what the field holds. This is one of the highest-value, lowest-effort attributes in HTML and it is almost always missing. Keep the `<form>` element and a real submit button. A form that submits on Enter, works before JavaScript loads, and degrades gracefully when a script fails is more robust than one assembled entirely from click handlers. HTML gives you that behaviour free; you have to work to lose it. Alt text: what it is actually for alt is not a caption and it is not a keyword slot. It is what the image says, written for someone who cannot see it. That means the right alt text depends entirely on why the image is there:

Enrolments doubled between January and June.

Note the middle case. alt="" is not the same as omitting alt. An empty alt says "this image carries no information, move on". A missing alt leaves the screen reader with nothing to announce but the file name, so the user hears "image, swirl dot p n g" — which is noise and tells them nothing. The useful test: if you had to read the page aloud down a telephone, what would you say when you reached this image? If the answer is "nothing, it is just a decorative flourish", that is alt="". If the answer is a sentence, that sentence is your alt text. Tables, and the layout myth "Never use tables for layout" is correct advice that has been over-learned into "never use tables". Tables are the right element for tabular data — rows and columns where the position of a cell carries meaning. A price list, a comparison, a schedule, a set of results. What makes a table accessible is not the

tag but the structure inside it:

Course fees, 2026

Course	Fee
HTML	Free

is what lets a screen reader say "Fee: Free" instead of just "Free" when the user moves across a row. Without the header association, a table read aloud becomes a stream of disconnected values — technically all the data, practically useless. gives the table a name so it can be found and skipped. The attributes that earn their place A few small things in and on do more than their size suggests. Learning HTML — Omni Academy lang tells a screen reader which pronunciation rules to use. Without it, English read with the wrong language's phonetics is close to unintelligible. It also helps translation tools decide whether to offer. charset must come early, because the browser has to know how to decode the bytes before it can parse them. Get it wrong or leave it out and non-ASCII characters turn into mojibake. viewport is the line that makes a page respond to phone widths at all. Without it, a mobile browser assumes a desktop-width page and zooms out, which is why an otherwise responsive site can still render as a tiny unreadable version of itself. is the tab name, the bookmark name, the search result headline and the first thing a screen reader announces on page load. It should say what the page is, not just what the site is. How to tell whether your HTML is good Four checks, in increasing order of effort, all of which you can do today. Read the headings alone. If they describe the page as a contents page would, the structure is sound. Unplug the mouse. Tab through the page. Can you reach everything interactive? Can you see where you are — is the focus outline visible, and did you resist the urge to remove it with outline: none? Can you escape anything you open? Turn off CSS. Most browsers' developer tools can disable stylesheets. What is left should still be a readable document in a sensible order: heading, then content, then related things. If it becomes an incomprehensible jumble, your meaning was in the CSS, which means it was never really there. Run a validator. The W3C validator catches unclosed tags, duplicate IDs and invalid nesting — the class of mistake the browser silently repairs and you never notice. It is a few seconds and it finds things reading cannot. What to practise If you are learning HTML now, the fastest route to competence is not memorising more elements. It is building two or three small, complete pages and getting the structure right: 1. An article page. One <h1>, proper heading nesting, real paragraphs, a figure with a caption, and one table that genuinely wants to be a table. 2. A form. Six or seven fields with labels, correct input types, autocomplete, and a real submit button. Fill it in on a phone and see which keyboards appear. 3. A page with a navigation bar. Use <nav>, <main> and <footer>, then tab through it with the mouse unplugged. Then take each one and apply the four checks above. You will find something in every one of them, and the things you find are precisely the ones that no amount of further tag-memorising would have taught you. HTML rewards the person who asks "what is this thing?" before asking "how should it look?". That question is almost the whole skill, and it is the one that keeps paying — long after the fashions in CSS and JavaScript around it have changed.