aiMOOC

Anwendungsentwicklung und Softwarequalität – Bedienoberflächen barrierearm entwickeln

QR-Code

Anwendungsentwicklung und Softwarequalität – Bedienoberflächen barrierearm entwickeln

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 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.

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.

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 W3C beschreibt diese Anforderungen in den 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.

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.

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

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:

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

Problematisch:

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

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

Merksatz

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

Mini-Aufgabe: Basis

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

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

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>`.

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.

<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>

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

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.

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.

<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>

Fehlerkorrektur als Qualitätsmerkmal

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

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.

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

:focus-visible {
  outline: 3px solid currentColor;
  outline-offset: 3px;
}

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

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.

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.

<!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>

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.

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.

<!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>

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.

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.

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.

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.

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.

Qualitätscheck für die Ausbildung

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

Quellen und Medienrechte

W3C: WAI Forms Tutorial – https://www.w3.org/WAI/tutorials/forms/
WCAG 2.2: Focus Visible – https://www.w3.org/WAI/WCAG22/Understanding/focus-visible
WCAG 2.2: Forms, Labels und Validierung – https://www.w3.org/WAI/tutorials/forms/labels/ und https://www.w3.org/WAI/tutorials/forms/validation/
: Wikimedia Commons, Dave Braunschweig, CC BY-SA 4.0.
: Wikimedia Commons, Cburnett, unter anderem CC BY-SA 3.0.
: Wikimedia Commons, DePlusJean, CC BY-SA 4.0.
: 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

Interaktive Aufgaben

Quiz: Teste Dein Wissen

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)

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)

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)

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)

Welche Taste wird typischerweise genutzt, um zum nächsten fokussierbaren Element zu gelangen? (Tab) (!Escape) (!Druck) (!Feststelltaste)

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)

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)

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)

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)

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)

Memory

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

Drag and Drop

Ordne die richtigen Begriffe zu.	Thema
Sichtbare Beschriftung	Label
Ergänzender Hinweis	aria-describedby
Pflichtangabe	required
Vorwärtsnavigation	Tabulatortaste
Aktives Bedienelement	Fokus

Kreuzworträtsel

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?

LearningApps

Lückentext

Basis-, Anwendungs- und Transferaufgaben

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.

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.

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.

Offene Aufgaben

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.

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.

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.

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.

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.