haunschild.de

Web & Internet

13. Januar 2012
von Marc Haunschild
Keine Kommentare

Vorschau auf TYPO3 Version 4.7

Ich bin ja kein TYPO3-Spezialist. Zum Glück habe ich mit +Sacha Vorbeck einen sehr kompetenten Kollegen. So konzentriert sich jeder auf das, was er am besten kann: BITV/WCAG, HTML und CSS mache ich, TYPO3 er, wobei er geduldig alles umsetzt, wodrum ich ihn bitte. Im Laufe der Jahre ist auf diese Weise ein Setup entstanden, dass unsere Ansprüche an Barrierefreiheit, Usability und so weiter weitesgehend erfüllt und auch die tägliche Arbeit erleichtert (zum Beispiel das Aufsetzen neuer Angebote). Diese Anpassungen sind sehr umfangreich und an einigen wenigen Stellen kommt es bei Updates zu Problemen (z. B. das Kontaktformular und das Suchergebnis – hier mussten wir in den TYPO3-Kern eingreifen, um die Ausgabe unseren Wünschen anzupassen).

An anderen Stellen, zum Beispiel der Ausgabe der News-Details gibt es Ausgaben, die durch einen einzigen Marker erzeugt werden und gar nicht geändert werden können (da kommt – wenn ich mich recht entsinne – ein komplettes HTML-Konstrukt mit Tags und Werten raus. Ich glaube das betrifft das Datum. Da hat man im Quellcode so etwas wie ###single-date### und als Ausgabe < p>12.1.2012< /p> -Dadurch bekommt man das p nicht weg).

Die beiden ersten Probleme werden mit TYPO3 4.7 gelöst sein. Die Bundesanstalt für Landwirtschaft und Ernährung hat ein KP2-Projekt umgesetzt (KP2 steht für Konjunkturpaket 2 – solche Projekte wurden während der ersten Bankenkrise vom Staat aufgelegt, um die deutsche Wirtschaft zu stützen). Im Rahmen dieses Pojektes wurde TYPO3 zugänglicher und bekam endlich ein Standard-Setup, mit dem auch ein Anfänger direkt loslegen kann, ohne erst selber ein eigenes Template schreiben zu müssen.

Das wird als government package angeboten, ist weitestgehend barrierefrei und steht mit Version 4.7 der Allgemeinheit zur Verfügung.

Außerdem wurden viele weitere Details verbessert, zum Beispiel die indexed_search, die Wartbarkeit für System-Administrationen usw.

Unter der Haube hat sich bei der Verwaltung von Dateien viel getan – ein kompletter file abstrction layer ist hinzu gekommen.

Hierzu noch ein paar Ergänzungen von Oliver Hader, Leader of the v4 Core Team bei TYPO3 Association:

An dieser Stelle noch ein Hinweis zur Vollständigkeit:

  • derzeit wird noch intern an einem Projekt gearbeitet, den file-abstraction-layer zu erweitern – z.b. kommt gerade webdav Unterstützung mit dazu
  • die Medien-Verwaltung (media management, derzeit noch als DAM bekannt) wird somit auch noch bearbeitet

Ziel ist es, bis zum Final Release von 4.7 (Ende April 2012) diese Sachen natürlich stabil, fertig und auch korrekt veröffentlicht zu haben. Ergo Basiskomponenten im TYPO3 core von 4.7 und optionale Komponenten im TYPO3 extension repository (TER)”

Als beta gibt es das bereits. Der voraussichtliche Erscheinungstermin ist Ende April.

Dokus:
http://docs.typo3incubator.org/

Barrierefreie Bildergalerie:
https://svn.typo3.org/TYPO3v4/Extensions/media_gallery/trunk/

GovPackage:
http://govpackagetest.typo3incubator.org/

Das Projekt:
http://news.typo3.org/news/article/typo3-receives-german-governmental-funding-for-accessibility-and-usability-project/

12. Januar 2012
von Marc Haunschild
Keine Kommentare

Neue Kurse “Webseiten erstellen” (HTML und CSS)

Am 30. Januar geht es mit dem Vorbereitungskurs wieder los. Hier lernen Sie die Grundbegriffe, was Webdesign ist, was Sie sich vor der ersten Webseite überlegen sollten und was Sie dafür außer Ihrer eigenen Kreativität benötigen.

Alle meine Kurse des ersten Halbjahres 2012 bauen aufeinander auf.

Vorkenntnisse sind kaum nötig. Es reicht, wenn Sie sich mit Windows oder einem anderen grafischen Betriebssystem gut auskennen. Wer unsicher ist, kann im Vorbereitungskurs feststellen, ob er über die nötigen Kenntnisse verfügt und diese nötigenfalls festigen.

Einzige Ausnahme: Der Wochenendkurs für Eilige. Hier können Sie vorhandene Kenntnisse auffrischen und auf den neuesten Stand bringen (HTML5 und CSS3).

Da in zwei Tagen ein Großteil der beiden anderen Kurse vermittelt wird, ist das Tempo entsprechend anspruchsvoll. Es gibt aber auch reichlich Lektüre zum mitlesen und nachbereiten.

Wenn Sie neugierig geworden sind, besuchen Sie doch mal die Übersicht meiner Kurse bei der Volkshochschule Bonn.

3. Januar 2012
von Marc Haunschild
Keine Kommentare

Einfacher ist besser als besser

Einfacher für den Nutzer ist schwere Denkarbeit für den Entwickler.

Dabei gab es mal die gute alte Zeit, da hatte der InternetExplorer eine Verbreitung von fast 100% und die meisten Monitore eine Auflösung von 800×600 Pixeln. Daraufhin wurden Webseiten “optimiert”.

Ob die User das so wollten oder nicht. Man wurde einfach nicht gefragt. Der Nutzer hatte keine Chance. “Friss oder stirb” war die Devise.

Heute machen es sich manche Kollegen noch immer so einfach, obwohl viel mehr möglich ist und man auch sehr viel mehr über die Bedürfnisse und Wünsche der Nutzer weiß. Es gibt zahlreiche öffentlich zugängliche Studien, es gibt die WCAG 2.0 die in Bezug auf Nutzbarkeit mt unterschiedlichen Auflösungen und Geräten beachtenswerte Empfehlungen gibt und es gibt mehr vorgefertigte Lösungen als je zuvor. Jakob Nielsen ist seit vielen Jahren aktiv und seine Thesen werden öffentlich dsikutiert.

Heute bleibt es jedem Entwickler selber überlassen, ob er Nutzerbedürfnisse berücksichtigt oder nicht und die Nutzer sind nicht mehr die Dummen.

Sie haben heute nämlich die Wahl: es gibt inzwischen einfach zu viele gut gemachte Webseiten, als dass ich mich noch über bequeme “Webmaster” ärgern müsste.

Wenn ihr also Traffic auf Euren Webseiten (oder denen Eurer Kunden) wollt, macht es den Benutzern einfach, setzt intelligente Layouts ein, die sich an die Bedürfnisse der Nutzer anpassen.

Viele erschließen sich das Web aber auch auf anderem Weg: immer mehr Apps bieten gegenüber einer Webseite kaum einen Mehrwert. Dennoch werden sie verwendet. Vielleicht sind die Webseiten gar nicht immer so attraktiv, wie die Ersteller sich das erhofften.

Der Vorteile der meisten Apps: sie lassen sich von “Idioten” bedienen. Ich bin einer von denen, denn ich will nicht, dass ich über das Konzept einer Website nachdenken muss. Einfacher ist besser als besser und lasst mich nicht nachdenken, wenn ich Eure Webseiten besuche.

Damit die Nutzer nicht denken müssen, müssen die Köpfe der Entwickler um so mehr rauchen:

Unser Job ist vielfältiger geworden und darum auch interessanter. Die Herausforderungen sind mehr geworden, aber auch die Werkzeuge sind mächtiger.

Daher braucht man heute nicht länger, um eine Webseite zu erstellen als früher, obwohl moderne Seiten flexibler auf das Verhalten der Nutzer reagieren.

Deswegen zählt für mich auch das Kostenargument nicht.

Um aber doch noch ein Wort zu den Kosten zu sagen: wer ein Design in Pixeln abliefert, sollte das zu dem Preis anbieten, wie 1&1 den Homepagebaukasten – da kriegt man nämlich dasselbe und das ist auch dasselbe wert.

Um es mal plakativ und provokant zuzuspitzen.

Andere Meinungen zu diesem Thema in der XING-Gruppe “Webdesign und Usability“.

2. Januar 2012
von Marc Haunschild
Keine Kommentare

bittersmann.de

Allen Webentwicklern mit Lernpotential und -interesse sei ein Blick auf die Seite von Gunnar Bittersmann ans Herz gelegt. Eine hilfreiche Alternative für Floats, (zum Beispiel um Bildergalerien zu realisieren) löst ein lästiges Problem, wenn man es mit unterschiedlich hohen Elementen zu tun hat (in der Bildergalerie zum Beispiel Grafiken mit unterschiedlich langen Bildunterschriften). Wer also an gut erklärten Lösungen interessiert ist, schaut sich das mal an. Und alle die bereits alles zu wissen behaupten: seht es Euch trotzdem mal an, Ihr müsst es ja niemandem verraten. :-)

2. Januar 2012
von Marc Haunschild
4 Kommentare

Textskalierbarkeit im BITV-Test stärker an die WCAG anpassen?

Auf http://www.bitvtest.de ist ein Artikel mit dem Namen „Textskalierbarkeit im BITV-Test stärker an die WCAG anpassen?“ erschienen. In diesem Text wird darum gebeten, sich an der Diskussion zu beteiligen, ob der BITV-Test hinsichtlich Text-Zoom und Kontraste stärker an die WCAG angepasst werden sollte.

Zum Hintergrund: Die WCAG schreiben nicht ausdrücklich vor, dass Texte mittels Text-Zoom vergrößerbar sein müssen. Laut dem derzeitigen Wortlaut der WCAG könnte eine Webseite auch dann als barrierefrei eingestuft werden, wenn sich Texte nur mittels Page-Zoom vergrößern ließen. Da dies aber diverse Nachteile für Nutzer hat und Text-Zoom auch von den Betroffenen bevorzugt wird, ist dies ein Nachteil und praxisfern.

Ähnliches gilt für hohe Kontraste. Um diese zu erreichen genügt es laut WCAG irgendwo auf der Seite einen winzigen, theoretisch nutzbaren, in der Praxis aber nicht auffindbaren Button oder Link zu einer kontrastreicheren Version anzubieten.

Der BITV-Test  prüft dagegen auch die Skalierbarkeit von Texten mittels Text-Zoom und ob Kontrastumschalter prominent (am Seitenanfang) angeboten werden und geht damit über die praxisfernen Minimalanforderungen der WCAG hinaus.

Die Frage ist nun, ob es sinnvoll ist, sich zugunsten einer Annäherung an die WCAG über die tatsächlichen Bedürfnisse der Nutzer hinwegzusetzen und einen Test anzubieten, der zwar formal-bürokratisch korrekter zu sein scheint, aber an den Nutzern vorbei geht.

Hier einige Punkte, die ich (als Freund von Text-Zoom) zur Diskussion beisteuern möchte:

1.) Der BIK-BITV-Test prüft zunächst einmal, ob eine Seite die Ansprüche der BITV erfüllt und nicht die WCAG-Konformität. Natürlich sind BITV und WCAG sehr ähnlich, aber nicht identisch. Die BITV ist (für mich unverständlich) nicht einmal dort, wo es möglich wäre, identisch mit der offiziellen deutschen Übersetzung der WCAG. Vor allem aber fehlen der BITV die erläuternden Dokumente. Daher ist es im Einzelfall allein aus der BITV heraus gar nicht möglich zu sagen, wie getestet werden müsste, um zu überprüfen, ob eine Seite den Anforderungen genügt.

Hier kommt man meiner Meinung nach nur weiter, wenn man sich wie ein Gericht fragt, was die Intention des Gesetzgebers (BGG) gewesen ist. Und es dürfte wohl kein Zweifel da dran bestehen, dass die BITV eine bessere Bedienbarkeit von Webseiten für Menschen mit Einschränkungen erreichen möchte. Diese benutzen aber nun einmal vorzugsweise Text-Zoom.

Gestützt wird dies durch §2 der BITV, in dem ausdrücklich gesagt wird, wem die Verordnung nutzen soll:  „Die Gestaltung von Angeboten der Informationstechnik (§ 1) nach dieser Verordnung ist dazu bestimmt, behinderten Menschen im Sinne des § 3 des Behindertengleichstellungsgesetzes, denen ohne die Erfüllung zusätzlicher Bedingungen die Nutzung der Informationstechnik nur eingeschränkt möglich ist, den Zugang dazu zu eröffnen.“

Von daher sollte man es sich ruhig einmal zunutze machen, dass WCAG und BITV nicht identisch sind – zum Vorteil der Betroffenen, für die diese Verordnung ja nun einmal erlassen wurde.

2.) Da die Techniken nicht normativ sind, geben die WCAG es auch nicht her, dass eine Technik NICHT verwendet werden darf. Da Text-Zoom nun einmal die beste Möglichkeit ist, Texte zu vergrößern und der Page-Zoom nur eine Krücke, wenn eine Webseite schlecht gemacht ist, ist es nur recht und billig, ALLE in Browsern bereitgestellten Techniken zu prüfen. Gerade im Sinne der Praxisnähe, sollte der Text mit den von den Nutzern beliebteren Technik beibehalten werden und ggfs darauf verzichtet werden zu überprüfen, ob Page-Zoom funktioniert (obwohl ich das auch  regelmäßig nutze – zum Beispiel zur Vergrößerung von Grafiken) . Denn sowohl WCAG als auch BITV haben ja nun einmal den Anspruch, das Web für behinderte Menschen besser zu machen und die neuen Versionen 2.0 sollen ja einen begonnenen Weg weiterführen und nicht zu einer (partiellen) Verschlechterung beitragen.

Mehr geben die Texte der WCAG auch nicht her.

3.) Zugegebenermaßen etwas weiter ausholen muss ich für mein drittes Argument. Webseiten, die ein gutes oder sehr gutes Ergebnis im BITV-Test erreichen sind in aller Regel gut gemachte Webseiten, die zahlreiche Qualitätskriterien erfüllen, sowohl technischer, als auch redaktioneller Natur (valides HTML, eindeutige Dokumenttitel, um nur zwei Beispiele zu nennen).

Eine barrierefreie Seite nach BITV mit BIK-BITV-Test-Stempel „gut zugänglich“ oder besser, ist in fast allen mir bekannten Fällen eine gut gemachte Webseite, erstellt von Leuten, die weitestgehend wissen, was sie machen. Selbst wenn mal ein oder mehrere Prüfschritte nicht erfolgreich getestet werden können, ist dies in der Regel mit Bedacht und begründbar geschehen. Frei nach dem Motto: man muss die Regel kennen, um sie zu brechen.

Aus diesem Grund empfehle ich Entscheidern, die selber nicht die Möglichkeit in ihrer Organisationsstruktur haben, einen Katalog von Testkriterien zu erstellen, zumindest schon in ihren Ausschreibungsunterlagen den abschließenden BITV-Test zu verlangen und zwar die vollen hundert Punkte! Und das natürlich auch für Seiten, die nicht im Geltungsbereich der BITV liegen.

Zwar ist das oft unerreichbar (aus diversen Gründen), aber jeder nicht erfüllte Prüfschritt muss begründet werden (zum Beispiel mit technischem, finanziellem Aufwand oder konkurrierenden Vorgaben des Auftraggebers).

So erhält der Auftraggeber einen unabhängigen Prüfbericht und die Begründungen sollten nachvollziehbar und verständlich sein. So wird dem Auftraggeber klar, was der Auftragnehmer sich gedacht hat und kann besser entscheiden.

Natürlich ist der BITV-Test nicht hierfür gemacht, diese Vorgehensweise hat sich aber als praktikabel und sinnvoll erwiesen. So bekommt man eindeutig die besseren Agenturen und Freelancer!

Gerade der Text-Zoom hat auch für Menschen eine hohe Bedeutung, die eine Webseite zwar lesen können, aber nur mit unnötiger Anstrengung, was zu Lasten der allgemeinen Leistungsfähigkeit geht.

Daher ist der Text-Zoom z. B. gerade bei Werktätigen, zu deren Berufsbild es gehört, viel im Web unterwegs zu sein, ein klares Qualitätsmerkmal.

Für mich ein eher weiches Kriterium in Bezug auf Barrierefreiheit, aber ein klares Merkmal für eine gut gemachte Site, das seine Bedeutung (und Rechtfertigung) vor allem dadurch erhält, dass diese Funktion so sehr vielen Menschen Vorteile schafft (jedenfalls so lange „Webdesigner“ an der sinnvollen Standardschriftgröße der Browser (16px) rummanipulieren)!

4.) Außerdem ist der Text-Zoom ein hervorragendes Beispiel dafür, wie Menschen ohne Behinderungen von BITV-konformen Websites profitieren können.

Das alles gilt natürlich auch für Kontraste!

Diese Prüfschritte sollten daher unbedingt beibehalten werden, auch wenn gerade mein 3. Und 4. Argument den WCAG-Verantwortlichen irrelevant vorkommen mögen: Diese Prüfschritte sind gut und wichtig.

Die Vorteile hoher Kontraste und skalierbare Schriften sind leicht vorzuführende Merkmale von gut gemachten Webseiten, mit denen sich Entscheider vom Sinn der Barrierefreiheit überzeugen lassen und sie sind darum besonders wichtig für die Verbreitung barrierefreier Webseiten.

Es wäre absolut kontraproduktiv diese nicht mehr zu testen!

Besser die Working Group macht hier fällige Anpassungen, als BIK!

16. Dezember 2011
von Marc Haunschild
Keine Kommentare

Wie man Stile des Betriebssystems im CSS verwenden kann

War mir neu (habe ich eigentlich auch nie nach gesucht – aber vielleicht möchte es ja der eine oder andere nutzen).

Man kann mit CSS auf die Schriften, Farben usw. zurückgreifen, die der Besucher einer Webseite bei sich im Betriebssystem verwendet. – Ist mit CSS3 wohl rausgeflogen, funktioniert aber (noch – meistens jedenfalls).

Hier der Artikel auf Sitepoint (engl.):

How to Use Operating System Styles in CSS

15. Dezember 2011
von Marc Haunschild
Keine Kommentare

Der Unterschied zwischen width=”auto” und width=”100%”

Das CSS-Box-Modell beschreibt, die Dimensionen von Block-Level-Elementen. Neu ist die Möglichkeit mit CSS3 zu bestimmen, ob sich die Breitenangabe auf den Inhalt des Elementes (also zum Beispiel den Text eines Absatzes) oder auf das Element inklusive Innenabstände und Rahmen beziehen soll.
Manchmal ist das sinnvoll, zum Beispiel, wenn man möchte, dass ein Element genauso breit ist, wie sein Elternelement. Nach dem CSS-Box-Modell bezieht sich die Breitenangabe nämlich auf den Inhalt. Rahmen und Innenabstände werden hinzugefügt, so dass zum Beispiel ein Formularfeld mit border und padding nicht mehr ins Elternelement passt. Hier hilft die neue Eigenschaft box-sizing. Mit “box-sizing:border-box; width:100%” kann man erreichen, dass ein Element genauso breit ist, wie sein Elternelement. Aber das ist nicht immer der beste Weg. Wann immer möglich sollte statt dessen width:auto verwendet werden. Dann muss man sich um margin, padding oder border nicht selber kümmern. Die Details erklärt ein Artikel auf Berea Street (engl.):

http://www.456bereastreet.com/archive/201112/the_difference_between_widthauto_and_width100/

9. Dezember 2011
von Marc Haunschild
Keine Kommentare

Gesundheitskosmos-Bonn.de

Ein richtig tolles Projekt hat Hanna Kocanis für Bonn auf die Beine gestellt. Im letzten Jahr hat sie bei mir erst HTML und CSS gelernt. Jetzt hat sie die Seite Gesundheitskosmos-Bonn.de eröffnet. In verschiedenen Rubriken erklärt sie den Gesundheitskosmos Bonn und wie man sich darin zurecht findet.

Natürlich würde ich mich über mehr solcher Beispiele von Teilnehmern meiner Kurse freuen – und werde gerne darauf verlinken!

7. Dezember 2011
von Marc Haunschild
Keine Kommentare

Autor für HTML5-Lehrbuch gesucht

 

 

für einen renommierten Lehrbuchverlag suche ich einen Autor, der HTML5 inklusive API, JavaScript-Script-Beispiele, Canvas, Offline-Features usw wortgewandt vermitteln kann.

Zur Abgrenzung: die semantischen Elemente werden in einem zweiten Buch erläutert, das vor kurzem erschienen ist.

Wer Komplexes leicht verständlich erklären kann und in HTML5 und JavaScript/AJAX fit genug ist, ein Fortgeschrittenen-Buch zu schreiben, kann mir bei Interesse einfach mailen.