Begriff

Adaptive Technologie

Accessibility Hardware S1

2 Quellen 0 Lernpfade 0 Backlinks enriched

Warum wichtig?

Dieser Begriff ist ein Knoten im SengakujiWorks-Wissensnetz. Nutze Level 0 für die erste Einordnung, Level 1 für Praxis, Level 2 für technische Struktur und Level 3 für Grenzen, Fallstricke und Expertenkontext.

Technologie soll für alle Menschen nutzbar sein, auch für Menschen mit Behinderungen. Adaptive (oder Assistive) Technologie hilft dabei, Barrieren zu überwinden.

Screenreader: Liest Blinden vor, was auf dem Bildschirm steht.
Braille-Zeile: Tastatur, die Text in fühlbare Punkte wandelt.
Eye-Tracker: Ermöglicht Gelähmten, den PC nur mit den Augen zu steuern (Stephen Hawking nutzte so etwas).
Sprachsteuerung: Hilft Menschen, die keine Hände benutzen können.

Merksatz: Hard- und Software, die Menschen mit Einschränkungen dabei unterstützt, Computer und Technologie zu nutzen.

Als Webentwickler musst du "Barrierefreiheit" (Accessibility / A11y) beachten. Wenn du ein Bild auf die Webseite packst, musst du einen "Alt-Text" schreiben (<img alt="Ein rotes Auto">). Der Blinde sieht das Bild nicht, aber sein Screenreader liest ihm vor: "Bild: Ein rotes Auto". Ohne diesen Text sagt der Reader nur: "Bild 12345.jpg" – nutzlos.

1. ARIA-Attribute (WAI-ARIA)

Wenn HTML für komplexe UI-Komponenten (wie Dropdowns oder Modals) nicht ausreicht, muss der Entwickler nachhelfen. Screenreader wissen nativ nicht, ob ein <div> gerade als Pop-up dient. Hier nutzt man WAI-ARIA (Web Accessibility Initiative - Accessible Rich Internet Applications).

<!-- Sagt dem Screenreader: "Dieser Button klappt ein Menü aus." -->
<button aria-expanded="false" aria-controls="menu1">Menü</button>

Diese Attribute fügen semantische Bedeutung (Rollen, Zustände, Eigenschaften) in den DOM (Document Object Model) ein, ohne das Aussehen (CSS) zu verändern. Sie sind die Brücke zwischen custom JavaScript-Komponenten und der adaptiven Technologie.

2. AOM (Accessibility Object Model)

Parallel zum DOM baut der Browser das AOM (die Accessibility Tree). Er liest das fertige HTML, ignoriert alle Design-Reste (wie farbige Container ohne Inhalt) und übersetzt die Struktur in eine Baumstruktur, die speziell für Screenreader (wie JAWS, NVDA oder VoiceOver) optimiert ist. Wenn ein Entwickler CSS display: none oder visibility: hidden setzt, wird das Element komplett aus dem AOM entfernt. Es existiert für blinde Nutzer nicht mehr. Nutzt man jedoch opacity: 0 oder sr-only CSS-Klassen, bleibt der Text für Screenreader lesbar.

3. Screenreader-Trap

Ein häufiger Bug (Softwarefehler) in der Webentwicklung ist die Keyboard Trap. Ein Nutzer navigiert per TAB-Taste. Er öffnet ein Modal (z.B. einen Cookie-Banner). Die Adaptive Technologie muss nun den Fokus zwingend im Modal gefangen halten, bis es geschlossen wird. Passiert das nicht, drückt der Nutzer TAB, der Fokus wandert in den Hintergrund (den er nicht sieht/liest) und er interagiert unsichtbar mit der Seite, völlig desorientiert. Ein Albtraum für die Usability.

Quick-Check

Ist das nur für Behinderte?
Nein ("Curb Cut Effect"). Die Rampe am Bordstein hilft dem Rollstuhlfahrer, aber auch der Mutter mit Kinderwagen. Untertitel helfen Gehörlosen, aber auch dir im lauten Zug. Barrierefreiheit hilft allen.
Warum machen es nicht alle Firmen?
Es kostet Zeit und Geld. Oft fehlt das Bewusstsein ("Wir haben keine blinden Kunden" –> Henne-Ei-Problem: Blinde nutzen die Seite nicht, weil sie unzugänglich ist).
Ist Siri/Alexa Adaptive Technologie?
Ursprünglich ja! Spracherkennung wurde für Menschen entwickelt, die nicht tippen können. Heute ist es ein Mainstream-Feature.