CRE107 Barrierefreiheit im Web

Veröffentlicht am von

Was man bedenken sollte, wenn man Websites plant und gestaltet

Episode image forCRE107 Barrierefreiheit im Web

Accessibility war lange Zeit das schwarze Schaf im Web, kommt aber durch eine Reihe von Gesetzen zur Verfplichtung zur Barrierefreiheit und auch durch einen brandneuen Standard der W3C zu neuer Aufmerksamkeit. Im Gespräch mit Tim Pritlove erzählen Tomas Caspers und Jan Eric Hellbusch von der Entstehung der Accessibility-Bewegung, über technische Standards und was man bei Ihrer Anwendung berücksichtigen sollte.

Unter anderem geht es um folgende Themen: Geburt des Web Standards Project, Auswirkung der Farbwahl in Webseiten für Farbenfehlsichtige, Bedeutung der Struktur und semantischem Markup für Blinde, Vorteile von barrierefreiem Design für nicht-behinderte Nutzer, Screenreader-Programme und vergleichbare Funktionalitäten in Betriebssystemen, Aspekte der Gebärdensprache, Aufbau, Anwendung und Testbarkeit der Web Content Accessibility Guidelines der W3C, Gesetzliche Vorgaben und Verpflichtung zur Barrierefreiheit für Behörden und öffentliche Körperschaften und Accessibility für Podcasts.

avatar
Tim Pritlove
Twitter Icon @timpritlove@mastodon.social Icon Website Icon Spenden via PayPal Icon
avatar
Jan Eric Hellbusch
Twitter Icon Website Icon
avatar
Tomas Caspers
Twitter Icon Website Icon
Shownotes

Links:

35 Gedanken zu „CRE107 Barrierefreiheit im Web“

  1. Wow du erhöhst die Schlagzahl ja wirklich extrem Tim. Folge ist schon heruntergeladen aber der Podcast muss sich hinten anstellen hab noch einiges anzuhören.

    Grüße aus Hamburg

    Antworten ↓

  5. Im letzten Teil wurde ich verunsichert über meine Vorstellung zur Funktionsweise des Screenreaders: es hörte sich so an als würde er gerenderte Inhalte als Eingaben erhalten und daraus für den Benutzer lesbare Ausgaben erzeugen. Ist dies tatsächlich so? Ich hätte eigentlich gedacht, dass er ein eigenes Modul zum Rendern (oder sonstwie darstellen) von strukturierten Dateiformaten wie HTML mitbringt und diese Formate direkt verarbeitet und in Ausgaben umsetzt.

    Zudem war es sehr interessant, die Details über Gebärdensprache(n) anzuhören. Eine eigene CRE-Folge dazu fände ich sehr interessant, dabei könnte gern detaillierter auf die Unterschiede im „Wortschatz“ im Vergleich zu gesprochenen Sprachen sowie die Unterschiede zwischen unterschiedlichen Gebärdensprachen wie etwa der deutschen oder der amerikanischen eingegangen werden, denn ich war überrascht zu hören, dass Gebärdensprache international tatsächlich verständlich sein soll. Gilt dies auch für „Sprecher“ in Regionen mit ganz unterschiedlicher Grammatik der dort tatsächlich gesprochenen (d.h., nicht gebärdeten) Sprachen? Es wäre toll, wenn es mal eine Sendung darüber gäbe, vielleicht in Anknüpfung an CRE41, eventuell zusammen mit anderen nichtlautlichen Sprach- oder Mitteilungsformen, falls Gebärdensprache allein nicht umfangreich genug als Thema sein sollte. Auch die Entstehungs- und Entwicklungsgeschichte einiger derzeit aktueller Gebärdensprachen wäre interessant, um die Ähnlichkeiten zu erklären.

    Antworten ↓

  6. @J

    Die Screenreadertechnologie ist nicht ganz so einfach … Was beschrieben wurde, gilt z.B. für auf Windows laufende Screenreader:

    1. „Offiziell“ liefern Anwendungen (z.B. IE und Firefox) alle möglichen Daten an die MSAA-Schnittstelle von Windows. Der Screenreader holt die Informationen dort ab. Leider funktioniert das nicht immer so, wie man sich das vielleicht vorstellt, denn einerseits müssen die Anwendungen Infos liefern und andererseits müssen die Screenreader die Infos auch abholen.

    2. Speziell bei HTML orientieren sich die Screenreader auch mal an den Quellcode bzw. DOM.

    3. Dwo die Infos im Screenreader tatsächlich herkommen, kann nicht immer beantwortet werden, denn neben den beiden erstgenannten Möglichkeiten gibt es auch ein sogenanntes Off-Screen-Modell. Was sich genau dahinter verbirgt, entzieht sich aber meiner Kenntnis; ich bin bisher immer davon ausgegangen, dass es besondere Anpassungsskripte sind, um die Lücken in 1. zu überbrücken. Das würde zumindest erklären, warum z.B. JAWS lange nicht so recht mit Firefox wollte, obwohl Firefox die MSAA-Schnittstelle unterstützte.

    Alle ausgewerteten Infos werden dann in einem virtuellen Puffer geschoben, der bei Nutzeraktionen ständig aktualisiert wird. Deswegen können AJAX-Techniken problematisch werden: Wenn Inhalte ohne Zutun des Nutzers verändert werden, kriegt der Screenreader das gar nicht mit (JAWS, Window Eyes).

    Antworten ↓

  7. Wird denn die MSAA-Schnittstelle in der Regel auch von Programmen benutzt und ist es überhaupt ein gutes Entwicklungsinterface? Ich könnte mir denken, dass einige Entwickler davon bestenfalls schonmal gehört haben, aber mir scheint, dass man nicht unbedingt zufällig darüber stolpert. Zudem scheint jede Anwendung von sich aus Informationen für diese Schnittstelle bereitstellen zu müssen. Ich habe den Eindruck, dass die Benutzeroberfläche von Anwendungen derzeit nicht gut abstrahiert ist, und die existierenden Schnittstellen es dem Entwickler auch nicht gerade leicht machen, dies zu realisieren, da er sich, wenn er ein Programm mit grafischer Benutzeroberfläche erstellen will, auf eine bestimmte Darstellung derselben festlegen muss. Es wäre schön, wenn es eine Art Stylesheetsprache für GUI-Oberflächen gäbe, sodass statt der normalen Darstellung auch eine andere gewählt werden könnte, insbesondere wäre aber so gewährleistet, dass Entwickler ihr Programm nach funktionalen Gesichtspunkten beschreiben und die Darstellung prinzipiell auch komplett Anderen überlassen könnten, wenn sie keine Lust haben, sich überhaupt um das Aussehen ihrer Oberfläche zu kümmern.

    Was speziell die Darstellung von Browserinhalten angeht, so wundert es mich doch sehr, dass Screenreader überhaupt mit Webbrowsern zusammenarbeiten. Ich hätte eigentlich gedacht, dass sie den Browser kommplett ersetzen, da die von Browsern interpretierten Formate ja ohnehin offen sind, sodass der Screenreader sie auch gleich selbst interpretieren könnte. Insgesamt scheint mir, dass eine ganze Reihe von Workarounds gemacht werden, die dennoch wohl oft auch nicht optimal funktionieren. Die derzeitige Architektur scheint mir recht unzulänglich zu sein, und Verbesserungen wäre durchaus auch für Nutzer interessant, die ihre Anwendungen einfach zur Arbeitserleichterung gern „benutzerdefiniert eingestellt“ nutzen würden.

    Antworten ↓

  8. Tolles Thema. sehr interessant und sehr aufschlussreich. ich hatte bisher keinerlei wirklichen kontakt mit diesen dingen. man hat mal davon gehört , und das wars.

    sehr sehr informativ. danke dafür. tolle interview partner. kompliment.

    Gruß, Gilbert

    Antworten ↓

  9. Sehr schöner Podcast. Locker geführt und trotzdem nicht zuviel geplappert. So muss das sein.
    Ich freue mich schon auf die nächste Sendung. Weiter so Tim!

    Antworten ↓

  10. ..sehr informative sendung. aber warum sind eigentlich layout tabellen so schlimm? ist es technisch nicht mögilich mit tabellen strukturierte seiten zu lesen … kann mir da jemand eine vernünftige erklärung geben?

    viele grüße

    Antworten ↓

  11. die nackten inhalte lassen sich schon lesen, aber nicht die bedeutung derselben. tabellen sind ja ursprünglich für messwerte oder sonstiges vorgesehen, was normalerweise in tabellen übersichtlich dargestellt werden kann. werden tabellen nun zum layout benutzt, dann ist nicht unmittelbar erkennbar, wofür die einzelnen zelleninhalte gut sein sollen, da sie nicht die inhalte enthalten, die man erwarten würde. was sollen etwa leere zellen oder stark verschachtelte zellen beinhalten? da hier metainformationen über den inhalt dieser zellen fehlen, kann ein programm daraus keine strukturierte darstellung erzeugen, da der ort, an dem die zelleninhalte später erscheinen nicht unbedingt deren zweck verrät. so könnte beispielsweise text irgendwo am linken rand in einer länglichen zelle ein navigationsmenü enthalten oder auch kommentare zu einem literarischen text im „hauptfeld“ daneben. eine zuordnung ohne explizite metainformationen ist hier nicht möglich, auf einen sinnvollen zusammenhang der zellen kann nicht automatisch geschlossen werden.

    Antworten ↓

  12. ok, soweit ist das nachvollziehbar. aber wo ist da der unterschied zu div layouts. da kann eine genauere beschreibung des inhaltes ja auch nicht eindeutig spezifiziert werden, wie im podcast ja glaube ich auch gesagt wird. ich kann mir schon vorstellen, das ein mehrfach verschachteltes tabellen layout schwerer zu interprtieren ist. aber die browser schaffen das ja auch, also warum sollte das ein screen reader nicht auch können..

    nicht das ich jetzt unbedingt ein fan von tabellen layouts wäre. kann nur nicht so ganz nachvollziehen warum tabellen layouts so verteufelt werden, bzw bisher konnte ich keinen eindeutigen grund erkennen..

    Antworten ↓

  13. @greg.. tabellen verhauen den zusammenhang. gerade bei sehr verschachtelten tabellen wird dann nicht mehr deutlich ob das jetzt z.b. zum menu gehört oder zu einer link-liste. das alles ergibt keinen zusammenhang.

    bei der nutzung von divs kann sowas nicht passieren.
    wenn man tabellen nutzt, wird nur die optische seite gesehen, ohne diese macht der inhalt keinen sinn mehr…

    das nur kurz dazu..

    Antworten ↓

  14. @hanna_ ..ja so ähnlich hat ja auch schon „jemand“ argumentiert. aber woher weiß man den eindeutig welches div ein menu ist und welches inhalt enthält. das problem ist doch da genau das gleiche. und divs lassen sich ja auch mehrfach verschachteln. also für mich macht das erstmal keinen unterschied…

    Antworten ↓

  15. @greg Denk mal aus einer anderen Perspektive darüber nach. Es geht nicht um Layout, sondern um die Strukturierung von Inhalten. Was für Inhalte haben wir denn typischerweise so im Web?

    Der wesentliche Vorteil von divs ist die eindimensional hierarchische Struktur. Es ist immer klar erkennbar, was welchem untergeordnet ist und in welcher Reihenfolge Elemente darzustellen sind. Natürlich muss der Entwickler auch divs korrekt anwenden, automatisch toll wird auch mit divs nichts.

    Tabellen sind schon mal zweidimensional, was für die Strukturierung von Inhalten im Web nur in Einzelfällen sinn macht (und für diese sollen Tabellen ja auch ruhig verwendet werden). Kaum jemand würde auf die Idee kommen, seinen Fließtext eine Excel-Tabelle zu schreiben. Macht einfach keinen Sinn. Tabellen-Layouts sind zudem aus der Not entstanden, wir hatten ja nichts :-)

    Doppelt schwierig wird es, wenn dann noch Tabellenzellen zusammengefasst werden , Spacer-Images eingefügt werden usw.

    Antworten ↓

  16. ich kenne mich nicht besonders gut aus mit html (zu lang her, inzwischen vieles neu), aber soweit ich es gesehen habe, kennzeichnen div-elemente allgemeine blöcke. das ist schonmal besser als eine tabellenzelle, bei der nicht offensichtlich ist, dass darin überhaupt ein inhaltlicher block abgelegt sein soll. da man nur wenige blöcke haben wird, lassen sich diese schonmal schneller manuell durchsuchen als einzelne tabellenzeilen. hinzu kommt, dass blcöke ineinander geschachtelt werden können, sodass eine hierarchie der inhalte entsteht. bei tabellen gibt es keine echte schachtelung im sinne hierarchischer scopes einzelner zellen, die zellen lassen sich lediglich visuell anordnen, aber nicht logisch. mit div-blöcken lässt sich eine inhaltliche gliederungsabsicht des autors also deutlich besser ausdrücken.

    zur schwierigkeit der interpretation von tabellen durch browser: tabellen werden ja nicht inhaltlich interpretiert, sondern lediglich ihr layout, d.h., ihre visuelle darstellung. für blinde kann aber kein layout in diesem sinne erzeugt werden, vielmehr ist es wichtig, inhaltlich navigieren zu können. durch tabellen kann man vermutlich zellenweise navigieren, gewünscht ist aber, inhaltliche blöcke anspringen zu können, wofür eine hierarchische anordnung erforderlich ist. eine menge von zellen ist nicht hierarchisch geordnet.

    dennoch bin ich (nach dem oberflächlichen blick, den ich auf die derzeitige seitenbeschreibungssprache geworfen habe) der ansicht, dass die vorlagen für logisches markup ruhig etwas zahlreicher sein könnten. optimal zur seitenbeschreibung ist html vielleicht auch nicht, aber es ist nunmal da…

    Antworten ↓

  18. Zitat von J:
    »Ich hätte eigentlich gedacht, dass sie den Browser kommplett ersetzen, da die von Browsern interpretierten Formate ja ohnehin offen sind, sodass der Screenreader sie auch gleich selbst interpretieren könnte.«

    Nee, weil das Vorlesen von Webseiten ja nur eine von ganz vielen Aufgaben von Screenreadern (als der akustische Zugang des Blinden zum Betriebssystem und allen anderen Anwendungen) ist. Wenn man das sorum betrachtet, dann müssten die das ja für beliebige Anwendungen ebenfalls machen. Ok, tun sie teilweise (JAWS lässt sich z.B. mit Skripten an bestimmte Anwendungen anpassen), aber prinzipiell sind die SR schon drauf angewiesen, was ihnen die Accessibility-Schnittstelle durchreicht.

    Antworten ↓

  19. Zitat von greg:
    »aber warum sind eigentlich layout tabellen so schlimm?«

    Zum einen weil Layout-Tabellen in der Regel nicht die Bedeutung ihrer Inhalte wiedergeben (eben weil die Inhalte der Layout-Tabelle keine tabellarischen Daten sind). Tabellarische Daten (und dafür ist table wiederum hervorragend geeignet) sind irgendwas, wo die Inhalte der Zellen in irgendeiner Form in einem Bezug zueinander stehen und man den Inhalt spalten- oder zeilenweise umsortieren könnte.

    Zum anderen machen Layout-Tabelen immer wieder Probleme, wenn man sie linearisiert (also die Zellinhalte so in der Reihenfolge vorliest wie sie im Quelltext vorkommen). Ein simples Beispiel dafür: in einem per Tabelle realisierten Formular steht:

    | Vorname | Nachname |
    | [Eingabe] | [Eingabe] |

    Für den sehenden Nutzer ist über die Nähe der Labels zum Eingabefeld klar, was wozugehört, im Screenreader würde aber Vorname Nachname Eingabe Eingabe vorgelesen und die Zuordnung ist dahin. In dem Beispiel geht das noch, aber in einigermaßen komplexen Formularen führt das sehr schnell dazu, dass das ganze unbedienbar ist.

    »aber wo ist da der unterschied zu div layouts. da kann eine genauere beschreibung des inhaltes ja auch nicht eindeutig spezifiziert werden, wie im podcast ja glaube ich auch gesagt wird.«

    Ein div ist erstmal ein komplett bedeutungsfreies Element – das ist der wichtigste Unterschied zu table, das streng genommen sagt, dass jetzt tabellarische Inhalte folgen (Wetterdaten, Börsenkurse, Fahrpläne etc.). Aber man kann mittlerweile mit den im Podcast auch angesprochenen WAI-ARIA landmark roles einem div (oder anderen Strukturelementen) viel mehr an Bedeutung mitgeben. div role=“navigation“ sagt dann dem Screenreader, dass in diesem Tag die Navigation der Seite zu finden ist, div role=“main“ kennzeichnet den wesentlichen Inhalt usw.

    Antworten ↓

  20. Dass die Screenreader zum Teil auf einzelne Anwendungen angepasst werden, zeigt ja, dass die Accessability-Schnittstellen wohl oft nicht in wünschenswerter Weise von den Anwendungen beliefert wird. Die Idee, HTML dann gleich selbst zu interpretieren, ist zwar im allgemeinen keine gute, da es Anwendungsentwickler (in diesem Fall von Browsern) nicht dazu anregen dürfte, sich um die Belieferung von Accessability-Schnittstellen verdient zu machen, würde aber vermutlich zügiger zur besseren Zugänglichkeit von Webinhalten führen als auf Anwendungsentwickler zu warten.

    Antworten ↓

  21. Ich fand den Podcast interessant und sehr hellsichtig: Als ich beim Joggen im Wald gegrüßt wurde, musste ich grinsen.
    Ich würde ja gerne die Podcast auf dem ipod auch gerne schneller stellen und frage ich, ob ich podcasts in Hörbücher umwandeln kann. Weiß jemand wie das geht?

    Antworten ↓

  22. im dem video wird gezeigt wie man mit mit nur augen und “ einem muskel“ text schreiben kann…
    er zeigt einige personen die trotz ihrer einschränkung text schreiben ….

    Google Tech Talks April 19, 2007 ABSTRACT Keyboards are inefficient for two reasons: they do not exploit the redundancy in normal language; and they waste the fine analogue capabilities of the user’s motor system (fingers and eyes, for example). I describe a system intended to rectify both these inefficiencies. Dasher is a text-entry system in which a language model plays an integral role, and it’s driven by continuous gestures. Users can achieve single-finger writing speeds of 35 words per minute and hands-free writing speeds of 25 words per minute. Dasher is free software, and it works in all languages, and on many platforms. Dasher is part of Debian, and there’s even a little java version for your web-browser. http://www.dasher.org.uk/ «

    link zu video vom dasher ersteller
    http://video.google.de/videoplay?docid=5078334075080674416&ei=7puWSbmXJ4SQ2wLi8ci7Cw&q=google+tech+talk

    Antworten ↓

  25. Super interessante Folge. Ich habe gerade meine Brille nicht zur Verfügung weil ich sie bei einem Kumpel vergessen habe. Schon meine -1,75 Dioptrien sind eine ziemliche Einschränkung. (warum ist die Schrift im Kommentarfeld so winzig?) Ich bewundere jeden, der mit körperlichen Einschränkungen einen Rechner bedient.

    Antworten ↓

  26. Pingback: bits’n'pieces» Blogarchiv » chaosradio express: danke für über 100 Podcasts

  27. Ich fand die Aussage ja auch einmal gut, dass „behinderte Leute“ nicht nur sehbehinderte, etc. Menschen sind. Sondern auch einfach gestresste, genervte Menschen.

    Und dann wird man durch schlecht gemachte Webseiten gehindert / behindert. (Zum Beispiel weil keine schnelle Tastaturnavigation vorhanden ist, oder weil man durch Frames schlecht scrollen kann)

    Antworten ↓

  28. Hi, ich höre mir Podcasts meistens auf 110%-130% der Geschwindigkeit an, um ein paar Minuten meiner Zeit zu sparen. Es war echt lustig zu hören, dass ich nicht der einzige bin.

    Antworten ↓

  29. Hi Tim,

    wahrscheinlich einer der besten CRE Folgen.
    Hat echt spaß gemacht euch 3 zuzuhören.

    Etwas schade fand ich, dass vorallem auf die Screenreader eingegangen wurde und man wenig über die Braillezeille gehört hat…

    Antworten ↓

  34. Gestern habe ich zufällig gelesen, dass es einen Draft für HTML 5 gibt. Ich habe mir bei http://www.w3.org/TR/html5-diff/ mal die Neuerungen angeschaut, und auf den ersten Blick scheinen sie der Accessabilityverbesserung sehr zuträglich zu sein, da die neuen Elemente (siehe v.a. Abschnitt 3.1) nun deutlich konsequenter strukturorientiert sind, was auch deutlich wird, wenn man sich die weggefallenen Elemente (Abschnitte 3.4, 3.5) anschaut: es handelt sich v.a. um darstellungsorientierte Elemente. Können die Gesprächsgäste den Eindruck bestätigen? Wären weitere Konstrukte noch besonderes nützlich, die derzeit nicht auftauchen?

    Antworten ↓

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.