🖼️ See the drawing + lab 🏠 Course home 🌿 Branch on GitHub ✏️ View source

🖼️ आकृती आणि labThe drawing + lab पूर्ण पानावर उघडा ↗Open full page ↗

🧱 धडा 02 — HTML रचना: फलकाचा सांगाडा

📍 तुम्ही इथे आहात: 12 पैकी धडा 02 · मागे: lesson-01-why-ui · पुढे: lesson-03-css-layout

📦 या ब्रँचमध्ये काय आहे

धडा 01, आणि सांगाडा: semantic elements (landmarks), अर्थपूर्ण forms (labels, required, types), आणि mouse वापरणाऱ्यांशिवाय इतर कोणी फलक वापरू शकेल की नाही हे ठरवणारे छोटे attributes.

🧒 5 वर्षांच्या मुलाला समजावल्यासारखे

दोन फलक अगदी सारखे दिसू शकतात आणि आतून पूर्णपणे वेगळे असू शकतात.

एक फलक बिनानावाच्या आयतांनी बनलेला आहे: इथे <div>, तिथे <div>, button सारखा दिसावा म्हणून रंगवलेला एक <div onclick>. दुसरा फलक आपल्या भागांना नावे देतो: हा header आहे, हे navigation आहे, हा main मजकूर आहे, ही पाच items ची list आहे, हे button आहे, आणि या input चे label "Name" आहे.

फक्त दुसरा फलक screen reader वाचू शकतो ("list, five items…"), keyboard ने चालवता येतो (Tab buttons आणि links पर्यंत पोहोचतो, Enter त्यांना दाबतो), search engine ला समजतो, किंवा "Enrol नावाचे button" मागणारा robot त्याची test करू शकतो. तुम्हाला जो अर्थ सांगायचा आहे तोच अर्थ असलेला element निवडून हे सगळे तुम्हाला फुकट मिळते.

पहिल्या दिवशी महत्त्वाचे नियम:

<html lang="en"> — फलक कोणत्या भाषेत आहे (screen readers उच्चार बदलतात).
एक <h1>, मग त्याखाली <h2> — headings म्हणजे अनुक्रमणिका, जिच्या आधारे लोक पानावर फिरतात.
Landmarks: <header>, <nav>, <main>, <section>, <footer>.
कृतींसाठी <button>, कुठेतरी जाण्यासाठी <a href>. Click करता येणारा <div> कधीच नाही.
प्रत्येक <input>/<select> ला <label for="id"> मिळते. Placeholder म्हणजे label नाही — type करायला लागल्यावर ते नाहीसे होते.
प्रत्येक <img> ला alt मिळते — वर्णन, किंवा चित्र फक्त सजावट असेल तर alt="" (आपल्या avatars सारखे, जे शेजारीच नाव पुन्हा दाखवतात).

🗺️ आकृती

flowchart TB
    subgraph page["📄 ui/index.html"]
        sk["🔗 skip link (first tab stop)"]
        hd["🧱 header — h1 + nav + theme button"]
        mn["🧱 main"]
        s1["section#students — h2, filter, ul.cards"]
        s2["section#enrol — h2, form: label+input, label+select, button"]
        s3["section#about — h2, prose"]
        ft["🧱 footer"]
        sk --> hd --> mn --> s1 --> s2 --> s3 --> ft
    end
    free["free with the right element:<br/>keyboard · focus · screen-reader names · tests that ask for roles"]
    page -.-> free

❓ काय

Semantic elements सोबत एक role असतो जो browser सहाय्यक तंत्रज्ञानाला दाखवतो: <button> → button, <nav> → navigation, <ul><li> → list, <main> → main landmark. <div> चा role "generic" असतो — म्हणजे काहीच नाही.
Forms: <label for="name"> शब्दांना field शी जोडते (label वर click केल्यास field वर focus जातो). Attributes म्हणजे वागणे: required, minlength, type="email", autocomplete. <button type="submit"> form पाठवते; type="button" पाठवत नाही.
<template>: निष्क्रिय HTML, जे तुम्ही JavaScript मध्ये clone करता — आपले student card JS string ऐवजी तिथे राहते (lesson 04 ते वापरतो).
सजावट नसलेले attributes: lang, alt, पानावरचे title, status भागावरचे aria-live (lesson 06), for/id जोड्या.
Document outline: h1 → h2 → h3, एकही पातळी न वगळता. डोळस users जसे पान वरवर पाहतात, तसे screen reader users heading वरून heading वर उड्या मारतात.
Validation attributes तुम्हाला browser च्या फुकट तपासण्या आणि तुमचे स्वतःचे संदेश जोडण्याची जागा देतात (lesson 04 मध्ये input.checkValidity()).

🤔 का

कारण semantics म्हणजे तुम्ही कधीही विकत घ्याल अशी सर्वात स्वस्त accessibility, SEO आणि testability: तुम्ही <div> ऐवजी <button> लिहिता आणि keyboard support, focus, roles आणि नाव मिळते — काहीही न मोजता. नंतर ते जोडायचे म्हणजे ARIA वापरून browser हाताने पुन्हा बनवणे, तेही वाईट पद्धतीने.

🔧 कसे (या repo मध्ये)

ui/index.html वरपासून खालपर्यंत वाचा — ते छोटे आहे — 80 ओळींपेक्षा कमी — आणि प्रत्येक element त्याच्या अर्थासाठी निवडला आहे: skip link, एक h1 असलेला header, स्वतःचे h2 असलेले तीन section, जिथे प्रत्येक control ला label आहे असा form, card साठी एक <template>, आणि सजावटीच्या avatars वर alt="".

🧪 करून पाहा

python3 ui/mock_api.py        # then open http://127.0.0.1:8000/
# 1) keyboard tour: press Tab from the top — skip link, nav links, theme button, filter, form fields, Enrol
# 2) break it on purpose: change <button type="submit"> to <div>Enrol</div>, reload, and try Tab + Enter
# 3) put it back, then remove the <label for="name"> and run:
python3 ui/smoke_test.py      # ❌ every input has a label
# 4) add a real section of your own: <section id="homework" aria-labelledby="hw-h"><h2 id="hw-h">Homework</h2>…</section>

✅ तपासा — तुम्हाला काय दिसायला हवे

Tab प्रत्येक control पर्यंत दिसण्याच्या क्रमानेच पोहोचतो आणि focus ring स्पष्ट दिसते. <div> असताना Tab त्याला पूर्णपणे वगळतो आणि Enter काहीच करत नाही — button तुम्ही कधीच न लिहिलेली चार कामे करत होते. Label नसल्यावर smoke test fail होतो आणि ते परत लावल्यावर पुन्हा pass होतो.

🏁 तुम्ही आत्ताच काय सिद्ध केले

योग्य element तुम्हाला keyboard, focus, roles आणि नावे फुकट देतो — आणि एक robot ते दहा ओळींत तपासू शकतो.

⚠️ नेहमीच्या चुका

<button> ऐवजी <div onclick> (keyboard नाही, focus नाही, role नाही)
<label> ऐवजी placeholder
heading पातळ्या वगळणे, किंवा "बरोबर दिसतात म्हणून" तीन <h1>
सजावटीच्या चित्रांना रचलेला alt text — alt="" वापरा
अंतरासाठी <br> (ते CSS चे काम आहे) आणि मांडणीसाठी tables

🏭 प्रत्यक्ष वापरात हे का महत्त्वाचे: accessibility चे खटले, fail झालेली audits आणि "tests .btn-3 निवडतात म्हणून flaky आहेत" — या सगळ्यांचे मूळ या धड्यात आहे. Roles आणि labels मागणाऱ्या tests (lesson 10) redesigns नंतरही टिकतात; class names मागणाऱ्या tests टिकत नाहीत.

⏭️ पुढे

सांगाडा बरोबर आहे; आता तो प्रत्येक screen वर नीट दिसेल असे करा: CSS layout — box model, flexbox, grid, responsive.

git checkout lesson-03-css-layout

🧱 Lesson 02 — HTML structure: the board's skeleton

📍 You are here: Lesson 02 of 12 · Previous: lesson-01-why-ui · Next: lesson-03-css-layout

📦 What's in this branch

Lesson 01, plus the skeleton: semantic elements (landmarks), forms that mean it (labels, required, types), and the small attributes that decide whether anyone but a mouse user can use the board.

🧒 Explain like I'm 5

Two boards can look identical and be completely different underneath.

One is made of anonymous rectangles: <div> here, <div> there, a <div onclick> painted to look like a button. The other names its parts: this is the header, this is the navigation, this is the main content, this is a list of five items, this is a button, and this input's label is "Name".

Only the second board can be read by a screen reader ("list, five items…"), operated with a keyboard (Tab reaches buttons and links, Enter presses them), understood by a search engine, or tested by a robot that asks for "the button named Enrol". You get all of that for free by choosing the element that means what you mean.

The rules that matter on day one:

<html lang="en"> — what language the board is in (screen readers change pronunciation).
One <h1>, then <h2>s under it — headings are the table of contents people navigate by.
Landmarks: <header>, <nav>, <main>, <section>, <footer>.
<button> for actions, <a href> for going places. Never a clickable <div>.
Every <input>/<select> gets a <label for="id">. Placeholder is not a label — it disappears when you type.
Every <img> gets alt — a description, or alt="" if the image is pure decoration (like our avatars, which repeat the name next to them).

🗺️ Diagram

flowchart TB
    subgraph page["📄 ui/index.html"]
        sk["🔗 skip link (first tab stop)"]
        hd["🧱 header — h1 + nav + theme button"]
        mn["🧱 main"]
        s1["section#students — h2, filter, ul.cards"]
        s2["section#enrol — h2, form: label+input, label+select, button"]
        s3["section#about — h2, prose"]
        ft["🧱 footer"]
        sk --> hd --> mn --> s1 --> s2 --> s3 --> ft
    end
    free["free with the right element:<br/>keyboard · focus · screen-reader names · tests that ask for roles"]
    page -.-> free

❓ What

Semantic elements carry a role the browser exposes to assistive technology: <button> → button, <nav> → navigation, <ul><li> → list, <main> → main landmark. A <div> has role "generic" — nothing.
Forms: <label for="name"> ties the words to the field (clicking the label focuses it). Attributes are behaviour: required, minlength, type="email", autocomplete. <button type="submit"> submits; type="button" does not.
<template>: inert HTML you clone in JavaScript — our student card lives there instead of in a JS string (lesson 04 uses it).
Attributes that are not decoration: lang, alt, title on the page, aria-live on a status region (lesson 06), for/id pairs.
The document outline: h1 → h2 → h3 with no skipped levels. Screen reader users jump by heading the way sighted users skim.
Validation attributes give you free browser checks and a hook for your own messages (input.checkValidity() in lesson 04).

🤔 Why

Because semantics are the cheapest accessibility, SEO and testability you will ever buy: you type <button> instead of <div> and get keyboard support, focus, roles and a name — for nothing. Retrofitting them later means re-implementing the browser by hand with ARIA, badly.

🔧 How (in this repo)

Read ui/index.html top to bottom — it is short — under 80 lines — and every element was chosen for what it means: the skip link, the header with one h1, three sections with their own h2, a form where every control has a label, a <template> for the card, and alt="" on decorative avatars.

🧪 Try it

python3 ui/mock_api.py        # then open http://127.0.0.1:8000/
# 1) keyboard tour: press Tab from the top — skip link, nav links, theme button, filter, form fields, Enrol
# 2) break it on purpose: change <button type="submit"> to <div>Enrol</div>, reload, and try Tab + Enter
# 3) put it back, then remove the <label for="name"> and run:
python3 ui/smoke_test.py      # ❌ every input has a label
# 4) add a real section of your own: <section id="homework" aria-labelledby="hw-h"><h2 id="hw-h">Homework</h2>…</section>

✅ Verify — what you should see

Tab reaches every control in visual order and the focus ring is obvious. With the <div>, Tab skips it entirely and Enter does nothing — the button was doing four jobs you never wrote. The smoke test fails on the missing label and passes again when you restore it.

🏁 What you just proved

The right element gives you keyboard, focus, roles and names for free — and a robot can check that in ten lines.

⚠️ Common mistakes

<div onclick> instead of <button> (no keyboard, no focus, no role)
placeholder instead of <label>
skipping heading levels, or three <h1>s "because they look right"
decorative images with invented alt text — use alt=""
<br> for spacing (that is CSS's job) and tables for layout

🏭 Why this matters in production: accessibility lawsuits, failed audits and "the tests are flaky because they select .btn-3" all trace back to this lesson. Tests that ask for roles and labels (lesson 10) survive redesigns; tests that ask for class names do not.

⏭️ Next

The skeleton is right; now make it look like something on every screen: CSS layout — box model, flexbox, grid, responsive.

git checkout lesson-03-css-layout

← Previouswhy ui Next →css layout

This page is the lesson's README from the lesson-02-html-structure branch, shown here so the whole School stays on one site. Code files open on GitHub at the same branch.