You now have end-to-end exposure to HTML as practiced on modern sites: document grammar, text semantics, linking, media, tables, forms, embedded graphics, hosted media, bridging APIs, and accessibility obligations.
Habits to keep
- Semantic elements before classes or ARIA.
- Validate markup and monitor regressions in CI.
- Pair every lesson here with CSS layout practice and JavaScript fundamentals.
- Use the HTML reference desk for lookups instead of memorizing every edge case.
Suggested next tracks
- CSS for responsive layout, typography systems, and motion handled responsibly.
- JavaScript for DOM scripting, fetch, modules, and tooling.
- Portfolio projects combining semantic HTML, accessible components, and deployment literacy.
Ship small pages often—iteration deepens intuition faster than passive reading alone.
Keep asking these questions on every PR
- Does this HTML still make sense with CSS disabled?
- Can I complete the task with keyboard only while seeing focus?
- Are names exposed to assistive tech equal to what sighted users infer?
- Did we validate on real mobile devices, not only desktop emulators?
Rendered output (final self-review card)
Pre-merge HTML checklist
- Semantic elements used before ARIA fallback.
- Form controls have labels and errors are announced.
- Media has text alternatives or captions.
Topic-end mock interview set (20 questions)
Practice these aloud. A strong answer explains trade-offs and gives implementation checks; a weak answer stays generic or memorized.
1) Semantic HTML vs div soup?
Strong: Uses semantic elements for structure, navigation, and accessibility tree clarity; mentions maintainability and SEO side effects. Weak: “Semantics are optional because CSS can style anything.”
2) When do you use ARIA?
Strong: Native first; add ARIA only when native semantics cannot express intent, and pair with keyboard behavior. Weak: “Add ARIA everywhere for extra accessibility.”
3) Why pair label with form controls?
Strong: Improves SR announcement, click/tap target, and form usability; references for/id. Weak: “Placeholder text is enough.”
4) GET vs POST in interviews?
Strong: GET for safe/idempotent queries; POST for mutations/body payloads; still requires server validation. Weak: “GET is old, POST is modern.”
5) Why avoid <a href="#"> for actions?
Strong: Anchors navigate; actions should be buttons for correct semantics, keyboard behavior, and history expectations. Weak: “Either is fine if styled similarly.”
6) target="_blank" safety requirement?
Strong: Use rel="noopener" (often noreferrer) to prevent opener abuse. Weak: “No extra attributes needed.”
7) Good alt text strategy?
Strong: Describe purpose/context, keep concise, use empty alt only for purely decorative images. Weak: “Just repeat file name or write ‘image’.”
8) Why set image width/height?
Strong: Reserves layout space to reduce CLS; CSS can still scale visually. Weak: “Not needed with modern browsers.”
9) Explain srcset + sizes.
Strong: Browser picks candidate based on slot size and DPR; verify in DevTools network. Weak: “Add both and browser always chooses smallest file.”
10) Table accessibility baseline?
Strong: Use caption, th, and scope so header relationships are announced. Weak: “Tables are just rows and columns; semantics don’t matter.”
11) Why heading hierarchy matters?
Strong: Supports document outline and assistive tech navigation; avoid skipping levels without reason. Weak: “Pick heading tags by size preference.”
12) What is progressive enhancement?
Strong: Core task works with baseline HTML; CSS/JS/API layers enhance experience when available. Weak: “Build JS-first and ignore no-script paths.”
13) Basic keyboard QA script?
Strong: Tab through interactive controls, confirm visible focus, logical order, no traps, and Enter/Space behavior. Weak: “If mouse works, keyboard probably works too.”
14) Why test at 200% zoom?
Strong: Validates reflow/readability/action availability for low-vision users and small screens. Weak: “Zoom checks are design QA, not accessibility.”
15) Native validation vs custom validation?
Strong: Native gives quick baseline; custom UX may override but server validation remains source of truth. Weak: “Frontend validation means backend checks are optional.”
16) What does defer solve for scripts?
Strong: Prevents parser blocking for classic scripts and runs after document parse in order. Weak: “It makes scripts async and orderless.”
17) Why put charset early in head?
Strong: Ensures correct byte decoding before parser reads deeper content. Weak: “Charset position has no practical effect.”
18) Discuss skip links.
Strong: First-focus shortcut to main content; target should be focusable and visually confirmed. Weak: “Skip links are outdated and can be omitted.”
19) How to evaluate link text quality?
Strong: Links should be unique and meaningful out of context (link lists in SR). Weak: “Multiple ‘Read more’ links are always fine.”
20) Your HTML PR exit criteria?
Strong: Valid semantics, keyboard completion, accessible names, responsive media checks, and no critical a11y/security regressions. Weak: “Looks right in my browser, ship it.”
Important interview questions and answers
- Q: What does progressive enhancement mean in API-driven pages?
A: Core tasks should work with baseline HTML first, then richer APIs enhance experience when supported. - Q: Why is feature detection better than browser sniffing?
A: It checks actual capability, avoids brittle UA assumptions, and degrades gracefully. - Q: What is the first accessibility check before shipping any page?
A: Verify keyboard-only task completion with visible focus and meaningful accessible names.
Challenge
30-second recap
- Without scrolling, list five elements you will use on every new page.
- Pick your next track: CSS or JavaScript.
Done when: you can explain HTML’s role vs CSS and JS in one paragraph.
Interview prep
- How do HTML, CSS, and JavaScript divide responsibility?
HTML structures meaning, CSS presents it, JavaScript adds behavior—keep critical content available without JS.