Archiv der Kategorie: Barrierefreiheit

Konform zu WCAG: Kontrastfarben automatisch berechnen

Ich bin darauf hingewiesen worden, dass mein Color Tool für barrierefreie Kontrastfarben im WEB nicht der aktuellsten Version der WCAG entspricht. OK, hab ich ein bisschen recherchiert und umgestrickt. Was früher als Brightness gehandelt wurde, heißt jetzt Luminescence und wird etwas anders berechnet. Zum Vergleich der Schrift- und Hintergrundfarbe wird eine Ratio herangezogen, 4.5:1 entspricht AA, 7:1 enspricht AAA. Die Berechnung ist im Ganzen etwas komplexer geworden, aber doch kein Hexenwerk. Nachlesen kann man die nötigen Formeln hier:
https://www.w3.org/WAI/GL/wiki/Relative_luminance

Das Kernstück ist die Formel zur Umrechnung des RGB-Wertes aus dem Colorpicker in WCAG-konforme Lumineszenz, die sieht so aus:

function Luminescence($r, $g, $b) //neuere Definition nach wcag s. a. https://www.w3.org/WAI/GL/wiki/Relative_luminance

 {
 $rs = $r/255;
 $gs = $g/255;
 $bs = $b/255;
 
 if ($rs <= 0.03928)
 {
 $R = $rs/12.92;
 }
 else {
 $R = (($rs+0.055)/1.055) ** 2.4;}
 
 if ($gs <= 0.03928)
 { $G = $gs/12.92;
 }
 else {
 $G = (($gs+0.055)/1.055) ** 2.4;
 }
 
 if ($bs <= 0.03928){
 $B = $bs/12.92 ;}
 else 
 {$B = (($bs+0.055)/1.055) ** 2.4;}

 $Lumi = 0.2126 * $R + 0.7152 * $G + 0.0722 * $B;
 
 return $Lumi;
 
 
 }

Dann braucht man noch die Formel für die Contrast Ratio, die findet sich hier im WCAG-Wiki. Damit kann man sich einstellen, ob man AA oder AAA kompatibel sein möchte, und das wars dann auch im Grossen und Ganzen.

if ($input_luminescence >= $row_luminescence){
  $ratio = ($input_luminescence+0.05)/($row_luminescence+0.05);
  }
 else
 {
 $ratio = ($row_luminescence+0.05)/($input_luminescence+0.05);
 }

 if ($ratio>4.5){ //Nur die Farben nehmen bei denen die Ratio grösser als 4.5 ist
...

Viel Spaß beim Ausprogrammieren!

Barrierefreie Farbkontraste 2: der Sourcecode

OK jetzt gilts: man kann eine beliebige RGB-Farbe wählen und sich ausgeben lassen, welche der 140 benannten HTML-Farben einen guten (barrierefreien) Kontrast dazu liefert. Das kann man nicht nur für Schriften verwenden, sondern auch für Logos und Icons, die auf einen farbigen Hintergrund gesetzt werden sollen.

Voraussetzung ist eine Tabelle, in der die 140 Farben mit Color Group (Farbfamilie), Namen und Hex- und RGB-Notation gespeichert sind, ich zeig hier noch mal einen Ausschnitt:

mysql_farbtabelle

Wie die Farben da reinkommen beschreibe ich jetzt hier nicht, das ging über ein Excel-Makro und ist letzendlich völlig wurst für die Funktionalität. Also, wir haben unsere Farbtabelle.

Jetzt brauchen wir eine Datenbankverbindung, die beschreibe ich hier auch nicht mehr extra. Dann muss wieder mal ein Formular her, für die Auswahl der Basisfarbe bietet sich der Input-Type Color an, bei dem man in den meisten modernen Browsern einen schicken Colorpicker angezeigt bekommt. Man könnte auch ein Eingabefeld für den Hex- oder RGB-Wert nehmen, das ist letztlich Geschmackssache. Also, los gehts, mit einer Datei namens farbnamen.php, die sieht zunächst so aus:

<!DOCTYPE html>
<html lang="de">
<style type="text/css">
h1,h2,h3{
    font-family:Arial;
}
</style>
<head>
<title>Colors Arbeitspapier</title>
</head>

<body>
<h1>Beispiel Contrast Colors mit HTML Named Colors</h1>

<form action="farbnamen.php" method="post">

      <h2>Bitte eine Farbe auswählen:</h2>
      <input type="color" name="farbe" value=""><br>
      <h2>Bitte eine Farbfamilie für die Kontrastfarbe wählen:</h2>
    <select name="farbfamilien">
        <option value="BLUE">Blau</option>
        <option value="GREEN">Grün</option>
        <option value="PURPLE">Violett</option>
        <option value="WHITE">Weiß</option>
        <option value="BROWN">Braun</option>
        <option value="YELLOW">Gelb</option>
        <option value="GRAY">Grau</option>
        <option value="RED">Rot</option>
        <option value="PINK">Pink</option>
        <option value="ORANGE">Orange</option>
      </select>
     <br><br>
    <input type="submit" name = "senden">
  
</form>

Das ist erstmal straightes HTML, zuerst kommt der Color Picker, dann das Dropdownfeld für unsere Farbfamilien, und das wars auch schon. Man könnte den Select auch mit einem Distinct aus der Datenbank füttern, das hab ich mir jetzt gespart und die 10 Einträge so reingeschrieben.

Los geht es wie immer wenn auf den Submit-Button geklickt wurde. Der Colorpicker liefert den Hex-Wert der gewählten Farbe, das Dropdownfeld den Namen der Farbfamilie. Den Hex-Wert zerlege ich in die einzelnen Komponenten, die brauche ich später um meine Funktion zur Berechnung der wahrgenommenen relativen Helligkeit damit zu füttern, dazu weiter unten mehr. Das Ganze sieht jetzt erstmal so aus:

startbildschirm

Bei Klick auf das schwarze Farbkästchen poppt der Colorpicker auf, in Chrome beispielsweise sieht der so aus:

chrome_colorpicker

Das Dropdownfeld ist auch keine Überraschung:

dropdown

Aber jetzt wirds gleich interessant, ich habe nämlich für die Zerlegung des Hex-Wertes in seine RGB-Komponenten eine schicke Funktion gefunden, das geht mit sscanf():

<?php
require_once('config.php');

if(isset($_POST['senden'])){
    
    
    echo "Sie haben diese Farbe gewählt:<span style='background-color:".$_POST['farbe']."'>Hexadezimalwert: ".$_POST['farbe']."</span><br>";
    
    $akt_farbe = $_POST['farbe'];
    
    //RGB-Werte aus hex holen
    $hex = $akt_farbe;
    list($r, $g, $b) = sscanf($hex, "#%02x%02x%02x");
        
    echo "<h3>Die relative Helligkeit beträgt: ".Brightness($r,$g,$b)."</h3>";
    echo "<h3>Kontrastfarbe aus der Farbfamilie ".$_POST['farbfamilien']."</h3>";
    echo "<hr>";
    $input_brightness = Brightness($r,$g,$b);

Mit der Funktion Brightness wird wie gesagt die wahrgenommene Helligkeit der gewählten Farbe bestimmt, Input-Parameter sind die drei RGB-Komponenten. Die Funktion selber sieht so aus:

//relative (wahrgenommene) Helligkeit aus RGB berechnen
function Brightness($r, $g, $b)
    {
       return sqrt(
          $r * $r * .241 + 
          $g * $g * .691 + 
          $b * $b * .068);
    }

Jetzt hole ich mir aus der Datenbank alle Farben, die zu der gewählten Farbfamilie gehören. Zuerst setze ich noch einen Flag $gefunden, der bleibt auf False wenn in der gewählten Farbfamilie keine Farbe mit einem ausreichenden Kontrastwert gefunden wurde und dient dann weiter unten zur Info-Ausgabe.

Dann gehe ich mit einem While über alle gefunden Farben und gebe nur diejenigen aus, bei denen eine Differenz > 130 zur relativen Helligkeit der vom Benutzer vorgegebenen Farbe gefunden wird.

//alle passenden Einträge der Farbtabelle ausgeben
        //Flag default  
        $gefunden = false;
        
        //Nur die Einträge der gewählten Farbfamilie auslesen
          $abfrage = mysqli_query($conn,"SELECT * FROM $table 
                    WHERE familie LIKE '".$_POST['farbfamilien']."' "); 
          while($row = mysqli_fetch_array($abfrage,MYSQLI_ASSOC)) 
          { 
            //RGB-Werte aus hex holen
            $hex = $row['hex'];
            list($r, $g, $b) = sscanf($hex, "#%02x%02x%02x");
            //Helligkeit bestimmen
            $row_brightness = Brightness($r,$g,$b);
            
            //Kontrastwert berechnen
            $differenz = abs($row_brightness - $input_brightness);
            
            //Nur Kontrast höher als 130 ausgeben (Wert ggf anpassen)
            if ($differenz > 130){
                //flag setzen wenn mindestens ein Kontrast > 130 gefunden wurde
                $gefunden = true;
            echo ' <span style="color:'.$row['farbname'].'">'.$row['farbname'].'</span>.'.$row['hex'].'rel. Helligkeit: '.$row_brightness.' Differenz: '.$differenz.'<br>'; 
            echo "<h1><span style='color:".$row['farbname']."; background-color:".$akt_farbe."'>".$row['farbname']." ist ein guter Kontrast</span></h1>";
            echo "<hr>";
            }
            
        } // ende von while $row...
if($gefunden==false){echo "Keine passende Kontrastfarbe in der Farbfamilie ".$_POST['farbfamilien']." gefunden";}

} //Ende von isset senden

Für die Ausgabe der passenden Kontrastfarben verwende ich Spans und formatiere sie mit den entsprechenden Farbwerten. Falls keine Farbe mit ausreichendem Kontrast gefunden wurde, gebe ich dies als Info aus. Das war’s!

Hier noch ein Screenshot der Ausgabe, als Besipiel habe ich als Grundfarbe Gelb und für die Kontrastfarbe die Farbfamilie Blau gewählt:

farben_ausgabe

Fertig ist das Werkzeug zur Kontrastfarbenbestimmung. Zugegeben könnte man es noch wesentlich hübscher formatieren, aber die Funktionalität haut hin, das genügt mir jetzt erstmal. Schlanke noch nicht mal 100 Zeilen Code, das ist mal wieder was für mich und meine minimalistischen Freunde – viel Spaß beim Nachbauen!

Nachtrag

Jetzt konnte ich mir es doch nicht verkneifen, die ganze Sache noch ein bißchen ansehnlicher zu gestalten. Der Prototyp sieht jetzt so aus:

aufgehuebscht

Die Farben hole ich mir natürlich aus der Datenbank, wenn ich dazukomme, schreib ich noch einen neuen Artikel darüber. Aber hier ist jetzt mal Schlussende, der Beitrag ist lang genug

Barrierefreie Farbkontraste – ich hab da so ne Idee

Also, wie man ausrechnet ob auf einem farbigen Hintergrund eine schwarze oder weiße Schriftfarbe besser lesbar ist, das hatten wir ja gerade eben schon mal. Jetzt ist der Kunde aber König, und man kommt auch mal in die Verlegenheit, eine farbige Schrift auf farbigem Grund darstellen zu sollen. Die Anforderung könnte also heissen: es soll eine grüne Schrift auf rotem Grund ausgegeben werden, und die soll möglichst gut lesbar sein. Da kann man einen Colorpicker nehmen und so ungefähr schauen was besser lesbar ist, aber das ist ja doch bloß Trial&Error. Es gibt auch Formeln, mit denen man so etwas berechnen kann, fündig wird man z.B. beim W3C, oder auf dieser Seite von nbtech. Nach deren Algorithmus kann man die „perceived brightness“, also die wahrgenommene Helligkeit einer Farbe als Wert zwischen 0=schwarz und 255=weiß berechnen. Das ist nicht trivial, weil z.B. grüne Töne vom menschlichen Auge als heller wahrgenommen werden als rote Schattierungen. Darum berechnet man die jeweilige wahrgenommene Helligkeit, und vergleicht die Farben dahingehend. Ein Unterschied von ca. 120 zwischen den zwei Farben wird nach W3C als ausreichender Kontrast angesehen. Die Formel lautet wie folgt:

brightness = sqrt( .241 R² + .691 G² + .068 B² )

sqrt ist die Quadratwurzel, R, G, B sind unsere guten alten Bekannten Rot- Grün- und Blauanteil aus dem RGB-Farbraum, wie wir sie in HTML so gerne verwenden (ausführliche Infos hierzu z.B. hier bei W3Schools)

Gar nicht so einfach: was ist Rot, was ist Grün?

Auch das ist nicht trivial, weil von der Meinung des Betrachters abhängig. Ein dunkles Rotbraun mag für einen noch als Rot durchgehen, der nächste ordnet es schon den braunen Tönen zu. Ein sonniges Gelb kann auch als Orange gelten, und ein blaustichiges Grün als Blauton herhalten. Sowas kann man nicht berechnen, da kann man sich nur eine Krücke suchen und daran festhalten. Bei den 16,7 Mio vorhandenen RGB-Farben ist es auch ein Ding der Unmöglichkeit, überall die korrekte Farbfamilie zu bestimmen. Wir nehmen ein paar Farben weniger, das tuts als Arbeitshypothese auch.

Eine Untermenge: die benannten HTML-Farben

Ich habe da eine interessante Zusammenstellung der benannten HTML-Farben im Web gefunden. Bei https://htmlcolorcodes.com/color-names/ gibt es eine Tabelle der von allen modernen Browsern unterstützten benamsten Farben, die nach Farbfamilien (Color Groups) gruppiert ist. Auch bei w3schools gibt es eine gut gestaltete Seite über die Color Groups, nur sind sie da ein bißchen anders zusammengefaßt.

Die Seite von htmlcolorcodes.com habe ich mir mal als Arbeitsgrundlage geklemmt und in eine Datenbanktabelle gejagt. Es sollten eigentlich 140 Farben sein, auf der Seite sind aber 143 Farben aufgeführt. Die Tabelle enthält Duplikate, da werden Farben unter zwei verschiedenen Farbfamilien genannt. Ist jetzt aber nicht so schlimm, letztendlich ist die Information wertvoll, welche Farbtöne als Rot, Blau, Gelb usw. empfunden werden. Es gibt eine Liste von 10 Farbfamilien. Ich werde bei den englischen Bezeichnungen bleiben, schliesslich sind auch die HTML-Farbnamen in Englisch.

Hier mal die Liste der Farbfamilien, mit der jeweiligen Anzahl der zugeordneten Farben:

YELLOW   11
WHITE   17
RED   9
PURPLE   19
PINK   6
ORANGE   6
GREEN   23
GRAY   10
BROWN   17
BLUE   25

Wie gesagt, die Summe ist hier 143, nicht 140, aber das vernachlässigen wir jetzt mal. Dass Blue die meisten Farbtöne zugeordnet hat verwundert auch nicht weiter, da Blau nunmal eine sehr beliebte Farbe bei Webdesignern und Grafikern ist und im Web sehr häufig verwendet wird.

Wer sagt, dass das Rot ist?

Unter der Farbfamilie „Red“ sind 9 benannte Farben zu finden:

family_red

Da sieht man schon, daß die Zuordnung der einzelnen Farbtöne zu denen Farbfamilien ausgesprochen subjektiv und diskutabel ist, Lightcoral würde ich eher unter Pink einordnen. Wenn man sich die RGB-Werte dieser Farben anschaut, wird man auch nicht schlauer.

red_family_rgb

Es ist mitnichten so, dass diese Farben alle einen besonders hohen R-Anteil haben, Darkred ist zum Beispiel so ein Ausreisser mit 139 als R-Wert, dafür sind die G-und B-Werte Null. Ich hab lange rumgesucht, aber bisher keine praktikable Berechnungsmethode gefunden, mit der man x-beliebige Farbtöne einer der obengenannten Farbfamilien zuordnen kann. Deswegen verwende ich die Zuordnungen von htmlcolocodes.com, da hat man zumindest mal einen Anhaltspunkt.

Und wozu das Ganze?

Ganz einfach: mir schwebt sowas wie ein spezialisierter Colorpicker vor, in dem man eine frei wählbare Farbe vorgibt. Dann wählt man aus, aus welcher Farbfamilie die Kontrastfarbe kommen soll, und erhält einen oder mehrere Vorschläge, welche Farbtöne einen guten Kontrast bieten würden. Das als Arbeitshypothese. Mal sehen, wie weit ich damit komme.

Die Voraussetzung: eine MySQL-Tabelle mit allen 140 benannten Farben

Diese enthält die Farbfamilie, den Farbnamen, den Hex-Wert und den RGB-Wert. Die habe ich natürlich nicht per Hand eingehackt, da habe ich einen kleinen Umweg über ein Excel-Makro genommen, mehr wird nicht verraten. Die Tabelle sieht so aus, die Feldnamen sind selbsterklärend:

mysql_farbtabelle

Das wird meine Ausgangsbasis. Und ich komme mit unter 100 Zeilen Code aus. Den Source gibt es dann im nächsten Beitrag.

Das kann ich einfacher: Kontrastfarbe berechnen

Heute war in The Whip (Ausgabe 759) ein Artikel darüber, dass Lyft ihren ColorBox-Algorithmus zur Berechnung der optimalen Kontrastfarbe Open Source zur Verfügung gestellt hat, hier mal der Link zum Artikel:

Lyft Open Sources ColorBox Algorithm for Building Accessible Color Systems

Ziel der Sache ist, schwarze oder weiße Schrift auf farbigem Grund mit einem Farbkontrast darzustellen, der möglichst gut lesbar und damit barrierefrei ist.

Ich hab mir den Source auf Github natürlich gleich mal angesehen, schließlich habe ich vor nicht allzulanger Zeit hier ein kleines Javascript vorgestellt (Kontrastfarbe automatisch berechnen) das genau diesen Zweck erfüllt. Was soll ich sagen, das Skript von Lyft ist recht eindrucksvoll und etliche Seiten lang. Ich mach das selbe, mit weniger als 80 Zeilen Sourcecode, und davon ist noch die Hälfte für die HTML-Ausgabe. Warum umständlich, wenns auch einfach geht 🙂

Ein dicker, fetter WordPress-Bug: die Sache mit den Alt-Texten

Warum sind Alt-Texte so wichtig?

Wenn man Bilder in seine Webseite einfügt, kann man viel falsch machen. Zum Beispiel (was in WordPress leicht passiert) keinen Alt-Text einfügen, oder nur einen kryptischen Dateinamen wie DSC73635.JPG, so wie es aus der Digicam kommt, verwenden. Dabei ist der Alt-Text immens wichtig, wenn man barrierefreie Webseiten gestalten will, weil er für User von Screenreadern und anderen Hilfsmitteln die einzige Möglichkeit ist, Informationen über Bilder zu erhalten. Und auch für nicht barierrefreie Seiten gilt: der Alt-Text ist nach W3C ein „required“ Attribut, also eine Pflichtangabe.

Bilder einfügen in WordPress: schnell mal drübergeklickt

WordPress bietet zwar beim Hochladen über die Mediathek die Möglichkeit, einen Alternativtext zum Bild einzugeben, aber es meckert auch nichts an wenn man dieses Feld leer läßt und ein Bild ohne Alt-Text hochlädt. Hier gehört eine Prüfung hin, die den Anwender auf den Fehler hinweist!

Wenn sie übrigens beim Bilder hochladen vergessen haben, alt-Texte anzugeben, wird der jeweilige Dateiname dafür verwendet. Das ist gängige Praxis, aber nicht schön, weil der Screenreader dann eben -zig mal DSC01648 oder sowas vorliest, und das bringt natürlich überhaupt nichts.

Und sogar wenn man brav seinen Alt-Text eingibt, hat WordPress so seine Schwierigkeiten mit der Verwaltung. Das hatte ich in einem Beitrag über die Bildausgabe schon einmal erwähnt, aber es ist ein derart kapitaler Bug, daß ich ihn jetzt nochmal ausführlich beschreibe. Ich muß jetzt mal ein bißchen ausholen, um das näher zu erklären.

Wo landet der Alt-Text auf der Datenbank?

Zur Erinnerung: das Bild als solches landet in der wp_posts mit dem Post Type attachement. In der wp_postmeta gibt es dann tatsächlich noch einen Datensatz mit einem Fremdschlüssel, der die ID unseres Bild-Datensatzes aus der wp_posts enthält. Da wo im Feld meta_key das Schlüsselwort _wp_attachment_image_alt steht, da steckt daneben im Feld meta_value der alt-Text.

Das klingt soweit ja noch ganz gut, aber was, wenn man Alt-Texte nachträglich ändern will oder muß?

Dann passiert folgender blühende Unsinn:

Wenn sie jetzt im visuellen Editor hingehen und das jeweilige Bild bearbeiten, können sie zwar einen neuen, besseren alt-Text eingeben, aber der wird mitnichten in der Datenbank im Feld meta_value gespeichert! Der landet nur im img-src-Tag im post_content, und die Datenbank kriegt nichts mit davon. Wenn sie das Pferd jetzt andersherum aufzäumen und in der Mediathek das richtige Bild raussuchen, hier auf Bearbeiten gehen und da einen neuen alt-Text eingeben, landet der zwar in der Tabelle wp_postmeta (beim Metakey _wp_attachment_image_alt) aber nicht im Beitrag. Man müßte erst das betreffende Bild aus dem Beitrag löschen und aus der Mediathek wieder neu hereinnehmen, dann dürfte wieder das Datenbankfeld für den alt-Text herangezogen werden.

Übrigens: wenn sie den Alt-Text im visuellen Editor geändert haben und jetzt eine programmgesteuerte Ausgabe der alt-Texte via get_image_attribute() oder Ähnlichem probieren, kriegen sie natürlich die falschen Alt-Texte angezeigt, nämlich die aus der wp_postmeta, und nicht die aus dem img-src-Tag. Schöner Sch…, nicht wahr?

Konsequenzen dringend nötig

Das ist ein richtiger dicker, fetter Bug, da gibts kein Schönreden. Und es ist besonders ärgerlich, weil eben die Alternativtexte für die Barrierefreiheit so wichtig sind! Da dürfen sich die WordPress-Entwickler in Bälde etwas einfallen lassen, das Thema „Accessibility“, wie die Barrierefreiheit im Englischen heißt, ist auch in USA aktuell und taucht dort immer öfter in den Medien auf. Es gab auch schon spektakuläre Gerichtsurteile gegen Firmen, die ihre Webseiten nicht nach den Regeln der Barrierefreiheit gestaltet haben. Da darf man gespannt sein, wie der Gesetzgeber reagiert! Accessibility oder Zugänglichkeit von Webseiten ist eben ein brandaktuelles Thema, nicht nur bei uns.

In eigener Sache: Let’s talk about SEO, baby!

An diesem Wochenende hat mein Besucherzähler auf dieser Seite die 5.000er-Marke geknackt, und das ist eine respektable Zahl für einen sehr spezialisierten kleinen Blog wie den schwarzen Pinguin. Gezählt wird hier seit Februar diesen Jahres (2017), also hab ich hier rund gerechnet 5.000 Besucher in einem halben Jahr gehabt. Das freut mich persönlich sehr und ermutigt mich, mit meiner lockeren Plauderei über IT am Feierabend und WordPress im Speziellen weiterzumachen. Mir geht auch so schnell der Stoff nicht aus, keine Bange, nächste Woche gibts dann wieder Spaß auf der Datenbank!

Barrierefreiheit als SEO-Booster

Da wir gerade beim Thema sind: der Renner auf evileu.de ist nach wie vor das Inselfisch-Kochbuch mit aktuell 33.648 Besuchern, und da sind die Besucherzahlen nach einem eh schon guten Start nochmal kräftig in die Höhe gegangen, seit ich das Kochbuch in Sachen Barrierefreiheit komplett umgebaut habe. Auch nicht schlecht läuft meine Oddballs-Handarbeitsseite, hier sind es immerhin auch schon 11.297 Besucher in einem halben Jahr. Das ist wirklich nicht übel für eine rein private Webseite, und ich werde oft gefragt, wie ich das denn gemacht habe.

Meine SEO-Tricks

Da muß ich euch leider enttäuschen. Ich nutze kein SEO-all-in-one Pack, ich jongliere nicht mit Keywords, mir ist mein Google Ranking egal, ich schalte keine Werbung, ich mach das hier alles zu Fuß.

Was ich allerdings schon mache: ich blogge wie der Weltmeister. Im Inselfisch-Kochbuch gibts mindestens einmal die Woche ein neues Rezept, hier quassel ich auch ungefähr ebenso oft aus dem Nähkästchen der alten Programmiererin, und auf den Handarbeitsseiten gibts regelmäßig Fotos meiner aktuellen Socken, Schals und Pullover und gelegentlich auch mal eine neue Anleitung zum Download als PDF. Das heißt, auf meinen Blogseiten ist regelmäßig Neues geboten, und das lieben nicht nur die Suchmaschinen, das lieben anscheinend auch menschliche Besucher.

Beiträge mit Hand und Fuß

Und ich erzähle halt nicht nur irgendeinen Keyword-gespickten Quark, meine Beiträge haben (meistens) Hand und Fuß. Nach meinen Kochrezepten kann auch ein Anfänger kochen, wenn man einen Schal nach meiner Handarbeitsanleitung strickt, dann wird das auch was, und wenn man meinen Code hier nachprogrammiert, dann funzt das auch. Das ist mein ganzes Geheimnis.

Wiederholungstäter und Mundpropaganda

Das sind meine wichtigsten Werbemittel. Meine streng wissenschaftlichen Analysen (ich hab einfach viele Leute gefragt) haben ergeben, dass gerade das Inselfisch-Kochbuch durch Mundpropaganda immer mehr Besucher bekommt, besonders das mit der Barrierefreiheit spricht sich hübsch herum. Und dann kommen meine Besucher auch wieder, sie benutzen das Kochbuch als Nachschlagewerk. Ich hab jetzt schon von vielen weiblichen Fans gehört, dass sie im Supermarkt mit dem Smartphone schnell mal ein Rezept im Inselfisch-Kochbuch nachschlagen und schauen, was sie dafür einkaufen müssen. Da hilft es natürlich, dass ein sauber umgesetztes WordPress-Theme im Regelfall fully responsive ist und auch auf dem Smartphone vernünftig dargestellt wird.

Spezialisierung: ein Blog, ein Thema

Das mit der Spezialisierung war bei mir dringend notwendig, weil ich so breitgefächerte Interessen habe. Ich male, ich programmiere, ich koche für mein Leben gern, ich schreibe Bücher für Kinder und für Erwachsene und produziere Handarbeiten am laufenden Band, und das ist noch lang nicht alles.

Ich habe in früheren Jahren schon mehrere vergebliche Anläufe gemacht, alle meine Interessensgebiete auf einer einzigen Webseite unterzubringen, und bin jedesmal an dieser Sysiphosarbeit gescheitert. Letztendlich war Wordpress der Schlüssel für die erfolgreiche Realisierung des Gemischtwarenladens evileu.de.

Ich habe jedem meiner vielen Hobbies einen eigenen Blog gegönnt, in dem ich jeweils nur über ein einziges Thema blogge. Es sind jetzt insgesamt etwas mehr als 10 Blogs, nicht alle sehr aktiv, aber doch eine stolze Anzahl für eine private Homepage. Wenn man nur mal auf die Seiten über meine Malerei schaut, das Thema ist jetzt aufgesplittet in meine Biographie als Malerin, meine Aquarelle, die Serie mit den blauen Planeten und dazu noch die Computergrafiken mit GIMP. Das macht 4 Kunst-Blogs, und die sind alle proppevoll mit Bildern und meinen Texten dazu. Aber eben sauber nach Themen getrennt, sonst verzettelt man sich. Und auch die Besucher verzetteln sich wenn eine Webseite zu viele verschiedene Topics anbietet, da werden die Menüs und Untermenüs und Unter-Untermenüs so verschachtelt, dass kein Schwein mehr durchblickt, und die Besucher nicht wiederkommen, weil sie nichts wiederfinden.

Jetzt fahre ich da eine ganz klare Linie, und das hat für mich als viel-Bloggerin den Vorteil, dass ich sofort weiß wohin damit, wenn mir eine Idee zu einem neuen Beitrag kommt. Und meine Besucher kennen sich auch aus, da jeder Themenblog einen unverwechselbarenb Look&Feel hat, und man sofort weiß ob man auf der Handarbeitsseite oder im Inselfisch-Kochbuch gelandet ist. Ich bin ein Buchhalterkind, ich liebe strukturierte Ablagesysteme!

Damit sind wir ganz wunderbar beim nächsten Stichwort gelandet:

Strukturierung: h1, h2 und Co.: eigentlich HTML für Anfänger

Ob sie es glauben oder nicht, Textverarbeitung am Computer gab es schon lange vor Windows und WYSIWYG. Ich erinnere nur an TeX/LaTeX oder an Word für DOS, wo man mitnichten auf dem Bildschirm angezeigt bekam, was dann auf dem Drucker herauskam. Damals lernten wir alles über die Verwendung von sog. Textauszeichnungen, in Word für Windows heißen sie Formatvorlagen. Und da HTML nichts anderes als eine Textauszeichnungssprache ist, gibt es sie hier genauso. Jeder kennt sie, kaum jemand wendet sie richtig an. Für Überschriften sind h1..h6 vorgesehen, eine Tabelle formatiert man mit Hilfe des <table>-Tags, es gibt nummerierte Listen, es gibt Image-Tags für die Bilder… das sind viele, aber doch nicht endlos viele. Eine hübsche komplette Liste aller HTML5-Tags findet ihr hier bei MDN Web Docs

Trennung von Text und Formatierung

Die Idee dabei ist, Text und Formatierung sauber zu trennen. Ein einfaches Beispiel: eine Hauptüberschrift soll fett, in Arial und in 30 Punkt Größe angezeigt werden. Was macht der WYSIWYG-Anwender? Er markiert den betreffenden Textabschnitt, drückt auf das Icon für „fett“, wählt in der Dropdownliste für die Schriftart „Arial“ und scrollt in der Schriftgrößen-Zahleneingabe rauf bis 30. Das erzielt zwar den gewünschten Effekt, aber es ist textverarbeitungstechnisch nicht sauber. Wie gehts richtig? Die Überschrift kriegt die Tags <h1>…</h1>, und wenn man es nicht dem Browser überlassen will wie eine Überschrift erster Ordnung dargestellt wird, legt man es in seiner CSS-Datei fest. Hierhin kommen unsere Textattribute, wenn man es richtig machen will.

Saubere Gliederung

Das habe ich bei der Umarbeitung meiner Webseiten auf barrierefrei neu lernen müssen, bei mir hatte sich da über die Jahre auch eine gewisse Schlamperei eingeschlichen. Ich schreibe ja sehr viel Text, und lange Textwüsten auf einer Webseite sind absolutes Bildschirmgift, die liest kein Schwein. Also, umdenken, Text in kürzere logische Einheiten unterteilen, Zwischenüberschriften einfügen, wo es Sinn macht, Listen und Tabellen verwenden. Das erhöht die Lesbarkeit und hält den Besucher bei der Stange, weil er nicht von unstrukturierten Endlostexten gelangweilt wird.

Einfaches Beispiel: Rezepte mit Struktur

Ich hätte da wieder ein einfaches Beispiel: alle meine Rezepte im Inselfisch-Kochbuch haben die selbe logische Gliederung:

Einleitung
Zutaten
Zubereitung
Tipps

Diese Elemente sind als h2-Überschriften formatiert. H1 ist der Titel des jeweiligen Rezepts, das ist unser post_title aus WordPress. Der Text dazwischen ist einfach <p> wie Absatz. That’s all, nach diesem Muster schreibe ich alle meine Rezepte. Ich muß nicht drüber nachdenken wie ich es mache, und es hat bei meinem Publikum einen hohen Wiedererkennungswert und dient der allgemeinen Übersichtlichkeit und Verständlichkeit. Mehr ist nicht dran an der Strukturierung – machen muß man es halt!

Übrigens: Suchmaschinen lieben klar strukturierte HTML-Dokumente. Benutzer mit Handicap (Screenreader & Co.) lieben sie auch, weil sie so klar durch das Dokument navigieren können. Deswegen ist eine gute Textstrukturierung auch eine der wichtigsten Voraussetzungen der Barrierefreiheit nach WCAG.

Mehr ist nicht dran an meinem SEO-Programm

Mit dieser Strategie bin ich zu meinen stolzen Besucherzahlen gekommen, über alle Blogs gerechnet sind das jetzt insgesamt fast 50.000 seit Anfang des Jahres. Genug aus dem Nähkästchen geplaudert, ich mach hier mal die Kiste zu. Ich hab mir nämlich gerade ein neues Projekt in Sachen Barrierefreiheit angelacht, da hat der schwarze Pinguin jetzt ein bißchen Sendepause. Bis die Tage!

Wer schreibt schon Kommentare? Die Spam-Bots!

Das mit den Kommentaren in WordPress ist so eine Sache. Da haben sich die WordPress-Entwickler echt Mühe gegeben und so richtig rangeklotzt, das sieht man an den fein einstellbaren Optionen unter Einstellungen/Kommentare. Ja und wozu? Jetzt will sie keiner!

Meine E-Mail soll ich angeben? Nein Danke!

Erstens schreibt kein Schwein einen Kommentar, wenn er seine E-Mail-Adresse hinterlassen soll. Das kann man zwar ausschalten, aber es ist per Default aktiviert, und schreckt erfahrungsgemäß ganz viele Besucher ab. Niemand möchte sich ungefragte Werbemails und Newsletter einfangen, und eine E-Mail-Adresse ist schließlich eine sehr persönliche Information, die man nicht so ohne weiteres auf einer fremden Seite eingibt. Ausserdem gibt es wohl eine sehr hohe Hemmschwelle, auf fremden Seiten überhaupt Spuren zu hinterlassen. Die überwiegende Mehrzahl der Besucher bleibt lieber in der passiven Betrachter-Rolle und kommentiert auch dann nicht, wenn die E-Mail-Addi nicht abgefragt wird. Anders sieht das in den unzähligen gutbesuchten Hobby- und Freizeitforen aus, da ist die Hemmschwelle derartig niedrig, daß die Leute in den Forenbeiträgen über alles, aber wirklich alles plaudern. Scheinbar ohne sich dessen bewußt zu sein, daß JEDER ihre Beiträge lesen kann. Schauen sie mal bei chefkoch.de in die Plauderecke, dann wissen sie was ich meine…
Aber das ist jetzt ein bißchen sehr Off Topic, zurück zu unserer durchschnittlichen WordPress-Webseite.

Kommentare zu geschäftlichen Seiten – macht das überhaupt Sinn?

WordPress ist ja das ideale Frontend für überschaubare Webauftritte von kleinen Unternehmen und Selbständigen, für den Metzger und die Gaststätte um die Ecke, für das Lebensmittelgeschäft, die Autowerkstatt, für Ärzte, Anwälte, Steuerberater – was diese Kundschaft benötigt, ist einfach eine Visitenkarte im Internet, in der sich die Firma darstellt, und in der die relevanten Firmeninformationen (Geschäftsfeld, Angebote, Spezialitäten, Öffnungszeiten, Anfahrtskizze etc pp.) zu finden sind. Meistens ist noch ein einfaches Kontaktformular gefragt, und mehr nicht. Das geht sogar noch weiter: die Blog-Funktionalität von WordPress wird größtenteils kaum genutzt, ganz selten gibt es mal die Anforderung nach einer Seite mit aktuellen Informationen wie z.B. die Wochenkarte eines Restaurants oder das monatliche Mandantenrundschreiben eines Steuerberaters. In der Regel aber sind die WordPress-Seiten für kleinere Unternehmen statisch, erfordern keinerlei Interaktivität und möchten auch bittesehr keine Kommentare haben, die werden fast immer ganz deaktiviert, punktum.

Und wie ist das mit dem Spam?

Das hält sich dank Akismet, Antispam Bee und Konsorten in sehr überschaubaren Grenzen. Ein Spamschutz-Plugin ist ein Muß für jede WordPress-Webseite, die irgendeine Art von Kontaktformular anbietet. Aber die bekannten Spamwächter funktionieren absolut zuverlässig und sind völlig problemlos sowohl in der Installation als auch im laufenden Betrieb.

Und was ist mit Captcha als Schutz?

Mit Kanonen auf Spatzen geschossen. Ausserdem sind Captcha und reCaptcha und wie sie alle heissen unüberwindliche Hindernisse im Sinne der Accessibility/Barrierefreiheit. Einen sehr informativen Artikel hierzu finden sie hier bei bitv-lotse.de, und den empfehle ich jetzt als Abendlektüre.

Barrierefreiheit für den Hausgebrauch: ein Inhaltsverzeichnis V.01

Wozu ein Inhaltsverzeichnis?

Aber ich darf doch mal bitten, ein ordentliches Kochbuch braucht ein Inhaltsverzeichnis, in dem alle Rezepte alphabetisch aufgelistet zu finden sind! Wo man fix etwas nachschlagen kann wenn man ein bestimmtes Rezept sucht, wie zum Beispiel Lasagne unter Buchstabe L. Oder wo man auch mehrere Rezepte unter einem Begriff wie K wie Kartoffel… -suppe, -knödel, usw.findet.

Das brauchte ich auch für mein Inselfisch-Kochbuch, und hab logo schnell mal was programmiert. Meine Rezepte sind natürlich als Beiträge abgelegt, also ein beherzter Griff in die Tabelle wp_posts, und alle mit dem post_type „post“ und davon natürlich nur die veröffentlichten Beiträge, also post_status „publish“ rausgeholt. Alphabetisch sortiert nach Titel, von A wie Apfelkücherl bis Z wie Zwetschgenknödel, das war jetzt echt nicht weiter schwierig.

Das SQL-Statement

Das war wie gesagt ganz simpel:

SELECT * from wp_posts where post_status = ‚publish‘ and post_type = ‚post‘ order by post_title

Schon alles, mehr brauchen wir nicht.

Die foreach-Schleife

Die Ausgabe geht dann wieder mit einer foreach-Schleife, die sah am Anfang einfach so aus:

foreach ( $alleposts as $einpost ) 
{ 
 
  $url = get_permalink($einpost->ID);
  echo "<a href='".$url."'>", $einpost->post_title, '</a></br>';
}

Das mit dem get_permalink hatten wir schon, das holt uns die komplette URL zur ID des aktuellen Datensatzes. Daraus hab ich mit dem <a href…> und dem Beitragstitel flugs den Link zum Rezept gebastelt, und fertig war mein alphabetisches Inhaltsverzeichnis! Ich benamste es in IVZ kompakt, machte ein Plugin draus und fand es ganz toll.

ivz_B

Tscha, und dann kamen die netten Herren von der Pfennigparade und fanden das IVZkompakt prinzipiell eine gute Idee, aber sie hatten einige Verbesserungsvorschläge. Stellen sie sich einfach vor, sie müßten sich eine unstrukturierte (wenn auch alphabetische) Liste von über 200 Rezepten am Stück vorlesen lassen, dann können sie sich denken daß das nicht im Sinne der Barrierefreiheit ist. Also mußte eine Untergliederung nach Buchstaben her, und entsprechend Zwischenüberschriften. Als „nice to have“ wurde noch gewünscht, zu jedem Buchstaben auch die Anzahl der vorhandenen Rezepte sehen zu können, damit man selbst entscheiden konnte ob man da jetzt durch alle durchgehen oder lieber zum nächsten Buchstaben springen wollte.

Der Wunsch der netten Jungs war mir Befehl, ich habe das IVZ komplett umgestrickt, aber dafür gibts einen neuen Beitrag.

Barrierefreiheit für den Hausgebrauch: Strukturierung

Ich stehe beim großen Thema Barrierefreiheit zugegeben erst am Anfang, da gibt es noch viel zu lernen. Aber ich hatte tatkräftige Hilfe von der Stiftung Pfennigparade, die erfahrenen Programmierer dort haben mir viele wertvolle Tipps gegeben, so daß ich mein Inselfisch-Kochbuch zumindest barrierearm und auch für Menschen mit Handicap gut zugänglich gestalten konnte. Das war für mich ein großer persönlicher Erfolg, und ich freue mich über stetig wachsende Besucherzahlen. Es war aber auch ein Haufen Arbeit, und ich möchte hier einige Tipps geben, die es anderen WordPress-Entwicklern und auch privaten Anwendern vielleicht leichter machen, barrierearme Webseiten zu erstellen.

Von Anfang an gut strukturieren: HTML Bascis

Die allermeiste Heidenarbeit war es, die Beiträge in meinem Kochbuch im nachhinein durchzustrukturieren und sinnvoll zu formatieren. Ich habe über 200 Rezepte manuell anfassen müssen, weil ich sie im Lauf der Jahre einfach so als Fließtexte erfasst hatte und keine vernünftige Dokumentstruktur drin hatte. Dabei ist es eigentlich ganz einfach: längere Textpassagen sind mit Zwischenüberschriften zu untergliedern, und diese sind in HTML ganz schlicht als h1, h2, h3… h6 auszuzeichnen. Wobei ich mehr als h3 noch nie gebraucht habe, für die meisten Zwecke reichen zwei Überschriften-Ebenen vollkommen aus. Der Fließtext dazwischen wird sinnvollerweise als Absatz (<p>) formatiert. Für Aufzählungen nimmt man ein <ul>, für nummerierte Listen ein <ol>. Reinstes HTML-Basic! All diese Strukturierungselemente stehen im visuellen Editor einwandfrei zur Verfügung, nur benutzen muß man sie auch!

Anwendungsbeispiel Kochrezept

Ich zeige zuerst einmal, wie man es nicht macht. Dieser Rezepttext wurde einfach so heruntergeschrieben und mag jedem einigermassen erfahrenen Hobbykoch etwas sagen, aber er ist grottenschlecht im Sinne der Barrierefreiheit weil gar nicht strukturiert. Das geht schon damit los, daß die eigentliche Überschrift mit im Fließtext klemmt und nur fett hervorgehoben wurde. Auch der Rest des Rezepts ist schlicht gar nicht strukturiert, das wird einfach so heruntergeplaudert und man kann schlecht erkennen, wo es jetzt um die Zutaten und wo es um die Zubereitung geht, und was da sonst noch stehen mag.

Das unstrukturierte Rezept

Curry-Bananen-Dip zum Fondue, oder auch zu Gegrilltem. Man braucht dafür eine richtig reife Banane, am Besten schon ein paar Tage vorher kaufen und reifen lassen, bis sie schön weich ist und cremig wird. Banane mit Limettensaft mit einer Gabel fein zermusen, Salz und soviel Currypulver darangeben daß es deutlich scharf, aber noch angenehm schmeckt. Sofort servieren, oder den Dip mit zusätzlich etwas Limettensaft beträufeln, er verfärbt sich sonst braun. Nach einem guten, würzigen aber nicht penetranten Currypulver muß man ein wenig suchen, die aus dem Supermarkt sind meistens nicht so überragend. Wenn man kein anderes kriegt, eher weniger Currypulver verwenden und die nötige Schärfe mit ein paar Tropfen Tabasco oder etwas Sambal Oelek herbeizaubern.

Da muß Struktur rein! Ein Kochrezept besteht ja bei mir meistens aus 4 Komponenten:

einer Einleitung, in der ich ein paar nette Worte über Herkunft und Besonderheiten des Rezeptes erzähle,
einer Zutatenliste,
der eigentlichen Zubereitung
und dann noch ein oder mehrere Tipps zum Rezept.

Ja dunnerlittchen, da sind mir vielleicht die Schuppen aus den Haaren gefallen, als mir der nette Herr Programmierer von der Pfennigparade erklärte, daß das als Strukturierung vollständig ausreichte, ich müßte es nur auch in HTML umsetzen!

Und das geht so: Zwischenüberschriften rein und mit Überschrift 2 formatieren, Überschrift 1 ist schon vergeben, die hat in WordPress der Beitragstitel. Zutaten und Zubereitung klar trennen, die Tipps einzeln ans Ende setzen. Das sieht dann so aus:

Das gut strukturierte Rezept:

Curry-Bananen-Dip

Einleitung

Zum Fondue, oder auch zu Gegrilltem. Man braucht dafür eine richtig reife Banane, am Besten schon ein paar Tage vorher kaufen und reifen lassen, bis sie schön weich ist und cremig wird.

Zutaten

1 reife Banane, Saft 1 Limette, wenig Salz, 1-2 Teel. gutes Currypulver.

Zubereitung

Banane mit dem Limettensaft mit einer Gabel fein zermusen, Salz und soviel Currypulver darangeben daß es deutlich scharf, aber noch angenehm schmeckt. Sofort servieren, oder den Dip mit zusätzlich etwas Limettensaft beträufeln, er verfärbt sich sonst braun.

Tipp:

Nach einem guten, würzigen aber nicht penetranten Currypulver muß man ein wenig suchen, die aus dem Supermarkt sind meistens nicht so überragend. Wenn man kein anderes kriegt, eher weniger Currypulver verwenden und die nötige Schärfe mit ein paar Tropfen Tabasco oder etwas Sambal Oelek herbeizaubern.

Fazit

Da staunste, was? Die Strukturierung im Sinne der Barrierefreieheit hat das Rezept wesentlich übersichtlicher gemacht und auch für „normale“ Besucher besser zu lesen. Das ist übrigens ein angenehmer Nebeneffekt bei der Gestaltung im Sinne der Accessibility, wie das auf neudeutsch heißt: es tut der Lesbarkeit und der Verständlichkeit der meisten Texte gut, wenn man auf eine saubere Strukturierung achtet.

Aber trotzdem, 200 Rezepte nachträglich strukturieren, das mach ich nicht nochmal, das war eine Mordsarbeit. Jetzt schau ich halt, daß ich die Rezepte gleich von Anfang an richtig strukturiere und formatiere, und gut ists.

Mea culpa: warum dieser Blog alles andere als barrierefrei ist

Barrierefreiheit im Internet ist ein Thema, das mich in letzter Zeit sehr viel beschäftigt hat. Ich bin durch die Initiative „Bayern barrierefrei“ des Freistaats auf das Thema aufmerksam geworden, und halte es für immens wichtig. Auch Menschen mit Handicap haben ein Grundrecht auf Informationsfreiheit! Da ist Umdenken nötig, denn die meisten Webdesigner vergessen vor lauter SEO-Zirkus und Multimedia-Geblinker, daß es auch Benutzer gibt, die z.B. auf einen Screenreader oder eine Braillezeile angeweisen sind.

Mein Pilotprojekt

Ich habe in den letzten Monaten als Pilotprojekt mein Inselfisch-Kochbuch barrierearm gestaltet, und ich kann ihnen sagen: es war eine Heidenarbeit! Wenn ich dabei nicht so tatkräftige Unterstützung von der Stiftung Pfennigparade bekommen hätte, ich hätt’s aufgeben müssen. Dabei ist das mit der Barrierefreiheit, genauer gesagt: mit der Barrierearmut eigentlich gar nicht so schwer zu realisieren, es gibt einige nicht schwer zu begreifende Grundregeln. Wenn man die von Anfang an beachtet und z.B. seine Beiträge vernünftig durchformatiert und anständig gliedert, und auf aussagekräftige Alt-Texte bei den Bildern achtet, ist schon viel gewonnen. Wenn man das im Nachhinein korrigieren will, dann artet es in Arbeit aus. Ich habe über 200 Rezepte und -zig Bilder manuell durchgeforstet und überarbeitet. Es gibt leider keine Plugins, die einem die logische Gliederung von Texten abnehmen könnten, und wird sie wohl auch nie geben, da muß man schon selber ran. Ich versuche mir jetzt anzugewöhnen, von Anfang an strukturiert zu schreiben, weil ich die Ochsentour mit der manuellen Überarbeitung nicht nochmal durchziehen möchte, einmal hat gereicht.

Böse Sünde: Codeschnipsel als Screenshots

Das geht natürlich im Sinne der Barrierefreiheit überhaupt nicht. Screenshots sind ja auch nur Bilder, wenn da was zu Lesen steht, damit kann kein Screenreader etwas anfangen! Ich habe in diesem Artikel schon mal kurz darüber gemault, daß es einem WordPress so gnadenlos schwer macht, Programmcode vernünftig in einem Artikel darzustellen. Ich habe jetzt die Screenshots als Notlösung genommen, bin aber noch auf der Suche nach einer besseren Lösung. Vielleicht wäre es hilfreich, den relevanten Programmcode zu einem Artikel als Textdatei mit dranzuhängen, das wär schon mal besser als nix. Ich denke da an die vielen IT-Bücher, wo man die Codebeispiele als CD mitgeliefert bekommt… mhm, könnte gehen, wenn ich es mir recht überlege. Ich werde mal mit meinem Kontakt bei der Stiftung Pfennigparade darüber sprechen, da muß es einen vernünftigen Kompromiss geben, so daß ich ungehindert flüssig schreiben kann und trotzdem eine nach Möglichkeit barrierearme Seite dabei herauskommt.

Nachtrag: Habe nachgeforscht, leider scheint es wirklich keine andere Möglichkeit zu geben, als den visuellen Editor NICHT zu benutzen. Keine schöne Lösung… na ja, vielleicht finde ich noch ein Plugin, das den Programmcode nicht verhackstückt. Die Hoffnung stirbt zuletzt 😉

Und was hat das alles mit WordPress zu tun?

Mehr als sie denken. Letztendlich ist ja WordPress unser Werkzeug der Wahl zum Erstellen von Webseiten, und dazu gehört ein bißchen mehr als nur schicke Layouts und tolle Animationseffekte. Ausserdem verführt WordPress beim Hochladen von Bildern zur Schlamperei bei der Beschriftung. Von älteren Webdesignern (z.B. der gute alte NVU) wurde man noch gezwungen, beim Bilder einfügen zumindest einen Alt-Text einzugeben. Bei WordPress kann man da locker drüberklicken, die meisten Leute tun es auch weil ihnen nicht klar ist was ein „Alternativtext“ ist und wozu der gut sein soll.

Jetzt noch die gute Nachricht: es ist gar nicht so schwer, mit WordPress barrierearme Webseiten zu gestalten, wenn man es von Anfang an richtig macht. Die meisten modernen Themes sind gut strukturiert und mit <h1>, <h2>, <li> usw. sauber durchgegliedert, und sie sind auch mit der Tastatur bedienbar. Es gibt sogar spezielle Themes, die von Anfang an auf Barrierefreiheit zugeschnitten sind, aber da muß ich noch ein bißchen forschen, dann erzähle ich mehr darüber, ein andermal. Es wird wieder Zeit für ein bißchen Spaß auf der Datenbank!