Am Montag, den 17.10. 2022, spreche ich über das Testen von Barrierefreiheit mit Hilfe von browsereigenen Tools auf der Online-Konferenz „Barrierefreie Webseiten“ des Rheinwerk-Verlags: „Barrierefreiheit testen? Nutzen Sie doch ihren Browser“. Mein Fokus liegt als auf dem Testen von Barrierefreiheit im Browser selbst.

Gerade weil ich täglich mit vielen externen Tools (Bookmarklets, Browsererweiterungen) arbeite, finde ich es spannend, die Möglichkeiten der Browser im Hinblick auf das Testen von Barrierefreiheit näher in Augenschein zu nehmen. Und es ist doch überraschend, wie viele unterschiedliche Möglichkeiten die Browser bieten, um etwa die Bedienung mit Tastatur zu testen oder sich die Kontraste von Texten genauer anzusehen. Klar – mit den Dev-Tools sollte man schon ein wenig vertraut sein. Die meisten Optionen und Tools zum Testen von Barrierefreiheit in den Browsern finden sich in den Dev-Tools.

Auch nach dem Vortrag finde ich es spannend, auszuloten, welche Prüfschritte sich mit Hilfe des Browsers testen lassen oder wo ich dann doch ein ausführliches Tools (Bookmarklet, Browsererweiterung) benötige. Es wäre auch mal interessant, eine Geschichte der Browser Dev-Tools im Hinblick auf die Barrierefreiheit zu formulieren.

Der Beitrag Barrierefreiheit testen im Browser! (Vortrag) erschien zuerst auf sprungmarker testet.

Beim Testen fallen uns immer wieder interessante Ergebnisse auf. Der W3C-Validator gibt einen Fehler in der Validierung für Überschriften in Datentabellen aus. So ist eine HTML Überschrift (h1-h6) nicht valide (Validierung mit dem W3C Nu HTML Checker), wenn man sie innerhalb einer Überschrift (th) einer Datentabelle einsetzt.

// Einsatz einer h4-Ueberschrift innerhalb einer th
// ist nicht valide
<table>
  <tr>
      <th>
	  <h4>Ansprechparnter</h4>
      </th>
  </tr>
</table>

Dass das inhaltlich nicht wirklich sinnvoll ist, müssen wir nicht diskutieren. Aber dass es auch nicht valide ist, weil es in der HTML Spezifikation explizit ausgeschlossen ist, war eine interessante Erkenntnis.

Die HTML Spezifikation weist explizit für Überschriften (th) von Datentabellen (table) darauf hin, dass Überschriften keinen heading content enthalten dürfen. Und heading content definiert den Kopfbereich eines Inhaltsbereichs und dafür werden gewöhnlich die HTML Überschriften (h1-h6) eingesetzt.

Insofern gibt es jetzt nicht nur ein inhaltliches Argument, bereits als Überschriften (th) ausgezeichnete Inhalte noch einmal mit Überschriften (h1-h6) zu versehen. Es gibt im W3C Validator auch kein valides Ergebnis.

Der Beitrag Überschrift in Datentabelle nicht valide erschien zuerst auf sprungmarker testet.

Das Bookmarklet WAI-ARIA Usage von TPGi analysiert den Einsatz von WAI-ARIA in HTML gemäß der Spezifikation ARIA in HTML (W3C Recommendation, 9.12. 2021). Es nutzt die Inhalte der Tabelle „Roles of ARIA Attribute usage by HTML elment“. In dieser Tabelle wird jedem HTML Element (Spalte 1) zuerst die implizite WAI-ARIA Semantik (Spalte 2) zugeordnet und dann die Möglichkeit, noch weitere WAI-ARIA Roles (Rollen), States (Zustände) und Properties (Eigenschaften) (Spalte 3) für dieses Element zu integrieren.

Nutzt man das Bookmarklet WAI-ARIA Usage auf Webseiten, erhält man unter anderem folgende Ergebnisse:

• WAI-ARIA Rollen und Attribute, die valide sind
• Nicht-Valide WAI-ARIA Rollen und Attribute
• WAI-ARIA Rollen und Attribute, die nicht mehr notwendig oder obsolet (deprecated) sind
• Hinweise auf nichtexistierende WAI-ARIA Rollen und Attribute
• Abhängigkeiten zwischen den WAI-ARIA Rollen (parent / child Rollen)
• Elemente mit nicht validen WAI-ARIA Attributen

Bookmarklet Ergebnis: Valide WAI-ARIA Rollen und Attribute

Anhand der Ergebnisse der validen WAI-ARIA Rollen lässt sich schon ein erster Blick etwa auf die verwendeten Widgets oder den Einsatz von Inline-SVGs werfen. Bei Seiten mit Inline-SVGs findet man häufig zur barrierefreien Optimierung die WAI-ARIA Rolle img. Für die generelle Struktur einer Seite wird der Suchbereich mit Hilfe von WAI-ARIA Rolle search gekennzeichnet. Man kann daher schnell erkennen, ob ein Modalfenster (dialog), Tooltips, angepasste Formularelemente oder Statusmeldungen auf der Seite vorhanden sind.

Bookmarklet Ergebnis: Nicht valide WAI-ARIA Rollen und Attribute

Interessanter in den Ergebnissen sind natürlich die nicht-validen WAI-ARIA Rollen und Attribute des Bookmarklets WAI-ARIA Usage. So wird etwa darauf hingewiesen, dass in einem Formularfeld, das bereits das HTML Attribut required enthält, nicht mehr das WAI-ARIA Attribut aria-required eingesetzt werden soll.

Authors SHOULD NOT use the aria-required=“true“ on any element which also has a required attribute.

Quelle: ARIA in HTML: 3.1 Requirements for use of ARIA attributes in place of equivalent HTML attributes

Oder eine HTML Liste (ul) hat eine WAI-ARIA Rolle navigation. Eine HTML Liste (ul) hat eine implizite WAI-ARIA Rolle list und kann nur zusätzlich etwa eine WAI-ARIA Rolle listbox oder menu enthalten. Das Bookmarklet weist korrekt darauf hin, dass role=navigation keine valide WAI-ARIA Rolle auf diesem Element ist. Die HTML Liste verliert dann auch ihre implizite semantische Rolle als Liste und wird nun von Screenreadern als Navigationselement vorgelesen, die einzelnen HTML Listenelemente (li) stehen in keinem Listenzusammenhang mehr (Test mit VoiceOver auf dem Mac).

Auch auf die immer wieder anzutreffende nicht valide Kombination einer Überschrift (etwa einer h2) und einer WAI-ARIA Rolle button wird hingewiesen. Dies findet sich leider häufig bei der Umsetzung eines Akkordeons. Die ursprüngliche Überschrift (etwa eine h2) wird mit einer WAI-ARIA Rolle button von Screenreadern nicht mehr als Überschrift erkannt. Die Überschrift taucht dann weder in der Übersicht der Überschriften auf, noch lässt sie sich mit der Tastatur etwa mit Hilfe eines Tastaturkürzel wie H erreichen (Test mit VoiceOver auf dem Mac).

Bookmarklet Ergebnis: Obsolete WAI-ARIA Rollen und Attribute

Hier stoßen wir vor allem auf die obsoleten WAI-ARIA Landmark Roles wie role=banner oder role=main. Aber auch auf nicht notwendige WAI-ARIA Rollen wird hingewiesen wie eine WAI-ARIA Rolle list auf einer HTML Liste (ul).

Bookmarklet Ergebnis: Abhängigkeiten zwischen den WAI-ARIA Rollen (parent / child Rollen)

Das Bookmarklet WAI-ARIA Usage analysiert Abhängigkeiten in gängigen WAI-ARIA Widgets. Vor allem weist es auf fehlende WAI-ARIA Rollen im Widget – von Eltern- und Kind-Elmenten (parent / child Rollen) – hin.

Fehlen etwa dem WAI-ARIA-Widget Tabs bei den Kind-Elementen etwa die WAI-ARIA Rollen tab, wird das entsprechend mit einer Referenz zum Quellcode angemerkt. Infolgedessen werden die Kind-Elemente nicht mehr als einzelne Tabs erkannt.

Role tablist missing required child role (tab).

Quelle: WAI-ARIA Usage – Fehlerhinweis

Fazit

Das Bookmarklet WAI-ARIA Usage gibt Hinweise, wie und wo WAI-ARIA Rollen, Attribute und Eigenschaften auf der Seite unzureichend oder sogar fehlerhaft eingesetzt werden. Vor allem für die konkrete Entwicklung kann das durchaus von Vorteil sein, weil die Fehlermeldung immer mit einer entsprechenden Referenz zum Quellcode versehen ist.

Eine eingehende Analyse aller WAI-ARIA Widgets ersetzt das Bookmarklet nicht. Es kann nur Hinweise geben, wo und wie WAI-ARIA auf der Webseite nicht korrekt eingesetzt wird. Das Fehlen von WAI-ARIA bildet das Bookmarklet nicht ab – etwa der Einsatz eines Akkordeons ohne entsprechende WAI-ARIA Optimierung.

Die Ergebnisse des Bookmarklets – wie hier beispielhaft beschrieben – spiegeln häufig die andauernde Debatte zum Einsatz von WAI-ARIA gut wider.

Hinweis

Bookmarklets sind zwar einfach in der Nutzung, aber sie laden jedoch oftmals eine externe JS-Datei eines anderen Servers. Das fällt bei vielen Servern unter Cross-Site-Scripting und das Bookmarklet lädt sich dann nicht. Auch beim Bookmarklet WAI-ARIA Usage ist das der Fall.

Der Beitrag Bookmarklet WAI-ARIA Usage erschien zuerst auf sprungmarker testet.

In GitHub lässt sich dazu auch ein entsprechendes Issue aus dem Jahre 2019 (!) finden, das bis heute nicht aufgearbeitet worden ist. Joe Dolson hat als letzter darauf hingewiesen, dass es etwas mehr Bewegung im Thema Sprachwechsel geben sollte. Die Debatte dazu enthält die üblichen Missverständnisse. Zu sehr wird der Sprachwechsel im Text mit Hilfe des HTML-Attributs lang auf die allgemeine Möglichkeit, Sprache im Webauftritt festzulegen, reduziert. Deswegen dreht sich die Diskussion fast nur um die Option, einen ganzen Absatz – oder wie es in WordPress korrekt lautet – eines ganzen Blocks – mit einem Sprachwechsel zu versehen.

Innerhalb eines Absatzes – Blocks – den Sprachwechsel von einem Wort oder mehreren Wörtern korrekt auszuzeichnen, scheint schon komplexer zu sein. Daher wird in der Debatte zwar immer wieder darauf hingewiesen, dass das gehen könnte, aber leider bis dato nicht weiterverfolgt. Der Hinweis, dass es auch im alten WordPress Editor (Classic-Editor) keine Möglichkeit zur Auszeichnung des Sprachwechsels gab, wird noch unterstützend angeführt.

Es bleibt zu hoffen, dass es im neuen Editor baldigst eine Möglichkeit zur Auszeichnung des Sprachwechsels geben wird.

Das Plugin Juiz Lang Attribute für den Sprachwechsel

Bis dahin kann man das Plugin Juiz Lang Attribute einsetzen. Es funktioniert für die aktuelle WordPress-Version (5.8.2).

Ein Wort oder mehrere Wörter im Absatz – Block – im WordPress Editor markieren. Dann in der Bearbeiten-Leiste die weiteren Optionen (visuell durch einen Pfeil gekennzeichnet) öffnen und die Option „Add LANG Attribute“ auswählen.

Es öffnet sich ein Modalfenster und man kann dann das Sprachkürzel, z.B. für Englisch, „en“ in das Feld eintragen. Die Beschriftung des Feldes ist nur in Englisch verfügbar: „What LANG value“. Nach dem Bestätigen mit „OK“ schließt sich das Modalfenster und die Auszeichnung des Sprachwechsels findet sich im HTML-Code:

<span lang="en" class="juizlang">What LANG value</span>

Nicht optimal ist, dass das Plugin mit dem Sprachwechsel auch eine eigene CSS-Klasse integriert: juizlang. Sie findet aber keine Entsprechung in CSS und ist damit ein reiner Platzhalter. Eigentlich sollte das Plugin auch das HTML-Attribut hreflang bei Verlinkungen ermöglichen. Diese Option konnte ich jedoch im aktuellen Editor nicht finden. Auch die Möglichkeit, die englischen Texte ins Deutsche zu übersetzen, ist derzeit nicht gegeben.

Ich habe dem Plugin-Entwickler meine Anmerkungen entsprechend zurückgemeldet. Es wäre vor allem interessant, wie lange er das Plugin noch bereitstellen wird, da es mit der aktuellen WordPress-Version offiziell ungetestet ist.

Der Beitrag Sprachwechsel im WordPress-Editor erschien zuerst auf sprungmarker testet.

Irgendwie sind sie nun doch verflogen – die letzten Jahre. Mein Blog „sprungmarker“ ist mehr als in die Jahre gekommen – in vielerlei Hinsicht war ein Relaunch fällig. Ich habe versucht, auch neben meiner Arbeit als Frontend-Entwicklerin meinen Blog weiter mit dem zu füllen, was mir wichtig ist. Aber irgendwie hat die Arbeit in der Agentur viel von meiner Energie – vor allem im Thema „Barrierefreiheit“ – beansprucht.

Dazu kam für mich persönlich noch, dass sich die Szene, in der das Thema „Barrierefreiheit“ – speziell in Deutschland – vorangetrieben wurde, irgendwie weg fraktioniert hat. Mittlerweile gibt es eine neue Szene, die ich von außen beobachte. Wie Web und Frontend hat sich „Barrierefreiheit“ extrem weiterentwickelt. Das ist zum einen einfach toll (!), bringt für mich aber auch mit sich, dass ich mich fokussieren muss, um dieses Thema auf meinem Blog hier präsent zu halten.

Ein Relaunch: Vom Frontend zu Beratung und Testing

Auch beruflich hat sich ein Wechsel vollzogen: vom Frontend zu Beratung und Testing. Die letzten zwei bis drei Jahre habe ich nur noch ganz wenig Frontend-Projekte mitbetreut, privat entwickle ich noch meine eigenen Projekte, wie diesen Blog. Der Hauptfokus lag und liegt bei der Durchführung von BIK-Tests, dem Ausbau der BIK-Prüfstelle und die nicht nur damit einhergehende Beratung zu Umsetzung und Optimierung von barrierefreien Webauftritten und mobilen Apps.

Daher wird sich der thematische Fokus in meinem Blog nun auch ändern: sprungmarker testet. Ich werde mich hier intensiver mit Werkzeugen beschäftigen, die für das Testen von Webauftritten immer wichtiger werden – seien es manuelle oder automatisierte Möglichkeiten. Normen und Gesetze, Monitoring und Berichte sind die aktuellen Schlagworte, wie das Thema „Barrierefreiheit“ öffentlich positioniert wird. Aber bewegt sich dadurch wirklich mehr, liegt die letzte Hoffnung auf mehr Barrierefreiheit letztlich beim EAA (European Accessibility Act)? Auch das Thema „Barrierefreiheit“ selbst hat quasi über die letzten Jahre eine Art Relaunch erlebt.

Ich werde versuchen, wieder in meinen Blog „hineinzuwachsen“. Es fühlt sich noch etwas seltsam an, eine frühere Leidenschaft wieder zu aktivieren. Ich halte euch / Sie auf dem Laufenden. :)

Der Beitrag Relaunch – sprungmarker testet erschien zuerst auf sprungmarker testet.

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

• 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 testet.

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

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
• Rendering without lumpy bits – Jake Archibald
• Responsible Responsive Images – Mat Marquis
• Console Browsers: The Ultimate Torture Test – Anna Debenham

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

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

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

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

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

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?

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.

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?

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.

Wie steht es um den Tastaturfokus?

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

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.

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!

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

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

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

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.

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.

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.

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.

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.

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.

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

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.

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>

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

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

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.

Features

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

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

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

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

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