Tags

#Web & Publishing

Alles rund um Websites, Publishing, CMS, Blogging und den technischen Unterbau des Webs.

Barrierefreiheit auf Knopfdruck (und KI)

Barrierefreiheit auf Knopfdruck (und KI)

Ich habe ein kleines Kirby-Plugin gebaut, das die Stellen übernimmt, die ich aus Zeitmangel wahrscheinlich seltenst ausgefüllt hätte, aber die schon auch wichtig sind: Via LLM von OpenAI kann ich jetzt Alt-Texte von Bildern per Button generieren lassen und wenn ich will, auch die Meta-Descriptions für Suchmaschinen. Und dabei habe ich wieder viel über Kirby gelernt und warum es eine gute Entscheidung war, zu wechseln.

Wenn ich etwas gar nicht schreiben würde, schreibe ich’s lieber mit LLMs, besonders da, wo Barrierefreiheit dranhängt. Nicht, weil ich es nicht könnte, sondern damit nichts liegen bleibt: Alt-Texte, Meta-Descriptions, diese stillen Pflichtfelder, die am Ende irgendwie auch wichtig sind, aber dafür auch noch einmal richtig viel Zeit kosten können, ohne das der eigentliche Beitrag davon auf den ersten Blick profitiert.

Aus dieser … nenne ich es einmal … Faulheit ist ein kleines Kirby-Plugin entstanden, das zwei Dinge zuverlässig erledigt: barrierefreie Alt-Texte für Bilder und sachliche Meta-Descriptions für Seiten. Auf Knopfdruck direkt im Panel.

Ich gebe dem Modell den vollen Kontext, setze Length-Guards und formatiere die Antwort passgenau: ca. 110 Zeichen für Alt, ca. 160 für Meta. Optional kann das Plugin das Bild als Data-URL mitschicken („Vision“), damit die KI nicht im luftleeren Raum rät.

Warum klappt das so erstaunlich gut? Weil Kirby Inhalte und Mediendaten wunderbar strukturiert. Alle Bild-Metadaten liegen in Sidecar-Contentdateien neben der Bilddatei, z. B. mein-foto.jpg.txt. Menschenlesbar, versionierbar, und serverseitig perfekt als Prompt-Kontext nutzbar.

Damit das sauber bleibt, habe ich zwei kleine Helfer daneben gelegt. Mein Plugin sync-meta hält Felder synchron, die sowohl in der Seiten-Contentdatei (default.txt) als auch in den Bild-Sidecars (bild.jpg.txt) vorkommen. Zum Beispiel liegt die Bildunterschrift bei einem Beitrag mit nur einem Bild in der Contentdatei, nicht in der Sidecar. Hintergrund ist, dass mein System historisch gewachsen ist und sich die Anforderungen, je besser ich Kirby kennenlerne, auch immer wieder anpassen.

Das Plugin exif-import sorgt dafür, dass Sidecars nicht leer starten: Beim Upload lese ich optional EXIF/IPTC aus und fülle Datum, Ort, Kamera, ggf. Caption vor – was immer das Asset hergibt. Danach muss die KI nicht mehr raten, sie ergänzt.

Der Generierungs-Flow ist bewusst serverseitig: Das Panel schickt nur IDs. Das Backend sammelt Kontext (Seitentitel, Teaser, Text, Bild-Captions, optional Geodaten), ergänzt auf Wunsch das Bild selbst und nutzt zentral gepflegte, nüchterne Prompts. Ton und Stil kann ich global in der config.php oder je Blueprint feinjustieren.

Wenn der Kontext zu dünn ist, breche ich ab, statt Floskeln zu produzieren. Und wenn ich „zu faul“ bin, drücke ich guten Gewissens auf „Vorschlagen“ – besser ein kurzer KI-Text als gar keiner. Genau dafür ist das da.

Am Ende schreibe ich weiterhin gern selbst, aber ich finde es sehr angenehm, Sachen zu automatisieren, die sonst aus Zeitgründen wegfallen würden. Barrierefreiheit profitiert (Alt-Texte sind da!) und mein Kopf bleibt frei für die Teile, die wirklich menschliche Aufmerksamkeit brauchen.

Basteln am eigenen Bloghaus

Basteln am eigenen Bloghaus

Seit ich von Wordpress weg bin, fühlt sich Bloggen wieder wie Basteln an. Kirby ist mein Werkzeugkasten, und aus Ordnern, Textdateien und ein paar Skripten wächst gerade mein eigenes kleines Zuhause. Zwischen Rückschlägen, Heureka-Momenten und schiefen Polaroid-Slidern macht das erstaunlich viel Spaß.

Ich bin immer noch ein bisschen berauscht von dem Gefühl, hier mein eigenes, kleines Zuhause zu bauen. Nicht mehr dieses sperrige Wordpress-Mietshaus, bei dem man immer gefühlt zur Verwaltung musste, wenn man nur eine Kleinigkeit anders haben wollte, sondern ein selbstgezimmertes Häuschen, das knarzt, wenn man die Treppe hochgeht, und trotzdem genau das richtige Licht in der Küche hat.

Das Fundament heißt bei mir Kirby. Für alle, die das nicht kennen: Kirby ist ein CMS, aber ohne Datenbank, ohne den ganzen aufgeblähten Kram. Alles liegt als einfache Textdatei in Ordnern. Jeder Beitrag ist ein Ordner mit einer txt, den Bildern und kleinen Zusatzdateien. Man schreibt direkt darein. Kirby liest das aus und baut daraus die Seite.

Die letzten Tage habe ich vor allem im Keller geschraubt: ein Exif-Import! Klingt trocken, fühlt sich aber an wie Magie. Plötzlich spuckt mein System beim Speichern eines Beitrags die Metadaten von Bildern aus, die ohnehin schon in den Dateien stecken. Ordnerstruktur, Textdateien, Bilder – alles in einem Takt. Und wenn ich ein Bild hochlade, schiebt sich wie von selbst das Aufnahmedatum oder der Ort dazu, fein säuberlich abgelegt.

Klar, Rückschläge gab’s auch. Im ersten Wurf dachte ich: alles in die Hauptdatei, passt schon. Bis mir auffiel, dass das ganze Konzept zerbröselt, sobald mehr als ein Bild im Beitrag auftaucht. Also wieder zurück ans Script, Schraubenschlüssel gezückt, und die Infos in die Bild-Textdateien verschoben. Seitdem erscheinen sie automatisch unter den Fotos. Nur die Alt-Texte und die Bildunterschriften hängen gerade noch am selben Tropf. Da muss ich noch mal ran, denn Alt-Text ist nüchtern, Bildunterschrift eher Bühne. Und da will ich mal schauen, ob ich die API von OpenAi da nutzen kann, um beispielsweise halb automatisch die Alt-Beschreibungen oder aber auch die Metadescription generieren zu lasse .

Nebenbei bastle ich am Layout. Erst hatte ich für die Bilddarstellung ein Polaroid über die gesamte Bildschirmbreite, dann festgestellt: zu plump. Jetzt baut mein Script munter Slider, wenn mehrere Bilder hintereinander auftauchen. Das ist noch nicht ganz elegant, aber fühlt sich schon viel mehr nach meinem Blog an – ein bisschen wie die Entscheidung, ob man im Wohnzimmer Teppich oder Parkett verlegt.

Und dann dieser kleine Zaubermoment: Ich lasse mir von Kirby eine optimierte Bildversion rechnen, damit die Seite fix lädt. Klickt man aufs Bild, springt die große Datei nach, und dieser Mini-Moment des Nachladens macht mich jedes Mal froh. Es ist wie ein Augenzwinkern des Systems: „Siehst du, so einfach kann’s gehen.“ Hach.

Back to the blog

Back to the blog

Ich habe mich immer wieder beim Warten erwischt. Instagram ist doch viel zu kommerziell, Mastodon, Bluesky und Threads wollen irgendwie alle vom Twitter-Exodus…

Ich habe mich immer wieder beim Warten erwischt. Instagram ist doch viel zu kommerziell, Mastodon, Bluesky und Threads wollen irgendwie alle vom Twitter-Exodus profitieren und die Zeiten der großen Lagerfeuer-Netzwerke scheint ja sowieso vorbei zu sein.

Und anstatt weiter zu warten und zu schauen, wie sich was entwickelt, habe ich mir jetzt mithilfe der tollen Indieweb-Community was Eigenes hier zusammengezimmert. Das Prinzip heißt POSSE: Publish on your own site, syndicate everywhere. Ich schreibe hier auf hnz.io und versuche möglichst automatisiert dahin zu posten, wo es meine Leute auch sehen. Klingt und ist sehr oldschool, aber deshalb für mich auch eher befreiend. Wenn ihr wisst, was ich meine. Auch wenn ich Pixelfed super finde, es fühlt sich da doch manchmal recht einsam an. Und wenn es die APIs hergeben, werden die Reaktionen hierher zurückgespielt.

Was bisher geschah

Verlinkte Listen in Wordpress automatisch generieren

Verlinkte Listen in Wordpress automatisch generieren

Manchmal benötigt man in Wordpress Strukturen, die spezieller und kleinteiliger sind, als die üblichen Kategorien/Tag-Zuweisungen. Mit ein paar Umwegen und dem Plugin ACF ist es auch Wordpress möglich, contentabhängige Listen zu generieren.

Wenn ich mir kleinere und moderne Content-Management-Systeme wie beispielsweise http://de.processwire.com anschaue, bin ich schon etwas neidisch:

Bei Processwire gibt es keine vorgefertigten Feldtypen; man muss sie bei jedem Projekt neu aufbauen. Das führt dann dazu, dass http://demo.processwire.com eben durch die enorm vereinfachte Felder-Philosophie ziemlich schnell umgesetzt sind. https://www.youtube.com/watch?v=IHqnLQy9R1A&list=PLo7Qkm2fy7zDdXCHTBUZXG7C3poa3efAQ&index=2.

Eine Webseite für einen speziellen Kundenwunsch hätten wir damit wunderbar umsetzen können, wenn wir a) die Zeit gehabt hätten uns in Processwire intensiv einzuarbeiten und b) wir nicht so auf Wordpress stehen würden.
Die Voraussetzungen

Die Kunden hatten eine alte Seite mit ziemlich vielen Daten, die in Beziehung miteinander stehen. Wenn wir uns auf die Processwire-Demo-Seite von oben beziehen: eine Seite mit Hochhäusern. Jeder Stadt sind dort Hochhäuser zugeordnet. Jedem Hochhaus eine spezifische Höhe, ein Baujahr und die Architekten. Diese spezifischen Daten sind wiederum untereinander verknüpft: Es gibt Übersichtsseiten über Architekten und welche Häuser sie entworfen haben, wie auch Seiten mit Häusern gleicher Höhe.
Das Problem

Das Problem an der Sache war, dass die gesamten Daten der alten Kundenseite via PHP aus Text-Dateien ausgelesen wurden und bei Syntaxfehlern natürlich das ganze Beziehungsgeflecht kaputt gemacht werden konnte. Deshalb hatte der vorherige Entwickler gesagt: Ihr dürft das nicht ändern, ich mach das gerne für euch.

Der Kunde möchte es aber bei einer Wordpress-Seite selbst ändern.
Die Vorüberlegungen

Uns ist es enorm wichtig, wenn nicht sogar am wichtigsten, dass die Update-Fähigkeiten unserer Wordpress-Seiten gewahrt bleiben. Deshalb sind Frickeleien am Core natürlich tabu und auch Plugins werden bei uns nur entwickelt, wenn es zu diesen einen längerfristigen Service & Wartungsvertrag gibt.

Wir brauchen eine flexible Lösung, die quasi das Kategorie/Tag-System von Wordpress aufbohrt. Zusätzlich soll der Inhalt nur an speziellen Positionen im Template ausgeben werden und jederzeit selbst von dem Kunden gepflegt werden können.

Und es klappt!
Die workin media Lösung

Viele, die sich schon intensiver mit Wordpress auseinandergesetzt haben, kennen mit Sicherheit das Plugin http://www.advancedcustomfields.com von Elliot Condon. Damit kann man relativ simpel neue Inhaltsfelder generieren um nicht-statische Inhalte an fixen Positionen im Layout auszugeben.

https://workin-media.hnz.io/wp-content/uploads/2015/06/advanced-custom-fields.png Ansicht des Plugins im Backend.

Jedem Feld kann dort ein Label zugeordnet werden. Wir haben nun das Beispiel „Hochhaus“ genommen und als Checkbox angelegt: Jedes Hochhaus ist dort seiner Seite zugeordnet (siehe links).

Wenn man nun eine neue Seite erstellt, beispielsweise „New York City“, dann kann dort der Nutzer „Park Avenue“ und „Chrysler Building“ anhäkeln; denn wir wissen ja alle, dass das AT&T Corporate Center in Chicago steht.

Diese manuelle Zuordnung mussten wir so implementieren, weil bei unserem Kunden, anders als bei den Hochhäusern, sich die Elemente einer Kategorie oft verändern können und er so die Möglichkeit hat auf der Seite, auf der sie ausgegeben werden, die Inhalte zu definieren.

Die Ausgabe haben wir mit folgendem Code in der function.php des aktiven Themes gesteuert:

// Add Shortcode
function hochaus() {

$values = get_field('Hochaus');
$field = get_field_object('Hochhaus');
$label = $value[$key];

if($values) {
echo '
';
foreach($values as $value)
{
echo '- ' . '[' . $value . '](' . $value . ')' . '
';
}
echo '
';
}
}
add_shortcode( 'hochhaus', 'hochhaus' );

Was macht der Code? Er erstellt über den Shortcode eine Liste, mit allen angehäkelten Häusern an der Position des Shortcodes. Außerdem verlinkt er sie zu dem Linkziel, das im ACF definiert wurde.
Wofür eignet sich die Methode?

- Darstellung kleinerer Inventarlisten

- Zuordnung verschieder Datenpunkte

- Flexible Handhabung/Pflege der Ausgabe

Bildnachweis: https://pixabay.com/de/einstellungen-optionen-software-265131/