„Blue Beanie Day 2014 – Twitter Liste“ weiterlesen
Der Beitrag Blue Beanie Day 2014 – Twitter Liste erschien zuerst auf sprungmarker.
]]>Am 30.11. ist es wieder soweit – es ist Blue Beanie Day. Wir setzen unsere blauen Hauben auf und zeigen damit, dass uns Webstandards wichtig sind.
Real habe ich nur einen blau gestreiften Schal und Hauben oder Mützen trage ich so gut wie nie. Aber wir haben ja noch die virtuelle Medaille und können unser virtuelles Selbst beliebig blau gestalten. Daher gibt es auch dieses Jahr wieder eine Twitter Liste mit Avataren, die etwas Blaues tragen: bbd14. Da finden sich dann irgendwie in Blau verwandelte Firmenlogos neben realen Fotos von blau Behaubten.
Macht jedes Jahr wieder Spass – die Jagd auf Blau. :)
Der Beitrag Blue Beanie Day 2014 – Twitter Liste erschien zuerst auf sprungmarker.
]]>„HTML 5 Semantik – ein Blick auf den Blue Beanie Day“ weiterlesen
Der Beitrag HTML 5 Semantik – ein Blick auf den Blue Beanie Day erschien zuerst auf sprungmarker.
]]>Aufgrund von HTML 5 als W3C Recommendation bietet sich ein Rückblick auf nun schon fast ein Jahrzehnt HTML 5 Entwicklung an.
Im Grunde gibt es nur Vorteile durch HTML 5. Endlich hat sich eine Semantik entwickelt, die sich an die realen Bedürfnisse im Web anpasst. Eine Semantik, die sich auf den ersten Blick schnell erschließt: Den Kopf der Webseite als header
, den Fuss als footer
und der Hauptinhalt als main
. Natürlich geht es auch kleinteiliger. So kennzeichnet sich die Hauptnavigation mit nav
, eine inhaltliche Einheit als article
aus und Bild und Bildbeschreibung finden sich unter der semantischen Struktur figure
und figcaption
wieder.
Durch die neue semantische Vielfalt wird es aber auch komplizierter. Das fängt mit dem header
Element an, das mehrfach verwendet werden kann und lässt ganze Diskussionsforen über Semantik und Einsatz des section
Elements streiten. Vor HTML 5 war die Semantik begrenzt und nicht auf ganze Semantik-Gebäude ausgerichtet. Nun können wir Webseiten quasi semantisch durch konzeptionieren. Aber wie macht man das so genau? Das W3C und die WHATWG bieten zwar für jedes Element immer auch ein Beispiel, aber letztlich sitzt man vor seiner Webseite und bedient sich aus dem semantischen Werkzeugkasten.
Schnell haben sich daraus dann populäre Blogsysteme wie WordPress für ihr Default-Theme ein Semantik-Gerüst gebaut. Etliche Webstandards-Seiten wie HTML5 Doctor haben die dann noch getuned. Es war richtig spannend zu sehen, was sich wie am besten und sinnvollsten inhaltlich strukturieren lässt. Wie stark lässt sich das aside
Element dehnen. Hat man vor HTML 5 schon immer unter die Haube von Webseiten geguckt, macht man das seit HTML 5 mit schöner Gewohnheit und Regelmäßigkeit. Da sich die Semantik weiterentwickelt – HTML 5 ist ja nun living standard, entwickelt sich also am lebenden Beispiel weiter – , ändern sich auch die semantischen Gebäude. Also vergewissert man sich immer wieder, ob das eigene semantische Gerüst noch stimmig genug ist. Die Frage ist heute nicht mehr, ist das Gerüst auch korrekt. Oder man erhält Anregungen, die man für sich und mit anderen diskutieren kann wie letzthin am Accessibility Summit 2014, als Becky Gibson in ihrem Vortrag zur HTML 5 Accessibility für typische Teaser den Mehr-Link mit dem aside
Element gekennzeichnet hat.
Man ist heute als Semantiker und Entwickler stärker gefordert, mit HTML 5 an semantische Grenzen zu gehen. In einem W3C Kurs sollte ich eine HTML 5 Seite responsive erstellen und hatte als Rückmeldung erhalten, meine Seite sei übersemantisch. Gut, ich hatte versucht, eben auch mal einen semantischen Grenzgang zu wagen. :) Aber genau diese Gratwanderung ist spannend.
Semantik ist nach wie vor der Grundstein für die Barrierefreiheit im Web oder wie es Shawn Lauriat auf dem Accessibility Summit 2014 in seiner Präsentation Accessibility Challenges in Complex Web Applications so schön verrechnet hat: Es gilt beim semantischen Einsatz von HTML 5 das 90/10 Verhältnis. 10% semantische Entwicklungsarbeit und 90% Semantik gibt es gratis frei Haus. Schnürt man noch WAI-ARIA dazu, hat man etwas mehr Entwicklungsarbeit, aber noch mehr gratis Semantik – vor allem für Screenreader-Nutzer. Das rechnerische Verhältnis für WAI-ARIA ist dann – so Lauriat – 40/60. Immer noch ein sehr guter Schnitt. :)
Die semantische Gratwanderung mit HTML 5 ist natürlich auch steinig – sieht man sich aktuelle Webseiten an, findet man eher semantischen Wildwuchs. Vielfach wird ohnehin auf HTML 5 Semantik verzichtet, sondern nur der HTML5-Doctype – Marke HTML 5 Alibi – eingesetzt. Da, wo die HTML Semantik dann tapfer eingesetzt wird, kommt sie meist über header
und footer
Element nicht hinaus. Schon bei der Hauptnavigation beginnt die erste semantische Klippe. Man findet nicht wenige Seiten, die fünf und mehr nav
Elemente einsetzen. Gut, die HTML 5 Spezifikation gibt da nur Empfehlungen. Aber hier schließt sich die Argumentation zum Thema Barrierefreiheit: Nicht jede Linkliste ist eine wichtige Navigation. Im Grunde sollte nur die Hauptnavigation der Webseite mit dem nav
Element gekennzeichnet werden.
Das section
Element hat kaum jemand verstanden und hat schlicht die Divitis – den Übereinsatz des div
Elements – ersetzt. Oder wie Roger Johansson schon 2012 für den semantischen Einsatz von HTML 5 summierte:
Articleitis, sectionitis and headeritis are the new divitis.
Quelle: Roger Johansson – Twitter
Ähnliche Probleme bereitet auch der Einsatz von WAI-ARIA. Selbst die vergleichsweise einfach einzusetzenden role
Attribute wie banner
oder main
werden entweder gar nicht eingesetzt oder nicht wirklich auf passenden inhaltlichen Bereichen. Jared Smith hat das ausführlich in seiner Präsentation ARIA Gone Even Wilder auf dem Accessibility Summit 2014 dargestellt: ARIA wird häufig anstatt herkömmlicher Semantik verwendet und dann auch oftmals mit falschen roles. Ähnliches lässt sich für das placeholder
Attribut aus der wunderbaren Welt der HTML 5 Formulare feststellen: Kaum war das neue Attribut da, hat man schon die herkömmliche Formular-Semantik fallen gelassen und damit das label
Element. Ein placeholder
tut es doch auch – nur dass sich dabei keiner erinnert oder mal nachblättert, was die Funktion des placeholder
Attribute eigentlich ist: nämlich einen zusätzlichen Hinweis bei der Eingabe in ein Formularfeld zu geben – etwa welches Format ein Datum haben sollte.
Im Grunde wird es nicht einfacher werden – weder mit HTML 5 noch mit der dadurch erzeugbaren Semantik. Aber das soll nicht heißen, wir lassen das lieber mit der Semantik. Was wir weiterhin brauchen werden – mehr Best Practice Beispiele, mehr Unter-die-Haube-Gucken auch beim semantischen Wildwuchs und sich Gedanken darüber machen, wie man semantische Problemstellen und wacklige Semantik-Gebäude optimieren kann.
Auch dafür ist der Blue Beanie Day da. Uns immer wieder daran zu erinnern, dass das Web diversity – Vielfalt – bedeutet – ist ja auch mit dem Pony von My Little Pony Motto des diesjährigen Blue Beanie Day. Und so vielfältig wie das Web, so vielfältig ist der Einsatz von Semantik im Web. Unsere Aufgabe als Entwickler ist es, eine sinnvolle und vielfältige Semantik für möglichst alle zu integrieren. Dafür setzen wir gerne morgen wieder eine blaue Haube auf.
Der Beitrag HTML 5 Semantik – ein Blick auf den Blue Beanie Day erschien zuerst auf sprungmarker.
]]>„Opera goes Webkit und verliert an Barrierefreiheit“ weiterlesen
Der Beitrag Opera goes Webkit und verliert an Barrierefreiheit erschien zuerst auf sprungmarker.
]]>Fritz Weisshart wies mich dankenswerter Weise darauf hin, dass das HTML5 Video-Element in der aktuellen Opera Version 15 nicht mehr mit Tastatur bedienbar sei. Ich habe das gleich getestet und das ist korrekt.
Sowohl in der aktuellen Version als auch in Opera Next das gleiche Ergebnis. Der Player für Audio und Video ist per Tastatur erreichbar, aber keiner der Elemente des Players ist bedienbar. Ich werde daher meinen Artikel HTML5 Medien und ihre Tastaturbedienbarkeit auf den aktuellen Stand insgesamt bringen müssen.
Das ist wirklich sehr schade. Hält sich Opera mit seinen Entwicklungs-Zyklen an die von Webkit Nightly und Chrome Canary – auch dort ist keine Tastatur-Bedienbarkeit bis dato in Sicht, dann wird sich sobald nichts ändern, womöglich fällt die barrierefreie Bedienbarkeit ganz unter den Tisch.
Wie Terrill Thompson in seinem Test-Artikel Comparison of Browsers on HTML5 Video Accessibility für die aktuelle Chrome-Version feststellt, ist der Video-Player zumindest halb für Screenreader-Nutzer bedienbar. Mit Hilfe der Erweiterung Chrome Vox lässt sich das Video starten und stoppen, aber der Rest der Steuerung ist nicht erreichbar. Mit Hilfe von JAWS sind die einzelnen Steuerelemente wohl erreichbar, verschwinden jedoch nach kurzer Zeit wieder.
Wenn das der Webkit Way of Living sein soll, dann trauern wir wirklich um den alten Opera Browser.
Der Beitrag Opera goes Webkit und verliert an Barrierefreiheit erschien zuerst auf sprungmarker.
]]>„Recap of Mobilism 2013“ weiterlesen
Der Beitrag Recap of Mobilism 2013 erschien zuerst auf sprungmarker.
]]>The most important topics and starting points for me this year are:
Following talks are summarized:
I had a particular interest in this talk. To get the right workflow in RWD is still in progress, especially for big agencies. In particular there has to be a better one between design and development. Yes – we know that, Photoshop is not the right choice for RWD anymore and so are image-based mockups. But how do we get in a real good workflow with designers and using web-based mockups? This is still a crucial moment and as Stephen Hay shows there is not one tool to fill the gap.
Web-based mockups more effectively represent the end result in the browser because they are already in the browser.
Stephen Hay
Using all kind of generators makes the gap smaller between design and development – you have to evaluate what fits best:
Susy grid is quite handy and straight forward, I am using it a lot – not only for prototyping and it works with rem units as well. But I think for prototyping flexbox may be more flexible and faster. Without SASS – or just fill in LESS or Stylus – developing gets really very slow nowadays. Far more interesting for me is what the difference between static site generators like Jekyll and such tools as Yeoman or Middleman is.
To present our web-based mockups we can use a live demo of course but we will come into the need for presenting screenshots. I will have to look up CaspersJs for capturing automated screenshots of a website. And we could even generate a style guide out of out web-based mockup.
I think it is still a challenge to get a real good workflow out of such varying tools. But Stephen Hay’s talk helps to get it rolling. Get his slides.
Jake Archibald is quite a performer and in a very speedy manner. So I had to recap and test some of his results myself afterwards and as I may say this browser painting tools he presented are fascinating.
Heavy Styles?
Use dev tools to see what’s going on.Jake Archibald
Performance is crucial especially for RWD and web apps. He showed browser painting tools and their magic results to get at the bottom of performance issues. I could not get along that far with Firefox and its Toggle Paint Flashing Plugin. For a start with such tools I recommend using Chrome Canary dev tools. Activating the option Enable continuous page repainting shows page painting time on using the page. It’s fascinating to test CSS i.e. border-radius
and box-shadow
and get immediate response on performance issues. I will integrate this in my dev workflow for sure. Get his slides.
Another crucial issue for RWD is Responsive Images. Everyone likes to shrink browser windows and seems to be satisfied with shrinking images by max-width
. “Best viewed in the First World”, as Mat Marquis pointed out.
72% of responsive websites send roughly the same data to both mobile and desktop users.
Mat Marquis
This is where Responsive Images comes in – use the picture
element with its media queries as often as possible and its polyfill such as picturefill. You find the living document W3C Picture Elmeent at the W3C and get news at the Responsive Images Community Group and ResponsiveImages.org.
I hope that the picture element solution gets implemented soon and we get rid of such problems like fallback image downloads each time. Get his slides.
I have to admit but I never really developed for console browsers. This is another start for me on Mobilism – getting acquainted to consoles.
13% in the UK 2011 used a console to access the internet.
Anna Debenham
Console browsers support no flash, only small parts of CSS and some HTML5. Anna Debenham presents the results of her console tests on Game Console Browsers. For instance Nintendo Wii U – released end of 2012 – has only 258/500 HTML5 and 48% CSS3 support.
Important is that consoles have more than touch or keyboard input:
Today even cameras and printer have browsers. The learnings are common practice as to add more blank space between elements and provide good visual feedback. But I think you have to do a lot of testing to get used to the issues and to the devices itself. Thanks for your good work, Anna. Get her slides.
Mobilism gets me a good start in topics as console browsers, RWD workflow and performance debugging in the browser. This is why I really like to attend this conference and I hope it will come to stage the next year.
And many thanks for my new testing device I won: Nokia Asha 311. It’s a really small device, more low end, Series 40 OS and has a proxy browser.
Der Beitrag Recap of Mobilism 2013 erschien zuerst auf sprungmarker.
]]>Der Beitrag Review: 2012 erschien zuerst auf sprungmarker.
]]>Trotzdem habe ich noch einige Projekte vorangetrieben – und wie fast jedes Jahr knubbelten sich diese im zweiten Halbjahr. So habe ich für cologne.js – die Kölner JavaScript Gruppe – einen Vortrag zu JavaScript und Barrierefreiheit gehalten – als einfaches Beispiel habe ich mir die Umsetzung eines Akkordions in Frameworks wie jQuery UI und Accessible Mootools und der WAI-Gruppe angesehen: Accessible Javascript. Besonders spannend war dazu im Vergleich die doch eher geringe barrierefreie Umsetzung bei jQuery Mobile.
Nach 2 Jahren war er wieder da: der Wiener A-Tag. Diesmal stand er ganz im Zeichen der Mobile Accessibility. Zum dritten Mal in Folge und damit zum letzten Mal (:)) habe ich mich zu neuen barrierefreien Ufern aufgemacht und das Thema Responsive Webdesign und Barrierefreiheit abgeklopft. Ich nutze Vorträge und Projekte immer gerne dazu, etwas neu zu beleuchten und weiter zu entwickeln. Aus dem Vortrag ist auch gleich ein ganzes Projekt zum Thema entstanden, an dem ich nach und nach weiter entwickeln werde: Responsive Accessibility in der Praxis. Mehr Infos zum Projekt in Kürze …
Nach über 2 Jahren Vorlaufzeit gibt es jetzt in WordPress eine Core-Accessibility-Gruppe. Der gehöre ich an, aber ich bin nicht sonderlich mit Procedere und Prozess zufrieden. Ich kenne weder, wie WordPress intern Aufgaben abarbeitet, noch weiß ich letztlich, was die Gruppe macht und machen soll. Der barrierefreie Grundgedanke, den Core insgesamt von Beginn an barrierefrei auf- und auszuarbeiten, klappt wohl nicht. Daher sollen wir in der Gruppe diverse Tickets begutachten und bewerten. Keine Ahnung, irgendwie habe ich mittlerweile auch zu wenig Freizeit, um mich da wirklich einzuarbeiten. Letztlich geht es mir ums Frontend und auch das neue Default-Theme ist nicht wesentlich besser als die vorherigen. Auch bin ich nicht immer mit den Korrekturen bis dato einverstanden, na ja. :)
Im Dezember hatte ich dann nach fast 3 Jahren die erste Lesung aus meinem Buch in Graz. Das war ziemlich spannend, weil so richtige Fans da waren. :) Vor 3 Jahren hätte mir das noch mehr Auftrieb gegeben …
In der Summe doch recht spannend gewesen, das Jahr 2012. Und wird es hier wieder voller werden 2013? Das frage ich mich auch, mal abwarten. :)
Der Beitrag Review: 2012 erschien zuerst auf sprungmarker.
]]>„Re: Wie tot ist die BIENE“ weiterlesen
Der Beitrag Re: Wie tot ist die BIENE erschien zuerst auf sprungmarker.
]]>Nach dem jahrelangen Warten, dass sich immer mehr Barrierefreiheit im Web durchsetzt (infinit), dem Warten auf das längst fällige Update der WCAG auf die Version 2.0 (2008) und dem mehr als geduldigen Warten darauf, dass die Gesetzeslage nachzieht mit der BITV 2 (2011), bleibt nun das abermalige Warten auf die BIENE 2012, 2013 oder 2014?
Auf der republica2012 in Berlin setzt Martin Georgi (Aktion Mensch) den nächsten BIENE-Wettbewerb für Ende diese Jahres an (Video – Minute 4:28 – danke an Kerstin Probiesch für diesen Hinweis). Was wohl meint, dass dann erst die Ausschreibung beginnen wird.
Das Thema Barrierefreiheit im Web ist komplexer geworden und entwickelt sich wie das Web insgesamt immer rascher. Die Frage hatte ich schon einmal hier gestellt, ob ein barrierefreier Wettbewerb da immer up to date bleiben kann: Der BIENE-Wettbewerb in der Krise – und das war 2008, als die BIENE bereits eine inhaltliche Pause eingelegt hatte.
Ich denke, die Frage ist heute immer noch die gleiche: Sind solche Wettbewerbe überhaupt nachhaltig genug, können sie mit den aktuellen Entwicklungen mithalten? Daher, so sehr sich alle auf ein Wiedersehen mit der BIENE freuen, ist es wichtig, dass die BIENE als Wettbewerb sich die Pausen nimmt, die sie braucht. Nur so kann die BIENE ihr hohes Level in Sachen Barrierefreiheit im Web halten – und sie legt das inhaltliche Niveau hoch, wie man im kobinet Interview nachlesen kann -, in dem sie sich ständig erneuert. Auch wenn Bienen keine Schmetterlinge werden. :)
Der Beitrag Re: Wie tot ist die BIENE erschien zuerst auf sprungmarker.
]]>„Re: Ist die Barrierefreiheit tot?“ weiterlesen
Der Beitrag Re: Ist die Barrierefreiheit tot? erschien zuerst auf sprungmarker.
]]>Man könnte jetzt mit so voll- bzw. volksmundigen Antworten beginnen, wie Totgesagte leben ohnehin immer länger oder derzeit sind Zombies wieder hoch im Kurs oder waren es Vampire. ;) Aber lassen wird das mal beiseite – beginnen wir mit dem Sezieren. Wolfgang Wiese geht das Thema von zwei Seiten an, warum es still geworden ist um das Thema Barrierefreiheit. Zum einen könnte es ein positives Ergebnis sein: Allen ist das Thema präsent und zur Routine geworden – es ist kein Extra-Thema mehr. Zum anderen könnte es sein, dass das Thema niemanden mehr interessiert, die wenigen Rührigen haben aufgegeben und sich anderen Themen zugewandt.
Durchaus lässt sich das sagen, in den Kommentaren zum Artikel wird das auch angemerkt. Seit 2004 – das ist die magische Marke, die Wiese ansetzt – hat sich tatsächlich viel verbessert. Gerade Blog- und CMS-Systeme haben die Ausgaben der Inhalte optimiert. Aber das ist ja stets so, zuerst wird ein neues Thema erschlossen und erst einige Zeit später greifen dann auch die barrierefreien Standards nach und nach. Das heißt jetzt nicht, dass alle Systeme auf grün stehen würden, aber mit und ohne Druck von Betroffenen bewegt sich immer wieder ein Stück. Ich kenne das von WordPress ganz gut, ein ewiger Prozess-Kaugummi, bis sich wieder was bewegt.
Barrierefreiheit ist zwar zur Routine geworden, was auch meint, dass etwa Entwicklern das Thema durchaus bekannt ist, aber meiner Ansicht nach gibt es eine barrierefreie Info-Schere. Man weiß etwa über WAI-ARIA etwas, wendet es aber entweder nicht an, falsch oder sieht sich den Gesamtrahmen nicht an. Das ist ein großes Problem. Durch die rasante Entwicklung der sagen wir mal letzten 2 Jahre kommen soviele neue Themen auf die Barrierefreiheit zu, dass noch weniger auf den Gesamtrahmen acht gegeben und schlicht auf Verdacht angewendet wird. Nach dem Motto: Da nehme ich mal ein wenig WAI-ARIA und dann noch ein wenig HTML5 Formularvalidierung etc. Für mich zeigt sich ein klarer Trend der Vereinfachung von Barrierefreiheit, der ohnehin schon gerne vorherrschte: Was leicht geht und schnell, das wird eingesetzt. Was kümmert schon noch eine konsistente Überschriftenhierarchie, schließlich sind ja Überschriften eingebaut. Vertiefung und Feinschliff im Thema Barrierefreiheit ist meiner Ansicht nach leider nicht zur Routine geworden. Und angesichts der rasanten Entwicklung wird das nicht besser werden.
Auch das lässt sich durchaus häufig finden, Barrierefreiheit wird da immer noch nicht in den Gesamtprozess eingebunden, sondern behält ihren Extrastatus. Damit steht sie nicht alleine derzeit, das findet man auch bei grundsätzlichen Konzepten wie der mobilen Optimierung, wo das Mobile gerne dem Desktop nachgereicht wird. Zuerst machen wir alles für das Herkömmliche fertig – weil wir uns da gut auskennen und den Rest reichen wir später nach. Konzepte wie Mobile First werden noch lange brauchen, bis sie wirklich verstanden und routinemäßig umgesetzt werden. Bis dahin wird an Bestehendes geklammert.
Viele aktuelle Debatten erinnern daher sehr stark an die zur Barrierefreiheit. Im Grunde könnte man hier einhaken und argumentative Hilfslinien ziehen, damit das Thema wieder aktueller wird. Auch so ein Luxus-Problem, dass das Thema Barrierefreiheit sich eben seit 2004 massiv gewandelt hat. sollte thematisiert werden. Selbst WCAG 2 und BITV 2 wirken mittlerweile veraltet angesichts der rasanten Entwicklung. Die WCAG 2 haben dabei den entschiedenen Vorteil, dass sich ihre Techniken nach und nach aktualisieren lassen.
Und wenn wir ganz ehrlich sind, die BITV 2 hat es uns nicht leichter gemacht. Nun sind wir als Entwickler ohnehin schon mit einer gewissen Schallgeschwindigkeit unterwegs und müssen uns auch noch mit teilweise völlig diffusen Abweichungen zwischen Empfehlung und Gesetzgebung abquälen. Dabei dachten wir, mit den WCAG 2 sei es ja nun eindeutiger und klarer geworden, einen Auftritt barrierefrei zu erstellen. Man kann einer aktuellen Debatte zustimmen, die WCAG 2 richten sich schon in großen Teilen an den avancierten Entwickler. Auch hier haben wir wieder die barrierefreie Info-Schere. Kann man den Gesamtrahmen nicht erfassen und weiß man nicht, wie Techniken sich untereinander bedingen und auch ausschließen können, landet man schnell wieder im alten Punkte-Abarbeiten. Dann setzt man gerne das um, was man eh kennt und den Rest lässt man dann außen vor, auch wenn es für den konkreten Anwendungsfall wichtiger gewesen wäre.
Auch da hat Wiese vollkommen recht, es ist still geworden in der deutschsprachigen Szene. Das hat viele Gründe – einige werden genannt, andere in den Kommentaren zum Artikel wieder abgearbeitet. Ich mag dazu nicht mehr viel sagen. Klar finde ich es schade, dass es so ist, wie es ist. Nehme aber durchaus auch wahr, dass an einigen Strängen trotzdem weiter gearbeitet wird etwa PDF und Barrierefreiheit – da wird wirklich wichtige Arbeit gemacht (axesPDF oder der PDF Accessibility Checker) oder an einem barrierefreien Testverfahren, sei es nun der BITV-Test oder ein noch kommendes Verfahren. Und wie Marco Zehe im Kommentar zum Artikel ganz richtig sagt, die Orientierung des barrierefreien Entwicklers geht aktuell schlicht in den englischsprachigen Raum. Dort bewegt sich mehr und lässt sich aufgrund von offenbar größeren Ressourcen mehr bewegen. Klar, es fehlen die Events, die früher das Thema fokussiert haben.
Freilich ganz so still und ohne entsprechenden gegenseitigen Resonanzboden ist es weit schwerer, immer am Thema dran zu bleiben. Dazu kommt die rasante Entwicklung, die einen dazu auffordert, beständig das Thema Barrierefreiheit mitzudenken und mitzunehmen. Ich mache das immer noch, aber präsentiere weniger meine Ergebnisse dazu. Das liegt zum einen daran, dass ich wirklich viel lerne, Kurse mache und mir Neues erarbeite. Und zum anderen, dass Energien halt auch begrenzt sind und ich mir überlege, wo ich sie noch hin packe. Und ach ja, ganz vergessen, einem neuen Job trete ich auch demnächst an und auch das wird meine Energien neu bündeln. :)
Aber bei mir ist der Wink mit dem argumentativen Zaunpfahl von Wolfgang Wiese durchaus angekommen, ich werde mal sehen, was ich abzwacken kann zum Thema.
Auf eine Frage von Kerstin Probiesch hin präzisiere ich den Hinweis, dass WCAG 2 und BITV 2 schon veraltet wirken. Damit meinte ich die angeschlossenen Techniken. WCAG 2 und BITV 2 sind ja technikneutral formuliert und unterliegen damit einer gewissen permanenten Aktualität. Obwohl ich glaube, dass man gar nicht so technikneutral formulieren kann, dass es nicht doch letztlich an gewisse technische Rahmenbedingungen gebunden bleibt.
Der Beitrag Re: Ist die Barrierefreiheit tot? erschien zuerst auf sprungmarker.
]]>„HTML5 Medien und ihre Tastaturbedienbarkeit“ weiterlesen
Der Beitrag HTML5 Medien und ihre Tastaturbedienbarkeit erschien zuerst auf sprungmarker.
]]>Man würde ja meinen, wenn beide Elemente nativ im Browser zur Verfügung stehen, dass sie auch per Tastatur erreichbar und vollständig bedienbar sind. Gut, wir könnten jetzt hier abzweigen und eine Diskussion darüber führen, was nativ in Bezug auf HTML5 noch heißt. Ich habe ja mal geflachst und nativ auf naiv umgemünzt. ;) Aber letztlich meint nativ mittlerweile, dass das Element erreichbar gemacht werden kann – bei Video- und Audio-Elementen in der Kombination mit Javaskript.
Aber das wäre eine andere Debatte, wir wollen uns ja nicht verzetteln. ;) Sieht man sich die aktuell umgesetzte Lage für Tastaturnutzung an, ist sie so schlecht nicht – auch wenn Safari und Chrome gänzlich außen vor bleiben. An der Umsetzung im Browser sieht man, dass den Browser-Herstellern an einer Tastaturbedienung durchaus gelegen ist. Wie der Stand bis dato ist, sehen wir uns nun genauer an:
Ein Beispiel mit der Standardkonfiguration von Audio- und Video-Player dient uns als Vorlage und besteht im Wesentlichen aus Audio- und Video-Element mit dem Attribut controls
, das die Steuerungselemente anzeigt, und festen Massen für das Video. Die für Audio und Video notwendigen Formate sind ebenfalls integriert. Aber das ist es schon. Auf eine Integration des track
Elements wird noch verzichtet, weil es bis dato von Browsern nicht interpretiert wird. Sieht man sich die Entwicklungsversionen der Browser an, wird wohl heftig an einer Integration des Elements gearbeitet. Aber erst wenn es wirklich unterstützt wird, kann man die Bedienung etwa einer Untertitelung mit Tastatur testen.
Bis dato ist in Internet Explorer ab 9, Firefox und Opera sowohl Audio- und Video-Player per Tastatur erreichbar. Safari ignoriert per Tastatur komplett, dass es diese Elemente auf der Webseite gibt. Mit Hilfe eines manuell gesetzten Tabindexes in Safari erreicht man zwar dann die Elemente, das war es aber auch schon. Das gleich gilt für Chrome. Die Betaversion von Chrome – derzeit auf dem Mac die 16 und noch was – gibt Hoffnung, weil die beiden Elemente immerhin mit der Tastatur erreicht werden können, mehr tut sich da aber auch noch nicht. Opera ist der absolute Spitzenreiter, was die Tastatur-Unterstützung betrifft – alle Elemente der Steuerung sind per Tastatur erreichbar, mit klarem Fokus und per Tastatur bedienbar.
Option | IE ab 9 | Opera | FF | Chrome Beta | Safari |
---|---|---|---|---|---|
Audio- / Videoelement per Tastatur erreichbar | ja | ja | ja | ja | nein |
Fokus erkennbar durch Rahmung | ja | ja | ja | ja | nein |
Steuerung ist generell bedienbar | ja | ja | ja | nein | nein |
Alle Elemente der Steuerung sind bedienbar | nein | ja | nein | nein | nein |
hat ein Kontextmenü | ja | ja | ja | ja | nein |
Chrome und Safari sind also außen vor – nur beim Kontextmenü gehen wir noch einmal auf Chrome ein. Grundsätzlich unterscheiden sich die restlichen Browser – IE ab 9, Opera und FF – darin, welche Elemente der Steuerung mit Tastatur erreichbar und bedienbar sind. Darauf gehen wir jetzt näher ein.
Option | IE ab 9 | Opera | FF |
---|---|---|---|
Abspielen / Anhalten per Leertaste | ja | ja | ja |
Fortschrittsbalken per Pfeiltasten links / rechts | ja | ja | ja |
Vor / Zurück springen (IE) | nein | nicht vorhanden | nicht vorhanden |
Lautstärke per Pfeiltasten oben / unten | ja | ja | ja |
Ton an / aus etwa mit return |
nein | ja | nein |
Hier scheint sich ein Quasi-Standard herauszubilden. Alle Browser arbeiten mit dem gleichen Bedienschema: Abspielen / Anhalten mit Hilfe der Leertaste, mit den Pfeiltasten links / rechts bewegt man sich auf dem Fortschrittsbalken vor- oder rückwärts – meistens in Intervallen von 15 Sekunden und die Lautstärke wird mit den Pfeiltasten nach oben oder unten nachgeregelt.
Die Lautstärkeregelung in Firefox ist visuell nicht nachvollziehbar, da muss man sich schon auf das Gehör verlassen. Überhaupt ist das automatische Wegklappen der Steuerung für die Tastaturbedienung eher suboptimal, weil man nie so genau nachvollziehen kann, was man grade macht. Gut, wenn man das Bedienschema kennt, geht das auch ohne visuelle Rückbestätigung. Generell muss man jedoch aufpassen, dass man nicht mehr weiter mit der Tabtaste geht, sobald man das Audio oder Video erreicht hat – sonst hat man mit dem nächsten Tab wieder aus dem Element navigiert und den Fokus verloren.
Opera geht da einen anderen, ungleich besseren Weg: Alle Elemente der Steuerung müssen zuerst mit Tastatur angesteuert werden und erst dann kann man sie nutzen. So erreicht man mit Tab die Laustärke-Regelung und kann mit return
den Ton stumm schalten oder wieder anschalten. Der Nachteil dabei ist, dass man nicht einfach sofort per Pfeiltasten arbeiten kann. Man muss die Browser-Entwicklung abwarten, ob die anderen hier den Weg von Opera gehen. Internet Explorer und Safari – nicht mit Tastatur bedienbar – scheren etwas aus, in dem sie eine weitere Möglichkeit anbieten, vor und zurück zu springen. Per Tastatur ist das ja bereits auf dem Fortschrittsbalken möglich – meisten in 15- oder 10-Sekunden-Schritten. Safari bietet 30 Sekunden-Sprünge zurück an, der Internet Explorer 30-Sekunden-Sprünge nach vor und zurück. Damit hat man im IE also zwei Möglichkeiten, sich im Video oder Audio fortzubewegen. Mit Tastatur erreichbar ist jedoch nur die auf dem Fortschrittsbalken. Die 30-Sekunden-Sprünge sind nur per Maus erreichbar.
Die Hervorhebung des aktuellen Elements ist bis auf Opera eher marginal umgesetzt. Opera zeigt um jedes Element, das den Tastaturfokus hat, einen gestrichelten Rahmen. Den besten Fokus haben noch die Laustärkeregelung und der Forschrittsbalken. Bei beiden ist durch die Farbgebung erkennbar, dass sich etwas verändert. Bei Fokus auf Abschalten oder Anhalten ist nicht wirklich eine farbliche Hervorhebung zu erkennen. Immerhin ändert sich das grafische Symbol – Standardsymbole für Start und Stop. Sieht man sich im Vergleich den Fokus bei Mausbedienung an, findet sich dort etwa im Internet Explorer eine klare farbliche Hervorhebung. Das würde man sich auch für bei Bedienung mit Tastatur wünschen. Generell könnte der Fokus des aktuellen Elements bei allen Browsern angehoben werden – für jede Bedienung.
Wer viel mit Kontextmenüs arbeitet, kommt bei Audio- und Video-Elementen voll auf seine Kosten. Allein mit Hilfe der Tastatur konnte ich das Kontextmenü nicht aktivieren, aber ich bin kein wirklicher Tastaturcrack. :) Das Kontextmenü doppelt einige Elemente der Steuerung wie Abspielen und Anhalten, fügt aber vor allem etliche neue Elemente hinzu. Auch sind die Optionen zwischen Audio- und Video-Element mitunter unterschiedlich – etwa Vollbild ist ja nur für Video von Belang. Außer Safari bieten alle anderen Browser ein ausführliches Kontextmenü an.
Option | IE ab 9 | Opera | FF | Chrome Beta |
---|---|---|---|---|
Anhalten / Fortsetzen | ja | ja | ja | ja |
Ton an / aus | ja | ja | ja | ja |
Vollbild | nein | nein | ja | nein |
Steuerung aus- und einblenden | nein | ja (nur Video) | ja | ja (nur Video) |
Wiedergabegeschwindigkeit erhöhen / verringern | ja | nein | nein | nein |
Schleife | nein | nein | nein | ja |
Datei speichern | ja | ja | ja | ja |
URL speichern | ja | ja | ja | ja |
Datei direkt ansehen | nein | nein | ja (nur Video) | ja |
Aufgrund der Optionen ergeben sich mitunter Fallen. Im Firefox kann man auch für Audio die Steuerung ausschalten. Leider ist dann das Audio nicht mehr zu sehen und nicht mehr erreichbar, auch wenn einige Schnipsel des Players durchaus noch zu sehen sind. Auch im Kontextmenüs sind dann die Audio-Optionen nicht mehr erreichbar, da bleibt nur das Neuladen der Seite. Opera und Chrome haben da schon nachgearbeitet und das Aus- und Einblenden der Steuerung nur für Videos vorgesehen.
Bei den Optionen Audio- und Video-Datei speichern, deren URL kopieren oder sie direkt abspielen erhält man natürlich immer nur das vom Browser unterstützte Format, bei mehreren unterstützten Formaten das erste in der Reihenfolge. Eine etwas obskure Funktion bietet der IE mit der Nachregelung der Wiedergabegeschwindigkeit – schneller oder langsamer. Wird sich womöglich nicht als Standard durchsetzen. :)
Für den Tastaturnutzer, der den Audio- oder Video-Player in der Standardausführung bedient, sieht die Situation nicht wirklich schlecht aus. Auch die übliche Schelte auf den IE greift nicht wirklich. Man sieht, dass die Browser sich wirklich bemühen, den Standard für Tastaturbedienbarkeit zu optimieren. Durchsetzen wird sich das oben beschriebene Bedienschema – optimal wäre, wenn sich alle ein wenig Opera zum Vorbild nähmen.
Safari und Chrome liegen in der Tastaturbedienbarkeit weit weg vom Schuss. Da bleibt die Frage, warum das so ist. Gerade Apple legt immer viel Wert auf Barrierefreiheit. Man kann nur hoffen, dass sich da wirklich bald etwas tut. Immerhin fokussiert Chrome schon mal die Hauptelemente. Der Rest ist noch Dead End.
Die Frage wird auch sein, was nutzt ein Standard-Player, wenn ich ihn nicht individuell anpassen kann – etwa mit CSS. Das ist wohl nicht vorgesehen. Was heißt, dass man ohnehin mit Javaskript den Player individualisieren muss, also die Steuerelemente nachbauen. Die Tastaturbedienbarkeit kann dann natürlich viel leichter optimiert werden. Trotzdem denke ich, dass der Standard-Player sehr wohl häufig im Einsatz sein wird – denken wir an ein CMS oder Blogsysteme.
Daher halte ich es – ganz abgesehen davon, ob das zu naiv oder zu sehr nativ gedacht ist – für wichtig, dass Standardelemente wie Audio und Video, die weitreichende Funktionen aufrufen, komplett mit Tastatur bedienbar und barrierefrei werden. Das war und ist mein Wunsch für den Blue Beanie Day – Standardisierung meint genau das – Standards barrierefrei zur Verfügung zu stellen. Soll der Player schicker, individueller und weitere Zusatzfunktionen haben, steht ja die Standard-Javaskript-API bereit. Und in einem weiteren Schritt müsste man testen, wie tastaturbedienbar der Default mit Screenreadern ist – das wäre noch ein weiterer Artikel. :)
Der Beitrag HTML5 Medien und ihre Tastaturbedienbarkeit erschien zuerst auf sprungmarker.
]]>„Der barrierefreie Webentwickler – ein Langweiler?“ weiterlesen
Der Beitrag Der barrierefreie Webentwickler – ein Langweiler? erschien zuerst auf sprungmarker.
]]>So findet Nico Brünjes in seiner Leselinks auf der Flucht zu meinem Artikel in Sachen reine Textvergrößerung und WCAG 2.0 / BITV 2.0 die blumigen Worte:
Den barrierefreien Entwickler lernen wir unter »WCAG 2 und die reine Textvergrößerung« kennen. Aber mal im Ernst: ein trockenes Thema. Wer wissen will, wie Barrierefreiheit tickt, braucht nur diesen Post zu lesen. Und dann schnell weg…
Quelle: Nico Brünjes – Leselinks auf der Flucht.
Dazu fällt mir nur zweierlei ein: Zum einen ist es schlicht so, dass Barrierefreiheit und deren Techniken sich immer schneller weiterentwickeln. Da kommt eine Gesetzgebung wie die BITV ohnehin nicht mehr nach, selbst das WCAG 2.0 mit ihren offenen Techniken hat da gut zu tun. Daher ist die Aufgabe des barrierefreien Entwicklers (gut: ich kann auch die Entwicklerin betonen), am Puls der Entwicklung Temperatur zu nehmen und jeweils Vergleiche zu ziehen, Veränderungen aufzuzeigen und sich selbst dabei mit zu entwickeln. Zum anderen ist es nun mal so, dass nicht alles Fun sein muss, aber letztlich ist die Beschäftigung und Weiterentwicklung eines Empfehlungsinventars wie das WCAG 2.0 durchaus spannend – wenn auch zeit- und debattenintensiv.
Mein barrierefreies Entwicklerleben kennt diese Begegnung mit dem Langeweilebonus, der stets von außen herangetragen wird, von jeher. Mir ist noch nie aufgefallen, dass intensive Beschäftigung – mit was auch immer – langweilig sein kann. Aber vielleicht ticke ich da letztlich einfach anders und verstehe unter Fun auch was andres.
Sei’s drum.
Der Beitrag Der barrierefreie Webentwickler – ein Langweiler? erschien zuerst auf sprungmarker.
]]>„WCAG 2 und die reine Textvergrößerung“ weiterlesen
Der Beitrag WCAG 2 und die reine Textvergrößerung erschien zuerst auf sprungmarker.
]]>Bevor wir uns jedoch mit der reinen Textvergrößerung beschäftigen, ist es notwendig, kurz auf die Textvergrößerung allgemein einzugehen. Auch nach dem kürzlichen Inkrafttreten der BITV 2.0 stellt sich diese Frage nicht wirklich neu, aber die Erfolgskriterien der WCAG 2.0 entsprechen im wesentlichen der BITV 2.0 zur Textvergrößerung: Veränderbare Textgröße (1.4.4 BITV Priorität I, WCAG 2.0 AA) und Visuelle Präsentation (1.4.8 BITV Priorität II, WCAG 2.0 AAA).
Die Unterscheidungen liegen im Detail – aber da Details in der Barrierefreiheit durchaus einen großen Unterschied machen können, zeige ich diese auf. Nach BITV 2.0 ist es auf Priorität I nötig, dass sich Text ohne assistive Technologie auf bis zu 200% vergrößern lässt. Wichtig dabei ist, dass inhaltlich nichts verloren geht und noch alles funktioniert. Die Frage dabei wird sein, wie definiert man Verlust? Inhaltlich ist das leichter verständlich, funktional wird es schon haariger.
Der Text lässt sich ohne assistive Technologie bis auf 200 % vergrößern, ohne dass es zu einem Verlust von Inhalt oder Funktionalität kommt.
Quelle: BITV 2.0: 1.4.4 Veränderbare Textgröße
Die WCAG 2.0 schränkt gerne ihre Erfolgskriterien weiter ein und so trifft diese Vergrößerung von Text auf 200% auf Captions und Schriftgrafiken nicht zu. Für Schriftgrafik, die man ohnehin nicht wirklich verwenden soll, ist das einleuchtend. Wird sie mit dem Page Zoom hochgezogen, wird die Grafik dadurch nicht besser und fast immer schwerer lesbar. Warum Captions etwa bei Videos nicht ebenso vergrößerbar sein sollen, ist weniger klar. Ist der Player flexibel gebaut, werden auch die Captions mit vergrößert und in HTML5 Playern skaliert beides im Page Zoom mit. Aber interessant sind die Einschränkungen allemal, weil sich die Frage stellt, ob die BITV 2.0 dann für beides eine hinreichende Vergrößerung fordert.
Ist auf dieser Stufe (WCAG 2.0 AA, BITV 2.0 Priorität 1) nun denkbar, dass mit Textvergrößerung nur der Page Zoom gemeint sein kann. Und genau hier hake ich jetzt ein und ich kann verraten: Ja, genau der Page Zoom ist auf dieser Stufe gemeint.
Das Problem mit den WCAG 2.0 ist, dass sie mitunter durchaus zu unterschiedlichen Interpretationen einlädt – jeder kann da sein eigener Exeget werden. Was dann bei so wichtigen Fragestellungen, wie denn nun mit der reinen Textvergrößerung umgehen, zu erhitzten Debatten führt. Der BITV-Test hat in seinem Artikel Textvergrößerung: warum Zoom-Vergrößerung nicht ausreicht auf diese Schwierigkeit hingewiesen, die ausführlichere englische Version hat dann einige Debatten ausgelöst.
Das Problem im Umgang mit dem WCAG 2.0 ist, dass man nicht etwa aus einem Fehlerbeispiel hochrechnen kann und den darin dargestellten Fehlerfall und seine Lösung als ausreichende Technik für das Erfolgskriterium nutzen kann. Unter verbreitete Fehler für 1.4.4. veränderbare Textgröße findet sich das Beispiel F69. Die Beispiele, die darin aufgeführt werden, sprechen dafür, dass auch die reine Textvergrößerung mit gemeint sein könnte. Beide Code-Beispiele spiegeln die Problematik wieder, dass der Text flexibel vergrößert werden kann, aber der ihn umgebende Behälter eine feste Breite und – was problematischer ist – eine feste Höhe hat.
Nutzt man den Page Zoom für diese beiden Beispielfälle, gibt es keine Probleme. Voraussetzung ist natürlich, dass der Browser diesen auch implementiert hat. Bei der reinen Textvergrößerung, die einige Browser zusätzlich anbieten, läuft der Text entweder über den Behälter hinaus und über den nächsten Text oder wird schlicht abgeschnitten. Auch das erwähnte Beispiel bei Vergrößerungen von absoluten Positionierungen kann zu diesen Problemen führen, aber weit weniger im Page Zoom. Suggeriert wird in diesen Fehlerbeispielen, dass der reine Textzoom hierbei eine tragende Rolle spielt.
Und daran hat sich auch die Debatte entfacht: an diesem Interpretationsspielraum zwischen Fehler F69 und der Aussage des Erfolgskriteriums. Der BITV-Test sieht da durchaus eine Verbindung – und es ist ja nicht von der Hand zu weisen, wenn auch nur eine implizite und keine, die über die hinreichenden Techniken weiter angesprochen wird. In den Kommentaren aus dem englischsprachigen Bereich kam daher auch sofort die Kritik, dass das eine Überinterpretation sei und man das Erfolgskriterium Textvergrößerung so verstehen sollte: Hinreichend ist es, wenn eine Seite mit Page Zoom entsprechend skaliert, aber wenn die reine Textvergrößerung genutzt wird – was von der Projektanforderung abhängig gemacht wird, dann muss auch diese funktionieren.
Wir sind dann also bei der letzten Interpretation wieder auf dem Level des IE 6 angekommen – wenn der Kunde eine reine Textvergrößerung für sein Projekt wünscht, dann wird zum Standard – Page Zoom – auch noch die reine Textvergrößerung optimiert. Durchaus ein Standpunkt – und wenn ich mal unken darf – einer, der sich durchsetzen wird.
Auf Level AAA und Priorität 2 stimmen WCAG 2.0 und BITV 2.0 hinsichtlich Textvergrößerung überein:
der Text kann im Vollbildmodus ohne assistive Technologie bis auf 200 % vergrößert werden, ohne dass die Nutzerinnen oder Nutzer eine Textzeile horizontal scrollen müssen.
Quelle: BITV 2.0 – 1.4.9 Visuelle Präsentation
Auf Level AAA und Priorität 2 kommen also folgende Bedingungen hinzu: der Vollbildmodus und dass bei 200% nicht horizontal gescrollt wird. Vollbildmodus meint die jeweils aktuelle Standardauflösung des Browsers (ich würde das heute nicht mehr nur auf den Desktop reduzieren wollen). Interessanterweise wird das Erfolgskriterium 1.4.9 Visuelle Präsentation nur auf Desktop- und Laptop-Browser angewendet.
Das horizontale Scrollen ist nur pro Zeile zu verstehen und wird nicht auf mehrspaltiges Layout bezogen. Ist der Hauptbereich im sichtbaren und lesbaren Bereich ohne Scrollen, ist das hinreichend. Für den Seitenbereich scrollt man dann horizontal nach rechts und liest dort innerhalb des sichtbaren Bereichs. Das ist eine wichtiger Punkt, weil man daran gut erkennen kann, dass es auch hier hauptsächlich um den Page Zoom geht.
Freilich finden sich auf diesem Level dann mehr ausreichende Techniken, die nicht nur den Text sondern auch das ihn umgebende Layout flexibler machen wie etwa Erfolgskriterium G146 liquides Layout. Zwingend dazu muss jedoch noch eine weitere flexible Technik dazu kombiniert werden wie Schriftgröße in Prozenten (C12).
Man kann deutlich den Anforderungsanstieg von AA auf AAA für die Textvergrößerung erkennen. Auf AA kann man noch wählen zwischen:
Man hat also auf AA noch die Wahl, kann jedoch ebenso schon auf ein liquides, flexibles Layout setzen.
Auf Level AAA hat man dann im Grunde nur noch die Option des liquiden Layouts (G146) oder man hat einzelne Bereiche oder Seiten, die horizontal scrollen müssen wie etwa Diagramme (C26). Diese Einzelseiten versieht man dann mit einem Layout-Switcher, um zwischen dem liquiden Standardlayout und dem Layout, das horizontal scrollt, zu wechseln.
Die Fehlerbeispiele aus Level AA F69 würden dann auch besser für AAA passen, wenn es darum geht, sowohl Text als ihn umgebendes Layout flexibel zu halten.
Geht es um die Flexibilität der Textvergrößerung findet sich diese als eine von mehreren Optionen auf Level AA, auf AAA ist sie unumgänglich, will man ein komplexeres Layout als den Beispiel-Zweispalter wirklich lesbar halten auf 200% Vergrößerung. Der Page Zoom ist da dann auch nur noch sehr bedingt eine nutzbare Option, wenn der jeweils fokussierte Lesebereich pro Zeile ohne horizontales Scrollen klappen soll.
Insofern wird auf Level AA letztlich nur der Page Zoom gefordert, aber es überlässt dem Entwickler oder dem Entscheider, welche ausreichende Technik gewählt wird. Das lässt sich ja an den Überscheidungen der Techniken ablesen, auch wenn für AAA der Page Zoom dann nicht mehr reichen wird.
Detlev Fischer vom BITV-Test hat diese Debatte um die reine Textvergrößerung an die WAI weitergetragen und einen Konflikt gemeldet (Comment LC-2513). Vor einigen Tagen kam von der WAI die Antwort, dass das Fehlerbeispiel F69 nicht nur auf die reine Textvergrößerung bezogen sei sondern auch auf den Page Zoom. Der Fehler beziehe sich auf beides. Sie werden daher ein weiteres Beispiel für einen Fehler mit Page Zoom zur Verfügung stellen. Aber: Für die Erfüllung des Erfolgskriterium sei der Page Zoom ausreichend.
Ich denke, es ist nicht wirklich sinnvoll, die reine Textvergrößerung vom Page Zoom zu separieren. Beides kann, wie man in Hellbusch / Probiesch Barrierefreiheit verstehen und umsetzen in Beispielen nachlesen kann, durchaus auch kombiniert werden. Spätestens dann wird es für beide Zoom-Techniken eng bei zu wenig Flexibilität.
Und mit unseren aktuellen Layout- und Contenttechniken wie Mobile First oder Responsive Web Design und CSS Flexible Box Layout Module findet ohnehin eine Renaissance des Flexiblen statt. Sich dabei noch mit dem Desktop-Modell aufzuhalten, ein fixes Layout mit x-fachen Media Queries für x-Auflösungen zu stützen, dass der Page Zoom dann irgendwie schon noch überall passt und man dann irgendwie Level AA erreicht hat, das kann es letztlich nicht sein, das ist weder aktuell robust noch nach vorne stabil.
Mag auch die reine Textvergrößerung nicht mehr wirklich im barrierefreien Debatten-Fokus bleiben, kann sie einfach mal so nebenbei schlicht in die Flexibilität mitgenommen werden. Sicherlich gibt es in der Kombination unterschiedlicher Browser, Media Queries und der reinen Textvergrößerung ein paar Aha-Erlebnisse, aber mehr als ein kurze Lernphase ist nicht nötig, um diese Zoom-Option flexibel zu gestalten und zu integrieren.
Klar – für den BITV-Test stellt sich tatsächlich die Frage, ob der Prüfschritt 1.4.4.a Schriftgröße variabel wirklich in dieser Form beibehalten werden kann bzw. wie die Prüfung auf Level AA und Priorität da aussehen kann.
Und letztlich ist die Debatte Page Zoom versus einfache Textvergrößerung eine irreführende. Es geht darum, wie flexibel lege ich Inhalt und Layout für aktuelle und zukünftige Ausgaben an. Der Page Zoom unterstützt fix und flexibel, die reine Textvergrößerung auch. Die Frage ist dabei nur, wie gut les- und nutzbar ist das Ergebnis.
Heute liest man eine erneute Antwort in der WAI Liste zum Thema Erfolgskriterium 1.4.4 von Gregg Vanderheiden, der wohl aus WAI-Sicht argumentiert: Es würde vom Layout der Seite abhängen, ob der Page Zoom nicht auch für AAA – also Erfolgskriterium 1.4.8 – hinreichen kann, wenn der Hauptbereich jeweils lesbar bleibt ohne horizontales Scrollen.
Der Beitrag WCAG 2 und die reine Textvergrößerung erschien zuerst auf sprungmarker.
]]>„Was ist mit cufón, typeface.js oder lettering.js?“ weiterlesen
Der Beitrag Was ist mit cufón, typeface.js oder lettering.js? erschien zuerst auf sprungmarker.
]]>Schriftersetzung ist noch immer aktuell, wenn es sich um Lizenz- oder Darstellungsfragen dreht. Leider möchte man aus mehreren Gründen sagen: Zum einen sind mit dem verstärkten Einsatz von font-face
alternative Schriftersetzungs-Lösungen fast obsolet geworden und, entwickelt man im Hinblick auf Barrierefreiheit, waren diese alternativen Lösungen nie wirklich eine Option.
War früher in Sachen Schriftersetzung sIFR Marktführer, übernahmen später Javaskript-basierte Lösungen die Führung. Die bekanntesten sehen wir uns nun im Hinblick auf Barrierefreiheit genauer an: cufón, typeface.js und eine Methode der Schriftmanipulation – lettering.js.
Im BIK-Test des Monats März 2011 spielt die Schriftersetzung mit Hilfe von cufón eine nicht unbedeutende Rolle: Das Bundesministerium für Gesundheit setzt in großen Teilen auf diese Schriftersetzung, setzte muss man nun sagen. Das problematische Testergebnis, am dem cufón einen nicht unbeträchtlichen Anteil hat, scheint Wirkung gezeigt zu haben. Es befinden sich zwar noch Code-Reste mit dem Verweis auf cufón im Quellcode oder in Skripten, aber cufón erzeugt keine Ersetzung mit Hilfe des canvas
-Elements mehr.
Damit sind wir schon beim technischen Stichwort: Sowohl cufón als auch typeface.js nutzen die Möglichkeiten des Browsers, Vektorgrafiken zu rendern. Die Ausgangsschrift wird mit Hilfe eines Konverters in eine Javaskript-Datei umgewandelt. Der Browser stellt den Text dann entsprechend seiner Möglichkeiten mit Hilfe des canvas
-Elements oder als Internet Explorer vor Version 9 als VML dar.
Bei lettering.js liegt der Fall etwas anders: Hier wird mit Hilfe von Javaskript um jeden Buchstaben eines Wortes ein span
-Element gesetzt, damit man jeden Buchstaben per CSS einzeln manipulieren kann. Dieses Verfahren kann man auch auf größere Einheiten ausweiten, etwa einzelne Wörter manipulieren oder ganze Zeilen. Hier handelt es sich auch nicht um eine Schriftersetzung, sondern um eine -manipulation.
Sicherlich sind die beiden Schriftersetzungsmethoden im Vergleich etwa zu sIFR ein Gewinn gewesen. Lange gab es zur Darstellung von sIFR kaum Alternativen. Freilich blieb die Lizenzfrage die gleiche, längst haben die Schriftenhersteller in ihren EULAs nachgezogen und legen die Lizenzen auch explizit für sIFR oder cufón fest. Wie für sIFR gilt, sieht man sich die Barrierefreiheit solcher Lösungen an, kann es ganz schnell unschön werden.
Wir sehen uns daher alle drei Methoden unter folgendem barrierefreien Blickwinkel an:
Für den Test haben wir einen einfachen Text ausgewählt: eine Überschrift und einen Absatz.
<h1>
Überall dieselbe alte Leier.</h1>
<p>
Das Layout ist fertig, <a href=”https://sprungmarker.de” title=”weiter zum sprungmarker Projekt”>der Text</a> lässt auf sich warten. Damit das Layout nun nicht nackt im Raume steht und sich klein und leer vorkommt, springe ich ein: der Blindtext.</p>
Nur bei typeface.js wird die Überschrift durch einen Absatz ersetzt, da keine Überschriften unterstützt werden – zumindest keine semantischen Überschriften. Die Webseite von typeface.js arbeitet mit visuellen Überschriften, die aber nur mit Hilfe von div-Elementen und CSS hergestellt sind. Im Grunde hat sich typeface.js damit schon für eine weitere barrierefreie Prüfung disqualifiziert.
Der Beitrag Was ist mit cufón, typeface.js oder lettering.js? erschien zuerst auf sprungmarker.
]]>„Accessible child themes: Updates“ weiterlesen
Der Beitrag Accessible child themes: Updates erschien zuerst auf sprungmarker.
]]>That’s why I now can offer a more solid update of Accessible TwentyTen – an accessible child theme for Twenty Ten. There is not much really new, but I refurbished some aspects as author info and some content parts. Also functions.php is renewed to get it better prepared for child theme developers who want to work with my child theme.
Richard Shepherd gets Twenty Ten running with real HTML5 semantics. His project TwentyTen Five is a work in progress, you can find it on github. This is a really good effort and I appreciate this project. But as Twenty Ten it has the same accessibility issues. So I updated my accessible child theme for Twenty Ten Five: Accessible Five.
I notified Richard Shepherd about some accessibility issues which should be solved in the main theme TwentyTen Five and hope he will solve them in a future release.
Der Beitrag Accessible child themes: Updates erschien zuerst auf sprungmarker.
]]>„WordPress Child Theme for TwentyTenFive: Accessible Five“ weiterlesen
Der Beitrag WordPress Child Theme for TwentyTenFive: Accessible Five erschien zuerst auf sprungmarker.
]]>WordPress 3.0 got a new default theme: Twenty Ten. It’s doctype is yet HTML5, but the rest is still old XHTML. This is where TwentyTenFive get’s into. It’s mission is to get Twenty Ten upgraded to HTML5.
This is indeed a real improvement, but still has the same accessibility issues as Twenty Ten, e.g. not enough contrast in colors, few improvements for keyboard users and you get no real information about user’s location within a web page.
So I decided to upgrade my child theme project Accessible 1.0 to get it running with TwentyTenFive. This was at all quite easy because TwentyTenFive reuses most of the Twenty Ten stuff in CSS.
And it’s the same procedure: You get all functionality of TwentyTenFive plus accessible features of the child theme. That’s a nice deal. :)
And: the child theme uses no templates, only a css file and some programming in functions.php. That’s all. Accessible Five should only be a small accessible enhancement.
Accessible Five is equipped with features as:
Optional you can install MCE Accessible Language Change for WordPress editor TinyMCE to get button for adding language change in your content. Accessible Five supports this plugin and some more plugins are to come. Accessibility in WordPress is a more complex process, you have to get more accessible than your theme, e.g. many aspects of TinyMCE, plugins and widgets. I am working on it. :)
Currently you can see on this website Accessible Five in action. Just use this site only with keyboard and check the visible focus, use the skip links and enjoy the better contrast.
1.0 – first release
No upgrades right now.
Accessible Five as a zip file (45 Kb)
Der Beitrag WordPress Child Theme for TwentyTenFive: Accessible Five erschien zuerst auf sprungmarker.
]]>Der Beitrag Accessible WordPress erschien zuerst auf sprungmarker.
]]>Dort wird es dann auch alle weiteren Updates und Informationen zu meinen bisherigen Entwicklungen Accessible 1.0 und dem Plugin MCE Accessible Language Change geben. Die Projektumgebung ist dann sowohl Vorschau für Themes als auch Testumgebung – vor allem mit der neusten Entwicklungsversion von WordPress.
Um mit dem Thema schlicht mehr Leute zu erreichen, versuche ich mich mal im konsequenten Englisch – was mir jetzt nicht leicht fällt, ich spüre schon, dass das noch etwas hakelig läuft – aber ich werde mich schon improven. ;)
Damit wird auch sprungmarker.de wieder frei von Twenty Ten werden – dem Default-Theme von WordPress. Ich finde es weder sonderlich ästhetisch in Aussehen und Codequalität, noch halte ich es für innovativ. Nun heisst es die HTML 5 Kenntnisse mobilisieren und endlich was Schickes hier bauen – da freu ich mich richtig drauf.
Der Beitrag Accessible WordPress erschien zuerst auf sprungmarker.
]]>„WordPress 3.1 Release Candidate – Compatibility“ weiterlesen
Der Beitrag WordPress 3.1 Release Candidate – Compatibility erschien zuerst auf sprungmarker.
]]>I tested Accessible 1.0 – the WordPress child theme – and MCE Accessible Language Change – both are working with the current developer release 3.1.
Der Beitrag WordPress 3.1 Release Candidate – Compatibility erschien zuerst auf sprungmarker.
]]>„WordPress: Accessibility as a patch is not a good strategy“ weiterlesen
Der Beitrag WordPress: Accessibility as a patch is not a good strategy erschien zuerst auf sprungmarker.
]]>But I followed the development of Twenty Ten in WordPress Core a lot and got the impression that it is not so easy to get Twenty Ten more and more accessible. There is a kind of effort there to get accessibility forward but it takes a lot of time. Even small improvements as the skip link which is not reachable for keyboard users is somewhere in the developing pipeline – in a future release.That’s why I made Accessible 1.0 – to make Twenty Ten more accessible and can be used as long as the developing process in WordPress trunk is running. And the answers to our merging request are not really promising.
I would dearly love to see accessibility given a much higher profile but that’s not happened so far (and not for lack of trying). The whole subject – whilst generally popular superficially – is one that people do seem to have problems getting to grips with when it gets down to implementation. There are also so many other issues vying for attention that accessibility doesn’t seem to be able to hold anyone’s attention for any length of ti…oooh .. shiny jQuery thingy! ;-)
Eventually there will be a kind of WP-access group which will discuss WordPress accessibility issues and working on accessibility patches. Of course this would be a great improvement to get accessibility running. I am the first to discuss this issues there.
But I think to handle accessibility as a patch is not a good strategy. Accessibility as a patch will always be a loose end.
Der Beitrag WordPress: Accessibility as a patch is not a good strategy erschien zuerst auf sprungmarker.
]]>„WordPress Editor Plugin: MCE Accessible Language Change“ weiterlesen
Der Beitrag WordPress Editor Plugin: MCE Accessible Language Change erschien zuerst auf sprungmarker.
]]>One thing I always missed in WordPress editor TinyMCE is to add language change. So I made my first plugin. :) This was somehow hard because it’s not only to get a plugin in WordPress running, you also have to get into programming with TinyMCE. So keep in mind when you use the plugin, I am a novice …
The Plugin MCE Accessible Language Change – now in the WordPress Plugin directory – adds two buttons to the editor: one for changing the language of a word or phrase within a span
element and one for changing or adding the language of already existing block elements as paragraphs or headlines. Furthermore you can add the target language to a link:
span
elementTo change the language of a word or phrase, just select the word or phrase, klick on the button LANG and fill in the language adequate code, e.g. for a word or phrase in french fr. If you have to be If you need to be XHTML compliant, just fill in the language code again. You can modify of delete your entry at any time. Language change is highlighted in the editor, but not on the website.
You can add language change to existing HTML elements as paragraph or headlines. To add or edit the language of a e.g. a paragraph, just klick in the paragraph and on the button LANG ATTR and fill in the language code (e.g. for a french word or phrase fr) . If you need to be XHTML compliant, just fill in the language code again. You can modify of delete your entries at any time. To delete your entries, just empty the fields. If you need to add the target language to a link, just mark the link text and add the target language
If your link target is in a different language, you can add a target language to the link. Just klick in the link and on the button LANG ATTR and fill in the language code for the target language. You can modify of delete your entry at any time. To delete your entry, just empty the field.
The plugin is localized for english and german, please let me know if you would like additional localizations added.
Requirements: WordPress 3.0 and above
Tested up to: WordPress 3.3 on all modern browsers als IE 7/8, Safari, Chrome, Firefox and Opera (Windows, Mac)
TinyMCE is not yet running with IE 9.
Version: 1.1
Licence: GNU General Public License v2.0
Hoping to add more features in future updates, e.g. backwards compatibility.
span[lang],
.lang {
background: #f8f8f8;
border: 1px solid #d2d0ce;
padding: 2px;
1.0 – first release
* Minor changes renaming files according to the name of zip file
1.1
* Path correction for TinyMCE
1.1
* Path correction for TinyMCE
MCE Accessible Language Change in WordPress Plugin Directory
Der Beitrag WordPress Editor Plugin: MCE Accessible Language Change erschien zuerst auf sprungmarker.
]]>„Accessible 1.0 in the wild …“ weiterlesen
Der Beitrag Accessible 1.0 in the wild … erschien zuerst auf sprungmarker.
]]>Der Beitrag Accessible 1.0 in the wild … erschien zuerst auf sprungmarker.
]]>„Accessible 1.0 – Showroom“ weiterlesen
Der Beitrag Accessible 1.0 – Showroom erschien zuerst auf sprungmarker.
]]>It is interesting to see the child theme running in the wild and real action. Good examples to get the real edges of the theme.
Der Beitrag Accessible 1.0 – Showroom erschien zuerst auf sprungmarker.
]]>„WordPress Child Theme for Twenty Ten: Accessible TwentyTen“ weiterlesen
Der Beitrag WordPress Child Theme for Twenty Ten: Accessible TwentyTen erschien zuerst auf sprungmarker.
]]>WordPress 3.0 came out with a new default theme: Twenty Ten. The theme is compared to Kubrick an improvement, but still has mostly the same accessibility issues as its forerunner, e.g. not enough contrast in colors, few improvements for keyboard users and you get no real information about user’s location within a web page.
This is where Accessible TwentyTen get’s into: a child theme for the default theme Twenty Ten to get the parent theme more accessible. You get all functionality of Twenty Ten plus accessible features of the child theme. That’s a nice deal. :)
And: the child theme uses no templates, only a css file and some programming in functions.php. That’s all. Accessible TwentyTen should only be a small accessible enhancement.
Accessible TwentyTen is equipped with features as:
Optional you can install MCE Accessible Language Change for WordPress editor TinyMCE to get button for adding language change in your content. Accessible TwentyTen supports this plugin and some more plugins are to come. Accessibility in WordPress is a more complex process, you have to get more accessible than your theme, e.g. many aspects of TinyMCE, plugins and widgets. I am working on it. :)
Just use this site only with keyboard and check the visible focus, use the skip links and enjoy the better contrast.
1.0 – first release
2.0 – Minor updates and improved functions.php such as better tab focus for author info, paging and sticky entry, better contrast for data table and image caption, finally for development purposes functions in functions.php are consolidated to get it easier for other developer to overwrite functions …
Accessible TwentyTen as a zip file (45 Kb)
Der Beitrag WordPress Child Theme for Twenty Ten: Accessible TwentyTen erschien zuerst auf sprungmarker.
]]>