Archiv für den Monat: September 2017

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.