auto-claude: 5.2 - Explain native form validation, input types, and accessibility patterns

lessons/21-html-forms-basic.json

@@ -17,6 +17,10 @@
 			"initialCode": "",
 			"solution": "<form>\n  <label for=\"name\">Name:</label>\n  <input type=\"text\" id=\"name\" name=\"name\">\n</form>",
 			"previewContainer": "preview-area",
+			"concept": {
+				"explanation": "The label-for-id connection creates an accessible relationship that assistive technologies understand. When a screen reader encounters <label for=\"name\">, it announces \"Name, edit text\" so blind users know what to enter. Clicking the label also focuses the input, giving users a larger click target (helpful on mobile and for motor disabilities). The name attribute identifies the field when submitting data to a server, while the id attribute creates the accessibility link—both serve different but essential purposes.",
+				"diagram": "Form Accessibility Chain\n\n┌─────────────────────────────┐\n│ <label for=\"email\">        │ ← Click target\n│   Email:                    │   (focuses input)\n│ </label>                    │\n└────────────┬────────────────┘\n             │ for=\"email\"\n             ↓ connects to id\n┌────────────┴────────────────┐\n│ <input id=\"email\"           │ ← Accessibility link\n│        name=\"email\">        │   (server identifier)\n└─────────────────────────────┘\n\nWhat Happens:\n━━━━━━━━━━━━━━━━━━━━━━━━━━━━━\n1. User clicks label\n2. Browser finds matching id\n3. Input receives focus\n4. Screen reader announces label\n━━━━━━━━━━━━━━━━━━━━━━━━━━━━━\n\nWhy Both Attributes?\nid   → Accessibility (label link)\nname → Server data (form submit)"
+			},
 			"validations": [
 				{
 					"type": "element_exists",
@@ -56,6 +60,10 @@
 			"initialCode": "<form>\n  \n</form>",
 			"solution": "<form>\n  <label for=\"email\">Email:</label>\n  <input type=\"email\" id=\"email\" name=\"email\">\n  \n  <label for=\"password\">Password:</label>\n  <input type=\"password\" id=\"password\" name=\"password\">\n</form>",
 			"previewContainer": "preview-area",
+			"concept": {
+				"explanation": "Input types give the browser semantic understanding of what data to expect, enabling native features without JavaScript. On mobile, type=\"email\" shows a keyboard with @ and .com shortcuts, type=\"tel\" displays a numeric dialpad, and type=\"number\" shows +/- controls. The browser also provides free validation: type=\"email\" automatically checks for @ symbols and rejects invalid formats on submit. Using semantic input types is the foundation of progressive enhancement—you get better UX, accessibility, and validation for free.",
+				"diagram": "Input Type Benefits\n\nMobile Keyboard Optimization:\n┌────────────────────────────┐\ntype=\"text\"    → QWERTY      │ ABC...\ntype=\"email\"   → @ .com keys │ user@domain\ntype=\"tel\"     → Dialpad     │ 0-9 only\ntype=\"number\"  → +/- arrows  │ Steppers\ntype=\"url\"     → .com / www  │ https://\n└────────────────────────────┘\n\nNative Validation (Free!):\n━━━━━━━━━━━━━━━━━━━━━━━━━━━━━\nemail    → Must contain @\nurl      → Must start http://\nnumber   → Numeric characters only\ntel      → No validation (varies)\npassword → Hides characters ••••\n━━━━━━━━━━━━━━━━━━━━━━━━━━━━━\n\nAccessibility:\nScreen readers announce input type\n\"Email, edit text\" vs just \"edit text\""
+			},
 			"validations": [
 				{
 					"type": "element_exists",
@@ -85,6 +93,10 @@
 			"initialCode": "<form>\n  <label for=\"email\">Email:</label>\n  <input type=\"email\" id=\"email\">\n  \n  <label for=\"password\">Password:</label>\n  <input type=\"password\" id=\"password\">\n  \n</form>",
 			"solution": "<form>\n  <label for=\"email\">Email:</label>\n  <input type=\"email\" id=\"email\">\n  \n  <label for=\"password\">Password:</label>\n  <input type=\"password\" id=\"password\">\n  \n  <button type=\"submit\">Sign In</button>\n</form>",
 			"previewContainer": "preview-area",
+			"concept": {
+				"explanation": "When clicked, a submit button triggers the form's native submit event, which validates all required fields, checks input constraints (minlength, pattern, etc.), and prevents submission if validation fails—all without JavaScript. The browser handles Enter key submission automatically when focus is in any text input. Prefer <button type=\"submit\"> over <input type=\"submit\"> because buttons can contain HTML (icons, spinners during loading), while input elements can only display plain text set via the value attribute.",
+				"diagram": "Form Submission Flow\n\nUser Action:\n┌────────────────────────────┐\n│ <button type=\"submit\">     │ ← Click or\n│   Sign In                  │   Enter key\n│ </button>                  │   pressed\n└────────────┬───────────────┘\n             │\n             ↓ Triggers\n┌────────────┴───────────────┐\n│ Browser Validation:        │\n│  ✓ Check required fields   │\n│  ✓ Validate input types    │\n│  ✓ Test constraints        │\n│  ✓ Match patterns          │\n└────────────┬───────────────┘\n             │\n      ┌──────┴──────┐\n   ✓ Valid      ✗ Invalid\n      │              │\n      ↓              ↓\n  Submit form    Show error\n  (POST data)    (block submit)\n\nButton vs Input:\n━━━━━━━━━━━━━━━━━━━━━━━━━━━━━\n<button>   → Can contain HTML\n<input>    → Plain text only\n━━━━━━━━━━━━━━━━━━━━━━━━━━━━━"
+			},
 			"validations": [
 				{
 					"type": "element_exists",