sprungmarker https://sprungmarker.de accessibility is fun Wed, 23 May 2018 21:02:18 +0000 de-DE hourly 1 Blue Beanie Day 2014 – Twitter Liste https://sprungmarker.de/2014/blue-beanie-day-2014/ Sun, 30 Nov 2014 11:53:34 +0000 http://sprungmarker.de/?p=2225 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 …

Der Beitrag Blue Beanie Day 2014 – Twitter Liste erschien zuerst auf sprungmarker.

]]>
Blue Beanie Day - Avatar
Blue Beanie Day – Avatar

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 https://sprungmarker.de/2014/html-5-semantik-ein-blick-auf-den-blue-beanie-day/ https://sprungmarker.de/2014/html-5-semantik-ein-blick-auf-den-blue-beanie-day/#comments Sat, 29 Nov 2014 17:00:40 +0000 http://sprungmarker.de/?p=2201 Anlässlich des alljährlichen Blue Beanie Day  – am 30. November – bat mich Robert Lender, ihm 2 Fragen zu beantworten: Wie beurteile ich HTML 5 (Vorteile / Nachteile)? Ist HTML 5 auch förderlich für die Barrierefreiheit im Web? Aufgrund von HTML 5 als W3C Recommendation bietet sich ein Rückblick auf nun schon fast ein Jahrzehnt …

Der Beitrag HTML 5 Semantik – ein Blick auf den Blue Beanie Day erschien zuerst auf sprungmarker.

]]>
Anlässlich des alljährlichen Blue Beanie Day  – am 30. November – bat mich Robert Lender, ihm 2 Fragen zu beantworten:

  • Wie beurteile ich HTML 5 (Vorteile / Nachteile)?
  • Ist HTML 5 auch förderlich für die Barrierefreiheit im Web?

Aufgrund von HTML 5 als W3C Recommendation bietet sich ein Rückblick auf nun schon fast ein Jahrzehnt HTML 5 Entwicklung an. 

Wie beurteile ich HTML5 (Vorteile / Nachteile)

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.

Ist HTML 5 auch förderlich für die Barrierefreiheit im Web?

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.

]]>
https://sprungmarker.de/2014/html-5-semantik-ein-blick-auf-den-blue-beanie-day/feed/ 3
Opera goes Webkit und verliert an Barrierefreiheit https://sprungmarker.de/2013/opera-webkit-und-verliert-barrierefreiheit/ https://sprungmarker.de/2013/opera-webkit-und-verliert-barrierefreiheit/#comments Tue, 02 Jul 2013 22:39:07 +0000 http://sprungmarker.de/?p=1992 Man würde ja meinen, hat ein Browser einmal einen guten Stand an Barrierefreiheit erreicht, dann kann es nur noch optimaler werden. Dem ist nicht so – wie man an der aktuellen Version 15 von Opera mit der Webkit-Engine sehen kann. Fritz Weisshart wies mich dankenswerter Weise darauf hin, dass das HTML5 Video-Element in der aktuellen Opera …

Der Beitrag Opera goes Webkit und verliert an Barrierefreiheit erschien zuerst auf sprungmarker.

]]>
Man würde ja meinen, hat ein Browser einmal einen guten Stand an Barrierefreiheit erreicht, dann kann es nur noch optimaler werden. Dem ist nicht so – wie man an der aktuellen Version 15 von Opera mit der Webkit-Engine sehen kann.

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.

]]>
https://sprungmarker.de/2013/opera-webkit-und-verliert-barrierefreiheit/feed/ 2
Recap of Mobilism 2013 https://sprungmarker.de/2013/mobilism2013/ Thu, 06 Jun 2013 20:49:00 +0000 http://sprungmarker.de/?p=1959 Last month I attended Mobilism 2013 in Amsterdam – a really awesome conference about mobile web design. My first Mobilism in 2011 was a real starting point for Responsive Web Design (RWD) and Mobile First to me and I was excited which topics will win this year. There is full coverage at mobilsm website, video …

Der Beitrag Recap of Mobilism 2013 erschien zuerst auf sprungmarker.

]]>
Last month I attended Mobilism 2013 in Amsterdam – a really awesome conference about mobile web design. My first Mobilism in 2011 was a real starting point for Responsive Web Design (RWD) and Mobile First to me and I was excited which topics will win this year. There is full coverage at mobilsm website, video recordings will follow soon.

The most important topics and starting points for me this year are:

  • RWD workflow between design and development
  • Performance optimization and checking browser repaints
  • Working with and for console browsers

Following talks are summarized:

The New Photoshop, Part 2: The Revenge of the Web – Stephen Hay

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:

  • for layout and grid we use Susy,
  • SASS as preprocessor and
  • a static site generator like Jekyll or Hyde.

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.

Rendering without lumpy bits – Jake Archibald

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.

Responsible Responsive Images – Mat Marquis

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.

Console Browsers: The Ultimate Torture Test – Anna Debenham

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:

  • second screen
  • voice
  • stylus
  • gesture
  • d-pad.

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.

Summary

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.

]]>
Review: 2012 https://sprungmarker.de/2013/review_12/ Sat, 05 Jan 2013 17:25:03 +0000 http://sprungmarker.de/?p=1890 Von Reviews halt ich wenig, weil ich mich nicht immer selbst wieder spiegeln möchte. Aber es gab schon etwas Aufregendes im letzten Jahr – mein Wechsel in eine neue Agentur und in die 5-Tage-Woche. Das letzte halbe Jahr ist daher eher an mir vorbei gerauscht, vor allem die Restzeit – genannt Freizeit. Zu wenig Zeit …

Der Beitrag Review: 2012 erschien zuerst auf sprungmarker.

]]>
Von Reviews halt ich wenig, weil ich mich nicht immer selbst wieder spiegeln möchte. Aber es gab schon etwas Aufregendes im letzten Jahr – mein Wechsel in eine neue Agentur und in die 5-Tage-Woche. Das letzte halbe Jahr ist daher eher an mir vorbei gerauscht, vor allem die Restzeit – genannt Freizeit. Zu wenig Zeit für private Projekte.

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 https://sprungmarker.de/2012/re_wie_tot_ist_die_biene/ https://sprungmarker.de/2012/re_wie_tot_ist_die_biene/#comments Mon, 28 May 2012 22:59:52 +0000 http://sprungmarker.de/?p=1873 Wie und ob die Barrierefreiheit im Web tot ist, ist noch nicht geklärt, schon spitzt BIZEPS die Frage konkreter zu: Wie tot ist die BIENE? Man könnte jetzt sagen, neben dem möglichen Todsein steht vor allem das Warten auf etwas im Vordergrund, wenn man sich mit dem Thema Barrierefreiheit im Web beschäftigt. Nach dem jahrelangen …

Der Beitrag Re: Wie tot ist die BIENE erschien zuerst auf sprungmarker.

]]>
Wie und ob die Barrierefreiheit im Web tot ist, ist noch nicht geklärt, schon spitzt BIZEPS die Frage konkreter zu: Wie tot ist die BIENE? Man könnte jetzt sagen, neben dem möglichen Todsein steht vor allem das Warten auf etwas im Vordergrund, wenn man sich mit dem Thema Barrierefreiheit im Web beschäftigt.

honey - Schriftzug aus zerlaufenem Zucker

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.

]]>
https://sprungmarker.de/2012/re_wie_tot_ist_die_biene/feed/ 7
Re: Ist die Barrierefreiheit tot? https://sprungmarker.de/2012/barrierefreiheit_tot/ https://sprungmarker.de/2012/barrierefreiheit_tot/#comments Mon, 28 May 2012 14:14:32 +0000 http://sprungmarker.de/?p=1867 Wolfgang Wiese hat eine wichtige Frage gestellt: Ist die Barrierefreiheit tot?. Ganz abgesehen davon, ob diese Frage klar beantwortet werden kann, schließt sich an, warum stellen wir zum Thema Barrierefreiheit immer wieder die gleichen Fragen. Man könnte jetzt mit so voll- bzw. volksmundigen Antworten beginnen, wie Totgesagte leben ohnehin immer länger oder derzeit sind Zombies …

Der Beitrag Re: Ist die Barrierefreiheit tot? erschien zuerst auf sprungmarker.

]]>
Wolfgang Wiese hat eine wichtige Frage gestellt: Ist die Barrierefreiheit tot?. Ganz abgesehen davon, ob diese Frage klar beantwortet werden kann, schließt sich an, warum stellen wir zum Thema Barrierefreiheit immer wieder die gleichen Fragen.

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.

Barrierefreiheit ist zur Routine geworden

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.

Barrierefreiheit ist nicht zur Routine geworden

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.

Barrierefreiheit ohne Szene geht das überhaupt?

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.

Update

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.

]]>
https://sprungmarker.de/2012/barrierefreiheit_tot/feed/ 14
HTML5 Medien und ihre Tastaturbedienbarkeit https://sprungmarker.de/2011/html5-medien-und-ihre-tastaturbedienbarkeit/ https://sprungmarker.de/2011/html5-medien-und-ihre-tastaturbedienbarkeit/#comments Sun, 04 Dec 2011 21:10:16 +0000 http://sprungmarker.de/?p=1850 Nachträglich zum 5. Internationalen Tag der Tastatur und den Blue Beanie Day 2011 – vielen Dank an Robert Lender für sein beständiges Engagement in diesen Themen! – habe ich mich etwas ausführlicher mit den HTML5 Medien Elementen Audio und Video beschäftigt: Wie tastaturbedienbar sind sie in der Standardkonfiguration wirklich? HTML5 Audio Steuerelemente: Opera, Chrome, Safari, …

Der Beitrag HTML5 Medien und ihre Tastaturbedienbarkeit erschien zuerst auf sprungmarker.

]]>
Nachträglich zum 5. Internationalen Tag der Tastatur und den Blue Beanie Day 2011 – vielen Dank an Robert Lender für sein beständiges Engagement in diesen Themen! – habe ich mich etwas ausführlicher mit den HTML5 Medien Elementen Audio und Video beschäftigt: Wie tastaturbedienbar sind sie in der Standardkonfiguration wirklich?

Screenshot: HTML 5 Audio - Steuerelemente pro Browser
HTML5 Audio Steuerelemente: Opera, Chrome, Safari, Firefox, IE 9 (von oben)

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:

Die Standardkonfiguration

Screenshot: HTML5 Video - Steuerelemente pro Browser
HTML5 Video Steuerelemente: Opera, Chrome, Safari, Firefox, IE 9 (von oben)

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.

Ist Video und Audio generell mit Tastatur erreichbar?

Screenshot: Video Kontextmenü Firefox
HTML5 Video Kontextmenü – Firefox

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.

Welche Elemente der Steuerung sind mit Tastatur bedienbar?

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.

Screenshot: Audio Kontextmenü Chrome
HTML5 Audio Kontextmenü – Chrome

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.

Wie steht es um den Tastaturfokus?

Screenshot: HTML Steuerelement mit Fokushervorhebung
HTML5 Medien – Fokushervorhebung in IE 9 und Opera (von oben)

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.

Das Kontextmenü: das Schweizer-Messer der Medien-Elemente

Screenshot: Kontextmenü Opera Video
HTML5 Video Kontextmenü – Opera

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. :)

Da geht noch mehr!

Screenshot: IE 9 Kontextmenü Audio
HTML5 Audio Kontextmenü – IE 9

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.

]]>
https://sprungmarker.de/2011/html5-medien-und-ihre-tastaturbedienbarkeit/feed/ 18
Der barrierefreie Webentwickler – ein Langweiler? https://sprungmarker.de/2011/der-barrierefreie-webentwickler-ein-langweiler/ https://sprungmarker.de/2011/der-barrierefreie-webentwickler-ein-langweiler/#comments Tue, 01 Nov 2011 21:21:53 +0000 http://sprungmarker.de/?p=1840 Es ist immer wieder interessant, in und um die barrierefreie Entwicklerszene zu publizieren, da argumentiert es und möglichst kurz knapp, schließlich wissen wir ja alle: Barrierefreiheit so als ständiges Thema – das nervt doch nur! So findet Nico Brünjes in seiner Leselinks auf der Flucht zu meinem Artikel in Sachen reine Textvergrößerung und WCAG 2.0 …

Der Beitrag Der barrierefreie Webentwickler – ein Langweiler? erschien zuerst auf sprungmarker.

]]>
Es ist immer wieder interessant, in und um die barrierefreie Entwicklerszene zu publizieren, da argumentiert es und möglichst kurz knapp, schließlich wissen wir ja alle: Barrierefreiheit so als ständiges Thema – das nervt doch nur!

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.

]]>
https://sprungmarker.de/2011/der-barrierefreie-webentwickler-ein-langweiler/feed/ 4
WCAG 2 und die reine Textvergrößerung https://sprungmarker.de/2011/wcag-2-und-die-reine-textvergroserung/ https://sprungmarker.de/2011/wcag-2-und-die-reine-textvergroserung/#comments Mon, 31 Oct 2011 18:05:54 +0000 http://sprungmarker.de/?p=1789 Manche Themen flammen kurz in Artikeln und Kommentaren auf, aber letztlich fragt sich der barrierefreie Entwickler, ob er jetzt genug an der Hand hat, um Empfehlungen und Entscheidungen abgeben zu können. Ein Thema, das jüngst kurz in der Debatte war und gerade wieder ist, ist die reine Textvergrößerung. Die Frage dabei ist, setzt die WCAG 2.0 …

Der Beitrag WCAG 2 und die reine Textvergrößerung erschien zuerst auf sprungmarker.

]]>
Manche Themen flammen kurz in Artikeln und Kommentaren auf, aber letztlich fragt sich der barrierefreie Entwickler, ob er jetzt genug an der Hand hat, um Empfehlungen und Entscheidungen abgeben zu können. Ein Thema, das jüngst kurz in der Debatte war und gerade wieder ist, ist die reine Textvergrößerung. Die Frage dabei ist, setzt die WCAG 2.0 noch auf die reine Textvergrößerung oder ist die Vergrößerung der gesamten Seite mit Hilfe des Page Zooms hinreichend.

WCAG 2.0 und BITV 2.0: Textvergrößerung im Vergleich

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).

Screenshot Einstellung reine Textvergrößerung im IE 9
Auswahl reine Textvergrößerung IE9

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.

Textvergrößerung = Page Zoom?

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.

Screenshot Auswahl der reinen Textvergrößerung in Firefox
Auswahl reine Textvergrößerung Firefox

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.

Screenshot Auswahl reine Textvergrößerung in den Einstellungen von Chrome
Auswahl reine Textvergrößerung Chrome

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.

Reine Textvergrößerung = Level AAA und Priorität 2?

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.

Screenshot Auswahl reine Textvergrößerung in Safari
Auswahl reine Textvergrößerung Safari

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 unterstützt nur den bestehenden Page Zoom (G142)
  • man macht sowohl Schriftgröße als auch sie umgebende Layoutcontainer flexibel (Hier findet man auch schon die Option für Liquides Layout – G146)
  • man kann einen Text-Switcher einbauen, der unterschiedliche Vergrößerungen zulässt (G178)
  • G179 scheint sehr ähnlich G146.

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.

Screenshot Auswahl Page Zoom in den Einstellungen von Opera
Auswahl Page Zoom Opera mit Option “an Breite anpassen”

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.

Wir befinden uns bereits auf Level AA in flexiblen Zeiten

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.

Screenshot Auswahl reine Textvergrößerung in Camino
Auswahl reine Textvergrößerung Camino

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.

Screenshot Auswahl reine Textvergrößerung in OmniWeb
Auswahl reine Textvergrößerung OmniWeb

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.

Skurriles Update zum Schluss: Page Zoom reicht auch auf AAA?

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.

]]>
https://sprungmarker.de/2011/wcag-2-und-die-reine-textvergroserung/feed/ 25
Was ist mit cufón, typeface.js oder lettering.js? https://sprungmarker.de/2011/was-ist-mit-cufon-typeface-js-oder-lettering-js/ https://sprungmarker.de/2011/was-ist-mit-cufon-typeface-js-oder-lettering-js/#comments Sat, 09 Apr 2011 21:05:38 +0000 http://sprungmarker.de/?p=1665 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, …

Der Beitrag Was ist mit cufón, typeface.js oder lettering.js? erschien zuerst auf sprungmarker.

]]>
Schriftmanipulation lettering.js
Screenshot: Schriftmanipulation lettering.js - Vorlage

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.

Technik

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.

Vorlage Schriftersetzung Cufon
Screenshot Schriftersetzung Vorlage Cufon

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.

Barrierefreiheit

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:

  • Kommen Screenreader damit klar?
  • Wie sieht es mit der Skalierbarkeit aus?
  • Was passiert im Kontrastmodus oder bei benutzerdefinierten Farben?
  • Der ewige Knackpunkt all dieser Techniken: Verlinkungen

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>

Schriftersetzung Vorlage typeface.js
Screenshot Schriftersetzung Vorlage typeface.js

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.

]]>
https://sprungmarker.de/2011/was-ist-mit-cufon-typeface-js-oder-lettering-js/feed/ 1
Accessible child themes: Updates https://sprungmarker.de/2011/accessible-child-themes-updates/ Sun, 03 Apr 2011 15:10:06 +0000 http://sprungmarker.de/?p=120 I got somehow more professionalized in developing themes. There is now a development host running for my accessible child themes. WordPress provides a database for theme developers. So a developer can check a theme with standardized data to get all aspects of a WordPress theme running. That’s why I now can offer a more solid …

Der Beitrag Accessible child themes: Updates erschien zuerst auf sprungmarker.

]]>
I got somehow more professionalized in developing themes. There is now a development host running for my accessible child themes. WordPress provides a database for theme developers. So a developer can check a theme with standardized data to get all aspects of a WordPress theme running.

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 https://sprungmarker.de/2011/accessible-five/ https://sprungmarker.de/2011/accessible-five/#comments Sun, 03 Apr 2011 11:55:33 +0000 http://sprungmarker.de/?p=93 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 …

Der Beitrag WordPress Child Theme for TwentyTenFive: Accessible Five erschien zuerst auf sprungmarker.

]]>
Screenshot Accessible Five child theme for TwentyTenFive
Screenshot Accessible Five child theme for TwentyTenFive

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.

Screenshot: Accessible 5 file structure
Screenshot: Accessible Five file structure

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.

Features

Screenshot: Accessible 1.0 - visible skip link to content
Screenshot: Accessible Five – visible skip link to content

Accessible Five is equipped with features as:

  • Accessible colors and contrast according to  WCAG AAA
  • Accessible and visible link focus for keyboard use
  • Optimized link hover and active states
  • Skip link to content visible on keyboard focus
  • Added skip links back to top after content and after footer area
  • Added additional hidden headlines for sidebars (left and bottom)
  • Navigation “Home” translated for german users into “Startseite
  • Customization of WordPress edtitor TinyMCE
  • Translation ready (english and german included)

Theme informations

Screenshot: Accessible 1.0 - visible keyboard focus
Screenshot: Accessible Five – visible keyboard focus
  • Requirements: WordPress 3.0 and above and TwentyTenFive
  • Tested up to: WordPress 3.2 on all modern browsers als IE 7/8/9, Safari, Chrome, Firefox and Opera (Windows, Mac)
  • Version: 1.0
  • Licence: GNU General Public License v2.0

Future

  • Full layout and text zoom
  • maybe some more … :)

Installation

  • First check that TwentyTenFive folder – your main theme – is named “TwentyTenFive” – otherwise the child theme will not find the folder!
  • You have to have at least WordPress 3.0 running
  • Upload accessible folder to the “/wp-content/themes/” directory
  • Activate the theme in the “Manage Themes” area in WordPress
  • That’s all. :) And don’t worry, by installing the child theme your parent theme TwentyTenFive is the same as before plus accessible features.
Screenshot: Buttons MCE Accessible Language Change
Screenshot: Buttons MCE Accessible Language Change

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. :)

Demo

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.

Changelog

1.0 – first release

Upgrade notice

No upgrades right now.

Download

Accessible Five as a zip file (45 Kb)

Der Beitrag WordPress Child Theme for TwentyTenFive: Accessible Five erschien zuerst auf sprungmarker.

]]>
https://sprungmarker.de/2011/accessible-five/feed/ 16
Accessible WordPress https://sprungmarker.de/2011/accessible_wordpress/ https://sprungmarker.de/2011/accessible_wordpress/#comments Sun, 09 Jan 2011 14:39:58 +0000 http://sprungmarker.de/?p=1409 Meine Ausflüge Richtung WordPress letztes Jahr waren doch etwas üppiger und vor allem wird es auch Zeit, dass sich mit dem Thema WordPress und Barrierefreiheit jemand dauerhafter beschäftigt.

Der Beitrag Accessible WordPress erschien zuerst auf sprungmarker.

]]>
Meine Ausflüge Richtung WordPress letztes Jahr waren doch etwas üppiger und vor allem wird es auch Zeit, dass sich mit dem Thema WordPress und Barrierefreiheit jemand dauerhafter beschäftigt. Deswegen gibt es dazu jetzt eine eigene Projektseite: Accessible WordPress.

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.

]]>
https://sprungmarker.de/2011/accessible_wordpress/feed/ 1
WordPress 3.1 Release Candidate – Compatibility https://sprungmarker.de/2011/wordpress-3-1-release-candidate-compatibility/ https://sprungmarker.de/2011/wordpress-3-1-release-candidate-compatibility/#comments Sun, 09 Jan 2011 13:51:07 +0000 http://sprungmarker.de/?p=43 For developing purposes I am using now the newest WordPress release – aka nightly builds. I installed therefor the plugin WordPress Beta Tester. (Wow, linking is updated in WordPress editor – you can now make internal links easy by searching for terms or choosing articles directly – nice). I tested Accessible 1.0 – the WordPress …

Der Beitrag WordPress 3.1 Release Candidate – Compatibility erschien zuerst auf sprungmarker.

]]>
For developing purposes I am using now the newest WordPress release – aka nightly builds. I installed therefor the plugin WordPress Beta Tester. (Wow, linking is updated in WordPress editor – you can now make internal links easy by searching for terms or choosing articles directly – nice).

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.

]]>
https://sprungmarker.de/2011/wordpress-3-1-release-candidate-compatibility/feed/ 1
WordPress: Accessibility as a patch is not a good strategy https://sprungmarker.de/2011/wordpress-accessibility-a-patch-is-not-a-good-strategy/ Sat, 08 Jan 2011 17:36:50 +0000 http://sprungmarker.de/?p=31 SteveAlee made an request in WordPress forum to merge the accessibility improvements of Accessible 1.0 into the WordPress default theme Twenty Ten. Of course this would be my favorite goal to get Twenty Ten fully accessible and not to make a child theme for that purpose. But I followed the development of Twenty Ten in …

Der Beitrag WordPress: Accessibility as a patch is not a good strategy erschien zuerst auf sprungmarker.

]]>
SteveAlee made an request in WordPress forum to merge the accessibility improvements of Accessible 1.0 into the WordPress default theme Twenty Ten. Of course this would be my favorite goal to get Twenty Ten fully accessible and not to make a child theme for that purpose.

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! ;-)

esmi – theme diva

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 https://sprungmarker.de/2011/wordpress-editor-plugin-mce-accessible-language-change/ https://sprungmarker.de/2011/wordpress-editor-plugin-mce-accessible-language-change/#comments Sat, 08 Jan 2011 16:16:14 +0000 http://sprungmarker.de/?p=25 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 …

Der Beitrag WordPress Editor Plugin: MCE Accessible Language Change erschien zuerst auf sprungmarker.

]]>
Screenshot: Buttons MCE Accessible Language Change
Screenshot: Buttons MCE Accessible Language Change

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 Changenow in the WordPress Plugin directoryadds 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:

Language change within a span element

Screenshot: Popup add language change
Screenshot: Popup add language change

To 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.

Add or change language attributes of existing block elements

Screenshot: Popup add language change for block elements
Screenshot: Popup add language change for block elements

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

Add a target language to a link

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.

Plugin informations

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.

Installation

  1. Just download MCE Accessible Language Change in the WordPress Plugin directory.
  2. Upload mce-accessible-language-change folder to the “/wp-content/plugins/” directory
  3. Activate the plugin through the “Plugins” menu in WordPress
  4. To show your language change visually in the editor – not on your website: If you have already a file named editor-style.css in your WordPress theme, you have to copy the styles below into this file editor-styles.css to get your language changes visible in the editor.
    If you don’t have a file named editor-styles.css in your theme, you have to do nothing – MCE Accessible Language Change Plugin will do this for you.
span[lang],
.lang {
    background: #f8f8f8;
    border: 1px solid #d2d0ce;
    padding: 2px;

Changelog

1.0 – first release
* Minor changes renaming files according to the name of zip file

1.1
* Path correction for TinyMCE

Upgrade notice

1.1
* Path correction for TinyMCE

Download

MCE Accessible Language Change in WordPress Plugin Directory

Der Beitrag WordPress Editor Plugin: MCE Accessible Language Change erschien zuerst auf sprungmarker.

]]>
https://sprungmarker.de/2011/wordpress-editor-plugin-mce-accessible-language-change/feed/ 1
Accessible 1.0 in the wild … https://sprungmarker.de/2011/accessible-1-0-in-the-wild/ Sat, 08 Jan 2011 16:00:40 +0000 http://sprungmarker.de/?p=18 Accessible 1.0 – an accessible child theme for WordPress Twenty Ten theme – is now around for a while and get some attention and review: Accessible 1.0 was accepted for WordPress Honors 2010 in the category themes. I think you can still vote for it, but I fear as it is a child theme it …

Der Beitrag Accessible 1.0 in the wild … erschien zuerst auf sprungmarker.

]]>
Accessible 1.0 – an accessible child theme for WordPress Twenty Ten theme – is now around for a while and get some attention and review:

  • Accessible 1.0 was accepted for WordPress Honors 2010 in the category themes. I think you can still vote for it, but I fear as it is a child theme it will be hard to compete against real WordPress themes.
  • The child theme was included in the free WordPress theme directory. This is nice, because there is no possibility to get a child theme in the official WordPress theme directory. The reason: The do not include child theme. It’s quite understandable, most of the child themes do only some layout changes. But the child theme concept can realize much more and get’s really involved in theming. So there should be a small place to put this more advanced child themes into …
  • Dennis E. Lembrée tested the child theme for a while and was satisfied with its accessibility improvements so far. He made some tweaks, it would be interesting to hear about them.
  • Martin Ladstätter – an austrian accessibility expert – installed the theme and was somehow astonished about the easiness and promptness of the installation. This is indeed the most important point for me to develop such a child theme – to have a lightweight and easy to use child theme which improves accessibility.
  • Jens Grochtdreis – a german webstandards expert – made a small review of the child theme.
  • In the podcast macpcnux the child theme was recommended.

Der Beitrag Accessible 1.0 in the wild … erschien zuerst auf sprungmarker.

]]>
Accessible 1.0 – Showroom https://sprungmarker.de/2011/accessible-1-0-showroom/ Sat, 08 Jan 2011 15:15:17 +0000 http://sprungmarker.de/?p=8 Accessible 1.0 – an accessible child theme for WordPress Twenty Ten theme is now around for a while and is running live on following sites – thanks for testing and using it. :) And just give me a note to put your site or blog into the list: A more accessible WordPress – my own …

Der Beitrag Accessible 1.0 – Showroom erschien zuerst auf sprungmarker.

]]>
Accessible 1.0 – an accessible child theme for WordPress Twenty Ten theme is now around for a while and is running live on following sites – thanks for testing and using it. :) And just give me a note to put your site or blog into the list:

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 https://sprungmarker.de/2011/accessible-1-0/ https://sprungmarker.de/2011/accessible-1-0/#comments Fri, 07 Jan 2011 18:44:02 +0000 http://sprungmarker.de/?p=1 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 …

Der Beitrag WordPress Child Theme for Twenty Ten: Accessible TwentyTen erschien zuerst auf sprungmarker.

]]>
Screenshot Accessible 1.0 Home main part of the theme
Screenshot Accessible TwentyTen child theme for Twenty Ten

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.

Screenshot: Accessible 1.0 file structure
Screenshot: Accessible TwentyTen file structure

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.

Features

Screenshot: Accessible 1.0 - visible skip link to content
Screenshot: Accessible TwentyTen - visible skip link to content

Accessible TwentyTen is equipped with features as:

  • Accessible colors and contrast according to  WCAG AAA
  • Accessible and visible link focus for keyboard use
  • Optimized link hover and active states
  • Skip link to content visible on keyboard focus
  • Added skip links back to top after content and after footer area
  • Added additional hidden headlines for sidebars (left and bottom)
  • Navigation “Home” translated for german users into “Startseite
  • Customization of WordPress edtitor TinyMCE
  • Translation ready (english and german included)

Theme informations

Screenshot: Accessible 1.0 - visible keyboard focus
Screenshot: Accessible TwentyTen - visible keyboard focus
  • Requirements: WordPress 3.0 and above and Twenty Ten or a theme which is derived in great parts (CSS classes, Ids) from Twenty Ten
  • Tested up to: WordPress 3.2 on all modern browsers als IE 7/8/9, Safari, Chrome, Firefox and Opera (Windows, Mac)
  • Version: 2.0
  • Licence: GNU General Public License v2.0

Future

  • Full layout and text zoom
  • maybe some more … :)

Installation

  • You have to have at least WordPress 3.0 running
  • Upload accessible folder to the “/wp-content/themes/” directory
  • Activate the theme in the “Manage Themes” area in WordPress
  • That’s all. :) And don’t worry, by installing the child theme your parent theme Twenty Ten is the same as before plus accessible features.
Screenshot: Buttons MCE Accessible Language Change
Screenshot: Buttons MCE Accessible Language Change

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. :)

Demo

Just use this site only with keyboard and check the visible focus, use the skip links and enjoy the better contrast.

Changelog

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 …

Upgrade notice

  • Version 1.0 (11/2010)
  • Version 2.0 (04/2011)

Download

Accessible TwentyTen as a zip file (45 Kb)

Der Beitrag WordPress Child Theme for Twenty Ten: Accessible TwentyTen erschien zuerst auf sprungmarker.

]]>
https://sprungmarker.de/2011/accessible-1-0/feed/ 16