nicht angemeldet
Hallo Tim,
(Wobei mir auch nicht wirklich in den Kopf geht, daß es einfacher zu sein scheint, einen Screenreader zu entwickeln, der einen grafischen Browser benötigt, denn einen wirklichen akustischen Browser, der sich um die grafischen Bestandteile von CSS nicht kümmern muß)
Der grafische Browser liefert ja nicht nur den reinen Elementbaum als Objekte und stellt Browsingfunktionen, Menüs und Optionen und größtenteils Tasten- und Mausbedienung zur Verfügung, er hat auch ausgeklügelte Unterstützung der Webtechniken, von HTTP über Plugin-Integration bis JavaScript, welche man nicht extra für einen vollständigen, autonomen Sprachbrowser entwickeln will. Es ist letztlich unkomplizierter, über eine Schnittstelle (hier MSAA, http://www.barrierefreies-webdesign.de/knowhow/msaa/index.php) mit einem großen, ausgereiften Browser zusammenzuarbeiten anstatt einen weitesgehend neuen aus dem Nichts zu erschaffen. Den »großen« grafischen Browser macht ja nicht nur aus, dass er CSS unterstützt.
(Natürlich könnte man aus den Quellen eines ausgereiften grafischen Browsers, welcher sowieso eine solche Schnittstelle hat, eine abgespeckte Version programmieren...)
Hinzu kommt, dass nicht nur vollständig Blinde Screenreader benutzen, sondern auch Menschen, die das Vorlesen hauptsächlich als Unterstützung beziehungsweise Lesehilfe zusätzlich zur Bildschirmanzeige benutzen. Ein Analphabet kann beispielsweise Sprache hören und Bilder/Symbole ohne Schrift verstehen...
Grüße,
Mathias