---
marp: true
theme: gaia
paginate: true
backgroundColor: #fff
header: "Grundlagen IT- und Internettechnik (223015c)"
footer: "Michael Czechowski – HdM Stuttgart – SoSe 2026"
title: Grundlagen IT- und Internettechnik
---
<style>
:root {
  --color-foreground: #1a1a2e;
  --color-highlight: #d63384;
  --color-dimmed: #4a4a6a;
}
section.invert {
  --color-foreground: #fff;
}
section {
  font-size: 1.7rem;
}
h1 {
  color: #a02060;
}
section.invert h1 {
  color: #fff;
}
h2 {
  color: #1f2937;
}
pre {
  background: #0f0f23;
  color: #d63384;
  border-radius: 8px;
  border-left: 3px solid #d63384;
}
pre code {
  background: transparent;
  color: inherit;
}
code {
  background: #1a1a2e;
  color: #d63384;
  padding: 0.15em 0.4em;
  border-radius: 4px;
}
a {
  color: var(--color-highlight);
}
section.klausur {
  background: repeating-linear-gradient(
    135deg,
    #fce4ec,
    #fce4ec 40px,
    #fff 40px,
    #fff 80px
  ) !important;
}
@media print {
  section.klausur {
    background: #fce4ec !important;
  }
}
section.aufgabe {
  background: #fce4ec !important;
}
section.aufgabe footer {
  display: none;
}
</style>

<!--
  ╔═══════════════════════════════════════════════════════════════════╗
  ║  AUTO-GENERATED FILE - DO NOT EDIT MANUALLY                       ║
  ║                                                                   ║
  ║  This file is generated by: make klausur                          ║
  ║  Source: scripts/extract-klausur.sh                               ║
  ║                                                                   ║
  ║  To update, edit the source slides and re-run make klausur        ║
  ╚═══════════════════════════════════════════════════════════════════╝
-->

<!-- _class: invert -->
<!-- _header: '' -->
<!-- _backgroundColor: #000 -->

![bg cover opacity:0.2](./assets/background-termin-1.png)

# Grundlagen IT- und Internettechnik

**223015c** · Modul "Technik 1" · 1. Semester
Digital- und Medienwirtschaft
Hochschule der Medien Stuttgart

**Sommersemester 2026**

[https://librete.ch/hdm/223015c/](https://librete.ch/hdm/223015c/)

---

<!-- _header: "" -->
<!-- _footer: "" -->


# Von-Neumann-Architektur · 5 Komponenten

| # | Komponente | Aufgabe |
|---|------------|---------|
| 1 | **Steuerwerk** (Control Unit) | holt Befehl, entscheidet was zu tun ist |
| 2 | **Rechenwerk** (ALU) | führt Rechnung / Vergleich aus |
| 3 | **Speicher** (Memory) | hält Daten *und* Programm |
| 4 | **Eingabe / Ausgabe** (I/O) | Tastatur, Bildschirm, Netzwerk |
| 5 | **Bus** (Verbindung) | transportiert Daten zwischen allen |

**Schlüssel:** Speicher hält *beides* — Daten + Programm. (Stored Program.)

<!--
Klausurfähig: die 5 Komponenten und ihre Aufgaben benennen.

Wo seht ihr das in eurem eigenen Gerät?
- Steuerwerk + Rechenwerk = CPU
- Speicher = RAM (flüchtig) + SSD (persistent)
- I/O = USB-Ports, Display, Audio
- Bus = im Chip (Intern), zwischen Chips (PCIe, USB)

Die Architektur ist seit 1945 stabil. Quantencomputer brechen sie auf (kein klassisches stored program). Aber jeder PC, Mac, Smartphone, jeder Server, jede Spielkonsole folgt ihr noch immer.
-->


---

<!-- _header: "" -->
<!-- _footer: "" -->


# Internet-Timeline · 4 Milestones

| Jahr | Was | Was hat es verändert |
|------|-----|----------------------|
| **1969** | ARPANET | Erstes paket-vermitteltes Netzwerk, 4 Knoten |
| **1971** | Email (Ray Tomlinson) | Erste Nutzung des `@`-Zeichens |
| **1983** | TCP/IP | Wurde Standard-Protokoll des ARPANET |
| **1989** | **WWW** (Berners-Lee, CERN) | HTML, HTTP, URL — das Web wie wir es kennen |

1993: Mosaic-Browser → Internet wird *populär*.

<!--
Klausurfähig: die 4 Meilensteine und ihre Bedeutung.

Anmerkungen:
- 1969 ARPANET: noch militärisch + Forschung. Wenige Knoten.
- 1971 Email: Ray Tomlinson schickt die erste E-Mail mit @-Zeichen, das er gewählt hat um „User AT Maschine" zu trennen. Heute auf jedem Tastatur als Standard.
- 1983 TCP/IP: Vint Cerf + Bob Kahn. ARPANET wechselt am 1. Jan 1983 von NCP zu TCP/IP. Das ist die „Geburt des modernen Internets" im technischen Sinne.
- 1989 WWW: Tim Berners-Lee am CERN. Er erfindet HTTP (Protokoll), HTML (Markup) und URL (Adress-System) — drei Standards, eine Person.
- 1993 Mosaic: erste GUI-Browser, der Bilder im Text-Fluss anzeigen konnte. Damit explodierte die Web-Nutzung.

Internet ist nicht Web — Internet ist das Netzwerk, Web ist eine Anwendung darauf. Aber im Volksmund verwechselt.
-->


---

<!-- _header: "" -->
<!-- _footer: "" -->


# HTML-Anatomie

```html
<a href="https://librete.ch">Mein Link</a>
```

| Bestandteil | Was |
|-------------|-----|
| `<a` | **Opening-Tag** mit Tag-Namen |
| `href="https://..."` | **Attribut** (Name + Wert) |
| `>` | Ende des Opening-Tags |
| `Mein Link` | **Inhalt** des Elements |
| `</a>` | **Closing-Tag** |

Alles zusammen = ein **Element.**

<!--
Klausurfähig. Studis sollen die Bestandteile eines HTML-Elements unterscheiden können:
- Opening-Tag
- Closing-Tag
- Attribute (Name=Wert)
- Inhalt
- Element = alles zusammen

Achtung: einige Tags sind „self-closing" und haben keinen Closing-Tag:
- `<img src="..." alt="...">`
- `<br>`
- `<input>`
- `<meta>`

Diese werden auf der nächsten Folie behandelt.
-->


---

<!-- _header: "" -->
<!-- _footer: "" -->


# Document-Struktur: das Grundgerüst

```html
<!DOCTYPE html>
<html lang="de">
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1">
  <title>Meine Seite</title>
  <link rel="stylesheet" href="style.css">
</head>
<body>
  <h1>Hallo Welt</h1>
  <!-- alle sichtbaren Inhalte -->
</body>
</html>
```

<!--
Klausurfähig: die DOCTYPE + head + body-Struktur reproduzieren können.

Was passiert wo?
- DOCTYPE: sagt dem Browser „das ist HTML5". Ohne DOCTYPE: Quirks-Mode (alte Browser-Verhaltensweisen).
- html-Element + lang: Wurzel-Element + Sprache
- head: alles, was *nicht* sichtbar ist (Meta, Title, CSS-Links, Scripts)
- meta charset: sagt Browser, wie die Byte zu interpretieren sind (UTF-8 = international, alle Sprachen)
- meta viewport: für Mobile-Rendering, ohne zoomt iPhone alles auf 980px
- title: Browser-Tab-Titel + Lesezeichen-Name
- link stylesheet: CSS einbinden
- body: alle sichtbaren Inhalte
-->


---

<!-- _header: "" -->
<!-- _footer: "" -->


# Semantische HTML-Tags

| Tag | Bedeutung | Beispiel |
|-----|-----------|----------|
| `<header>` | Kopfbereich (Logo, Nav) | oben auf der Seite |
| `<nav>` | Navigations-Menü | Hauptmenü |
| `<main>` | Hauptinhalt | das eigentliche Thema |
| `<section>` | Thematischer Abschnitt | Kapitel der Seite |
| `<article>` | eigenständiger Inhalt | Blog-Post, News-Beitrag |
| `<aside>` | Seiten-Inhalt | Sidebar, Werbung |
| `<footer>` | Fußbereich | Impressum, Copyright |

**Vorteil:** Screen-Reader, Suchmaschinen + andere Entwickler verstehen die Struktur.

<!--
Klausurfähig: die 7 semantischen Tags und ihre Bedeutung.

Vor HTML5 (2008) gab es nur `<div>`. Man hat alles in div verpackt und mit Klassen markiert: `<div class="header">`. Funktioniert visuell — aber Maschinen (Screen-Reader, Suchmaschinen) verstehen nichts.

Mit semantischen Tags:
- Screen-Reader kann „Hauptnavigation überspringen" anbieten
- Google versteht, was Haupt-Inhalt der Seite ist (SEO-Boost)
- Andere Entwickler lesen den Code schneller

Faustregel: wenn ein Tag den *Zweck* eines Bereichs ausdrückt — semantisch. Wenn nur Styling — div.

Drei A11y-relevante Anti-Patterns:
- `<div onclick="...">` statt `<button>` (Tastatur nicht erreichbar)
- `<a href="javascript:void(0)">` statt `<button>` (semantisch falsch)
- alles in `<div>` (keine Hierarchie für Screen-Reader)
-->


---

<!-- _header: "" -->
<!-- _footer: "" -->


# Drei Adressen — IP · MAC · Port

| Adresse | Identifiziert | Beispiel |
|---------|---------------|----------|
| **IP** | das **Endgerät** (welt-eindeutig) | `192.168.1.42` (v4) · `2001:db8::1` (v6) |
| **MAC** | die **Netzwerk-Karte** (lokal eindeutig) | `00:1A:2B:3C:4D:5E` (6 Byte hex) |
| **Port** | das **Programm** auf dem Gerät | `80` (HTTP) · `443` (HTTPS) · `22` (SSH) |

**Drei Schichten, drei Fragen.** „Welcher Computer?" → IP. „Welches Kabel/WLAN?" → MAC. „Welches Programm?" → Port.

<!--
Klausurfähig (Block D).

Konkretes Beispiel:
- `localhost:8080` = IP 127.0.0.1 (eigene Maschine) + Port 8080 (typisch für lokale Dev-Server)
- `git.librete.ch:41240` = IP von librete.ch + Port 41240 (SSH-Custom-Port)
- `8.8.8.8:53` = Google's DNS-Server + Port 53 (DNS)

MAC ist die niedrigste Adress-Ebene — wird nur im lokalen Netz benutzt. Sobald ein Paket den Router verlässt, wird die MAC ausgetauscht (nächster Hop).
-->


---

<!-- _header: "" -->
<!-- _footer: "" -->


# TCP/IP · 4 Schichten

| # | Schicht | Aufgabe | Beispiel-Protokolle | Dateneinheit |
|---|---------|---------|---------------------|--------------|
| 1 | **Network Access** | Bits auf Kabel/WLAN | Ethernet · WiFi | Frame |
| 2 | **Internet** | Routing über mehrere Hops | **IP** · ICMP | Packet |
| 3 | **Transport** | Verbindung + Zuverlässigkeit | **TCP** · UDP | Segment |
| 4 | **Application** | Anwendungs-Logik | **HTTP** · DNS · SMTP | Data |

Schichten von unten nach oben. Jede höhere Schicht **nutzt** die darunter.

<!--
Klausurfähig (Block C). Studis sollen die 4 Schichten benennen + ein Protokoll pro Schicht zuordnen + die Dateneinheit pro Schicht.

Wichtige Protokolle:
- Schicht 1: Ethernet (Kabel), WiFi 802.11 (Funk), Bluetooth
- Schicht 2: IP v4/v6, ICMP (Ping), ARP (IP→MAC-Auflösung)
- Schicht 3: TCP (zuverlässig, mit Handshake), UDP (schnell, ohne Garantien)
- Schicht 4: HTTP/HTTPS, DNS, SMTP/IMAP/POP3, SSH, FTP, MQTT

Faustregel: jeder Buchstabe in einem URL-Schema sagt was über Schicht 4 (HTTP, FTP, MQTT, …).
-->


---

<!-- _header: "" -->
<!-- _footer: "" -->


# Encapsulation — Datenüberbringung

```
[Application Data]
        ↓ + TCP-Header
[Segment]
        ↓ + IP-Header
[Packet]
        ↓ + Ethernet-Header + Trailer
[Frame]
        ↓ als Bits auf das Kabel/WLAN
```

Beim Empfänger: **umgekehrte Reihenfolge.**

<!--
Klausurfähig (Block C.2, C.3).

Diese Verschachtelung ist nicht zufällig — sie ist die direkte Folge der Schichten-Architektur. Jede Schicht braucht eigene Adressierung + eigene Kontrolldaten → eigener Header.

Konsequenz: ein HTTP-Request hat in der Realität wesentlich mehr „Overhead" als nur die HTTP-Daten:
- Ethernet-Header: 14 Byte
- IP-Header: 20 Byte (v4) oder 40 Byte (v6)
- TCP-Header: 20 Byte (oft mit Optionen mehr)
- + HTTP-Header: typisch 200-1000 Byte
- Bei kleinem HTTP-Body: Overhead > Payload
-->


---

<!-- _header: "" -->
<!-- _footer: "" -->


# HTTP-Request — was geschickt wird

```http
GET /index.html HTTP/1.1
Host: librete.ch
User-Agent: Mozilla/5.0 (Macintosh; …)
Accept: text/html,application/xhtml+xml
Accept-Language: de-DE,en-US;q=0.9
Connection: keep-alive
```

| Bestandteil | Was |
|-------------|-----|
| `GET` | **Method** — was tun wir |
| `/index.html` | **Path** — was wollen wir |
| `HTTP/1.1` | **Version** |
| `Host: …` | **Header** (mehrere möglich) |

<!--
Klausurfähig (Block E.2). Studis sollen einen HTTP-Request lesen können.

Wichtige Methods:
- GET: lesen (idempotent — gleiche Anfrage gibt gleiche Antwort)
- POST: erstellen / Daten senden
- PUT: ersetzen
- DELETE: löschen
- HEAD: nur Header holen (z.B. um Datei-Größe zu prüfen ohne Download)

Wichtige Header:
- Host: welche Website auf dem Server (mehrere Sites pro Server möglich)
- User-Agent: Browser-Identifikation
- Accept: welche Content-Types die App verarbeiten kann
- Cookie: Session-Identifikation
- Authorization: Login-Token
-->


---

<!-- _header: "" -->
<!-- _footer: "" -->


# HTTP-Response — was zurückkommt

```http
HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Content-Length: 1234
Cache-Control: max-age=3600
Server: nginx/1.24

<!DOCTYPE html>
<html>...
```

| Bestandteil | Was |
|-------------|-----|
| `200 OK` | **Statuscode + Message** |
| `Content-Type: …` | **Header** mit Meta-Information |
| (leere Zeile) | trennt Header von Body |
| `<!DOCTYPE …` | **Body** (eigentlicher Inhalt) |

<!--
Klausurfähig (Block E.2).

Status-Code ist die wichtigste Zeile. Drei Stellen, erste Stelle gibt grobe Kategorie:
- 1xx: Informational (Hinweise)
- 2xx: Success (alles ok)
- 3xx: Redirect (woanders gucken)
- 4xx: Client Error (du hast Mist gebaut)
- 5xx: Server Error (Server hat Mist gebaut)
-->


---

<!-- _header: "" -->
<!-- _footer: "" -->


# Statuscodes — die wichtigsten

| Code | Name | Bedeutung |
|------|------|-----------|
| **200** | OK | alles gut, hier dein Inhalt |
| **301** | Moved Permanently | Seite ist umgezogen, hier neue URL |
| **302** | Found | temporäre Weiterleitung |
| **400** | Bad Request | deine Anfrage war kaputt |
| **401** | Unauthorized | du musst dich einloggen |
| **403** | Forbidden | eingeloggt aber nicht berechtigt |
| **404** | Not Found | gibt's nicht |
| **500** | Internal Server Error | Server hat Bug |
| **503** | Service Unavailable | Server überlastet / down |

<!--
Klausurfähig (Block E.3): mindestens 200, 301, 404, 500 mit Bedeutung.

Memo:
- 200 = "OK" — alltäglich erfolgreich
- 301 = permanenter Umzug (Cache-fähig, SEO-Geschichte)
- 404 = klassisch — Endbenutzer kennt sie
- 500 = Server crasht
-->


---

<!-- _header: "" -->
<!-- _footer: "" -->


# Block F · URL → Pixel in 7 Schritten

1. **URL parsen** — Schema, Host, Port, Path extrahieren
2. **DNS-Lookup** — Host-Name → IP-Adresse
3. **TCP-Handshake** mit Server-IP auf Port 443
4. **TLS-Handshake** für https (Zertifikat prüfen)
5. **HTTP-Request** senden
6. Server antwortet mit **HTML, CSS, JS** (als Body)
7. Browser **parsed + rendert** — HTML-Baum + CSS-Regeln + JS-Ausführung → Pixel

<!--
Klausurfähig (Block F — die Synthese-Stelle).

Pädagogisch wichtig: Studis sollen diese 7 Schritte FREI reproduzieren können.

Konkretes Beispiel: was passiert, wenn ich `https://librete.ch` eintippe?
1. URL: Schema https, Host librete.ch, Port 443 (Default für https), Path /
2. DNS-Resolver fragt: librete.ch → 185.232.71.45
3. Browser öffnet TCP-Verbindung zu 185.232.71.45:443
4. TLS-Handshake: Zertifikat prüfen, Verschlüsselung aushandeln
5. HTTP-Request: `GET / HTTP/1.1 \r\n Host: librete.ch ...`
6. Server antwortet mit `HTTP/1.1 200 OK` + HTML
7. Browser baut DOM-Tree, lädt CSS-Dateien, lädt Bilder, führt JS aus, rendert Pixel
-->


---

<!-- _header: "" -->
<!-- _footer: "" -->


# CSS-Selektoren

| Selektor | Was |
|----------|-----|
| `p` | alle `<p>`-Elemente |
| `.btn` | alle Elemente mit `class="btn"` |
| `#header` | das Element mit `id="header"` (nur EINS pro Seite) |
| `*` | alle Elemente |
| `button:hover` | Button beim Hover |
| `button:focus` | Button mit Tastatur-Fokus |
| `input:disabled` | deaktivierte Inputs |
| `nav > a` | alle `<a>` direkt unter `<nav>` |
| `h1 + p` | erstes `<p>` direkt nach einem `<h1>` |

<!--
Klausurfähig (Block H.2).

Grundtypen:
- Element-Selektor: `p`
- Klassen-Selektor: `.btn` (kann mehrfach vorkommen)
- ID-Selektor: `#header` (einmalig pro Seite!)
- Universal-Selektor: `*`

Pseudo-Klassen (Element in einem bestimmten Zustand):
- :hover, :focus, :active
- :first-child, :last-child, :nth-child(2n)
- :disabled, :checked, :required

Kombinatoren:
- a > b: b ist direktes Kind von a
- a b: b ist irgendwo unter a (Descendant)
- a + b: b ist direkter Geschwister-NACHFOLGER von a
- a ~ b: b ist Geschwister von a (irgendwo nach)
-->


---

<!-- _header: "" -->
<!-- _footer: "" -->


# Spezifizität — wer gewinnt?

Wenn mehrere CSS-Regeln auf das gleiche Element zutreffen: **die spezifischste gewinnt.**

| Selektor-Typ | Spezifizität |
|--------------|-------------:|
| Inline `style="..."` | 1000 |
| ID `#header` | 100 |
| Klasse `.btn`, Attribut `[type=text]`, Pseudo `:hover` | 10 |
| Element `p`, Pseudo-Element `::before` | 1 |
| `*` | 0 |

Bei Gleichstand: **letzte Regel** im CSS gewinnt.

<!--
Klausurfähig (Block H.3).

Konkretes Beispiel:
```css
p { color: blue; }           /* Spezifizität: 1 */
.notice { color: red; }      /* Spezifizität: 10 */
#warn { color: green; }      /* Spezifizität: 100 */
```

Wenn ein `<p id="warn" class="notice">Hi</p>` definiert ist:
- Welche Farbe? Grün, weil #warn (100) > .notice (10) > p (1).

`!important` umgeht die Regel — sollte vermieden werden (macht Refactoring schwer).
-->


---

<!-- _header: "" -->
<!-- _footer: "" -->


# Box-Model

```
+------------------------+
|        margin          |
|  +------------------+  |
|  |     border       |  |
|  | +--------------+ |  |
|  | |   padding    | |  |
|  | | +----------+ | |  |
|  | | | content  | | |  |
|  | | +----------+ | |  |
|  | +--------------+ |  |
|  +------------------+  |
+------------------------+
```

`box-sizing: border-box;` ist Best Practice — `width` inkludiert dann Padding + Border.

<!--
Klausurfähig (Block H.1).

Studis sollen das Box-Model malen können + erklären, was content/padding/border/margin ist + Bedeutung von `box-sizing: border-box`.

Tip: in DevTools, beim Inspector wird die Box-Model-Visualisierung neben dem Element angezeigt — beste Lern-Methode.
-->


---

<!-- _header: "" -->
<!-- _footer: "" -->


# Flexbox vs Grid

| | Flexbox | Grid |
|--|---------|------|
| Dimensions | **1D** (Reihe ODER Spalte) | **2D** (Reihe UND Spalte) |
| Geeignet für | Navigation, Karten-Liste, Button-Gruppe | Seiten-Layout, komplexe Raster |
| Container-CSS | `display: flex` | `display: grid` |
| Reihen-Richtung | `flex-direction` | `grid-template-rows` |
| Spalten-Richtung | (durch flex-direction) | `grid-template-columns` |

**Faustregel:** Brauchst du nur eine Richtung? Flex. Beide? Grid.

<!--
Klausurfähig (Block H.4 konzeptionell, nicht Code).

Konkrete Beispiele:
- Header-Navigation mit Logo links + Links rechts → Flexbox (1D Horizontal)
- Foto-Galerie mit gleichmäßigen Karten → Grid (2D, fixe Spalten)
- Sidebar + Hauptinhalt + Footer-Layout → Grid (ganze Seite)
- Button mit Icon links + Text rechts → Flexbox
-->


---

<!-- _header: "" -->
<!-- _footer: "" -->


# BFSG + EAA — was kommt am 28.06.2025?

**Barrierefreiheitsstärkungsgesetz (BFSG)** — DE-Gesetz, setzt **European Accessibility Act (EAA)** um.

**Pflicht für:**
- Online-Shops, Buchungssysteme
- Banken, Versicherungen
- E-Books, E-Reader
- Smartphone-Apps mit kommerziellem Bezug

**Ausnahmen:** Unternehmen < 10 Mitarbeiter + < 2 Mio € Umsatz.

Verstöße: bis **100 000 €** Bußgeld + Klagerecht durch Behindertenverbände.

<!--
Klausurfähig (Block I.1). Studis sollen kennen:
- BFSG / EAA als Gesetz/Richtlinie
- Datum 28.06.2025
- Wer betroffen ist
- Strafrahmen

Hintergrund: ~10% der Bevölkerung haben relevante Behinderungen (Sehen, Hören, Motorik, kognitiv). Die meisten Websites sind nicht barrierefrei → diese Menschen werden ausgeschlossen.

EU hat das mit EAA 2019 beschlossen. DE setzt es mit BFSG 2021 in nationales Recht. Übergangsfrist endet 28.06.2025.
-->


---

<!-- _header: "" -->
<!-- _footer: "" -->


# WCAG · 4 Prinzipien (POUR)

| Prinzip | Bedeutung | Beispiel |
|---------|-----------|----------|
| **P**erceivable | wahrnehmbar | Alt-Text für Bilder, Untertitel für Video |
| **O**perable | bedienbar | Keyboard-Navigation, Skip-Links |
| **U**nderstandable | verständlich | Lese-Niveau, klare Fehlermeldungen |
| **R**obust | robust gegenüber Tech | semantisches HTML, Standards-konform |

**WCAG 2.1 Level AA** ist meist Mindest-Anforderung.

<!--
Klausurfähig (Block I.2). Die 4 POUR-Prinzipien benennen können.

WCAG = Web Content Accessibility Guidelines, vom W3C.
- WCAG 1.0 (1999), 2.0 (2008), 2.1 (2018), 2.2 (2023)
- Drei Stufen: A (Minimum), AA (Standard), AAA (höchste)
- BFSG verlangt Level AA

Konkrete WCAG-Kriterien (Beispiele):
- 1.1.1 Non-text Content: Alt-Text für alle Bilder
- 1.4.3 Contrast (Minimum): Kontrast 4.5:1 für Text
- 2.1.1 Keyboard: alle Funktionen mit Tastatur erreichbar
- 2.4.7 Focus Visible: Fokus-Indikator sichtbar
- 3.3.1 Error Identification: Fehler klar markieren
- 4.1.2 Name, Role, Value: ARIA korrekt einsetzen
-->