In Revision 162 sind zwei Gäste mit von der Partie. Zum einen Mozillas Accessibility Experte Marco Zehe, der bereits zu Gast war, sowie Tomas Caspers, der sich seit vielen Jahren mit dem Thema Accessibility beschäftigt und bei uns zum ersten Mal dabei ist.
[00:01:43] News
- Sass 3.3.0
- Sass ist in der Version 3.3.0 veröffentlicht worden und bringt einige Neuerungen mit sich.
Schaunotizen
- [00:02:28] Indie UI und Accessibility
- Mit unseren beiden Themen-Gästen sprechen wir über das Thema Accessibility. Aufhänger dafür ist der Editors-Draft zu Indie UI, der sich mit der Verallgemeinerung von Benutzer-Input Events und sichtbaren Einstellungen beschäftigt.
Marco ist, wie auch manch anderer, mit dem Konzept von Indie UI nicht so ganz einverstanden und diskutiert seine Position mit Tomas, der den Ansatz der Spezifikation schon mal richtig findet.
Im Laufe der Diskussion driften wir auf die Erfahrungen der beiden mit dem allgemeinen Thema Accessibility ab.
[01:03:25] Keine Schaunotizen
- Grunt YSlow
- Grunt YSlow ist eine Grunt Task, die die Performance einer Website anhand der Metriken von Yahoo!s YSlow analysiert.
- Grunt PageSpeed
- Grunt PageSpeed ist das Pendant zur YSlow Implementierung als Grunt Task, basierend auf Google PageSpeed.
- Parker
- Das CSS Analyse-Tool Parker ermittelt Metriken eines Stylesheets und ist als CLI verfügbar.
- Bootstrap Accessibility Plugin
- Die Entwickler bei Paypal haben die Grundfunktionalität von Bootstrap so erweitert, dass die einzelnen Module zugänglicher sind und dies in ein Plugin verpackt.
- Umstieg von Mac auf Windows
- Marco hat sich für die Rückkehr zu Windows entschieden und beschreibt warum er diesen Schritt geht.
- Content Strategy Forum
- Vom 1. bis 3. Juli findet in Frankfurt das Content Strategy Forum. Im Call For Papers sind die Organisatoren auch an Front-End Entwicklung und die Schnittmengen mit der Content-Erstellung interessiert.
Kommentare
Franky #
Geschrieben am 25.03.2014 um 22:12
Ein paar Fragen von einem Accessibility-Noob:
– Warum baut man da ne api dazu und nimmt nicht was css-iges wie media-queries? Weil streng genommen gehts ja um die Präsentation der Inhalte. Aber ich bin halt oldschool und der Meinung dass man alles was geht deklarativ machen sollte…
– Was ist der unterschied zwischen einem screen-reader und einem „normalen“ seiten-vorleser wie ihn z.b. einige browser bieten/boten?
– Wie funktionieren diese erwähnten accessibility-tools die z.b. farbschemata anwenden? Quasi wie User-Stylesheets in Opera (nur halt über eine API)?
Generell muss man sagen dass auch User ohne visuelle und sonstige Einschränkung so Sachen wie Readability oder User-Stylesheets, oder sogar dedizierte Tools verwenden (ganz einfach weil viele farbschemata auch ohne visuelle Schwäche die Augen ermüden -> wenn ich den ganzen tag an irgendwelchen texten rumtippen müsste würde ich auch so ein tool zumindest einmal ausprobieren). Oder ich würde es ja genial finden wenn ich die Schlagzeilen meines Nachrichtenportals vorgelesen kriegen würde. Oder vlt braucht das head-up-display von meinem auto ein high-contrast-farbschema (hohoho, nachrichten lesen auf der autobahn :D)
Toll … jetzt weiß ich nicht einmal mehr was ich sagen wollte :P Vlt irgendwas im Sinne von: Konsum über unterschiedliche Kanäle ist wahrscheinlich im Kommen, und nicht (nur) auf Menschen mit Behinderung beschränkt. Die Frage ist nur ob ich das tatsächlich über scripting lösen will oder nicht viel lieber über eine deklaration in meinen styles.
Und: irgendwie erinnert mich die „hat der user ein accessability-device oder nicht“-debatte ja ein wenig an „hat der user touch-input oder nicht?“ … ja, kann sein dass ers hat, aber das sagt mir ja noch lange nicht dass er dann wirklich auf seinem monitor rumtappen will, z.B. bei einem Laptop. Und ebenso „hat er einen screen-reader“ ist nicht das gleiche wie „ah, dann können wir auf die monitor-darstellung eh …“
Marco Zehe #
Geschrieben am 6.04.2014 um 09:20
Hallo Franky,
ein Screen Reader liest nicht nur stumpf eine Seite von Beginn bis Ende vor oder filtert einen bestimmten Ausschnitt und liest diesen. Mit einem Screen Reader ist es möglich, Formulare auszufüllen, zu bestimmten Bereichen einer Seite wie zur nächsten oder vorherigen Überschrift, Formularfeldern, Links, nicht verlinkten Textblöcken und vielen anderen Merkmalen einer Seite zu navigieren. Man kan sich weiterhin Listen aller möglichen Dinge aufmachen und so schnell zu bestimmten Elementen auf einer Seite springen und diese wahlweise gleich aktivieren. Außerdem bietet ein Screen Reader natürlich Zugriff auf andere Bereiche des Browsers wie Dialoge, Menüs usw. Das leisten solche Seiten-Vorleser nicht und sind daher nicht für den Einsatz durch Blinde geeignet.
Der Caspers #
Geschrieben am 6.04.2014 um 08:54
Sehr geile Fragen, könnte man ne eigene Sendung draus machen :) Oder Marco könnte den a11y-Glücksrad-Erklärbär geben, falls der Herr Kröner mal verhindert sein sollte.
Zu 1. Sehe ich genau so, und Teile des W3C sehen bzw. sahen das schon seit langem genau so. Nur dummerweise haben sich die Hilfsmittel-Hersteller geweigert, die entsprechenden Vorschläge wie @media speech aus CSS2 Aural Style Sheets einzubauen. Jon Gibbins hatte da vor Jahren mal eine Übersicht gebaut: Aural CSS: Support for CSS 2 Aural Style Sheets / CSS 3 Speech Module – tl;dr: vergiss es, ist nur zu kleinen Teilen in Browsern ohne Marktanteil implementiert
Schepp #
Geschrieben am 8.04.2014 um 09:14
Ein Accessibility-Glücksrad fänd ich tatsächlich mal cool. Gibt es denn eine Seite, die sich zum Herauspicken von Themen via Glücksfee eignet?
Der Caspers #
Geschrieben am 8.04.2014 um 19:46
Für’s Glücksrad:
http://www.w3.org/TR/UNDERSTANDING-WCAG20/complete.html
oder
http://www.w3.org/TR/WCAG20-TECHS/complete.html
Ausgedruckt >100 bzw. >200 DIN A4-Seiten, da kannste lange scrollen…
Schepp #
Geschrieben am 8.04.2014 um 21:11
Yeah!
Der Caspers #
Geschrieben am 9.04.2014 um 11:31
Nee, die Dinger die ich meinte sind viel mehr als nur ein Styleswitcher oder User-Stylesheets. Ist eher vergleichbar mit Vorlesefunktion im Browser vs. kompletter Screenreader. Nur eben für stark sehbehinderte Nutzer, die eine ganz bestimmte Optik benötigen. Also nix was nur ein paar Werte in Webseiten ändert, sondern komplett das ganze GUI des gesamten Rechners auf die Bedürfnisse der Nutzer anpasst.
Beispiel dafür ist ZoomText (gibt’s neuerdings auch für Macs),
Das sind spezialisierte Tools, die den kompletten Bildschirminhalt umfärben, Kontraste verändern, bis zu 36× vergrößern (da brauchste dann einen 27″, um ganze Wörter lesen zu können), und teilweise auch einen annähernd kompletten Screenreader mitbringen.
Simulieren kannst du sowas unter MacOS z.B. über Systemeinstellungen → Bedienungshilfen → Sehen → Anzeige → Kontrastverbessern (und da mal mit den verschiedenen Knöpfchen rumspielen – da ist man sehr schnell an dem Punkt wo man eigentlich neue Icons bräuchte. Dummerweise habe ich aus einer nativen App heraus den Zugriff auf die Info, was da eingestellt ist, aber aus einer Website heraus leider nicht)
RSS-Feed zu diesem Beitrag
Kommentare sind für diesen Beitrag geschlossen.