HTML intermediate: semantic structure, forms, and accessibility
If you read the beginner lesson, you can put together a page with headings, paragraphs, links, and images. Good. Now we are going to level up. This lesson is about writing HTML the way professional web developers do, HTML that is not just functional but also semantically meaningful, accessible to people using screen readers, and friendly to search engines.
What does "semantic" mean?
Semantic HTML means using the tag that best describes the role of the content, not just any tag that makes it look right. For example, if you have a navigation menu, the semantically correct tag is <nav>, not a generic <div> with some styling. The browser does not care, but a screen reader does. A screen reader will let a blind user jump directly to the navigation. A search engine does the same. Even a future developer maintaining the code will thank you.
HTML5 introduced a set of semantic tags that describe the most common parts of a webpage. Here are the ones you will use most often.
The page-level semantic tags
<header>— the top section of a page or a section. Usually contains the logo, primary navigation, and a search bar.<nav>— a block of navigation links. You can have more than one, for example a primary nav in the header and a footer nav with legal links.<main>— the unique main content of the page. Use it only once per page, and do not put sidebars or footers inside it.<article>— a self-contained piece of content that could be syndicated on its own, like a blog post, a news article, a product card, or a forum reply.<section>— a thematic grouping of content, usually with a heading. Use it to divide a long page into chapters.<aside>— content that is tangentially related to the main content, like a sidebar, a pull quote, or a list of related links.<footer>— the bottom of a page or section, usually with copyright, contact info, and a secondary navigation.
A realistic page skeleton
Here is how a professionally-structured blog post page might look. Notice how the tags describe what each region is, instead of just being a stack of unnamed <div> elements.
<code>&lt;body&gt;
&lt;header&gt;
&lt;a href="/"&gt;&lt;img src="logo.svg" alt="Mangobaz"&gt;&lt;/a&gt;
&lt;nav aria-label="Primary"&gt;
&lt;ul&gt;
&lt;li&gt;&lt;a href="/"&gt;Home&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href="/articles"&gt;Articles&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href="/contact"&gt;Contact&lt;/a&gt;&lt;/li&gt;
&lt;/ul&gt;
&lt;/nav&gt;
&lt;/header&gt;
&lt;main&gt;
&lt;article&gt;
&lt;h1&gt;How to structure a blog post in HTML&lt;/h1&gt;
&lt;p&gt;Published on &lt;time datetime="2026-07-20"&gt;July 20, 2026&lt;/time&gt; by Hadi.&lt;/p&gt;
&lt;section&gt;
&lt;h2&gt;Introduction&lt;/h2&gt;
&lt;p&gt;...&lt;/p&gt;
&lt;/section&gt;
&lt;section&gt;
&lt;h2&gt;The main point&lt;/h2&gt;
&lt;p&gt;...&lt;/p&gt;
&lt;/section&gt;
&lt;/article&gt;
&lt;aside&gt;
&lt;h2&gt;Related posts&lt;/h2&gt;
&lt;ul&gt;
&lt;li&gt;&lt;a href="/post/a"&gt;Post A&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href="/post/b"&gt;Post B&lt;/a&gt;&lt;/li&gt;
&lt;/ul&gt;
&lt;/aside&gt;
&lt;/main&gt;
&lt;footer&gt;
&lt;p&gt;&amp;copy; 2026 Mangobaz.&lt;/p&gt;
&lt;/footer&gt;
&lt;/body&gt;</code>
Notice the aria-label="Primary" on the <nav>. That is an ARIA attribute, used to give extra context to assistive technology. When a screen reader user lands on this page, they can ask for a list of all landmarks, and they will hear "Primary navigation", "Main", "Article", "Aside", "Footer" instead of just "navigation, navigation, region, region". The label also disambiguates when you have multiple navs on a page.
Building a real, accessible form
Forms are where beginners get the most frustrated and where accessibility mistakes hurt the most users. Let us build a contact form the right way.
<code>&lt;form action="/contact" method="post" novalidate&gt;
&lt;div class="field"&gt;
&lt;label for="name"&gt;Your name&lt;/label&gt;
&lt;input type="text" id="name" name="name"
required minlength="2" maxlength="80"
autocomplete="name"&gt;
&lt;/div&gt;
&lt;div class="field"&gt;
&lt;label for="email"&gt;Email address&lt;/label&gt;
&lt;input type="email" id="email" name="email"
required autocomplete="email"
inputmode="email"&gt;
&lt;/div&gt;
&lt;div class="field"&gt;
&lt;label for="topic"&gt;What is this about?&lt;/label&gt;
&lt;select id="topic" name="topic" required&gt;
&lt;option value=""&gt;Please choose&lt;/option&gt;
&lt;option value="general"&gt;General question&lt;/option&gt;
&lt;option value="support"&gt;Support request&lt;/option&gt;
&lt;option value="press"&gt;Press inquiry&lt;/option&gt;
&lt;/select&gt;
&lt;/div&gt;
&lt;fieldset&gt;
&lt;legend&gt;How should we reply?&lt;/legend&gt;
&lt;label&gt;&lt;input type="radio" name="reply" value="email" checked&gt; Email&lt;/label&gt;
&lt;label&gt;&lt;input type="radio" name="reply" value="phone"&gt; Phone&lt;/label&gt;
&lt;label&gt;&lt;input type="radio" name="reply" value="no-reply"&gt; No reply needed&lt;/label&gt;
&lt;/fieldset&gt;
&lt;div class="field"&gt;
&lt;label for="msg"&gt;Your message&lt;/label&gt;
&lt;textarea id="msg" name="message" rows="6"
required minlength="10"&gt;&lt;/textarea&gt;
&lt;/div&gt;
&lt;div class="field"&gt;
&lt;label&gt;
&lt;input type="checkbox" name="agree" required&gt;
I agree to be contacted about this enquiry.
&lt;/label&gt;
&lt;/div&gt;
&lt;button type="submit"&gt;Send message&lt;/button&gt;
&lt;/form&gt;</code>
Notice several things that are easy to miss.
Every input has a <label> tied to it via the for attribute, and the input has the matching id. Clicking the label focuses the input. A screen reader announces the label when the input is focused. If you skip this step, a blind user has no idea what each field is for.
The type="email" on the email field tells the browser to expect an email address, so on mobile the keyboard shows the @ key by default. The autocomplete attributes let the browser autofill from the user saved addresses, which is a huge usability win. The required, minlength, and maxlength attributes are built-in client-side validation.
The radio group is wrapped in a <fieldset> with a <legend>. This tells screen readers that the three radios belong together as a single question. Without the fieldset, the user only hears the label of the currently focused radio and does not know there are two more choices.
Multimedia the right way
Embedding a video or an audio file is one line, but accessibility takes a little more.
<code>&lt;figure&gt;
&lt;video controls width="800" poster="preview.jpg"&gt;
&lt;source src="intro.mp4" type="video/mp4"&gt;
&lt;source src="intro.webm" type="video/webm"&gt;
&lt;track kind="captions" src="intro.en.vtt" srclang="en" label="English" default&gt;
&lt;track kind="subtitles" src="intro.ur.vtt" srclang="ur" label="Urdu"&gt;
Your browser does not support video. &lt;a href="intro.mp4"&gt;Download the video&lt;/a&gt; instead.
&lt;/video&gt;
&lt;figcaption&gt;A short introduction to the team.&lt;/figcaption&gt;
&lt;/figure&gt;</code>
The <track> elements provide captions and subtitles for deaf and hard of hearing visitors, and for anyone watching with the sound off. The fallback link inside the <video> element is shown by older browsers that do not support HTML5 video.
Common intermediate mistakes
Putting <div> on clickable things instead of <button>. A <div> is not focusable by keyboard, and screen readers do not announce it as interactive. If something should be clickable and trigger an action, use <button>. If it navigates, use <a> with an href.
Skipping the label because the placeholder is enough. The placeholder disappears as soon as the user types. A label stays visible. Always use a real label.
Using a <div> for a table. If your data really is a table, use <table>, <thead>, <tbody>, <tr>, <th>, and <td>. Screen readers can navigate them cell by cell. A div-based grid cannot.
What is next
Now that your HTML has real structure and is accessible, the natural next step is to make it look the way you want. That is the job of CSS, and that is exactly what the CSS beginner and intermediate lessons cover.
← More in HTML