Master your next HTML interview with our comprehensive collection of questions and expert-crafted answers. Get prepared with real scenarios that top companies ask.
Prepare for your HTML interview with proven strategies, practice questions, and personalized feedback from industry experts who've been in your shoes.
Thousands of mentors available
Flexible program structures
Free trial
Personal chats
1-on-1 calls
97% satisfaction rate
Choose your preferred way to study these interview questions
HTML Semantic essentially refers to the use of HTML markup to reinforce the semantics or meaning of the content. In other words, it's the use of HTML tags in a way that reflects the type of content they enclose. For instance, tags like <header>, <nav>, <footer>, and <article> are semantic because they accurately describe the type and purpose of the content they contain.
Semantic HTML is important both for accessibility and for SEO. It helps assistive technologies like screen readers understand the content, improving access for users with disabilities. For search engines, it provides clear context and meaning which can affect how the page is indexed and ranked. Additionally, semantic markup enhances the maintainability of the site, making it easier for developers to understand and work with.
HTML stands for HyperText Markup Language. It is the standard markup language used to structure content on a web page.
I usually explain it like this:
Why we use it:
header, article, and footerSo in simple terms, HTML is the foundation of the web. Without it, there is no organized content for a browser to render.
DOCTYPE is the declaration at the very top of an HTML file.
What it does: - Tells the browser how to interpret the document - Puts the page into standards mode - Helps browsers render the page consistently
For modern HTML, it’s just:
<!DOCTYPE html>
A couple of important notes: - It is not an HTML element - In HTML5, it’s very simple and mostly there to trigger proper browser behavior, not to reference a complex DTD like older HTML versions did
So in plain English, it’s basically the browser’s cue to say, “render this page using normal modern HTML rules.”
Try your first call for free with every mentor you're meeting. Cancel anytime, no questions asked.
In HTML, an element is the combination of a starting tag, its attributes, the content between the tags, and an ending tag. For example, in <p>Hello World!</p>, the whole thing is considered an "element" - including the opening tag, the content, and the closing tag.
On the other hand, a tag is used to mark the start or end of an element. There are opening tags like <p> and closing tags like </p>. In our earlier example <p>Hello World!</p>, <p> is the opening tag and </p> is the closing tag. Tags can also contain attributes to provide additional information about the element.
So, in essence, tags form the beginning and end of an element in HTML.
To comment lines in HTML, you use the <!-- --> syntax. Anything placed between these symbols will be considered as a comment by the browser and won't be rendered on the webpage. For example, if you want to comment out a line, you'd write <!-- This is a comment -->. You can also use this syntax to comment out blocks of code, meaning multiple lines, by placing all the lines between the opening <!-- and closing -->. Comments help developers understand the code better or to temporarily deactivate certain parts of HTML without deleting them.
The id and class attributes in HTML are used to assign identifiers to elements. Both are often used in conjunction with CSS or JavaScript to manipulate or style the elements.
The key difference is uniqueness and usage. An id is unique within a page and should be used only once, while a class can be applied to multiple elements. For example, if you have a specific style that needs to be applied just to one element, you would use an id. But if a style should be spread across many elements, you would use a class.
For instance, in CSS, IDs are referenced using a hash (#) symbol followed by the ID name, like #uniqueElement {...}. For classes, a dot (.) is used, like .multipleElements {...}.
Moreover, because IDs are unique, they have a higher specificity in CSS, meaning rules applied by IDs will override those set by classes if there's a conflict.
Nesting in HTML just means putting one element inside another to create structure.
A simple example is a paragraph inside a div:
<div><p>This is a paragraph.</p></div>
What matters is the relationship:
div is the parentp is the childWhy nesting matters:
The process is pretty straightforward:
So the order should be:
- Correct: <section><p>Text</p></section>
- Incorrect: <section><p>Text</section></p>
A few important rules:
header, article, nav, and footer, instead of relying on generic divs everywhereIf nesting is done wrong, browsers may try to fix it for you, but the layout, accessibility, or behavior can become inconsistent.
You create a hyperlink with the anchor tag, a.
Basic format:
- Use href to set where the link goes
- Put the clickable text between the opening and closing tags
Example:
- <a href="https://www.google.com">Go to Google</a>
A couple of common cases:
- External link: href="https://example.com"
- Internal page: href="about.html"
- Section on the same page: href="#contact"
So the main idea is simple:
- href = destination
- Link text = what the user clicks
Get personalized mentor recommendations based on your goals and experience level
Start matchingYou add an image in HTML with the img tag.
The two main attributes are:
src, the path or URL to the imagealt, a text description for accessibility and fallbackExample:
<img src="myimage.jpg" alt="A description of the image">
A few quick notes:
src can be a relative path like images/photo.jpghttps://example.com/photo.jpgalt is important for screen readers and if the image does not loadIf I were answering in an interview, I’d keep it simple and mention best practice too:
img to embed the imagesrc to the image locationalt textUsing an HTML validator matters because it catches problems early, before they turn into browser bugs or accessibility issues.
A validator helps with things like:
Why that matters in practice:
I would not say validation guarantees performance or rankings by itself, but it does help create a solid, standards-based site that is easier for browsers, assistive tech, and search engines to process.
I usually see it as a quality check, not just a rule checker. It helps keep the HTML clean, professional, and dependable.
Use the <br> tag.
A few key points:
<br> inserts a line breakExample:
<p>Roses are red,<br>Violets are blue,<br>HTML is easy,<br>And fun too!</p>
One important note:
<br> just to add visual spacing in a layoutThe <canvas> tag in HTML5 gives you a drawable area on the page.
You use it when you want to render graphics with JavaScript, like:
A couple of important points:
<canvas> itself is just a containerTypical setup:
<canvas> elementwidth and heightgetContext("2d")It also supports fallback content. So if a browser does not support <canvas>, the text inside the tag can be shown instead.
In short, <canvas> is used for dynamic, script-driven graphics in the browser.
Two common HTML list types are:
Unordered list
- Used when the order does not matter
- Displays bullet points by default
- Built with <ul>
- Each item uses <li>
Example:
Use <ul> as the wrapper, then add items like <li>Apple</li>, <li>Banana</li>, and <li>Cherry</li> inside it.
Ordered list
- Used when the sequence does matter
- Displays numbers by default
- Built with <ol>
- Each item still uses <li>
Example:
Use <ol> as the wrapper, then add items like <li>Step one</li>, <li>Step two</li>, and <li>Step three</li> inside it.
Quick syntax pattern
- Unordered: <ul> + multiple <li> items + </ul>
- Ordered: <ol> + multiple <li> items + </ol>
The key difference is simple:
- <ul> = bullets
- <ol> = numbered or ordered steps
The usual way is to use a YouTube iframe embed.
Quick process:
ShareEmbediframe code YouTube gives youA typical embed looks like:
<iframe width="560" height="315" src="https://www.youtube.com/embed/VIDEO_ID" title="YouTube video player" allowfullscreen></iframe>
A few key parts:
src, points to the YouTube embed URLwidth and height, control the player sizetitle, helps with accessibilityallowfullscreen, lets users expand the video fullscreenIf I want it to be more production-friendly, I usually also make it responsive with CSS so it scales nicely on mobile, instead of relying on fixed width and height.
There are 3 common ways to add CSS to an HTML page:
style attributep style="color: blue;"Best for: - Quick tests - One-off styling
Downside: - Hard to maintain - Mixes content and presentation - Not ideal for real projects
<style> tag in the <head>p { color: blue; } thereBest for: - Small projects - Single-page demos - Page-specific styles
Downside: - Not reusable across multiple pages
.css file using a <link> tag in the <head>link rel="stylesheet" href="styles.css"Best for: - Most real websites - Reusable, scalable styling - Keeping HTML clean
Why it’s preferred: - Easier to manage - Better organization - One stylesheet can serve multiple pages
If I were answering in an interview, I’d keep it simple: inline for quick overrides, internal for small page-level styling, and external CSS for most production use cases.
HTML escape characters, also known as HTML entities, are used to display reserved characters in HTML that would otherwise be interpreted differently by the browser.
For instance, if you try to use a less than or greater than symbol (< or >) in your HTML, the browser might interpret it as an opening or closing HTML tag. To avoid this, you can use escape characters or entities. So, instead of < and >, you'd use < and > respectively in your HTML.
Another common use case is for displaying special characters that are not readily available on the keyboard, such as copyright symbol (©), which can be represented as ©.
One more noteworthy entity is & which represents an ampersand. An actual ampersand (&) in your HTML can be mistaken as the start of an escape character, so it's best to use & when you want to display an ampersand.
So, in general, HTML escape characters ensure that the characters are displayed as intended and not mistaken for HTML tags or other entities.
I handle multilingual HTML by treating language, encoding, and accessibility as the basics from day one.
A solid answer usually covers 3 things:
In practice, I’d say:
lang attribute on the <html> element, like lang="en" or lang="es".lang to that specific element so browsers and screen readers interpret it correctly.meta charset="UTF-8" so characters from different languages display properly.I also pay attention to usability details:
dir="rtl"A simple example would be an English page with a French quote inside it. I’d keep the page as lang="en" and mark just the quote with lang="fr". That helps both accessibility tools and search engines understand the content properly.
The main new HTML5 form-related elements are:
<datalist><input> to show suggested values.Useful for autocomplete-style dropdown suggestions.
<output>
Often used with JavaScript in interactive forms.
<progress>
Good for uploads, loading states, or multi-step actions.
<meter>
It’s also worth mentioning that HTML5 expanded forms a lot through new input types, even though they are not separate elements.
Examples include:
emailurltelnumberrangedatetimemonthweekdatetime-localcolorsearchWhy that matters:
If I were answering this in an interview, I’d mention both: 1. The new form elements 2. The new input types, because both were big HTML5 form improvements
To make a checkbox appear checked by default when the page loads, you can use the checked attribute in the <input> tag. Here's an example:
html
<input type="checkbox" checked>
In this example, the checked attribute specifies that the checkbox should be preselected when the page loads. Note that there's no value after checked. This is a boolean attribute, which means its presence alone makes it true. If you want the checkbox to not be checked by default, you would simply leave the attribute out altogether.
The viewport meta tag in HTML is a way to control how your webpage scales on different sized devices to ensure it's optimized for all screen sizes. It's a critical part of making your site mobile-friendly.
html
<meta name="viewport" content="width=device-width, initial-scale=1">
In this common example, width=device-width makes the width of the webpage follow the screen-width of the device (which will vary depending on the device). The initial-scale=1 part sets the initial zoom level when the page is first loaded by the browser.
Without a viewport meta tag, mobile devices render pages at typical desktop screen widths, and then try to make the content look better by increasing font sizes and scaling the content to fit the screen. This often results in problematic layout for the page if it wasn't designed with this kind of scaling in mind. The viewport meta tag helps to avoid these issues, providing users with a better and more consistent browsing experience.
The required attribute in HTML is used in form input elements to enforce that a field must be filled out before the form can be submitted. As a part of built-in form validation in HTML, it helps ensure that important data is not missing when the form data is processed.
For example, if you have an input field for an email address which is important for your form, you could make it a required field like so:
html
<input type="email" name="email" required>
In this example, if users attempt to submit the form without providing an email address, the browser will highlight the field and display a message indicating that input is required. The user will then need to fill in that field before they can successfully submit the form.
This attribute offers a simple, client-side method of ensuring you receive necessary data, without needing extra JavaScript or server-side validation to enforce it (though, note that server-side validation remains important for security, as client-side validation is not foolproof).
data-* attributes are for attaching custom, non-visible information to an HTML element in a valid, standards-based way.
A simple way to think about it:
id, class, and hrefdata-* lets you add your own metadata when none of the built-in ones fitExample:
<div data-product-id="1234">...</div>In JavaScript, you can read it with dataset:
element.dataset.productIdWhy they’re useful:
class or id just to hold dataCommon use cases:
data-open="true"One important note, they’re meant for small bits of page-related metadata, not as a place to dump large application data or sensitive info.
The alt attribute gives an image a text alternative.
Why it matters:
alt text so users who cannot see the image still get the meaning.alt text appears instead.Example:
<img src="team-photo.jpg" alt="Marketing team standing in the office">
A couple of best practices:
alt="" so screen readers skip it.Lazy loading is a strategy used to delay the loading of resources until they are needed, rather than loading all resources upfront when a page loads. This can significantly improve performance and reduce data usage by only loading content as it's required.
In HTML, lazy loading is often applied to images and iframes. With the introduction of native lazy loading in modern browsers, you can simply add the loading attribute to your <img> or <iframe> tag with the value "lazy". For example:
html
<img src="image.png" loading="lazy" alt="My Image">
In this instance, the browser will wait to load "image.png" until the user scrolls near it. If the browser does not support the loading attribute, it will just ignore it and the resource will load normally, so it does not break anything for users on unsupported browsers.
Prior to native lazy loading, developers had to rely on JavaScript libraries such as Lozad.js or LazyLoad to achieve this functionality.
I usually think about HTML performance in one simple way, get meaningful content on screen fast, with as little blocking as possible.
A few things I focus on:
header, main, section, instead of extra divs everywhere.Smaller, cleaner markup is faster to parse and easier to maintain.
Reduce render-blocking resources
defer for scripts that do not need to run immediately.Avoid putting blocking JavaScript in the head unless it is truly required.
Load less upfront
loading="lazy".Do not ship hidden or offscreen content if it is not needed right away.
Cut down requests and payload size
Use caching, compression like Gzip or Brotli, and a CDN when appropriate.
Prioritize perceived performance
Preload important assets like fonts or hero images only when there is a clear benefit.
Write HTML that helps the browser
srcset and sizes.width and height on images.If I had to boil it down, I would say performance improves when the browser has less to download, less to parse, and less to block rendering.
The HTML title tag matters for both users and search engines.
Here’s why it’s important:
Example:
<title>My First Web Page</title>, that text usually shows in the tab and may also be used in search listingsBest practice is to make every page title:
So, it’s not just a label, it’s a key part of usability, accessibility, and SEO.
You can resize an image right in the <img> tag by setting width and/or height.
<img src="myimage.jpg" alt="My image" width="300"><img src="myimage.jpg" alt="My image" width="300" height="200">A couple of best practices:
width and height, make sure they match the image’s original proportions, otherwise it can look stretched.width, and let the browser calculate the other automatically.height: auto.So the short answer is, use width and height on the <img> element, but be careful not to distort the image.
To create a table in HTML, you use a few core tags:
<table> defines the table<tr> creates a row<th> creates a header cell<td> creates a data cellA simple structure looks like this:
<table><tr><th><tr> rows for the actual data<td> inside those rows for each cellExample structure:
<table>
<tr><th>Name</th><th>Role</th></tr>
<tr><td>Alice</td><td>Developer</td></tr>
<tr><td>Bob</td><td>Designer</td></tr>
</table>
A couple of best practices:
<th> for column headings, not just bold textborder<thead>, <tbody>, and <caption> for better structure and accessibilitySo really, it’s just rows inside a table, with headers and data cells placed in the right spots.
The main SEO-related tags in HTML fall into a few practical buckets:
titlemeta name="description"It does not usually improve rankings directly, but it can improve click-through rate.
Crawling and indexing tags
meta name="robots"index, noindex, follow, nofollow.meta name="googlebot"Same idea, but targeted specifically at Google’s crawler.
Canonical and duplicate content control
link rel="canonical"It tells search engines which URL is the preferred version of a page.
Social sharing tags that support visibility
meta property="og:title" and meta property="og:description"meta name="twitter:title"Same idea, but for X and similar previews.
Technical meta tags that indirectly help SEO
meta charset="UTF-8"meta name="viewport"Important for mobile responsiveness, which matters for SEO and usability.
Tags with little or no SEO value today
meta name="keywords"If I were answering this in an interview, I’d keep it simple: mention title, description, robots, and canonical first, then add Open Graph, Twitter Cards, and viewport as supporting tags. That shows you know both direct SEO signals and the tags that improve how pages are displayed and shared.
Use the target attribute on the anchor tag.
target="_blank" to open the link in a new tab or window, depending on the browser.<a href="https://www.example.com" target="_blank">Visit Example</a>One important best practice:
rel="noopener noreferrer" when using _blank for security and performance.So the safer version is:
<a href="https://www.example.com" target="_blank" rel="noopener noreferrer">Visit Example</a>
Small note, whether it opens in a new tab or a new window is usually controlled by the user's browser settings.
The main HTML5 page structure is pretty straightforward. I usually think of it in two layers, the document shell, and the semantic sections inside the page.
<!DOCTYPE html> sets the document as HTML5<html> is the root element for the whole page<head> holds metadata, like:<body> contains everything the user actually sees
Semantic layout elements inside <body>
HTML5 introduced semantic tags so the page structure is clearer for both developers and browsers.
<header> for the top section of a page or section
<nav> for navigation links<main> for the primary content of that page<section> for grouping related content<article> for standalone content, like a blog post or news item<aside> for side content, like a sidebar or related links<footer> for closing info, copyright, or contact linksA simple mental model is:
- head = page info
- body = visible content
- semantic tags = meaningful layout inside the body
If I were building a basic page, it would usually be organized as:
<!DOCTYPE html> → <html> → <head> → <body> → <header>, <nav>, <main>, <aside>, <footer>
That structure makes the page easier to read, maintain, and make accessible.
HTML5 added a bunch of semantic tags that make page structure much clearer, both for developers and for assistive tech.
Some of the big ones are:
<header>Often holds a logo, title, search, or nav
<footer>
Common for copyright, contact info, related links
<nav>
Best for primary menus, not every random link list
<main>
Should be unique on the page
<article>
Think blog posts, news articles, forum entries
<section>
Usually has its own heading
<aside>
Like sidebars, callouts, or related links
<figure> and <figcaption>
A simple way to explain why they matter:
One important point, semantic tags are about meaning, not styling. You use <section> or <article> because of what the content is, not because of how you want it to look.
Block-level and inline elements mainly differ in how they flow on the page.
Examples:
- <div>
- <p>
- <h1> to <h6>
- <section>
- <article>
Inline elements stay within the same line of content.
Examples:
- <span>
- <a>
- <strong>
- <em>
- <img>
A simple way to think about it:
One important detail, CSS can change this behavior with the display property. For example, a <div> can be made inline, and a <span> can be made block. But semantically, it is still best to choose the element based on meaning first, then use CSS for layout.
A drop-down list in HTML is usually built with the select element and a set of option elements.
Basic idea:
select is the dropdown itselfoption is each item inside itname is important when the field is submitted in a formvalue is the actual data sent to the serverExample structure:
select name="pets"option value="dog" shows Dogoption value="cat" shows Catoption value="rabbit" shows RabbitIf the user picks Dog, the submitted value is dog.
A few useful things to mention in an interview:
selected to make one option the defaultdisabled if an option should not be selectablemultiple if users should be able to choose more than one itemoptgroup to organize long lists into categorieslabel for accessibilityFor example, a good accessible setup is:
label connected to the selectSelect a petvalue attributesOne important point, if you need a searchable or highly customized dropdown, plain HTML select has limits. In that case, people often enhance it with JavaScript or a UI library, but the native select is still the simplest and most semantic starting point.
ARIA is there to fill accessibility gaps, not to replace good HTML.
Native HTML already has built-in semantics.
<button> is a button<a href="..."> is a link<input> is a form control<nav>, <main>, <header> give landmark meaningBrowsers and assistive technologies already understand these elements. ARIA adds extra accessibility information when native HTML alone cannot express what you need.
Use ARIA when you need to:
aria-expanded="true" on a collapsible buttonaria-selected="true" in a tab or listboxaria-checked="true" for custom checkable UI
Provide relationships
aria-labelledby to point to the visible labelaria-describedby to connect help text or error textaria-controls to reference the element being affected
Define roles for custom widgets
tablist, tab, and tabpanelFor custom dialogs, role="dialog" plus labeling attributes
Communicate live updates
aria-live="polite" for status messages that appear dynamicallyNative elements usually give you:
Example:
<button> already supports keyboard activation and is announced correctly.<div role="button"> requires you to manually add keyboard support, focusability, and behavior.So the interview-friendly rule is:
Avoid ARIA in these cases:
Bad:
- <div role="button">Submit</div>
Better:
- <button>Submit</button>
Bad:
- <div role="navigation">...</div>
Better:
- <nav>...</nav>
Example:
- Adding role="button" to a <button> is unnecessary
- Adding role="heading" to an actual <h2> is redundant
Worse, conflicting ARIA can make accessibility less reliable.
A custom control with ARIA but missing keyboard support is a common mistake.
Example:
- A div with role="checkbox" but no Space key handling is not actually usable.
ARIA can describe a widget, but it does not give you behavior for free.
aria-hidden on meaningful contentIf content should be available to screen readers, do not hide it with aria-hidden="true".
Also be careful not to put aria-hidden="true" on focusable elements or parents of focusable elements.
ARIA is for accessibility semantics, not styling or layout. It should not be used as a substitute for proper structure.
A clean way to say it:
There is a well-known accessibility rule:
That shows you understand that ARIA can help, but only when used correctly.
aria-expandedaria-describedbyrole="dialog" and aria-labelledbyaria-livediv pretending to be a button when <button> would workYou could say:
“ARIA complements native HTML by adding accessibility metadata for things HTML alone cannot fully express, like dynamic states, element relationships, live regions, and custom widgets. But I avoid ARIA when native semantic elements already provide the meaning and behavior, because built-in HTML is more reliable and requires less manual accessibility work. My rule is native first, ARIA only when needed.”
The main difference is when the browser downloads the script, when it executes it, and whether HTML parsing is blocked.
<script>Example: <script src="app.js"></script>
Effect on rendering:
- This can block page rendering and slow down initial load.
- If the script is in the <head>, users may wait longer before seeing content.
Use it when: - The script must run right away at that exact point in the document. - The script depends on earlier HTML only, or intentionally blocks parsing.
<script async>Example: <script src="analytics.js" async></script>
Effect on rendering: - Better than plain script for download performance. - But execution timing is unpredictable. - It can still interrupt parsing, so rendering may still be delayed briefly.
Use it when: - The script is independent. - It does not rely on other scripts. - Other scripts do not rely on it. - Good for analytics, ads, tracking, third-party widgets.
Key point:
- Multiple async scripts do not guarantee execution order.
<script defer>Example: <script src="main.js" defer></script>
Effect on rendering: - This avoids blocking HTML parsing. - Usually the best choice for page scripts that need the DOM. - Rendering is generally smoother and faster.
Use it when: - The script needs the full DOM. - Script order matters. - You want non-blocking loading for regular app logic.
Key point:
- Multiple defer scripts keep their order.
- They run before DOMContentLoaded.
scriptBlocks parsing: yes
async
Order guaranteed: no
defer
defer for most site JavaScript.async for independent third-party scripts.script only when you truly need immediate execution."script blocks parsing and runs right away, async downloads in parallel and runs as soon as it is ready, and defer downloads in parallel but waits until parsing is finished, which makes defer the safest default for most application code."
A good way to answer this is:
A strong answer sounds like this:
In one project, I inherited a marketing site that had grown quickly over time, so the HTML was pretty messy. It was built mostly by copying sections from older pages, and the structure had become inconsistent.
A few issues stood out right away:
div elements, with almost no semantic tagsh1 to h4div or span tags instead of proper button or a elementsalt text, and form fields were missing proper labelsWhat I did first was audit the page structure section by section. I mapped out the content hierarchy and identified which parts were really navigation, hero content, feature sections, forms, and footer content.
Then I refactored the markup to make it more semantic:
header, nav, main, section, article, and footer where appropriatebutton and a elementsalt textI was careful not to break styling, so I worked incrementally and coordinated with CSS changes as needed. I also tested with browser dev tools and a screen reader to make sure the refactor actually improved accessibility.
The result was that the HTML became much easier for the team to maintain, accessibility issues dropped significantly, and it also made future CSS and JavaScript changes cleaner because the structure was more predictable.
If you want, I can also turn this into a more natural 30 second interview response.
I’d handle it in two parts, diagnose first, then fix the markup.
I’d test like a real keyboard and screen reader user first.
Tab, Shift + Tab, Enter, Space, and arrow keys.Check that I can submit and correct errors without a mouse.
Screen reader smoke test
Listen for:
Inspect the HTML
<label> elements, not just placeholder text.<fieldset> and <legend>.type, name, id, for, required, aria-describedby, aria-invalid.Check for custom controls built from <div> or <span> instead of native elements.
Use browser/dev tools and audits
These help catch missing labels, bad ARIA, and focus issues
Common HTML problems and how I’d fix them
Missing labels
<label for="email">Email</label> tied to <input id="email">.Why: - Screen readers need a persistent accessible name. - Placeholders disappear and are not a replacement for labels.
Unclear grouping for radios or checkboxes
<fieldset> with a <legend>.Example:
- Payment method radio buttons should sit inside a fieldset with legend like Payment method.
Missing instructions or error association
aria-describedby to connect the input to hint or error text.aria-invalid="true" when validation fails.Example: - An input can reference hint and error IDs, so screen readers announce both.
Using placeholders as labels
Custom controls instead of native HTML
<div> pretending to be a checkbox, dropdown, or button.<button>, <input type="checkbox">, <select>, etc.Why: - Native controls come with keyboard support, semantics, and screen reader behavior for free.
Broken tab order
tabindex values or DOM order that doesn’t match visual flow.tabindex where possible.Missing button type
type="button" for non-submit actions.type="submit" for the actual submit action.Required fields not exposed properly
required attribute.Error handling not announced
aria-describedby.aria-invalid="true".If there is an error summary, ensure focus moves to it or it is announced appropriately.
My practical workflow
If I were answering this in an interview, I’d say my process is:
Retest after each fix
Example answer you could give
“I’d start by testing the form using only the keyboard to check focus order, keyboard access, and visible focus. Then I’d run a quick screen reader test with NVDA or VoiceOver to hear how each field is announced. From there, I’d inspect the HTML for common issues like missing <label> elements, placeholders being used as labels, missing <fieldset> and <legend> for grouped inputs, and custom controls built with non-semantic elements.
To fix it, I’d use native form elements wherever possible, explicitly associate labels with inputs using for and id, connect help and error text with aria-describedby, and mark invalid fields with aria-invalid. I’d also make sure required fields use the native required attribute and that the tab order follows the DOM logically. After changes, I’d retest with keyboard and screen reader to confirm the form is actually usable.”
A strong way to answer this is:
Example answer:
I’ve built responsive HTML layouts for landing pages, marketing sites, dashboards, and form-heavy web apps. My usual approach is mobile-first, starting with clean semantic HTML and then layering in responsive CSS using flexbox, grid, relative units, and media queries.
I focus on making layouts adapt naturally instead of just forcing them into a few screen sizes. That means things like fluid containers, flexible images, readable typography, and components that can stack, resize, or reflow depending on available space.
For cross-browser support, I test across Chrome, Safari, Firefox, and Edge, and I pay extra attention to mobile browsers, especially iOS Safari because it tends to expose layout quirks quickly. I also use browser dev tools for device simulation, but I try to validate on real devices whenever possible because touch behavior, viewport sizing, and font rendering can differ.
Some common challenges I’ve faced:
100vh not behaving consistently when browser UI appears or disappears.How I’ve handled those:
100vh and use safer layout strategies depending on the screen and component.One example was a dashboard where a multi-column desktop layout had to collapse cleanly to tablet and mobile without hurting usability. The challenge was that some widgets had dense data tables and fixed-width content. I restructured the HTML to keep a logical reading order, used flexible grid areas, and allowed lower-priority content to wrap or move below primary actions on smaller screens. That made the experience feel designed for each screen size instead of just shrunk down.
If this were in an interview, I’d keep it practical and emphasize that responsive HTML is not just about screen width, it’s about content structure, usability, and predictable behavior across real browsers and devices.
I’d answer this in two parts, how I’d approach it, and then what I’d actually do.
End with how you’d communicate scope and follow-up work.
How I’d handle it
I’d optimize for a fast first version, but I would protect the parts that are expensive to fix later.
What I’d move fast on: - Visual polish that can be iterated later - Fancy animations - Over-engineering components - Edge-case enhancements that are not critical for launch
What I would not cut: - Semantic HTML structure - Basic accessibility - Clear content hierarchy - Reusable, readable markup - Mobile responsiveness - Performance basics, like optimized images and avoiding unnecessary markup
My mindset is, clean HTML is not a luxury. It is usually the fastest way to build anyway, because messy structure slows you down the moment someone asks for revision two.
What I’d build first:
- A solid page outline using semantic elements like header, main, section, nav, and footer
- Proper heading order, so the content has a clear hierarchy
- Accessible buttons, links, forms, and alt text where needed
- Simple, consistent class naming, so future edits are easy
- A layout that works on mobile first, then scales up
How I’d balance speed and quality in practice: - Use an existing design system or proven patterns if available - Reuse components instead of inventing one-off markup - Keep the HTML shallow and readable - Avoid div soup - Build the MVP version first, then add enhancements in a second pass - Document quick shortcuts I took, so the team knows what to revisit
I’d also be transparent with the stakeholder. Something like:
Concrete example:
If they wanted a landing page by end of day, I would: - Build the hero, benefits, social proof, and CTA sections first - Use semantic sections and correct headings immediately - Make sure contrast, keyboard access, and link/button labeling are correct - Use compressed images and responsive layout - Skip complex carousel behavior or heavy animation unless it was truly critical - Leave notes for post-launch improvements like animation polish or deeper CMS integration
That shows I can ship fast, but I’m still protecting maintainability and accessibility. In my experience, that is the best balance, because it delivers now without creating avoidable cleanup later.
Knowing the questions is just the start. Work with experienced professionals who can help you perfect your answers, improve your presentation, and boost your confidence.
Comprehensive support to help you succeed at every stage of your interview journey
We've already delivered 1-on-1 mentorship to thousands of students, professionals, managers and executives. Even better, they've left an average rating of 4.9 out of 5 for our mentors.
Find HTML Interview Coaches