Hej Mistfinder, > > Da hab ich mal nachgefragt. > > Wozu das denn? Man befrage einfach einfach einen klassischen, gewiss nicht css-fähigen Textbrowser wie [lynx](http://lynx.browser.org/) oder [w3m](http://w3m.sourceforge.net/) und frage sich, ob man das so präsentiert haben will. Das ist, war und bleibt die für normalsichtige effektivste Methode um zu sehen wie jeder blinde Benutzer(*) mit der Seite klarkommen wird. Blinde benutzen aber nicht lynx, sondern Jaws, NVDA oder manchmal auch ins Betriebssystem eingebaute Funktionen wie Sprachausgabe von iOS. - Die Experten, die @Gunnar Bittersmann zu recht befragt, sind nicht nur selber täglich auf dieses Hilfsmittel angewiesen und können darum auch subtilere Verbesserungen wahrnehmen. Sie sind auch noch alle im Gebiet "Entwicklung barrierefreier Webseiten" bewandert und haben neben der Praxis auch ein umfangreiches theoretisches Wissen über Standards und Softwarefähigkeiten - auch ein paar Generationen zurück. Sie geben auch - wie in den Folien von Leonie Watson, die ebenfalls Gunnar hier verlinkt hat - auch noch Hinweise, wie man die Theorie in der Praxis anwendet. Vor allem aber: lynx wertet vieles schlicht nicht aus, was Screenreader-Nutzern eine Website erst komfortabel macht (WAI-Aria-Attribute, Rollen, usw) Es sind die vielen Kleinigkeiten in den Unterschieden. So wird eine Navigationsliste von lynx anders dargestellt als in einem Screenreader und in lynx ist eine Navigation ohne Liste viel weniger problematisch, als in einem Screenreader, denn lynx wird von einem Sehenden bedient, der nicht darauf angewiesen ist, diese liste überspringen zu können (auch wenn es nicht schön ist, die links einfach in einer Reihe stehen zu haben). Mittels `display: none` versteckte Inhalte in einem aufklappbaren Navigationsmenü wie auf [www.bildungsserveragrar.de](http://www.bildungsserveragrar.de) werden von Lynx komplett angezeigt - von Screenreadern nicht, lynx unterstützt kein https und kann solche Seiten überhaupt nciht anzeigen usw... Marc

Hej Mistfinder, > > Da hab ich mal nachgefragt. > > Wozu das denn? Man befrage einfach einfach einen klassischen, gewiss nicht css-fähigen Textbrowser wie [lynx](http://lynx.browser.org/) oder [w3m](http://w3m.sourceforge.net/) und frage sich, ob man das so präsentiert haben will. Das ist, war und bleibt die für normalsichtige effektivste Methode um zu sehen wie jeder blinde Benutzer(*) mit der Seite klarkommen wird. Blinde benutzen aber nicht lynx, sondern Jaws, NVDA oder manchmal auch ins Betriebssystem eingebaute Funktionen wie Sprachausgabe von iOS. - Die Experten, die @Gunnar Bittersmann zu recht befragt, sind nicht nur selber täglich auf dieses Hilfsmittel angewiesen und können darum auch subtilere Verbesserungen wahrnehmen. Sie sind auch noch alle im Gebiet "Entwicklung barrierefreier Webseiten" bewandert und haben neben der Praxis auch ein umfangreiches theoretisches Wissen über Standards und Softwarefähigkeiten - auch ein paar Generationen zurück. Sie geben auch - wie in den Folien von Leonie Watson, die ebenfalls Gunnar hier verlinkt hat - auch noch Hinweise, wie man die Theorie in der Praxis anwendet. Vor allem aber: lynx wertet vieles schlicht nicht aus, was Screenreader-Nutzern eine Website erst komfortabel macht (WAI-Aria-Attribute, Rollen, usw) Es sind die vielen Kleinigkeiten in den Unterschieden. So wird eine Navigationsliste von lynx anders dargestellt als in einem Screenreader und in lynx ist eine Navigation ohne Liste viel weniger problematisch, als in einem Screenreader, denn lynx wird von einem Sehenden bedient, der nicht darauf angewiesen ist, diese liste überspringen zu können (auch wenn es nicht schön ist, die links einfach in einer Reihe stehen zu haben). Mittels `display: none`{: .language-css} versteckte Inhalte in einem aufklappbaren Navigationsmenü wie auf [www.bildungsserveragrar.de](http://www.bildungsserveragrar.de) werden von Lynx komplett angezeigt - von Screenreadern nicht, lynx unterstützt kein https und kann solche Seiten überhaupt nciht anzeigen usw... Marc

Hej Mistfinder, > > Da hab ich mal nachgefragt. > > Wozu das denn? Man befrage einfach einfach einen klassischen, gewiss nicht css-fähigen Textbrowser wie [lynx](http://lynx.browser.org/) oder [w3m](http://w3m.sourceforge.net/) und frage sich, ob man das so präsentiert haben will. Das ist, war und bleibt die für normalsichtige effektivste Methode um zu sehen wie jeder blinde Benutzer(*) mit der Seite klarkommen wird. Blinde benutzen aber nicht lynx, sondern Jaws, NVDA oder manchmal auch ins Betriebssystem eingebaute Funktionen wie Sprachausgabe von iOS. - Die Experten, die @Gunnar Bittersmann zu recht befragt, sind nicht nur selber täglich auf dieses Hilfsmittel angewiesen und können darum auch subtilere Verbesserungen wahrnehmen. Sie sind auch noch alle im Gebiet "Entwicklung barrierefreier Webseiten" bewandert und haben neben der Praxis auch ein umfangreiches theoretisches Wissen über Standards und Softwarefähigkeiten - auch ein paar Generationen zurück. Sie geben auch - wie in den Folien von Leonie Watson, die ebenfalls Gunnar hier verlinkt hat - auch noch Hinweise, wie man die Theorie in der Praxis anwendet. Vor allem aber: lynx wertet vieles schlicht nicht aus, was Screenreader-Nutzern eine Website erst komfortabel macht (WAI-Aria-Attribute, Rollen, usw) Es sind die vielen Kleinigkeiten in den Unterschieden. So wird eine Navigationsliste von lynx anders dargestellt als in einem Screenreader und in lynx ist eine Navigation ohne Liste viel weniger problematisch, als in einem Screenreader, denn lynx wird von einem Sehenden bedient, der nicht darauf angewiesen ist, diese liste überspringen zu können (auch wenn es nicht schön ist, die links einfach in einer Reihe stehen zu haben). Mittels ~~~CSS display: none ~~~ versteckte Inhalte in einem aufklappbaren Navigationsmenü wie auf [www.bildungsserveragrar.de](http://www.bildungsserveragrar.de) werden von Lynx komplett angezeigt - von Screenreadern nicht, lynx unterstützt kein https und kann solche Seiten überhaupt nciht anzeigen usw... Marc