Glanz: aiMOOC über GPT aiMOOC Action erstellt

2026-10-09T19:30:22Z

aiMOOC über GPT aiMOOC Action erstellt

Neue Seite

{{T}}

{{BR}}
= Anwendungsentwicklung und Softwarequalität – Bedienoberflächen barrierearm entwickeln =

[[Datei:Accessibility.svg|320px|rahmenlos|center]]

'''Kurzbeschreibung:''' Du entwickelst und prüfst Bedienoberflächen mit Schwerpunkt auf '''Formularen, Fehlermeldungen und Tastaturbedienung'''. Du arbeitest ausschließlich mit lokalen, isolierten Testdateien und fiktiven Daten.

'''Zielgruppe:''' Ausbildung in der Anwendungsentwicklung, insbesondere [[Fachinformatiker für Anwendungsentwicklung|Fachinformatikerinnen und Fachinformatiker für Anwendungsentwicklung]].

'''Ausbildungsfall:''' Die fiktive Firma '''Lernwerk GmbH''' benötigt ein internes Formular, mit dem Auszubildende einen Schulungsraum reservieren. Die bisherige Oberfläche ist mit der Maus bedienbar, verursacht aber Probleme bei Tastatursteuerung, Beschriftung und Fehlerkorrektur.

'''Sicherheits- und Datenschutzregel:''' Nutze nur lokale Dateien oder ausdrücklich autorisierte Übungsumgebungen. Verwende ausschließlich fiktive Daten. Keine fremden Netze, Produktivsysteme, Zugangsdaten oder Kundendaten testen, angreifen oder ungefragt übertragen.

{{BR}}
= Lernziele =

Nach dem Kurs kannst Du barrierearme Formulare planen, typische Fehler erkennen, die Tastaturbedienung systematisch testen und Verbesserungen begründen. Du kannst außerdem zwischen sichtbarer Beschriftung, programmatischer Zuordnung, Fehlermeldung und Fokusführung unterscheiden.

{{BR}}
= Einleitung =

Barrierearme Bedienoberflächen helfen Menschen, die eine Website nicht oder nicht ausschließlich mit Maus und Bildschirm bedienen. Für Formulare sind vor allem eindeutige Beschriftungen, verständliche Hinweise, erkennbare Fehler und eine vollständige Tastaturbedienung wichtig.

Das [[World Wide Web Consortium|W3C]] beschreibt diese Anforderungen in den [[Web Content Accessibility Guidelines|WCAG]]. Für den Ausbildungsalltag ist besonders wichtig: Nutze nach Möglichkeit native [[HTML]]-Elemente, ordne Beschriftungen technisch korrekt zu und teste die Oberfläche praktisch mit der Tastatur.

[[Datei:Sample web form.png|450px|rahmenlos|center]]

Das Bild zeigt ein klassisches HTML-Formular. Für Barrierearmut reicht eine sichtbare Anordnung allein nicht: Die Beziehungen zwischen Beschriftung und Eingabefeld müssen auch im Code eindeutig sein.

{{#ev:youtube| https://www.youtube.com/watch?v=93UgG72os8M |500|center}}

Das W3C-WAI-Video demonstriert, warum Tastaturkompatibilität für viele Menschen entscheidend ist.

{{BR}}
= Lerneinheit 1: Formulare verständlich beschriften =

Ein Eingabefeld braucht einen verständlichen Namen. In HTML ist ein sichtbares `<label>` meist die beste Lösung. Das Attribut `for` des Labels verweist auf die `id` des Eingabefeldes.

'''Gut:'''

<syntaxhighlight lang="html">
<label for="name">Name der reservierenden Person</label>
<input id="name" name="name" type="text" autocomplete="name">
</syntaxhighlight>

'''Problematisch:'''

<syntaxhighlight lang="html">
<input type="text" placeholder="Name">
</syntaxhighlight>

Ein Placeholder ersetzt kein dauerhaft sichtbares Label. Er kann beim Tippen verschwinden und ist deshalb als alleinige Beschriftung ungeeignet.

{{BR}}
== Merksatz ==

'''Was Du sehen kannst, sollte möglichst auch programmatisch eindeutig zugeordnet sein.'''

{{BR}}
== Mini-Aufgabe: Basis ==

Prüfe den folgenden Ausschnitt und nenne den wichtigsten Mangel:

<syntaxhighlight lang="html">
<p>E-Mail-Adresse</p>
<input id="mail" type="email">
</syntaxhighlight>

'''Feedback:''' Die sichtbare Beschriftung ist nicht als `label` mit dem Eingabefeld verbunden. Dadurch ist die Beziehung für assistive Technik nicht zuverlässig erkennbar. Eine passende Lösung ist `<label for="mail">E-Mail-Adresse</label>`.

{{BR}}
= Lerneinheit 2: Hinweise und Pflichtfelder =

Anweisungen sollen kurz, sichtbar und am passenden Feld verfügbar sein. Pflichtfelder sollten nicht nur durch Farbe oder ein Sternsymbol kenntlich gemacht werden.

<syntaxhighlight lang="html">
<label for="datum">Datum der Schulung</label>
<p id="datum-hilfe">Format: TT.MM.JJJJ</p>
<input id="datum" name="datum" type="text"
aria-describedby="datum-hilfe" required>
</syntaxhighlight>

`aria-describedby` kann ergänzende Hinweise mit einem Eingabefeld verbinden. Es ersetzt kein gutes sichtbares Label.

{{BR}}
== Mini-Aufgabe: Anwendung ==

Ergänze für ein Feld „Teilnehmendenzahl“ eine sichtbare Beschriftung, einen Hinweis „1 bis 12 Personen“ und geeignete HTML-Attribute.

'''Gestufte Hilfe 1:''' Beginne mit `<label>` und `<input>`.

'''Gestufte Hilfe 2:''' Für Zahlen gibt es `type="number"`, `min` und `max`.

'''Gestufte Hilfe 3:''' Verbinde den Hinweis mit `aria-describedby`.

'''Feedback:''' Eine robuste Lösung nutzt native HTML-Attribute, weil Browser und assistive Technologien deren Bedeutung bereits kennen. Zusätzliche ARIA-Attribute sollten nur ergänzen, nicht unnötig native Semantik ersetzen.

{{BR}}
= Lerneinheit 3: Fehlermeldungen =

Eine gute Fehlermeldung beantwortet drei Fragen: '''Was ist falsch? Wo ist der Fehler? Wie kann ich ihn korrigieren?'''

'''Schwach:''' „Fehler 42“

'''Besser:''' „E-Mail-Adresse fehlt. Trage eine Adresse im Format name@beispiel.de ein.“

Für einfache Anforderungen kann die eingebaute HTML-Validierung eine gute Basis sein. Bei selbst entwickelten Fehlermeldungen muss zusätzlich geprüft werden, ob die Meldung programmatisch mit dem Feld verbunden und für assistive Technik wahrnehmbar ist.

<syntaxhighlight lang="html">
<label for="mail2">E-Mail-Adresse</label>
<input id="mail2" name="mail2" type="email"
aria-describedby="mail2-fehler"
aria-invalid="true">
<p id="mail2-fehler">Fehler: Trage eine gültige E-Mail-Adresse ein.</p>
</syntaxhighlight>

{{BR}}
== Fehlerkorrektur als Qualitätsmerkmal ==

Eine Fehlermeldung ist kein Selbstzweck. Sie soll die Korrektur erleichtern. Vermeide Meldungen, die nur Farbe, Position oder Fehlercodes nennen.

{{BR}}
= Lerneinheit 4: Tastaturbedienung =

Mit der Tabulatortaste bewegst Du den Fokus normalerweise durch interaktive Elemente. Mit `Shift` + `Tab` bewegst Du ihn rückwärts. Schaltflächen und Links müssen ohne Maus erreichbar und bedienbar sein.

[[Datei:WikiMooc Key TAB.svg|320px|rahmenlos|center]]

[[Datei:WikiMooc Key ENT1.svg|220px|rahmenlos|center]]

Ein sichtbarer Tastaturfokus ist wichtig, damit Du jederzeit erkennst, welches Element gerade aktiv ist.

<syntaxhighlight lang="css">
:focus-visible {
outline: 3px solid currentColor;
outline-offset: 3px;
}
</syntaxhighlight>

Vermeide CSS wie `outline: none`, wenn Du keinen gleichwertigen sichtbaren Fokusindikator bereitstellst.

{{BR}}
== Tastatur-Test in fünf Schritten ==

# [[Tabulatortaste]]: Erreiche alle interaktiven Elemente mit Tab und Shift + Tab.
# [[Fokus]]: Prüfe, ob der Fokus immer deutlich sichtbar ist.
# [[Reihenfolge]]: Prüfe, ob die Fokusreihenfolge der sichtbaren und logischen Reihenfolge entspricht.
# [[Bedienung]]: Aktiviere Schaltflächen, Links und Formulare ohne Maus.
# [[Fehlerkorrektur]]: Löse Validierungsfehler aus und korrigiere sie nur mit der Tastatur.

{{BR}}
= Lerneinheit 5: Lokales Formular-Labor =

Speichere den folgenden Inhalt als `reservierung.html` auf Deinem eigenen Rechner und öffne die Datei lokal im Browser. Es werden keine Daten versendet; das Formular verwendet fiktive Testdaten und hat kein Netzwerkziel.

<syntaxhighlight lang="html">
<!doctype html>
<html lang="de">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>Lokales Reservierungslabor</title>
<style>
body { font-family: sans-serif; max-width: 42rem; margin: 2rem auto; padding: 0 1rem; }
label { display: block; font-weight: bold; margin-top: 1rem; }
input, select, button { font: inherit; padding: .6rem; margin-top: .25rem; }
.hilfe { margin: .25rem 0; }
:focus-visible { outline: 3px solid currentColor; outline-offset: 3px; }
</style>
</head>
<body>
<main>
<h1>Schulungsraum reservieren</h1>
<p>Übungsumgebung mit fiktiven Daten. Pflichtfelder sind als Pflichtfeld bezeichnet.</p>

<form>
<label for="name">Name – Pflichtfeld</label>
<input id="name" name="name" autocomplete="name" required>

<label for="mail">E-Mail – Pflichtfeld</label>
<p class="hilfe" id="mail-hilfe">Beispiel: azubi@example.test</p>
<input id="mail" name="mail" type="email"
aria-describedby="mail-hilfe" required>

<label for="raum">Raum – Pflichtfeld</label>
<select id="raum" name="raum" required>
<option value="">Bitte auswählen</option>
<option>Raum A</option>
<option>Raum B</option>
</select>

<label for="personen">Teilnehmende – Pflichtfeld</label>
<p class="hilfe" id="personen-hilfe">Zulässig sind 1 bis 12 Personen.</p>
<input id="personen" name="personen" type="number"
min="1" max="12" aria-describedby="personen-hilfe" required>

<button type="submit">Reservierung lokal prüfen</button>
</form>
</main>
</body>
</html>
</syntaxhighlight>

'''Testauftrag:''' Öffne die Datei lokal. Benutze nur Tab, Shift + Tab, Pfeiltasten, Leertaste und Enter. Lasse Pflichtfelder leer, gib absichtlich ungültige Werte ein und beobachte Fokus und Browsermeldungen.

'''Feedback:''' Wenn alle Felder erreichbar sind, der Fokus sichtbar bleibt und Fehler ohne Maus korrigierbar sind, erfüllt die Oberfläche wichtige Grundlagen der Tastatur- und Formularzugänglichkeit. Das ist noch keine vollständige WCAG-Konformitätsprüfung.

{{BR}}
= Lerneinheit 6: Vergleichslabor – absichtlich problematisch =

Speichere den folgenden Code als `problemfall.html`. Die Datei ist ebenfalls rein lokal. Sie enthält bewusst Fehler, die Du finden und verbessern sollst.

<syntaxhighlight lang="html">
<!doctype html>
<html lang="de">
<head>
<meta charset="utf-8">
<title>Problemfall</title>
<style>
body { font-family: sans-serif; max-width: 40rem; margin: 2rem auto; }
:focus { outline: none; }
</style>
</head>
<body>
<h1>Raumbuchung</h1>

<p>Name</p>
<input type="text" placeholder="Name">

<p>E-Mail</p>
<input type="text" placeholder="E-Mail">

<p style="color:red">Pflichtfelder sind rot.</p>

<div onclick="alert('Nur Demonstration')">Buchen</div>
</body>
</html>
</syntaxhighlight>

'''Hinweis:''' Der Beispielcode demonstriert typische Qualitätsprobleme. Verwende ihn nicht als Vorlage für reale Systeme.

'''Gestufte Hilfe 1:''' Suche zuerst nach fehlenden nativen Formularelementen.

'''Gestufte Hilfe 2:''' Prüfe Beschriftung, Eingabetyp, Fokusdarstellung und Bedienbarkeit der vermeintlichen Schaltfläche.

'''Gestufte Hilfe 3:''' Ersetze den klickbaren `div` durch ein echtes `button`-Element, ergänze `label`-Elemente und entferne die Unterdrückung des Fokusindikators.

'''Feedback:''' Native Elemente reduzieren den Implementierungsaufwand und bringen bereits Rollen, Zustände und Tastaturverhalten mit. Das verbessert Wartbarkeit und Barrierearmut gleichzeitig.

{{BR}}
= Lerneinheit 7: Visualisierte Testdaten =

Die folgenden Daten sind '''fiktive Übungsdaten''' aus 20 manuellen Testfällen des Ausbildungsfalls. Sie dienen ausschließlich zur Analyse im Kurs.

{| class="wikitable"
! Beobachtung
! Anzahl
! Visualisierung
|-
| Fehlende oder unklare Beschriftung
| 7
| ███████
|-
| Unsichtbarer oder schwacher Fokus
| 5
| █████
|-
| Unklare Fehlermeldung
| 4
| ████
|-
| Unlogische Fokusreihenfolge
| 3
| ███
|-
| Nicht per Tastatur aktivierbares Bedienelement
| 1
| █
|}

'''Auswertung:''' In diesem fiktiven Testsatz treten Beschriftungsprobleme am häufigsten auf. Für die Fehlerbehebung sollte trotzdem nicht nur nach Häufigkeit priorisiert werden: Ein einzelnes nicht bedienbares Element kann einen kompletten Arbeitsablauf blockieren.

{{BR}}
== Transferfrage ==

Welche zwei Fehler würdest Du zuerst beheben, wenn die Anwendung morgen in einer internen Schulung verwendet werden soll? Begründe Deine Priorisierung mit Auswirkung auf die Nutzbarkeit, nicht nur mit der Anzahl.

'''Feedback:''' Eine gute Priorisierung berücksichtigt Schweregrad, betroffene Aufgabe, Reichweite und Reparaturaufwand. Häufigkeit allein reicht nicht.

{{BR}}
= Praxisfall: Lernwerk GmbH =

Die Lernwerk GmbH möchte das lokale Reservierungsformular später in eine interne Anwendung übernehmen. Deine Aufgabe ist ein kleiner Qualitätszyklus:

# [[Anforderungsanalyse]]: Formuliere überprüfbare Anforderungen an Labels, Fehlermeldungen und Tastaturbedienung.
# [[Implementierung]]: Verbessere die lokale Testdatei.
# [[Softwaretest]]: Prüfe den Ablauf ausschließlich in der isolierten lokalen Testumgebung.
# [[Fehlerbericht]]: Dokumentiere Fundstelle, Auswirkung, Reproduktion und Verbesserungsvorschlag.
# [[Review]]: Begründe, warum die Verbesserung für unterschiedliche Nutzende hilfreich ist.

{{BR}}
= Qualitätscheck für die Ausbildung =

{| class="wikitable"
! Prüffrage
! Erwartung
|-
| Hat jedes Eingabefeld eine verständliche Beschriftung?
| Sichtbares Label und korrekte technische Zuordnung
|-
| Sind Hinweise auch ohne Farbe verständlich?
| Textliche Information vorhanden
|-
| Erklärt eine Fehlermeldung die Korrektur?
| Fehler, Ort und Lösung sind verständlich
|-
| Ist alles mit der Tastatur erreichbar?
| Vollständige Bedienkette ohne Maus
|-
| Bleibt der Fokus sichtbar?
| Fokusindikator ist klar erkennbar
|-
| Entspricht die Reihenfolge der Aufgabe?
| Logischer Fokusfluss
|}

{{BR}}
= Quellen und Medienrechte =

# [[W3C]]: WAI Forms Tutorial – https://www.w3.org/WAI/tutorials/forms/
# [[Web Content Accessibility Guidelines|WCAG 2.2]]: Focus Visible – https://www.w3.org/WAI/WCAG22/Understanding/focus-visible
# [[Web Content Accessibility Guidelines|WCAG 2.2]]: Forms, Labels und Validierung – https://www.w3.org/WAI/tutorials/forms/labels/ und https://www.w3.org/WAI/tutorials/forms/validation/
# [[Datei:Accessibility.svg]]: Wikimedia Commons, Dave Braunschweig, CC BY-SA 4.0.
# [[Datei:Sample web form.png]]: Wikimedia Commons, Cburnett, unter anderem CC BY-SA 3.0.
# [[Datei:WikiMooc Key TAB.svg]]: Wikimedia Commons, DePlusJean, CC BY-SA 4.0.
# [[Datei:WikiMooc Key ENT1.svg]]: Wikimedia Commons, DePlusJean, CC BY-SA 4.0.
# W3C Web Accessibility Initiative: „Web Accessibility Perspectives: Keyboard Compatibility“, YouTube, https://www.youtube.com/watch?v=93UgG72os8M

{{BR}}
= Interaktive Aufgaben =

{{BR}}
== Quiz: Teste Dein Wissen ==

{{MC}}
'''Welche HTML-Kombination ordnet eine sichtbare Beschriftung zuverlässig einem Eingabefeld zu?'''
(label mit for und input mit passender id)
(!placeholder und input ohne id)
(!p Element und input)
(!div und span)
{{E}}
<br>

{{MC}}
'''Welche Aussage zu Placeholdern ist richtig?'''
(Ein Placeholder ersetzt kein dauerhaft sichtbares Label)
(!Ein Placeholder ist immer ein vollständiger Ersatz für ein Label)
(!Ein Placeholder bleibt beim Tippen immer sichtbar)
(!Ein Placeholder erzeugt automatisch eine Fehlermeldung)
{{E}}
<br>

{{MC}}
'''Wozu dient aria-describedby in einem Formular?'''
(Es verbindet ergänzende Hinweise mit einem Bedienelement)
(!Es ersetzt jedes label Element)
(!Es sendet Formulardaten)
(!Es sortiert die Tabreihenfolge)
{{E}}
<br>

{{MC}}
'''Was sollte eine gute Fehlermeldung ermöglichen?'''
(Den Fehler verstehen und gezielt korrigieren)
(!Nur einen technischen Fehlercode anzeigen)
(!Nur die Farbe des Feldes ändern)
(!Den Tastaturfokus entfernen)
{{E}}
<br>

{{MC}}
'''Welche Taste wird typischerweise genutzt, um zum nächsten fokussierbaren Element zu gelangen?'''
(Tab)
(!Escape)
(!Druck)
(!Feststelltaste)
{{E}}
<br>

{{MC}}
'''Was ist bei einem sichtbaren Tastaturfokus besonders wichtig?'''
(Das aktuell fokussierte Element ist klar erkennbar)
(!Der Fokus wird vollständig ausgeblendet)
(!Der Fokus erscheint nur bei Mausbewegung)
(!Der Fokus überspringt Formulare)
{{E}}
<br>

{{MC}}
'''Warum sind native HTML Bedienelemente meist eine gute Ausgangsbasis?'''
(Sie bringen Semantik und grundlegendes Tastaturverhalten mit)
(!Sie benötigen grundsätzlich keine Tests)
(!Sie verhindern automatisch jeden Eingabefehler)
(!Sie machen CSS überflüssig)
{{E}}
<br>

{{MC}}
'''Welche Testumgebung ist für die Übungen dieses Kurses vorgesehen?'''
(Eine lokale isolierte Testdatei mit fiktiven Daten)
(!Ein fremder Produktivserver)
(!Ein Kundensystem ohne Freigabe)
(!Ein öffentliches Netz mit echten Zugangsdaten)
{{E}}
<br>

{{MC}}
'''Was ist bei Pflichtfeldern sinnvoll?'''
(Die Pflichtangabe wird verständlich und nicht nur über Farbe vermittelt)
(!Pflichtfelder werden ausschließlich rot markiert)
(!Pflichtfelder bleiben unbeschriftet)
(!Pflichtfelder werden aus der Tabreihenfolge entfernt)
{{E}}
<br>

{{MC}}
'''Wann ist eine Formularprüfung besonders aussagekräftig?'''
(Wenn der vollständige Arbeitsablauf auch ohne Maus getestet wird)
(!Wenn nur die Startseite betrachtet wird)
(!Wenn nur die Farbe der Schaltfläche geprüft wird)
(!Wenn ausschließlich Quellcode gelesen wird)
{{E}}
<br>

{{BR}}
== Memory ==

<div class="memo-quiz">
{|
|-
| Label || Beschriftung eines Formularelements
|-
| Fokus || Aktuell bedienbares Element
|-
| Tabulatortaste || Navigation zum nächsten fokussierbaren Element
|-
| Fehlermeldung || Hinweis zur Korrektur einer Eingabe
|-
| required || HTML Attribut für ein Pflichtfeld
|-
| aria-describedby || Zuordnung ergänzender Beschreibung
|}
{{E}}
<br>

{{BR}}
== Drag and Drop ==

<div class="lueckentext-quiz">

{| class="wikitable"
! Ordne die richtigen Begriffe zu.
! Thema
|-
| '''Sichtbare Beschriftung'''
| Label
|-
| '''Ergänzender Hinweis'''
| aria-describedby
|-
| '''Pflichtangabe'''
| required
|-
| '''Vorwärtsnavigation'''
| Tabulatortaste
|-
| '''Aktives Bedienelement'''
| Fokus

|}
{{E}}

<br>

{{BR}}
== Kreuzworträtsel ==

<div class="kreuzwort-quiz">
{|
|-
| Label || Welches HTML Element beschriftet ein Formularfeld?
|-
| Fokus || Wie heißt der Zustand des aktuell bedienbaren Elements?
|-
| Fehler || Was muss bei ungültiger Eingabe verständlich erklärt werden?
|-
| Tastatur || Welches Eingabegerät soll die gesamte Bedienung ermöglichen?
|-
| Formular || Wie heißt eine Oberfläche zur strukturierten Dateneingabe?
|-
| Browser || Welche Software zeigt die lokale HTML Testdatei an?
|}
{{E}}
<br>

{{BR}}
== LearningApps ==

<iframe> https://learningapps.org/index.php?s=Anwendungsentwicklung+und+Softwarequalität+Bedienoberflächen+barrierearm+entwickeln </iframe>

{{BR}}
== Lückentext ==

<quiz display=simple>
{'''Vervollständige den Text.'''<br>
|type="{}"}
Ein Eingabefeld sollte eine verständliche { Beschriftung } besitzen. Ein HTML Label wird über das Attribut { for } mit einer passenden id verbunden. Ergänzende Hinweise können mit { aria-describedby } zugeordnet werden. Ein Pflichtfeld kann mit { required } gekennzeichnet werden. Bei der Tastaturbedienung zeigt der { Fokus } das aktuell aktive Element. Eine gute Fehlermeldung unterstützt die { Korrektur } der Eingabe. Für Übungen in diesem Kurs werden ausschließlich { lokale } Testumgebungen und fiktive Daten verwendet.
</quiz>

<br>

{{BR}}
= Basis-, Anwendungs- und Transferaufgaben =

{{BR}}
== Basis ==

# [[Formularanalyse]]: Markiere in einer lokalen Übungsdatei alle Labels, Eingabefelder, Hinweise und Schaltflächen.
# [[Tastaturtest]]: Durchlaufe das Formular vollständig mit Tab und Shift + Tab.
# [[Fehlermeldung]]: Formuliere eine unklare Meldung wie „Fehler“ so um, dass die Korrektur eindeutig wird.

'''Begründetes Feedback:''' Auf Basisniveau zählt vor allem, dass Du Elemente und typische Qualitätsmerkmale sicher erkennst. Eine Lösung ist gut, wenn sie konkret am Bedienelement überprüfbar ist.

{{BR}}
== Anwendung ==

# [[HTML-Formular]]: Verbessere `problemfall.html` mit nativen HTML Elementen und sichtbarem Fokus.
# [[Testprotokoll]]: Dokumentiere mindestens fünf Tastatur-Testfälle mit Erwartung und Ergebnis.
# [[Fehlerpriorisierung]]: Ordne die fiktiven Befunde nach Auswirkung auf den Arbeitsablauf.

'''Begründetes Feedback:''' Auf Anwendungsniveau musst Du eine Regel nicht nur nennen, sondern in Code und Testfällen nachvollziehbar umsetzen.

{{BR}}
== Transfer ==

# [[Softwarequalität]]: Entwickle eine kleine Definition of Done für barrierearme Formulare.
# [[Code-Review]]: Begründe, welche Barrieren durch native Elemente vermieden werden und welche weiterhin getestet werden müssen.
# [[Teststrategie]]: Entwirf eine Kombination aus manuellem Tastaturtest, Browservalidierung und späteren automatisierten Prüfungen.

'''Begründetes Feedback:''' Auf Transferniveau ist eine Lösung stark, wenn sie technische Umsetzung, Nutzungssituation und Qualitätssicherung miteinander verbindet.

{{BR}}
= Offene Aufgaben =

{{BR}}
=== Leicht ===

# [[Label-Check]]: Untersuche das lokale Reservierungsformular und liste alle korrekt zugeordneten Labels auf.
# [[Fokusprotokoll]]: Notiere die Fokusreihenfolge beim Durchtabben.
# [[Fehlermeldungen]]: Schreibe drei verständliche Fehlermeldungen für leere oder falsche Eingaben.
# [[Medienanalyse]]: Beschreibe anhand des W3C-WAI-Videos zwei Vorteile der Tastaturbedienung.

{{BR}}
=== Standard ===

# [[Formular verbessern]]: Überarbeite den lokalen Problemfall und dokumentiere jede Änderung in einem kurzen Vorher-Nachher-Vergleich.
# [[Testfälle entwickeln]]: Erstelle acht Testfälle zu Labels, Pflichtfeldern, Fehlermeldungen und Tastaturbedienung.
# [[Peer Review]]: Tausche Deine lokale Datei mit einer anderen Person und führe einen strukturierten Tastaturtest durch.
# [[Datenvisualisierung]]: Visualisiere die Befunde Deines lokalen Tests als Tabelle oder Balkendarstellung und interpretiere sie.

{{BR}}
=== Schwer ===

# [[Barrierearme Komponente]]: Entwirf ein wiederverwendbares Formularmuster für Dein Ausbildungsprojekt und begründe die Wahl der HTML Elemente.
# [[Qualitätssicherung]]: Erstelle eine Definition of Done mit prüfbaren Kriterien für barrierearme Bedienoberflächen.
# [[Transferanalyse]]: Vergleiche zwei lokale Formularvarianten hinsichtlich Bedienbarkeit, Wartbarkeit und Fehlerkorrektur.
# [[Testkonzept]]: Entwirf einen sicheren Prüfprozess, der lokale manuelle Tests mit autorisierten automatisierten Prüfungen kombiniert und den Umgang mit Testdaten festlegt.

{{:Offene Aufgabe - MOOC erstellen}}

{{BR}}
= Lernkontrolle =

# [[Transfer Formularentwurf]]: Eine Anwendung besitzt sichtbare Feldnamen, aber keine `label` Elemente. Erkläre die möglichen Auswirkungen und skizziere eine robuste Verbesserung.
# [[Fehlerstrategie]]: Entwickle für ein Formular mit drei Pflichtfeldern eine Strategie, wie Fehler erkannt, erklärt und korrigiert werden können, ohne ausschließlich Farbe zu verwenden.
# [[Tastaturproblem]]: Ein Dialog ist mit der Maus nutzbar, aber ein wichtiger Button ist per Tab nicht erreichbar. Analysiere die Auswirkung auf den Arbeitsablauf und priorisiere den Fehler.
# [[Qualitätsabwägung]]: Begründe, warum ein automatisierter Prüfbericht allein keine vollständige Aussage über die Tastaturbedienbarkeit liefert.
# [[Ausbildungsfall]]: Plane für die Lernwerk GmbH einen kurzen Abnahmetest, der Beschriftung, Fehlermeldungen, Fokus und vollständige Bedienbarkeit abdeckt.
# [[Sicherer Testprozess]]: Erkläre, warum reale Kundendaten und ungefragte Produktivtests für diesen Lernzweck ungeeignet sind und welche sichere Alternative genutzt wird.

<br>
<br>

{{BR}}
= Lernnachweis =

Für einen Lernnachweis zu diesem Thema solltest Du zeigen, dass Du:
# ein kleines Formular semantisch sinnvoll strukturieren kannst,
# sichtbare Beschriftungen korrekt mit Eingabefeldern verbindest,
# verständliche Hinweise und Fehlermeldungen formulierst,
# eine Oberfläche vollständig mit der Tastatur testest,
# einen sichtbaren und logischen Fokus beurteilst,
# Testbefunde nachvollziehbar dokumentierst und priorisierst,
# Verbesserungen mit Softwarequalität und Nutzbarkeit begründest,
# ausschließlich lokale oder ausdrücklich autorisierte Testumgebungen mit fiktiven Daten verwendest.

<br>
<br>

{{BR}}
= OERs zum Thema =

<iframe> https://de.m.wikipedia.org/wiki/Barrierefreies_Internet </iframe>

{{BR}}
= Verknüpfte Lernbereiche =

{| align=center
{{:D-Tab}}
'''[[Anwendungsentwicklung und Softwarequalität]]'''
# [[Barrierefreies Internet]]
# [[Web Content Accessibility Guidelines]]
# [[HTML]]
# [[Formular]]
# [[Usability]]
# [[Softwaretest]]
# [[Softwarequalität]]
# [[Benutzerschnittstelle]]
# [[Fokus]]
|}

[[Kategorie:Informatik]]
[[Kategorie:Anwendungsentwicklung]]
[[Kategorie:Softwarequalität]]
[[Kategorie:Webentwicklung]]
[[Kategorie:Barrierefreiheit]]
[[Kategorie:HTML]]
[[Kategorie:Ausbildung]]
[[Kategorie:Fachinformatiker]]
[[Kategorie:Berufliche Bildung]]

{{BR}}
= aiMOOC-Projekte =
[[Kategorie:AI_MOOC]] [[Kategorie:GPT aiMOOC]]
{{MT}}

Anwendungsentwicklung und Softwarequalität – Bedienoberflächen barrierearm entwickeln - Versionsgeschichte

Glanz: aiMOOC über GPT aiMOOC Action erstellt