Hallo zusammen,
bei Heise habe ich heute gelesen, dass Aktion Mensch einen barrierefreien Videoplayer "entwickelt" hat [0][1]. Genau genommen haben sie als Basis für den Player das Open Source Projekt "mediaelement.js" genommen, das unter der MIT-Lizenz steht. Dazu haben sie eine Erweiterung entwickelt, die leider nicht Open Source ist und die Nutzung nur sehr eingeschränkt erlaubt, z.B. auch mit einer Noncommercial-Klausel.
Ich finde das sehr Schade, da ich im ersten Moment dachte, dass es vielleicht cool wäre, die Videos der FSFE, z.B. das auf der Website von "Public Money Public Code" mit der Erweiterung barrierefrei zu gestalten. Nachdem ich die Lizenz der Erweiterung in der Textdatei gelesen habe, die dem Download beiligt, möchte ich das nicht mehr vorschlagen. Die Geschichte würde eigentlich perfekt zum Geist Freier Software oder Open Source passen: Jemand stört sich daran, dass es keinen barrierefreien Player im Netz gibt, schnappt sich ein bereits vorhandenes freies Projekt, verbessert es und gibt den Code an das Projekt zurück und alle profitieren davon.
Einzelne Kommentare unter dem Heise-Artikel hauen in dieselbe Kerbe: Aktion Mensch verhindert mit dieser Lizenz, dass sich der Player weiter verbreitet, als er könnte:
a) Anstatt einen Anwalt zu beschäftigen, sich eine Lizenz zu überlegen, die die Nutzer der Software benachteiligt, hätten sie einfach bei der MIT-Lizenz bleiben sollen, weil sie bereits juristisch geprüft ist.
b) Dadurch wäre es möglich gewesen, den Quellcode der Erweiterung an das ursprüngliche Projekt zurückfließen zu lassen. Die Erweiterungen wäre dadurch in der Zukunft weiter entwickelt und einer größeren Nutzerbasis bekannt gemacht worden.
c) Keine Noncommercial-Klauseln, weil sie immer schädlich und aus gutem Grund explizit inkompatibel zu Open Source und Freier Software sind. Für einen barrierefreien Player gibt es erst recht keinen Grund, Menschen von der Nutzung auszuschließen.
Immerhin hat Aktion Mensch in den Kommentaren auf die Kritik reagiert und sie wollen die Lizenz ihres Players prüfen.
Wenn die Lizenz der Erweiterung für den Player frei wäre, fände ich es super, wenn die Videos auf den Seiten der FSFE zukünftig auch barrierefrei wären. Kann man Aktion Mensch bei diesem Vorhaben irgendwie unterstützen? Was meint ihr?
Viele Grüße Christian
On Tue, 19 Dec 2017, Christian Imhorst wrote:
bei Heise habe ich heute gelesen, dass Aktion Mensch einen barrierefreien Videoplayer "entwickelt" hat [0][1].
Bei mir hängen keine Verweise zu [0] und [1] an. :-(
Würde mich doch mal interessieren, was eine Filmwiedergabe barrierefrei macht.
Nabend,
On Tue, Dec 19, 2017 at 07:11:53PM +0100, Henning Thielemann wrote:
On Tue, 19 Dec 2017, Christian Imhorst wrote:
bei Heise habe ich heute gelesen, dass Aktion Mensch einen barrierefreien Videoplayer "entwickelt" hat [0][1].
Bei mir hängen keine Verweise zu [0] und [1] an. :-(
Würde mich doch mal interessieren, was eine Filmwiedergabe barrierefrei macht.
ich tippe auf:
https://www.heise.de/ix/meldung/Aktion-Mensch-praesentiert-barrierefreien-Vi... https://www.aktion-mensch.de/barrierefreier-videoplayer
Am 19. Dezember 2017 um 19:11 schrieb Henning Thielemann < lemming@henning-thielemann.de>:
Bei mir hängen keine Verweise zu [0] und [1] an. :-(
Würde mich doch mal interessieren, was eine Filmwiedergabe barrierefrei macht.
Ups, sorry. Vergessen:
[0] https://www.heise.de/ix/meldung/Aktion-Mensch-praesentiert-barrierefreien-Vi... [1] https://www.aktion-mensch.de/barrierefreier-videoplayer
Barrierefrei d.h. Untertiteln bzw. Audiodeskription oder mit jemanden, der das Gesprochene in Gebärdensprache zeigt.
Hallo Christian,
# Christian Imhorst [2017-12-19 18:28 +0100]:
Wenn die Lizenz der Erweiterung für den Player frei wäre, fände ich es super, wenn die Videos auf den Seiten der FSFE zukünftig auch barrierefrei wären. Kann man Aktion Mensch bei diesem Vorhaben irgendwie unterstützen? Was meint ihr?
Ich spreche jetzt mal als Verantwortlicher für die PMPC-Seite, die Du ja angesprochen hast. Wir setzen bewusst auf weit verbreitete Standards, in diesem Fall ein HTML5 Video. Dieses ist in den meisten Browsern ohne ein Plugin oder Javascript (welches oft Barrierefreiheit behindert) abspielbar, und es unterstützt nativ Untertitel in verschiedenen Sprachen, die wir bei zahlreichen Videos verwenden.
Ich fände es toll, das Video noch mehr Menschen verfügbar zu machen. Allerdings sehe ich spontan bei dem vorgeschlagenen Player ein paar offene Fragen:
* Läuft alles auch ohne Javascript? Der Player verlangt anscheinend aktiviertes Javascript und zusätzlich die jQuery-Bibliothek. Das haben wir zwar auf einigen Webseiten auch eingebunden (mit Zähneknirschen), aber die Grundfunktionalität sollte auch immer ohne JS gegeben sein. * Werden mehrere Untertitel unterstützt? Toll beim HTML5-Video-Tag finde ich, dass man mehrere Untertitel einbinden kann. Im Beispiel des Players (demo.html), das man herunterladen kann, sieht es zumindest so aus. * Wie kann ich verschiedene Sprachversionen unterstützen? Bei der aktuellen Seite können wir je nach Spracheinstellung der Besucher ein unterschiedliches Video einbinden [1]. Binde ich den vorgestellten Player ebenfalls einfach per HTML-Snippet ein (bei dem ich ja ggf. den Videolink modifizieren kann), oder liegt das in irgendeiner Datei, die dynamisch geladen wird?
Ein weiterer Punkt ist natürlich der Aufwand. Schon jetzt sind professionell gestaltete Videos ein hoher Kostenaufwand, die Untertitel zeitaufwändig für unsere ehrenamtlichen Übersetzer. Zusätzlich bräuchten wir ein Video für Gebärdensprache (und gibt es da nicht auch verschiedene Sprachen?) sowie eine Tonspur mit Audiodeskription.
Falls da jemand Zeit hat, mal ein Beispiel für die Publiccode-Seite zu erstellen, würde ich mir das sehr gerne anschauen.
Viele Grüße Max
[1] https://git.fsfe.org/pmpc/website/src/branch/master/site/layouts/partials/fu...
Hallo Max,
vielen Dank für dein ausführliches Feedback.
Am 20. Dezember 2017 um 08:37 schrieb Max Mehl max.mehl@fsfe.org:
Wir setzen bewusst auf weit verbreitete Standards, in diesem Fall ein HTML5 Video. Dieses ist in den meisten Browsern ohne ein Plugin oder Javascript (welches oft Barrierefreiheit behindert) abspielbar, und es unterstützt nativ Untertitel in verschiedenen Sprachen, die wir bei zahlreichen Videos verwenden.
Guter Hinweis, aber da hätte ich jetzt gedacht, dass Aktion Mensch das Problem bekannt sein müsste und sie deswegen auf JavaScript verzichten. Tun sie aber nicht. Auf ihrer Website "Wie Blinde das Internet erkunden" wird JavaScript als Bremse nicht erwähnt, nur Flash.
Ich bin da aber leider zu wenig Experte, um das einschätzen zu können, würde aber auch sagen, dass HTML5 in diesem Sinn besser ist als JavaScript.
- Läuft alles auch ohne Javascript? Der Player verlangt anscheinend
aktiviertes Javascript und zusätzlich die jQuery-Bibliothek. Das haben wir zwar auf einigen Webseiten auch eingebunden (mit Zähneknirschen), aber die Grundfunktionalität sollte auch immer ohne JS gegeben sein.
Da Basis "mediaelement.js" denke ich nicht, dass es funktioniert. Wie ich das sehe, wird JavaScript für die Steuerung benötigt und für das Flash bzw. Silverlightfallback für ältere Browser, die kein HTML5 unterstützen.
- Werden mehrere Untertitel unterstützt? Toll beim HTML5-Video-Tag finde
ich, dass man mehrere Untertitel einbinden kann. Im Beispiel des Players (demo.html), das man herunterladen kann, sieht es zumindest so aus.
Ja das geht.
- Wie kann ich verschiedene Sprachversionen unterstützen? Bei der
aktuellen Seite können wir je nach Spracheinstellung der Besucher ein unterschiedliches Video einbinden [1]. Binde ich den vorgestellten Player ebenfalls einfach per HTML-Snippet ein (bei dem ich ja ggf. den Videolink modifizieren kann), oder liegt das in irgendeiner Datei, die dynamisch geladen wird?
Könnte man sich anschauen, wenn nicht das eigentliche K.O.-Kriterium käme, nämlich:
Ein weiterer Punkt ist natürlich der Aufwand. Schon jetzt sind professionell gestaltete Videos ein hoher Kostenaufwand, die Untertitel zeitaufwändig für unsere ehrenamtlichen Übersetzer. Zusätzlich bräuchten wir ein Video für Gebärdensprache (und gibt es da nicht auch verschiedene Sprachen?) sowie eine Tonspur mit Audiodeskription.
Man merkt dem PMPC-Video an, dass es mit einem sehr hohen Aufwand erstellt wurde. Ich kann mir gut vorstellen, dass es sehr schwierig ist, da noch einen drauf zu satteln.
Viele Grüße Christian
Hallo Christian,
On Mittwoch, 20. Dezember 2017 15:34:58 CET Christian Imhorst wrote:
Am 20. Dezember 2017 um 08:37 schrieb Max Mehl max.mehl@fsfe.org:
Wir setzen bewusst auf weit verbreitete Standards, in diesem Fall ein HTML5 Video. Dieses ist in den meisten Browsern ohne ein Plugin oder Javascript (welches oft Barrierefreiheit behindert) abspielbar, und es unterstützt nativ Untertitel in verschiedenen Sprachen, die wir bei zahlreichen Videos verwenden.
Guter Hinweis, aber da hätte ich jetzt gedacht, dass Aktion Mensch das Problem bekannt sein müsste und sie deswegen auf JavaScript verzichten. Tun sie aber nicht. Auf ihrer Website "Wie Blinde das Internet erkunden" wird JavaScript als Bremse nicht erwähnt, nur Flash.
Ich habe zwar nur sehr beschränktes Wissen zum Thema Barrierefreiheit, aber was ich bisher aus einschlägigen Vorträgen gehört habe war: Javascript ist (grundsätzlich) kein Problem, solange einige Regel beachtet werden.
Liebe Grüße, Johannes
On Wed, Dec 20, 2017 at 07:23:17PM +0100, Johannes Zarl-Zierl wrote:
Ich habe zwar nur sehr beschränktes Wissen zum Thema Barrierefreiheit, aber was ich bisher aus einschlägigen Vorträgen gehört habe war: Javascript ist (grundsätzlich) kein Problem, solange einige Regel beachtet werden.
Ich denke, Seiteninhalte hinter die Ausführung von JavaScript zu stellen nötigt den Benutzer dazu Code auszufuhren, über dessen Tun und Inhalt er effektiv keine Kontrolle hat. Das ist meiner Meinung nach inkompatibel mit den vier Freiheiten. Allein eine Free Software Lizenz ändert daran nichts, denn der Benutzer hat ja dann immer noch keine Kontrolle über das Script, das ihm die Seite da aufdrängt. Deswegen bin ich persönlich immer gegen den Einbau von JavaScript auf FSFE-Seiten. Einen offiziellen Konsens haben wir da leider im Moment nicht.
On Mittwoch, 20. Dezember 2017 23:40:57 CET Paul Hänsch wrote:
Ich denke, Seiteninhalte hinter die Ausführung von JavaScript zu stellen nötigt den Benutzer dazu Code auszufuhren, über dessen Tun und Inhalt er effektiv keine Kontrolle hat.
Diese Thematik sehe ich orthogonal zum Thema, ob JavaScript Barrierefreiheit unterstützt oder verhindert.
Das ist meiner Meinung nach inkompatibel mit den vier Freiheiten. Allein eine Free Software Lizenz ändert daran nichts, denn der Benutzer hat ja dann immer noch keine Kontrolle über das Script, das ihm die Seite da aufdrängt. Deswegen bin ich persönlich immer gegen den Einbau von JavaScript auf FSFE-Seiten. Einen offiziellen Konsens haben wir da leider im Moment nicht.
Ich bin mir nicht sicher, ob ich mir deinen Standpunkt in dieser Sache gänzlich zu eigen machen will. Ich tendiere aber dazu, dir zuzustimmen...
Liebe Grüße, Johannes
On Wed, Dec 20, 2017 at 11:53:31PM +0100, Johannes Zarl-Zierl wrote:
[...]
Diese Thematik sehe ich orthogonal zum Thema, ob JavaScript Barrierefreiheit unterstützt oder verhindert.
Das verstehe ich. Es ist nicht ganz das selbe. Lass mich nochmal versuchen zu deinem Punkt zurück zu finden.
On Wed, Dec 20, 2017 at 07:23:17PM +0100, Johannes Zarl-Zierl wrote:
Ich habe zwar nur sehr beschränktes Wissen zum Thema Barrierefreiheit, aber was ich bisher aus einschlägigen Vorträgen gehört habe war: Javascript ist (grundsätzlich) kein Problem, solange einige Regel beachtet werden.
Ich denke es kommt auf den Workflow an, den der jeweilige Benutzer gefunden hat.
Kann ein Benutzer z.B. eingeschränkt sehen, will er manchmal nur Text vergrößern, oder mit der Maus markieren können (zur Kontrasterhöhung oder Übertragung in ein TTS-System). Das Scripting darf dann nur nicht aktiv dazwischen funken.
Insbesondere Nutzer ohne Sicht können aber nach meinem Verständnis ein Braille-Terminal entspannter finden als einen Vorleseautomaten. Hier kommen häufig Browser zum einsatz, die einfach kein JavaScript implementieren, auch wenn das eher eine Überschneidung ist als eine zwingende technische Beschränkung. Hier ist es nötig, dass die Seite auch ganz ohne Scripting voll bedienbar bleibt, und dass vor allem der Textinhalt mit dem Dokument geladen wird (und nicht erst hinterher durch ein Script nachgeladen wird).
Hinzu kommt, dass es für den Entwickler sehr viel aufwändiger wird, Barrierefreie Workflows herzustellen und zu testen, sobald JavaScript ins Spiel kommt. Häufig fällt dann die Barrierefreiheit ganz oder teilweise unter den Tisch, weil z.B. umherspringende Elemente bei einigen Bedienweisen viel schwieriger zu beherrschen sind als bei anderen. Viele dieser Probleme kann man sich als Entwickler sparen, wenn man von vornherein auf JavaScript verzichtet.
Häufig können die gleichen Effekte, für die JavaScript eingebunden wird auch mit einem geschicktem Seitenlayout erreicht werden. Ist dies der Fall, besteht zwar optisch kein Unterschied den man spontan mit besserer oder schlechterer Bedienbarkeit assoziieren würde, der Browser kann jedoch unterstützende Techniken viel besser in dem Markup anwenden das er selbst kennt und implementiert als auf einer Funktionalität die von der Seite gescriptet wird.
Im Zwiefelsfall würde ich immer annehmen, das Browserseitiges Scripting zu Lasten der Barrierefreiheit ausfällt.
Am 21.12.2017 um 00:54 schrieb Paul Hänsch paul@fsfe.org:
On Wed, Dec 20, 2017 at 11:53:31PM +0100, Johannes Zarl-Zierl wrote:
[...]
Kann ein Benutzer z.B. eingeschränkt sehen, will er manchmal nur Text vergrößern, oder mit der Maus markieren können (zur Kontrasterhöhung oder Übertragung in ein TTS-System). Das Scripting darf dann nur nicht aktiv dazwischen funken.
Insbesondere Nutzer ohne Sicht können aber nach meinem Verständnis ein Braille-Terminal entspannter finden als einen Vorleseautomaten. Hier kommen häufig Browser zum einsatz, die einfach kein JavaScript implementieren, auch wenn das eher eine Überschneidung ist als eine zwingende technische Beschränkung. Hier ist es nötig, dass die Seite auch ganz ohne Scripting voll bedienbar bleibt, und dass vor allem der Textinhalt mit dem Dokument geladen wird (und nicht erst hinterher durch ein Script nachgeladen wird).
Hallo Paul,
bei blinden Benutzer ist es so, dass sie in der Regel eine Sprachausgabe benutzen, da die Informationsaufnahme über eine Sprachausgabe deutlich rascher vonstatten geht, als über eine Braillezeile. Hierzu werden spezielle Screenreader, wie VoiceOver, JAWS oder die freie Software NVDA benutzt. Als Browser kommen die normalen Browser in Einsatz, welche auch von sehenden Personen benutzt werden.
Bei der Barrierefreiheit für blinde benutzer kommt es nur darauf an, dass er alle Informationen in Textform zur Verfügung gestellt bekommt. Damit sind aber keine grafischen Screenshots mit Textinhalten gemeint.
Bei Sehbehinderten ist die Sache komplizierter, da hier Aspekte, wie die Farbgebung, Konstrastgebung und so weiter eine rolle spielen. Da sich die Auswirkungen einer Sehbehinderung sich individuell anders auswirken, ist es wichtig darauf zu achten, dass der Anwender die Schriftgröße oder die Farbgebung innerhalb der Website über seine Hilfssoftware, wie z. B. Zoomtext, frei wählen kann, um den für ihn am besten geeigneten Zustand zu erreichen.
Mit freundlichen Grüßen
Jochen Schmitt
Hallo zusammen,
Am Donnerstag, den 21.12.2017, 16:48 +0100 schrieb Jochen Schmitt:
Bei Sehbehinderten ist die Sache komplizierter, da hier Aspekte, wie die Farbgebung, Konstrastgebung und so weiter eine rolle spielen. Da sich die Auswirkungen einer Sehbehinderung sich individuell anders auswirken, ist es wichtig darauf zu achten, dass der Anwender die Schriftgröße oder die Farbgebung innerhalb der Website über seine Hilfssoftware, wie z. B. Zoomtext, frei wählen kann, um den für ihn am besten geeigneten Zustand zu erreichen.
Auch das dürfte bei Seiten ohne Javascript leichter zu erreichen sein.
Viele Grüße Michael
On Thu, Dec 21, 2017 at 04:48:50PM +0100, Jochen Schmitt wrote:
bei blinden Benutzer ist es so, dass sie in der Regel eine Sprachausgabe benutzen, da die Informationsaufnahme über eine Sprachausgabe deutlich rascher vonstatten geht, als über eine Braillezeile. Hierzu werden spezielle Screenreader, wie VoiceOver, JAWS oder die freie Software NVDA benutzt. Als Browser kommen die normalen Browser in Einsatz, welche auch von sehenden Personen benutzt werden.
Danke für die Beschreibung, meine Vorstellung hierzu war nur grob, und zudem veraltet.
Hast du Informationen dazu, was für Einschränkungen außerdem noch Hindernisse in der täglichen Arbei mit Webseiten darstellen können? Das erste woran wir denken sind immer Augenprobleme, wie stark fällt es aber im Allag ins gewicht, wenn ich z.B. - Maus, Tastatur oder Touchscreen jeweils nicht bequem nutzen kann? - nicht hören kann (Inhalte in Videos scheinen häufiger zu werden)? - Probleme mit Farbwechseln / Bewegtbildern habe, die in der Nähe der Inhalte auftauchen? - was für Probleme kann es noch geben?
Hat jemand Informationen dazu, wie hoch die Frustrate bei den jeweiligen Personengruppen derzeit ist? Kann jemand beschreiben wie man unter den jeweiligen Randbedingungen das Internet nutzt?
Am 23.12.2017 um 09:49 schrieb Paul Hänsch:
On Thu, Dec 21, 2017 at 04:48:50PM +0100, Jochen Schmitt wrote:
bei blinden Benutzer ist es so, dass sie in der Regel eine Sprachausgabe benutzen, da die Informationsaufnahme über eine Sprachausgabe deutlich rascher vonstatten geht, als über eine Braillezeile. Hierzu werden spezielle Screenreader, wie VoiceOver, JAWS oder die freie Software NVDA benutzt. Als Browser kommen die normalen Browser in Einsatz, welche auch von sehenden Personen benutzt werden.
Danke für die Beschreibung, meine Vorstellung hierzu war nur grob, und zudem veraltet.
Hast du Informationen dazu, was für Einschränkungen außerdem noch Hindernisse in der täglichen Arbei mit Webseiten darstellen können? Das erste woran wir denken sind immer Augenprobleme, wie stark fällt es aber im Allag ins gewicht, wenn ich z.B. - Maus, Tastatur oder Touchscreen jeweils nicht bequem nutzen kann? - nicht hören kann (Inhalte in Videos scheinen häufiger zu werden)? - Probleme mit Farbwechseln / Bewegtbildern habe, die in der Nähe der Inhalte auftauchen? - was für Probleme kann es noch geben?
Hat jemand Informationen dazu, wie hoch die Frustrate bei den jeweiligen Personengruppen derzeit ist? Kann jemand beschreiben wie man unter den jeweiligen Randbedingungen das Internet nutzt?
Nun, ich bin selbst (er)taub(t) und habe außerdem gerade ein Gutachten über die alltägliche Nutzung digitaler Technologie durch Menschen mit Behinderungen geschrieben. Dazu haben wir Nutzer*innen mit unterschiedlichen Behinderungen (Einschränkungen beim Sehen, beim Hören, bei der Beweglichkeit, beim Lernen) befragt. Wie leider immer, wenn es (in Deutschland) um Behinderung/Barrieren/Barrierefreiheit geht stellt die Lage sich kompliziert dar (was ich persönlich unglaublich frustrierend finden).
Ein paar Ergebnisse (mehr sehr gerne, aber nur auf Nachfrage, ich will nicht durch Textwüsten nerven):
- Den größten Frust in Bezug auf Webseiten und entsprechende Apps schieben derzeit Sehbehinderte und Blinde: Viele Webseiten sind so komplex, dass sie selbst wenn ein Screenreader sie (technisch) erfassen kann, kaum lesbar (heißt in diesem Fall: per Hören verstehbar) und navigierbar sind. Gut gemeinte Vorlesefunktionen auf den Seiten selbst kollidieren mit dem Screenreader, Captchas sind nicht erfassbar, Editoren nicht oder nur schlecht bedienbar usw.
- Für Hörgeschädigte kommt es sehr darauf an, wie gut sie der Schriftsprache mächtig sind: Wer Deutsch und/oder Englisch gut lesen und verstehen kann, kommt halbwegs klar. Die Tonqualität vieler Videos ist allerdings grauslich, automatisch erzeugte Untertitel sind oftmals lustig, aber nicht verständlich (Englisch funktioniert besser als Deutsch, aber auch längst nicht einwandfrei). Wer allerdings nur oder hauptsächlich Gebärdensprache kann, ist völlig aufgeschmissen. Denn selbst dort, wo es Videos in Gebärdensprache gibt, enthalten diese oft wenig bis keine Inhalte (die Produktion ist aufwändig). Stattdessen wird häufig nur die Navigation der Website erklärt (die in der Regel aber offensichtlich ist).
- Bei Menschen mit motorischen Einschränkungen geht es in der Regel mehr um die Frage der Eingabegeräte bzw. der generellen Kompatibilität von Browser, BS und diesen Geräten (auch keine Selbstverständlichkeit, insbesondere bei Spielen).
- Menschen mit Lernschwierigkeiten kämpfen oftmals sowohl mit Schriftsprache als auch mit zu komplexen Seiten. Bei ihnen ist das Frustpotential auch sehr groß, allerdings gibt es in dieser Gruppe bisher nur einen wohl relativ kleinen Teil der überhaupt Internetzugang hat.
Die zunehmende Appifizierung macht die Lage technisch noch komplizierter. Eine generelle Einschätzung ist hier aber schwierig.
Allerdings gibt es auch hilfreiche Dinge:
- Die Einhaltung der W3C Accessibility Guidelines 2.0 [1] befördert die Zugänglichkeit von Webseiten enorm.
- Aktion Mensch hat eine ganze Reihe von Hilfen für ein barrierefreies Internet zusammengestellt [2], darunter z.B. die deutsche Übersetzung der W3C Guidelines. Vieles scheint nicht völlig auf der Höhe der Zeit zu sein und manches auch kritikwürdig (so fing dieser Thread ja an), aber es gibt diese Hilfen. Ähnlich auch die vom BMAS geförderte Seite: "Barrierefrei informieren und kommunizieren – für alle" [3].
- Der DBSV informiert [4] u.a. über "Inklusives Kommunikationsdesign" [5].
- usw.
Was bei den Befragungen aber auch klar wurde: Es fehlt zum einen an einem allgemeinen Bewusstsein, bei Entwickler*innen und Designer*innen (und auch Auftraggeber*innen) im weitesten Sinne, dass so es etwas wie "Barrierefreiheit" oder auch "Design für alle" überhaupt gibt/geben sollte und warum. Zum anderen ist es - in der Praxis - häufig schwierig, geeignete Nutzer*innen/Tester*innen (= Menschen mit Behinderungen) zu finden.
Soweit erst einmal. Wie gesagt: Bei Interesse gerne mehr!
Schöne Feiertage! Irmhild
[1] https://www.w3.org/WAI/intro/wcag [2] https://www.einfach-fuer-alle.de/ [3] http://bik-fuer-alle.de/barrierefreiheit-umsetzen.html [4] https://www.dbsv.org/broschueren.html#barrierefreiheit [5] https://www.dbsv.org/broschueren.html?file=files/ueber-dbsv/publikationen/br...
Hallo zusammen,
ich habe zu der Diskussion noch zwei Anmerkungen:
1.) Am 23. Dezember 2017 um 11:41 schrieb Irmhild Rogalla < irmhild.rogalla@institut-pi.de>:
Soweit erst einmal. Wie gesagt: Bei Interesse gerne mehr!
Vielen Dank, die Beschreibung der Frustrate hat mich beeindruckt. Ich habe mir daraufhin auch deinen Vortrag "Warum nimmst du nicht einfach Skype" [0] und "ADRIANE - Desktop für blinde Computeranwender" [1] von Klaus Knopper vom CLT 2017 angeschaut. Es ist schon cool, wie Klaus Knopper bereits vorhandene Freie und Open Software nimmt, um daraus etwas neues, einen Desktop für Blinde, zu schaffen. Bei beiden Vorträgen sind mir viele Punkte bewusst geworden, über die man normalerweise, wenn man keine Einschränkungen hat, nicht so nachdenkt.
Ich hätte auf jeden Fall Interesse, da ich die Frage, wie wir AnwenderInnen mit Einschränkungen befähigen können, ihre Technologie selber kontrollieren zu können, wichtig finde. Gerade wenn es um die von dir angesprochene "Appifizierung" mit Smartphones geht. Dadurch werden ganze Benutzergruppen von bestimmten Technologien ausgeschlossen.
[0] https://chemnitzer.linux-tage.de/2017/de/programm/beitrag/264 [1] https://chemnitzer.linux-tage.de/2017/en/programm/beitrag/214
2.) Am 20.12.2017 schrieb Paul Hänsch:
Ich denke, Seiteninhalte hinter die Ausführung von JavaScript zu stellen
nötigt den Benutzer dazu Code auszufuhren, über dessen Tun und Inhalt er
effektiv keine Kontrolle hat.
Das ist jetzt vielleicht eher eine philosophische, als eine technische Frage, aber nötigt nicht jedes Programm AnwenderInnen dazu, Code auszuführen, über dessen Tun und Inhalt sie effektiv keine Kontrolle haben. Bei Freier Software ist der Quellcode einsehbar, so wie bei JavaScript im Prinzip auch, aber wer schaut sich den Quellcode der Software oder der Webseite vorher an, um zu gucken, was genau bei Ausführung des Codes passiert? Als einfacher Anwender möchte ich ja, dass die Webseite oder das Programm funktionieren und ich alle ihre Funktionen nutzen kann.
Das fiel mir irgendwie dazu ein, vielleicht bin ich da aber auch auf dem Holzweg.
Viele Grüße Christian
Am 01.01.2018 um 17:03 schrieb Christian Imhorst christian.imhorst@gmail.com:
"ADRIANE - Desktop für blinde Computeranwender" [1] von Klaus Knopper vom CLT 2017
Hallo Christian,
bezüglich des Vortrags von Herrn Knopper muss ich doch einige kritische Kommentare loswerden:
Das Hauptproblem von Adriane ist nach meiner Meinung die Tatsache, dass es sich um eine sonderlösung für blinde und sehbehinderte Anwender handelt.
Das Hauptziel sollte ein System sein, dass von allen Benutzern ohne spezielle Zusatzsoftware eingerichtet und benutzt werden kann.
Laut einer inoffiziellen Statistik haben gerade mal 30% der blinden oder sehbeihinderten Erwerbstätigen eine Arbeit auf dem ersten Arbeitsmarkt. Für eine Integration dieser Benutzergruppe wäre es hilfreich, wenn IT-Systeme ohne teuere Zusatzsoftware oder Anpassungen von diesen benutzt werden könnten.
Wie solche IT-Systeme aussehen könnten, zeigt die Firma Apple. Dort kann man die Geräte eigenständig ohne sehende Hilfe Einrichten und mit ihnen arbeiten. Dies gilt sowohl für das iPhone, dem iPad oder den Mac Computern, da allle Betriebsysteme dieser Firma standfardmäßig mit dem Screenreader VoiceOver ausgeliefert werden. Adriane hingegen ist eine Sonderlösung, die vielleicht im privaten Umfeld Bestand hat, aber im kommerziellen Bereicht Probleme verursacht, da zumindestens in Großbetrieben standardisierte Basissysteme im Einsatz sind, die im Notfall ohne großen Schwierigkeiten wiederhergestellt werden können.
wenn es um die von dir angesprochene "Appifizierung" mit Smartphones geht. Dadurch werden ganze Benutzergruppen von bestimmten Technologien ausgeschlossen. Gerade beim Smartphone muss ich Dir heftig widersprechen. Für Blinde war die WWDC 2009 ein wichtiger Wendepunkt, da Apple auf dieser Veranstalltung die Integration von VoiceOver in iOS verkündetet. Wenn Du einen blinden Mitbürger fragst, was für ein Smartphone er benutzt, ist die'' Wahrscheinlichkeit recht groß, dass es ein iPhone ist. Auf einem Blog hat ein blinder Benutzer ein Samsung Galaxy S8 getestet, welches er von seinem Netzbetreiber zur Verfügung gestellt bekam. Das Fazit war, dass Android bis heute nicht mit iOS mithalten kann, was die Barrierefreiheit betrifft.
Es wird die Ansicht vertreten, dass das iPhone die größte Innovation im Bereicht Hilfsmittel in den letzten zehn Jahren für Blinde Nutzer war.
Mit freundlichen Grüßen
Jochen Schmitt
Am 01.01.2018 um 18:40 schrieb Jochen Schmitt:
Am 01.01.2018 um 17:03 schrieb Christian Imhorst christian.imhorst@gmail.com:
Das Hauptziel sollte ein System sein, dass von allen Benutzern ohne spezielle Zusatzsoftware eingerichtet und benutzt werden kann.
In einem "normalen" Debian-System gibt es orca bzw. gnome-orca als Screen-Reader. Und eine Bildschirmlupe gibt es beispielsweise in neueren Versionen von XFCE4. Im Prinzip ist vieles, was Adriane ausmacht, bei Debian mit "on board", was wohl durchaus auch im Sinne von Klaus Knopper ist.
Hierbei dürfte für die Zielgruppe auch von Vorteil sein, dass zu einem GNU/Linux-System viele nicht-grafische Tools einfach dazugehören.
Das es Leute gibt, für die ein GNU-Betriebssystem nicht "normal" ist, ist leider bedauerlich, aber wir arbeiten ja daran, dass sich das schnellstmöglichst ändert.
Wie solche IT-Systeme aussehen könnten, zeigt die Firma Apple. Dort kann man die Geräte eigenständig ohne sehende Hilfe Einrichten und mit ihnen arbeiten. Dies gilt sowohl für das iPhone, dem iPad oder den Mac Computern, da allle Betriebsysteme dieser Firma standfardmäßig mit dem Screenreader VoiceOver ausgeliefert werden. Adriane hingegen ist eine Sonderlösung, die vielleicht im privaten Umfeld Bestand hat, aber im kommerziellen Bereicht Probleme verursacht, da zumindestens in Großbetrieben standardisierte Basissysteme im Einsatz sind, die im Notfall ohne großen Schwierigkeiten wiederhergestellt werden können.
Apple ist im "normalen" Windows-Umfeld auch eine "Sonderlösung".
Gruß Michael
Hallo Jochen,
ich denke, dass es bei ADRIANE darum geht, Freie und Open Source, also besonders GNU/Linux für Blinde erfahrbar zu machen.
Am 1. Januar 2018 um 18:40 schrieb Jochen Schmitt jochen@herr-schmitt.de:
Das Hauptproblem von Adriane ist nach meiner Meinung die Tatsache, dass es sich um eine sonderlösung für blinde und sehbehinderte Anwender handelt. Das Hauptziel sollte ein System sein, dass von allen Benutzern ohne spezielle Zusatzsoftware eingerichtet und benutzt werden kann.
Beim Hauptziel gebe ich dir recht, und es wäre schön, wenn es eine Distribution gäbe, die GNU/Linux mit einem XFCE oder auch Gnome ausliefert, das von allen Benutzern eingerichtet und benutzt werden kann. Daher sehe ich das Hauptproblem nicht bei ADRIANE, sondern dass es mit GNU/Linux einfach viel zu wenig in dieser Hinsicht gibt.
Wie solche IT-Systeme aussehen könnten, zeigt die Firma Apple. Dort kann man die Geräte eigenständig ohne sehende Hilfe Einrichten und mit ihnen arbeiten. Dies gilt sowohl für das iPhone, dem iPad oder den Mac Computern, da allle Betriebsysteme dieser Firma standfardmäßig mit dem Screenreader VoiceOver ausgeliefert werden.
Ich kenne Apple zu wenig, aber schön, dass sie das so machen. Wie gesagt, sehe ich das Problem eher darin, dass GNU/Linux hier zu wenig bietet. Es ist traurig, dass die Eule der Minerva Freier Software ihren Flug viel zu oft in der Dämmerung beginnt: Soll heißen, dass Freie Software vor allem bei Anwendersoftware häufig zu proprietären und unfreien Systemen erstmal aufschließen muss und damit zu oft in diesem Bereich hinterher hinkt.
Adriane hingegen ist eine Sonderlösung, die vielleicht im privaten Umfeld Bestand hat, aber im kommerziellen Bereicht Probleme verursacht, da zumindestens in Großbetrieben standardisierte Basissysteme im Einsatz sind, die im Notfall ohne großen Schwierigkeiten wiederhergestellt werden können.
ADRIANE ist als Sonderlösung gewollt. In Großbetrieben hat es vermutlich eh keine Chance, da deren Basissystem in der Regel Windows-Clients sind.
Das Fazit war, dass Android bis heute nicht mit iOS mithalten kann, was die
Barrierefreiheit betrifft. Es wird die Ansicht vertreten, dass das iPhone die größte Innovation im Bereicht Hilfsmittel in den letzten zehn Jahren für Blinde Nutzer war.
Das kann ich leider nicht beurteilen, glaube ich dir aber. Aus meiner Sicht ist das dann ein richtig fieser Vendor-Lock-In, wenn man gar keine mehr Chance hat, auf ein anderes System zu wechseln, weil andere Systeme für einen unbenutzbar sind. Dann ist ein Ansatz wie ADRIANE doch super, damit man überhaupt erfahren kann, dass es auch Alternativen wie GNU/Linux gibt, und dass man sie benutzen kann.
Viele Grüße Christian
Am 01.01.2018 um 20:30 schrieb Christian Imhorst christian.imhorst@gmail.com:
richtig fieser Vendor-Lock-In, wenn man gar keine mehr Chance hat, auf ein anderes System zu wechseln, weil andere Systeme für einen unbenutzbar sind. Dann ist ein
Hallo Christian,
das Problem ist nicht, dass Android völlig unbenutzbar wäre. Wenn man aber Android mit iOS vergleicht, muss man feststellen, dass iOS zur Zeit noch die Nase vorne hat. Es gibt zwar bei Android auch Fortschritte bei der Barrierefreiheit. Bei Android gibt es auf der anderen Seite die Update-Problematik bei den Smartphones. Dies ist nicht nur ein Problem bei den klassischen Anbietern. Selbst beim Fairphone, die bekanntlich großen Wert auf nachhaltigkeit legen, gibt es massive Probleme bezüglich des Upgrades auf die nächste Android-Version. Ein Fairphone, welches mit Android 7 ausgeliefert wird, wird man vielleicht noch auf die Version 8 bekommen. Ein weiteres Upgrade auf Version 9 kann man aber leider vergessen. Dies ist eine ganz andere Situation im Gegensatz zu Apple, wo man in der Regel mit einem Support-Zyklus von rund vier Jahren rechnen kann.
Mit freundlichen Grüßen
Jochen Schmitt
Hallo Christian, hi @ll,
Am 01.01.2018 um 17:03 schrieb Christian Imhorst:
Hallo zusammen,
ich habe zu der Diskussion noch zwei Anmerkungen:
1.) Am 23. Dezember 2017 um 11:41 schrieb Irmhild Rogalla <irmhild.rogalla@institut-pi.de mailto:irmhild.rogalla@institut-pi.de>:
Soweit erst einmal. Wie gesagt: Bei Interesse gerne mehr!
Vielen Dank, die Beschreibung der Frustrate hat mich beeindruckt. Ich habe mir daraufhin auch deinen Vortrag "Warum nimmst du nicht einfach Skype" [0]
Was meine Videokonferenz-Lösung angeht bin ich mittlerweile noch 'schlauer' und habe gewechselt, zu einer extern gehosteten und administrierten Nextcloud One-Instanz, soweit notwendig in Kombi mit per Handy hergestellten TelCos. Das funktioniert deutlich stabiler und passt besser zu meinen Bedürfnissen, auch wenn bei der Nextcloud noch Entwicklungsbedarf ist
...
Ich hätte auf jeden Fall Interesse, da ich die Frage, wie wir AnwenderInnen mit Einschränkungen befähigen können, ihre Technologie selber kontrollieren zu können, wichtig finde. Gerade wenn es um die von dir angesprochene "Appifizierung" mit Smartphones geht. Dadurch werden ganze Benutzergruppen von bestimmten Technologien ausgeschlossen.
Ja, ich fände es auch gut, wenn es dazu mehr Aktivität gäbe. Wie können wir da vorgehen?
Viele Grüße Irmhild
Hallo zusammen, hallo Irmhild,
Am 2. Januar 2018 um 10:27 schrieb Irmhild Rogalla < irmhild.rogalla@institut-pi.de>:
Ja, ich fände es auch gut, wenn es dazu mehr Aktivität gäbe. Wie können wir da vorgehen?
Auf jeden Fall können wir mehr Bewusstsein dafür schaffen, dass für viele Menschen viele Sachen beim Umgang mit Technologie nicht selbstverständlich sind und darauf achten, Barrieren abzubauen. Wir sollten darauf achten, dass wir alle Menschen im selbstbestimmten Umgang mit Technik unterstützen, und dass diese Technologie uns hilft, statt uns einzuschränken.
Ich bin mir unsicher, inwieweit das mit Freier Software allein funktioniert und/oder inwieweit man dazu auch Freie Hardware benötigt. Das Beispiel mit Apple scheint ja vor allem deswegen gut zu funktionieren, weil Software und Hardware eng zusammen arbeiten. Bei ADRIANE fand ich gut, dass sie versuchen, mit vorhandener Open Source Software und handelsüblicher Hardware (außer die Braille-Zeile) Barrieren abzubauen. Bei jeder handelsüblichen Tastatur sind die Tasten F und J markiert, worauf man aufbauen kann. Auf der Webseite Raspberry VI [0] werden Ideen und Erfahrungen gesammelt, wie man den Raspi und andere Boards für sehbehinderten oder blinden Menschen barrierefrei zugänglich machen kann. Vielleicht sind das ja schon gute Voraussetzungen, für Freie Software und Freie Hardware ohne Barrieren.
Barrierefreie Hardware, die von allen Menschen gut zu bedienen ist, ist vermutlich eine Herausforderung. Ich kann mir auch vorstellen, dass das iPad oder iPhone für Sehbehinderte, die mit VoiceOver nicht zurechtkommen, nur schwer nutzbar ist, weil viele Bedienelemente nicht kontrastreich genug sind. Vielleicht können Wearables und "intelligente/smarte" Geräte zukünftig gut unterstützen, wenn Kleider, die sich selbst beschreiben können, ihre Farbe mitteilen, bevor man sie anzieht, oder das Weißwäscheprogramm der Waschmaschinen Farbwäsche automatisch erkennt.
Augmented Reality könnte auch eine interessante Grundlagen für Projekte sein, wenn sie dabei unterstützt, Schriftzüge vorzulesen, oder wenn sie Ampelfarben oder andere Menschen erkennt. Ein Smartphone könnte dafür eine gute Basis darstellen. In der LUG Hannover haben wir beim vergangenen Treffen überlegt, inwieweit man Trainingsdaten für Freie (und Offline) Spracherkennungssoftware und Stimmensynthese nutzen könnte, indem man Daten von Gutenberg [1] oder Librivox [2] als Trainingsdaten benutzt. Immerhin liegen diese Texte einmal als Buch in Schriftsprache und in einer natürlichen Sprache als vorgelesenes Hörbuch vor, was eine gute Matrix abgeben könnte. Eventuell kann man hier noch weiter ansetzen.
Viele Grüße Christian
[0] http://www.raspberryvi.org/stories/index.html [1] https://www.gutenberg.org/wiki/DE_Hauptseite [2] https://librivox.org/
On Sat, 23 Dec 2017, Paul Hänsch wrote:
Hast du Informationen dazu, was für Einschränkungen außerdem noch Hindernisse in der täglichen Arbei mit Webseiten darstellen können? Das erste woran wir denken sind immer Augenprobleme, wie stark fällt es aber im Allag ins gewicht, wenn ich z.B.
- Maus, Tastatur oder Touchscreen jeweils nicht bequem nutzen kann?
- nicht hören kann (Inhalte in Videos scheinen häufiger zu werden)?
- Probleme mit Farbwechseln / Bewegtbildern habe, die in der Nähe der Inhalte auftauchen?
- was für Probleme kann es noch geben?
Es gibt auch einige Leute mit Farbenblindheit. Wenn ein Designer so clever ist, mit den Farben rot und grün Informationen transportieren zu wollen, dann geht das da schief.
Im Alter lässt natürlich auch die Sehschärfe nach. Wenn dann Text in Grafiken versteckt ist, oder das normale Groß- und Kleiner-Stellen der Schrift mit JavaScript blockiert oder durch einen webseiten-eigenen Einsteller ersetzt wird ...
On 12/21/2017 04:48 PM, Jochen Schmitt wrote:
bei blinden Benutzer ist es so, dass sie in der Regel eine Sprachausgabe benutzen, da die Informationsaufnahme über eine Sprachausgabe deutlich rascher vonstatten geht, als über eine Braillezeile. Hierzu werden spezielle Screenreader, wie VoiceOver, JAWS oder die freie Software NVDA benutzt. Als Browser kommen die normalen Browser in Einsatz, welche auch von sehenden Personen benutzt werden.
Hallo Jochen,
ich betreue in meiner Familie eine Webseite und da besteht durchaus das leise Interesse, dass diese Seite - sofern mit wenig Aufwand möglich - auch für Menschen mit körperlichen Einschränkungen genutzt werden kann.
Nun bin ich etwas überrascht, das die von dir genannte freie Software NVDA in der neusten Version nur für Windows 7 SP1 verfügbar ist. Ältere Versionen von Windows können nur noch die 2017.3 Version verwenden. Ein Hinweis auf andere Betriebssysteme (Mac OS oder Linux) fehlen leider völlig.
Das Programm NVDA ist in Python geschrieben, setzt aber bei einem ersten versuch dies zu bauen python2 und _winreg voraus. Dieses Modul wurde mit Python3 zu winreg umbenannt...
Hab ich noch etwas übersehen, oder ist die Software tatsächlich nur für MS Windows verfügbar?
Viele Grüße Thomas
Am 25.12.2017 um 13:15 schrieb Thomas Doczkal:
Das Programm NVDA ist in Python geschrieben, setzt aber bei einem ersten versuch dies zu bauen python2 und _winreg voraus. Dieses Modul wurde mit Python3 zu winreg umbenannt...
Hab ich noch etwas übersehen, oder ist die Software tatsächlich nur für MS Windows verfügbar?
Man müsste einmal schauen, was winreg oder _winreg macht.
Ich denke aber einmal, dass diese Software ziemlich mit Windows "verheiratet" ist [0].
Für Freie Betriebssysteme hat sich Klaus Knopper in's Zeug gelegt [1].
Gruß Michael
[0] nach Lektüre: https://de.wikipedia.org/wiki/NonVisual_Desktop_Access [1] https://de.wikipedia.org/wiki/ADRIANE
Am 25.12.2017 um 13:16 schrieb Thomas Doczkal mailinglist@doczkal.de:
Nun bin ich etwas überrascht, das die von dir genannte freie Software NVDA in der neusten Version nur für Windows 7 SP1 verfügbar ist. Ältere Versionen von Windows können nur noch die 2017.3 Version verwenden. Ein Hinweis auf andere Betriebssysteme (Mac OS oder Linux) fehlen leider völlig.
Das Programm NVDA ist in Python geschrieben, setzt aber bei einem ersten versuch dies zu bauen python2 und _winreg voraus. Dieses Modul wurde mit Python3 zu winreg umbenannt...
Hab ich noch etwas übersehen, oder ist die Software tatsächlich nur für MS Windows verfügbar?
Hallo thomas,
NVDA ist wirklich nur für Windows erhältlich. Für Mac OS stellt sich das Problem überhaupt nicht, da Mac OS generell mit VoiceOver ausgeliefert wird. Auch wenn es bei VoiceOver noch Luft nach oben gibt, handelt es sich hierbei um einen vernümftigen Screenreader. Der größte Vortgeil ist, dass durch die Integration von VoiceOver in Mac OS es auch blinden Benutzer möglich ist, einen mac ohne fremde Hilfe aufzusetzen.
Bei Linux hat man meines Erachtens das typische Linux-Prlbem, dass es eine Vielfalt von Toolkits und so weiter gibt, was die Entwicklung eines Screenreaders nicht gerade vereinfacht. Wenn man Linux auf einem Server per ssh bedienen will, ist das kein Problem, aber auf dem Desktop treten die oben genannten Probleme recht negativ zu Tage, wenn man mit einer graphischen Benutzeroberfläche arbeiten will.
Mit freundlichen Grüßen
Jochen Schmitt
On 12/25/2017 01:54 PM, Jochen Schmitt wrote:
Bei Linux hat man meines Erachtens das typische Linux-Prlbem, dass es eine Vielfalt von Toolkits und so weiter gibt, was die Entwicklung eines Screenreaders nicht gerade vereinfacht. Wenn man Linux auf einem Server per ssh bedienen will, ist das kein Problem, aber auf dem Desktop treten die oben genannten Probleme recht negativ zu Tage, wenn man mit einer graphischen Benutzeroberfläche arbeiten will.
Mit anderen Worten es gibt für Linux keinen Screenreader, der halbwegs brauchbare Ergebnisse liefert? Gibt es nicht vom Gnome-Project einen Screenreader? Wie gut ist der bedienbar? Als nicht betroffener ist es für mich immer schwierig solche Bewertungen zu abzugeben, deshalb würde mich schon interessieren was die Personen, die die auf die Software angewiesen sind nutzen und wie die Bewertungen der Software aussieht.
Für mich ist es her unpraktisch die Webseite für solche Tools zu verbessern, wenn die Voraussetzung ein MS Windows oder Mac OS ist. Beider habe ich nicht als primäres System zur Verfügung.
Viele Grüße Thomas
Am 25.12.2017 um 14:24 schrieb Thomas Doczkal mailinglist@doczkal.de:
On 12/25/2017 bnisse liefert? Gibt es nicht vom Gnome-Project einen
Screenreader? Wie gut ist der bedienbar? Als nicht betroffener ist es für mich immer schwierig solche Bewertungen zu abzugeben, deshalb würde mich schon inter
Hallo thomas,
ja, mir ist schon bekannt, dass es vom GnOME-Projekt einen Screenreader gibt. Um meine Skipsis zu verstehen, sollte ich kurz erklären, was ein Screenreader macht.
Ein Screenreader liest nicht nur einfach den Text vor, der auf dem Bildschirm angezeigt wird. Vielmehr muss er den Benutzer darüber informieren, um welches UI-Element, wie z. B. ein Textfeld oder Schaltfläche es sich hierbei handelt. außerdem stellt der Screenreader Tastenkürzel bereit, mit dem der Benutzer mit den Bedienelementen der Benutzeroberfläche interagieren kann. Man sollte sich vergewissern, dass ein blinder Benutzer nicht in der Lage ist, eine Mouse zu bedienen. Stattdessen arbeitet er mit der Tastatur, wo er mit HIlfe entsprechender Tastenkürzel durch die graphische Benutzeroberfläche navigiert.
Bei Linux tritt nun das Problem auf, dass die Bedienelemente nicht vom X-Sefver oder Wayland generiert werden. Vielmehr werden die Bedienelemente von den Toolkits, wie GTK oder Qt verwaltet. Das ist für die Entwicklung eines Screenreaders ein erhebliches Hinternis, da er ja mehrere Toolkits unterstützen müsste.
Außerdem habe ich noch in einen anderen Punkt negative Erfahrungen mit der Barrierefreiheit bei Linux gemacht. Ich hatte vor mehreren Jahren ein MacBoot Pro 2013 gekauft, welches ein sogenanntes Retina-Display besitzt. Auf diesem Rechner habe ich neben Mac OS Fedora Linux installiert.
Unter KDE fiel mir negativ auf, dass die Schrift praktisch unlesbar war, da die Schriftgröße viel zu klein war. Bei GNOME-Anwendungen sah die Situation anders aus, dort hatten die Buchstaben eine vernünftige Größe. Dies galt selbstverständlich auch für Mac OS.
Mit freundlichen Grüßen
Jochen Schmitt
Hallo,
Am 20.12.2017 um 23:40 schrieb Paul Hänsch:
On Wed, Dec 20, 2017 at 07:23:17PM +0100, Johannes Zarl-Zierl wrote:
Ich habe zwar nur sehr beschränktes Wissen zum Thema Barrierefreiheit, aber was ich bisher aus einschlägigen Vorträgen gehört habe war: Javascript ist (grundsätzlich) kein Problem, solange einige Regel beachtet werden.
Ich denke, Seiteninhalte hinter die Ausführung von JavaScript zu stellen nötigt den Benutzer dazu Code auszufuhren, über dessen Tun und Inhalt er effektiv keine Kontrolle hat. Das ist meiner Meinung nach inkompatibel mit den vier Freiheiten. Allein eine Free Software Lizenz ändert daran nichts, denn der Benutzer hat ja dann immer noch keine Kontrolle über das Script, das ihm die Seite da aufdrängt. Deswegen bin ich persönlich immer gegen den Einbau von JavaScript auf FSFE-Seiten. Einen offiziellen Konsens haben wir da leider im Moment nicht.
Ich stelle gerne von mir entwickelte unter einer Freien Lizenz zur Verfügung und tue dies auch mit einem guten Gewissen..
Der Anwender muss sie dann herunterladen, installieren und schließlich starten.
Dies bedeutet, dass er sich sehr bewusst darüber ist, dass auf seinem Rechner fremde Software zur Ausführung kommt.
Diese drei Schritte fallen - zumindest als bewusste Handlungen - bei in WWW-Seiten eingebettetem JS weg, sofern der Nutzer sich nicht bewusst dafür entschieden hat, die Ausführung von JS per default zu verbieten und seinen Browser entsprechend konfiguriert hat.
D.h. In den allermeisten Fällen wird fremde Software automatisch auf dem Rechner des Nutzers ausgeführt, der sich dessen oftmals auch nicht bewusst ist.
Dass diese Software auch oft nicht "frei" in unserem Sinne ist, kommt noch hinzu.
Es dürfte auch nicht einfach sein, so "on the fly" das "untergejubelte" JS an die eigenen Bedürfnisse anzupassen und die geänderte Version zur Anwendung zu bringen.
Die Situation ist also eine völlig andere, als bei der Nutzung "normaler" Freier Software.
Nun umfasst Freiheit im weitesten Sinne auch die Freiheit zur Unmündigkeit. Diesen nicht verantwortungsbewussten Gebrauch der Freiheit sollten wir aber weder propagieren, noch unterstützen oder gar befördern.
Dies ist kein generelles Plädoyer gegen JS. Es kann durchaus sinnvoll sein, Anwendungen zu entwickeln, die Webtechniken nutzen und hierfür auch JS einzusetzen. Es ist nur ein Plädoyer gegen den Einsatz von JS in bestimmten Fällen, vor allem im WWW.
Gruß Michael
On Wed, 20 Dec 2017, Paul Hänsch wrote:
On Wed, Dec 20, 2017 at 07:23:17PM +0100, Johannes Zarl-Zierl wrote:
Ich habe zwar nur sehr beschränktes Wissen zum Thema Barrierefreiheit, aber was ich bisher aus einschlägigen Vorträgen gehört habe war: Javascript ist (grundsätzlich) kein Problem, solange einige Regel beachtet werden.
Ich denke, Seiteninhalte hinter die Ausführung von JavaScript zu stellen nötigt den Benutzer dazu Code auszufuhren, über dessen Tun und Inhalt er effektiv keine Kontrolle hat. Das ist meiner Meinung nach inkompatibel mit den vier Freiheiten. Allein eine Free Software Lizenz ändert daran nichts, denn der Benutzer hat ja dann immer noch keine Kontrolle über das Script, das ihm die Seite da aufdrängt. Deswegen bin ich persönlich immer gegen den Einbau von JavaScript auf FSFE-Seiten. Einen offiziellen Konsens haben wir da leider im Moment nicht.
Sehe ich ganz genauso. Selbst wenn ich mich hinsetze, und den JavaScript-Code intensiv auf Gefahren hin abklopfe, kann ich beim nächsten Laden der Seite völlig anderen Code vorgesetzt bekommen.
JavaScript war mal als kleines Add-On gedacht, das man in seinem Browser auch getrost abschalten kann. Heute werden ganze Web-Seiten aus JavaScript-Code erzeugt. Die Suchmaschine kann nichts indizieren, mein Übersetzungsserver (parallelnetz.de) läuft ins Leere, die normalen Browserfunktionen "vor", "zurück", "URLs speichern" werden nutzlos. Dazu kommen die vielen Nervereien, die sich JavaScript-Programmierer ausdenken: Neuester Quatsch scheint mir zu sein, dass ich auf Zeitungsseiten nach unten rolle und statt der Kommentare einen neuen Artikel vorgesetzt bekomme, von dem ich nicht wieder zurück zum eigentlichen Artikel gelange.
Also auch wenn ich nicht irgendwie "eingeschränkt" bin, stellt der Zwang zum Aktivieren der JavaScript-Spielereien eine Barriere für mich dar. Vielleicht bin ich als jemand, der nicht bevormundet werden will, schon so sehr Außenseiter, dass ich speziell angepasste Web-Seiten benötige. :-)
Ich verfolge diese Liste sonst nicht aktiv, nur ein paar Anmerkungen dazu:
On Wed, Dec 20, 2017 at 03:34:58PM +0100, Christian Imhorst wrote:
Ich bin da aber leider zu wenig Experte, um das einschätzen zu können, würde aber auch sagen, dass HTML5 in diesem Sinn besser ist als JavaScript.
Der Begriff HTML5 ist diesbezüglich leider ein völliger Rohrkrepierer. Die tatsächliche Markup-Spezifikation hat eine Handvoll Features standardisiert, die von Browsern ohnehin schon mehr oder weiniger unterstützt wurden. Am berühmtesten ist dabei das Video-Tag. Vor allem aber erschien HTML5 im Paket mit einer Revision verschiedener Webstandards. Darunter CSS3, SVG und eine (mehr oder minder) einheitliche Spezifikation einer ECMA-Script-API (aka. JavaScript).
HTML5 ist damit im Sprachgebrauch zu einem Sammelbegriff von allem geworden, was Browser in den letzten Jahren irgendwie angefangen haben zu unterstützen. Insbesondere ist es eine Entschuldigung geworden Browserseitiges Scripting einzusetzen, weil das ja jetzt "standardisiert" sei.
Wenn du heute einen Webdev HTML5 sagen hörst, heißt das häufiger als nicht: "wir werfen da jetzt ganz viel JavaScript drauf". Möglicherweise ist das das Gegenteil von dem was du dir vorstellst. Klar ist dass du an dem Begriff eigentlich garnichts festmachen kannst. Ich empfehle ihn zu vermeiden.
Da Basis "mediaelement.js" denke ich nicht, dass es funktioniert. Wie ich das sehe, wird JavaScript für die Steuerung benötigt und für das Flash bzw. Silverlightfallback für ältere Browser, die kein HTML5 unterstützen.
Wahrscheinlich denken die Entwicker sowas in der Richtung, das ist aber quatsch. Das <video>-Tag ist mit einem Fallback spezifiziert, das in eben den Browsern wirksam wird, die das Tag nicht unterstützen (da unbekannte Tags schon immer quasi wie ein <div> behandelt werden). Darin kann z.B. das breit unterstützte, aber dazumal inoffizielle <embed>-Tag untergebracht werden, oder ein iFrame oder einfach ein Download-Link zum Video - all das geht auch als Kette von Fallbacks, die absolut kein Scripting benötigt.
- Wie kann ich verschiedene Sprachversionen unterstützen? Bei der
aktuellen Seite können wir je nach Spracheinstellung der Besucher ein unterschiedliches Video einbinden [1]. Binde ich den vorgestellten Player ebenfalls einfach per HTML-Snippet ein (bei dem ich ja ggf. den Videolink modifizieren kann), oder liegt das in irgendeiner Datei, die dynamisch geladen wird?
Videodateien und externe Untertitel lassen sich genau so per language negotiation selektieren, wie wir es mit html-Dateien machen.
Könnte man sich anschauen, wenn nicht das eigentliche K.O.-Kriterium käme, nämlich:
Ein weiterer Punkt ist natürlich der Aufwand. Schon jetzt sind professionell gestaltete Videos ein hoher Kostenaufwand, die Untertitel zeitaufwändig für unsere ehrenamtlichen Übersetzer. Zusätzlich bräuchten wir ein Video für Gebärdensprache (und gibt es da nicht auch verschiedene Sprachen?) sowie eine Tonspur mit Audiodeskription.
Richtig. Ist dieser Aufwand geleistet, braucht es allerdings kein JavaScript um verschiedene Varianten zur Auswahl zu stellen. Ich weiß ehrlich nicht was man da Scripten wollen würde, oder warum das Vorteile bringen soll.
Wenn die Aktion Mensch natürlich zu einer JavaScript-Klitsche geht und sagt, die sollen ein JavaScript bauen, das dies und jenes macht, nehmen die das Geld. Der Fehler liegt in der Spezifikation.
Der Hauptgrund, warum so viele Webseiten JS verwenden um damit das <video>-Tag zu erzeugen, das sie eigentlich gleich hätten in die Seite schreiben können, ist wahrscheinlich, dass sich das im Workflow so ähnlich anfühlt wie damals den Flash-Player einzubinden. Das gepaart mit Copy-und-Paste-Programmierung aus Unwissenheit.
Erschwerend kommt hinzu, dass Youtube ja auch JavaScript zur Video-Einbettung benutzt, auch im sogenannten HTML5-Player. Der interessierte Beobachter kommt dann schnell auf die Idee, dass das so sein muss. Eigentlich macht Youtube das aber nur aus DRM-Gründen.
Meine Erfahrung ist, dass man dieser Unwissenheit meist mit wenig Aufwand abhelfen kann. Webdevs verstehen die Problematik, wenn man sie anspricht, und sind schnell bereit auch aus einer anderen Quelle zu Copy-Pasten.
On Thu, 21 Dec 2017, Paul Hänsch wrote:
Wenn die Aktion Mensch natürlich zu einer JavaScript-Klitsche geht und sagt, die sollen ein JavaScript bauen, das dies und jenes macht, nehmen die das Geld. Der Fehler liegt in der Spezifikation.
Ist es nicht eher so, dass der Kunde zu irgendeiner Klitsche geht, irgendwas verlangt, und daraufhin JavaScript angedreht bekommt?
Meine Erfahrung ist, dass man dieser Unwissenheit meist mit wenig Aufwand abhelfen kann. Webdevs verstehen die Problematik, wenn man sie anspricht, und sind schnell bereit auch aus einer anderen Quelle zu Copy-Pasten.
Wirklich? Die Web-Entwickler die ich regelmäßig darauf anspreche, sind erbost, wenn ich mich wage, den zwingenden Einsatz von JavaScript zu kritisieren. Wir leben doch in 2017 und besorg dir mal einen modernen Browser usw. usf.