sprungmarker testet
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:
Weiterlesen „Der barrierefreie Webentwickler – ein Langweiler?“
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.
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).
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.
Weiterlesen „Was ist mit cufón, typeface.js oder lettering.js?“
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. Weiterlesen „Accessible child themes: Updates“
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.
Weiterlesen „WordPress Child Theme for TwentyTenFive: Accessible Five“
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.
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.
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. Weiterlesen „WordPress: Accessibility as a patch is not a good strategy“
One thing I always missed in WordPress editor TinyMCE is to add language change. So I made my first plugin. 🙂 This was somehow hard because it’s not only to get a plugin in WordPress running, you also have to get into programming with TinyMCE. So keep in mind when you use the plugin, I am a novice …
The Plugin MCE Accessible Language Change – now in the WordPress Plugin directory – adds two buttons to the editor: one for changing the language of a word or phrase within a span element and one for changing or adding the language of already existing block elements as paragraphs or headlines. Furthermore you can add the target language to a link:
Accessible 1.0 – an accessible child theme for WordPress Twenty Ten theme – is now around for a while and get some attention and review: