HTML Lesson 37 – HTML Case Study | Dataplexa
LESSON 37

HTML Case Study

Analyze a complete website build from start to finish, examining real-world HTML decisions and trade-offs.

Alex just got their first freelance client — a local bakery wants a simple website. The owner needs three pages: home, menu, and contact. Perfect chance to see how HTML knowledge transforms into a real project.

This case study walks through every decision Alex made. Why this tag instead of that one? When do performance concerns matter? How do you balance semantic HTML with client requests?

Project Requirements Analysis

The bakery owner, Maria, shared her wish list during their meeting. Alex took notes and translated business needs into HTML structure decisions.

Business Needs

Show daily specials, contact info, photo gallery, online ordering link, store hours, location map

HTML Translation

Article sections, address markup, figure elements, external links, time elements, iframe embeds

User Expectations

Fast loading, mobile-friendly, easy navigation, readable text, clickable phone numbers

Technical Constraints

Basic hosting, no database, minimal JavaScript, SEO-friendly URLs, accessible markup

Alex realized the biggest challenge: Maria thinks in terms of "pretty pictures and easy contact" while Alex needs to think in semantic HTML structure. The translation process becomes crucial.

Document Structure Strategy

Before writing any tags, Alex mapped out the site architecture. Three pages sharing common elements, but each with unique content needs.

header Logo, navigation, contact phone
main Page-specific content sections
article Daily specials, menu items
aside Store hours, social links
footer Address, copyright, legal links

This semantic structure serves multiple masters. Screen readers understand the page flow. Search engines can categorize content properly. And Maria gets the visual sections she imagined.

<!-- Alex's homepage structure for the bakery -->
<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <title>Sweet Dreams Bakery - Fresh Daily</title>
</head>
<body>
  <header>
    <h1>Sweet Dreams Bakery</h1>
    <nav>
      <a href="index.html">Home</a>
      <a href="menu.html">Menu</a>
      <a href="contact.html">Contact</a>
    </nav>
  </header>
</body>
</html>
localhost/bakery.html

What just happened?

Alex started with the foundation every page needs. The viewport meta tag makes the site mobile-friendly. The title includes both business name and benefit. Header contains the main navigation that appears on every page. Try this: View source on your favorite restaurant website — notice similar patterns.

Content Hierarchy Decisions

Maria wanted her daily special to be "the first thing people see" on the homepage. Alex had to balance this request with proper heading structure and semantic meaning.

<!-- Homepage content with proper heading hierarchy -->
<main>
  <section>
    <h2>Today's Special</h2>
    <article>
      <h3>Chocolate Raspberry Tart</h3>
      <p>Rich dark chocolate ganache with fresh raspberries</p>
      <p>Available until <time datetime="18:00">6 PM</time></p>
    </article>
  </section>
  
  <section>
    <h2>About Sweet Dreams</h2>
    <p>Family-owned bakery serving downtown since 1995</p>
  </section>
</main>
localhost/bakery.html

What just happened?

The daily special gets prominence through visual position (first on page) rather than breaking heading hierarchy. The time element with datetime attribute helps accessibility tools read "6 PM" correctly. Each special item becomes its own article for semantic clarity. Try this: Use browser dev tools to see how screen readers would navigate this structure.

The temptation was to use <h1> for the special to make it bigger. But that would break the document outline. CSS handles visual prominence — HTML handles meaning.

Form Design Challenges

The contact page needed a form for custom cake orders. Maria wanted to collect specific details without overwhelming customers. Alex designed for both usability and data quality.

<!-- Custom cake order form with smart validation -->
<form action="#" method="post">
  <fieldset>
    <legend>Custom Cake Order</legend>
    
    <label for="customer-name">Your Name *</label>
    <input type="text" id="customer-name" name="name" required>
    
    <label for="phone">Phone Number *</label>
    <input type="tel" id="phone" name="phone" required>
    
    <label for="event-date">Event Date</label>
    <input type="date" id="event-date" name="date">
    
    <label for="serving-size">How many people?</label>
    <select id="serving-size" name="servings">
      <option value="">Select size</option>
      <option value="small">8-12 people</option>
      <option value="medium">15-20 people</option>
      <option value="large">25+ people</option>
    </select>
  </fieldset>
  
  <button type="submit">Request Quote</button>
</form>
localhost/bakery-contact.html

What just happened?

The fieldset groups related fields together. Input type "tel" gives mobile users a phone keypad. The date input provides a calendar picker on most devices. Select dropdown gives Maria consistent data instead of free-form text. Required fields get asterisks in labels for clarity. Try this: Test the form on mobile — notice how input types change the keyboard.

Design Trade-off

Alex almost used radio buttons for serving size but chose a select dropdown instead. Radio buttons take more space but show all options immediately. Select dropdowns save space but hide choices until clicked. The decision: space mattered more than immediate visibility for this non-critical field.

Performance Decisions

Maria provided 47 photos of baked goods for the menu page. Alex needed to balance visual appeal with loading speed on mobile connections. HTML choices directly impact performance.

Image Strategy

Load hero image immediately

Lazy load gallery images

Provide alt text for each item

HTML Implementation

Figure elements for semantic meaning

Loading attribute controls timing

Meaningful descriptions help everyone

<!-- Menu page with performance-focused image handling -->
<main>
  <h1>Our Menu</h1>
  
  <section>
    <h2>Featured Items</h2>
    <figure>
      <div style="background:#fef3c7;padding:40px;text-align:center;color:#92400e;border-radius:8px;">[Image: Fresh croissants - loads immediately]</div>
      <figcaption>Butter croissants, baked fresh every morning</figcaption>
    </figure>
  </section>
  
  <section>
    <h2>All Pastries</h2>
    <figure>
      <div style="background:#e5e7eb;padding:20px;text-align:center;color:#6b7280;border-radius:8px;">[Image: Danish pastries - lazy loaded]</div>
      <figcaption>Assorted Danish pastries with fruit and cream</figcaption>
    </figure>
  </section>
</main>
localhost/bakery-menu.html

What just happened?

The figure element semantically connects images with their captions. Featured items load immediately since users expect to see them. Gallery images would use loading="lazy" to improve initial page load. Descriptive captions help accessibility and SEO. Try this: Open DevTools Network tab and reload — see how image loading affects page timing.

The real HTML would include loading="lazy" on images below the fold. But lazy loading can backfire on critical images — the hero croissant photo needs to appear immediately or visitors assume the site is broken.

Accessibility Implementation

Maria mentioned her sister uses a screen reader. Alex realized this wasn't an edge case — it was a customer requirement. Every HTML decision needed to work for assistive technology.

🔊

Screen Readers

Semantic HTML provides structure. Skip links help navigation. Alt text describes images.

⌨️

Keyboard Users

Tab order follows logical flow. Focus indicators show current position. All functions accessible without mouse.

👁️

Low Vision

High contrast text. Scalable fonts. Clear focus indicators. Meaningful link text.

<!-- Navigation with accessibility features -->
<nav aria-label="Main navigation">
  <a href="#main" class="skip-link">Skip to main content</a>
  <ul>
    <li><a href="index.html" aria-current="page">Home</a></li>
    <li><a href="menu.html">Menu</a></li>
    <li><a href="contact.html">Contact</a></li>
  </ul>
</nav>

<main id="main">
  <h1>Welcome to Sweet Dreams Bakery</h1>
  <p><a href="tel:+15551234567">Call us at (555) 123-4567</a> for orders</p>
</main>
localhost/bakery-accessible.html

What just happened?

The aria-label gives screen readers context about the navigation purpose. Skip link lets keyboard users jump past repetitive navigation. The aria-current attribute tells assistive technology which page is active. Phone link with tel: protocol enables one-tap dialing on mobile devices. Try this: Tab through the page using only your keyboard — notice the focus order.

Common accessibility mistake: using "click here" or "read more" for link text. Screen reader users often navigate by listing all links on a page. "Call us at (555) 123-4567" makes sense out of context. "Click here" tells them nothing useful.

Alex's biggest lesson: Accessibility features often improve the experience for everyone. The skip link helps power users navigate faster. Semantic HTML makes content easier to scan. Good alt text helps when images fail to load. Building inclusive sites creates better sites.

Quiz

Alex wanted Maria's daily special to be visually prominent but chose h2 instead of h1. Why was this the right decision?

For the bakery's menu page with 47 photos, which HTML approach best balances performance with user experience?

Alex used "Call us at (555) 123-4567" instead of "Click here to call" for the phone link. What accessibility benefit does this provide?

Up Next: HTML Project Planning

Transform client requirements into structured HTML plans using wireframes, content audits, and technical specifications.