Archiv der Kategorie: Wordpress

Gutenberg im Accessibility Test glatt durchgefallen

Der mit Spannung erwartete Testbericht des WordPress Accessibility Teams ist am 29.10. veröffentlicht worden, hier können sie die Details nachlesen:

Report on the Accessibility Status of Gutenberg

z:

Der wegen mangelnder Barrierefreiheit ins Kreuzfeuer geratene neue WordPress-Editor Gutenberg ist noch einmal auf Herz und Nieren getestet worden, und für nicht gut befunden. Joe Dolson zieht folgende Schlußbilanz:

“The accessibility team will continue to work to support Gutenberg to the best of our ability. However, based on its current status, we cannot recommend that anybody who has a need for assistive technology allow it to be in use on any sites they need to use at this time.”

Ich übersetze wörtlich:

“Das Accessibility Team wird weiterhin nach bestem Vermögen an der Unterstützung von Gutenberg arbeiten.  Wir können allerdings zum jetzigen Zeitpunkt, begründet in seinem aktuellen Status, nicht empfehlen dass ihn irgendjemand, der auf asssistive Technologien angewiesen ist, auf irgendeiner Webseite die benutzt werden muss einsetzt.”

Das, liebe Leser,  nennt man eine Klatsche, oder auch einen glatten Durchfall. Man darf gespannt sein, was dieses miserable Testergebnis für das für Mitte November geplante WordPress Release 5.0 bedeutet.

Gutenberg Adieu -wie man den ungeliebten Editor wieder los wird

In der gestrigen Ausgabe von The WHip war ein Artikel zur Deaktivierung des ungeliebten und umstrittenen neuen WordPress-Editors Gutenberg, den ich ihnen nicht vorenthalten will:

How to Disable the Gutenberg WordPress Editor (Need More Time)

Es geht darum, wie man den voraussichtlich ab Mitte November mit dem neuen WordPress-Release ausgelieferten Gutenberg deaktivieren kann. Zu diesem Zweck gibt es bereits zwei Plugins:

Classic Editor

Disable Gutenberg

Man ist also nicht auf Gedeih und Verderb auf den neuen Gutenberg angewiesen, sondern kann auf den klassischen WordPress-Editor zurückgreifen. Dies ist zumindest eine gute Interimslösung. Inwieweit zukünftige Gutenberg-Versionen für Benutzer mit assistiven Techologien benutzbar(er) sein werden, wird die Zukunft weisen. Bis dahin: Adieu Gutenberg, Welcome klassischer Editor !

Gutenberg gerät unter stärkeren Beschuss

Während das internationale WordPress Accessibility Team noch am Bericht über die letzten Gutenberg Barrierefreiheits Test feilt, hat sich überraschend Schützenhilfe von anderer Stelle angekündigt. Die Vereinigung der akademischen WordPress-Benutzer WPCampus hat in einem Bolgartikel vom 24. Oktober einen Accessibility Audit für den neuen WordPress-Editor eingefordert, nachzulesen hier:

WPCampus Releases Gutenberg Accessibility Audit RFP

WPCampus legt den Focus auf die Einhaltung des Barrierefreiheit  Level AA nach WCAG 2.0, und weist ausdrücklich darauf hin, dass eine Nichteinhaltung dieses Standards nicht nur nachlässig, sondern in vielen Ländern, besonders in USA und der EU, auch ungesetzlich ist. Da das nächste WordPress-Release 5.0 bereits für Mitte November geplant ist, ist der Einreichungsschluss für den  Audit auf 7. November gesetzt.

Währenddessen arbeitet das WordPress Accessibility Team mit Hochdruck am neuesten Testbericht über Gutenbergs mehr oder minder vorhandene Barrierefreiheit. Dies war auch das führende Thema der letzten Teamkonferenz am 26.10.  Und es sieht duster aus, die kürzlich stattgefundenen Accessibility Tests haben zum Teil verheerende Resultate geliefert. Es wurde wegen des knappen Zeitplanes darauf verzichtet, im Testbericht alle aufgefundenen Probleme aufzuführen, stattdessen konzentriert man sich auf diese fünf Themengruppen:

  • Cognitive Load & Complexity (kognitive Belastung &Komplexität)
  • Inconsistent User Interface Behavior (Unberechenbares User Interface Verhalten)
  • Dependency on Accessibility Anti-Patterns (Abhängigkeit von Barrierefreheits Anti-Mustern)
  • Dependency on Keyboard Shortcuts (Abhängigkeit von Tastaturkurzbefehlen)
  • Complex Keyboard Navigation Using Standard Methods (Hochkomplexe Tastaturnavigation mit Standardmitteln)

Der Bericht soll am nächsten Montag, den 29.10. 2018 veröffentlicht werden. Man darf gespannt sein, ob er die WordPress-Verantwortlichen zum Umdenken in Sachen Gutenberg bringt.

 

Gutenberg im Kreuzfeuer: wie barrierefrei ist der neue WordPress-Editor wirklich?

Auf dem letzten öffentlichen Meeting des internationalen WordPress Accessibility Teams am Montag, den 22.10.2018 wäre es beinahe zum Eklat gekommen. Auf der Agenda standen unter anderem:

“4. Communication plan for the Gutenberg accessibility feedback
5. Accessibility feedback on Gutenberg: be kind, open, transparent, professional”

Es ging also um die Umgehensweise mit dem neu entwickelten Editor Gutenberg, und dessen vorhandene oder nicht vorhandene Barrierefreiheit, die ja schon länger in der Öffentlichkeit thematisiert wird.

Dabei gerieten eine Vertreterin der User mit assistiven Technologien und ein Mitglied des Gutenberg Developer Teams heftig aneinander. Die Verteterin der gehandicappten Fraktion traf folgende Aussage  über das aktuelle Gutenberg -Release:

” I think that may be part of what is missing from all of this, referencing Joe‘s post about how individual parts of Gutenberg are great, but it’s the overall experience that causes significant issues.”

Ich übersetze wörtlich: “Ich denke, das ist einer der fehlenden Teile,bezüglich Joe’s Beitrag darüber, dass individuelle Teile von Gutenberg großartig sind, aber es ist die allgemeine Bedienbarkeit, die einen signifikanten Problemkreis dastellt”

Sie bezog sich dabei auf die letzten Tests, bei denen die mangelnde Tastaturbedienbarkeit einer der grossen Diskussionspunkte war.

Der Gutenberg-Entwickler argumentierte dagegen:

“Just a small note about Gutenberg accessibility VS classic editor. I don’t think it makes sense to compare how these two relates. Gutenberg is meant for the whole site editing (even if it’s not at the moment) which means it’s the customizer + editor + menus + widgets at the same time. So yes, it’s by definition more complex that’s why we can’t compare these two directly. We need to think about the whole picture”

Ich übersetze wörtlich:

“Nur eine Randnotiz über die Barrierefreiheit von Gutenberg gegenüber dem klassischen Editor. Ich glaube es macht keinen Sinn, diese beiden einem direkten Vergleich zu unterstellen. Gutenberg ist dafür gedacht, eine ganze Webseite zu editieren (auch wenn er es im Moment noch nicht tut), das heißt er ist der Customizer+Editor+Menüs+Widgets gleichzeitig. Also ja, er ist nach Definition komplexer (als der klassische Editor, Anm.d.Ü.), deswegen können wir die beiden nicht direkt miteinander vergleichen. Wir müssen an das gesamte Bild denken.”

In der darauf folgenden Debatte blieb der Gutenberg- Entwickler bei seinem Standpunkt, man könnte hier nicht Äpfel mit Birnen vergleichen, während die Vertreterin der User mit assistiven Technologien den Standpunkt vertrat, dass ein Vergleich zwischen dem klassischen Editor und Gutenberg nicht nur erlaubt, sondern essentiell notwendig sei.

Dabei argumentierte sie, dass Gutenberg den klassischen Editor ersetzen wird, und deswegen auch als Editor für Beiträge und Seiten in WordPress gewertet werden muss, egal was er sonst noch können sollte. Und als Beitrags-Editor ist Gutenberg nach dem jetzigen Stand der Dinge in Sachen Barrierefreihet noch meilenweit von WCAG-Standards entfernt, da eine durchgängige Tastaturbedienbarkeit nicht gegeben ist.

Die Debatte wurde nach einem kontroversen Schlagabtausch ohne Konsens durch den Diskussionsleiter beendet.

Meine persönliche Meinung dazu: warum soll Gutenberg in Zukunft als eierlegende Wollmilchsau fungieren und nicht nur das Editieren von Beiträgen, sondern auch die Umkonstruktion der gesamten Webseite erlauben? Ich halte das für blanken Unsinn, schließlich wollen meine Redakteure und Mitarbeiter einfach ihre Blog-Beiträge schreiben können, und sollen und wollen gar nicht in die Site-Architektur eingreifen. Der Schuß wird meiner Meinung nach nach hinten losgehen, denn wenn es jedem erlaubt wird, im Editor Menüs umzubauen, Widgets nach Belieben einzusetzen und im Customizer das Design der ganzen Site zu verändern, dann ist das Chaos vorprogrammiert.

Man kann gespannt sein, was die nächsten Accessibility Tests von Gutenberg ergeben – ich bin skeptisch. Man hätte bei der Neuentwicklung des Editors (auf Basis von React.js) von Anfang an die Barrierefreiheit mit berücksichtigen müssen. Sie jetzt nachträglich irgendwie aufzupfropfen kann eigentlich nur in die Hosen gehen. Ich bin schon sehr neugierig, wie sich die Debatte weiter entwickelt. Das nächste Accessibilty Team Meeting ist an diesem Freitag, ich werde teilnehmen und Bericht erstatten!

Bald 100.000 Besucher in meinem Inselfisch-Kochbuch

Wie einigen von ihnen vielleicht bekannt ist, betreibe ich seit einigen Jahren auf meiner privaten Webseite evileu.de ein barrierefreies Kochbuch, das Inselfisch-Kochbuch. Es ist ein WordPress-Blog mit mittlerweile über 300 Kochrezepten aus Bayern und aus aller Welt.

Das Inselfisch-Kochbuch

Das Kochbuch erfreut sich besonders seit der barrierefreien Umgestaltung Anfang letzten Jahres steigender Beliebtheit, und das ganz besonders bei Besuchern mit Handicap. Ich habe schon vielfache Rückmeldungen von sehgeschädigten oder anderweitig gehandicappeden Besuchern bekommen, dass das Inselfisch-Kochbuch auch mit einem Screenreader oder einer Braillezeile einwandfrei zu bedienen ist, und dass meine Rezepte leicht nachzukochen und gelingsicher sind.

Ich habe gerade meine Statistiken für diesen Monat ausgewertet: im Inselfisch-Kochbuch waren von Anfang 2017 bis heute mittlerweile 93.253 Besucher. Das ist für eine kleine, im ein-Frau-Betrieb geführte Webseite eine stolze Zahl, und ich freue mich sehr darüber. Die barrierefreie Umgestaltung das Inselfisch-Kochbuchs war eine Heidenarbeit, aber sie hat sich auf jeden Fall gelohnt!

Rian Rietvelds Rücktrittserklärung: autorisierte deutsche Übersetzung

Ich habe die soeben zurückgetretene ehemalige Chefin des WordPress Accessibility Teams gefragt, ob ich ihre Rücktrittserklärung ins Deutsche übersetzen und hier veröffentlichen darf, und sie hat mir ihr OK gegeben.

Hier zuerst der Link zu Rians Blogbeitrag vom 9.10.2018:

I have resigned as the WordPress accessibility team lead. Here is why.

 

Und hier folgt die deutsche Übersetzung:

Author Rian Rietveld Posted on 9 October 2018

Ich bin als Leiterin des WordPress Accessibility Teams zurückgetreten. Hier sage ich, warum.

Disclaimer: dieser Beitrag spiegelt ausschliesslich meine persönliche Meinung wieder

Nach mehreren Jahren der Arbeit an WordPress und Barrierefreiheit und der Beteiligung am Accessibility Team, habe ich die schwierige Entscheidung getroffen, das WordPress Accessibility Team zu verlassen. Ich bin es dem Team schuldig zu erklären warum ich diese Entscheidung getroffen habe und welche Hoffnung ich habe, dass sich die Dinge in Zukunft verbessern könnten.

Das letzte Jahr, insbesondre die letzten Wochen waren für mich zu sehr politisch kompliziert, da ist es besser wenn jetzt jemand anderer die Führung übernimmt.

In diesem Beitrag versuche ich eine Analyse dessen, was das WordPress Accessibility Team (wpa11y team) während der Entwicklung von Gutenberg getan hat und was die Probleme bei der Arbeit an seiner Barrierefreiheit waren.

Gutenberg

Als die Entwicklung von Gutenberg begann, verfolgte das wpa11y team den Fortschritt und testete, was da war. Und wir entdeckten, dass es viel zu verbessern gab. Also fing Andrea Fercia an, Tickets aufzumachen und Lösungen zu finden. Und das war eine gigantische Aufgabe.

Codebase

 

Wir hatten vier grosse Probleme:

 

Die Codebasis von Gutenberg ist für uns alle schwierig, weil niemand im wp11y team ein geschulter React Entwickler ist. Also war es sehr schwer, Änderungen zu implementieren und selbst PRs zu schreiben. Was wir tun konnten ist testen, sagen was falsch war und wie es sein sollte, und hoffen dass ein Entwickler das aufnehmen würde. Viel von der Arbeit des a11y teams ist vom Gutenberg Team getan worden, aber es gibt immer noch große Probleme.

 

Es gab keinen React Entwickler mit Barrierefreiheitskenntnissen in der Community, und keinen Barrierefreiheitsexperten mit React-Kenntnissen von ausserhalb der Community, der gewillt gewesen wäre, ohne Bezahlung an diesen Problemen zu arbeiten.

Funktionalität, die von Andrea getestet, verbessert und dann abgesegnet wurde änderte sich zu einem späteren Zeitpunkt, was die Barrierefreiheits- Verbesserungen zu nichte machte. Das hat Andrea schwer getroffen

Neue Funktionalitäten wurden vor der Implementierung nicht Tastatur-getestet. (z.B. der Date Picker)

Ich habe mein Netzwerk eingesetzt um Barrierefreiheitsexperten, Firmen und Entwickler mit sowohl React-Kenntnissen als auch Barrierefreiheitskenntnissen zu gewinnen. Wir machten im März dieses Jahres eine Testrunde, nachdem wir die Gutenberg Leitung gefragt hatten, wann sie gewillt waren einen vollständigen Test zu machen. Die Ergebnisse sind bei der Testprozedur und bei den Issues auf GitHub zu finden.

Die Ergebnisse zeigten so viele Barrierefreiheits-Probleme, dass die meisten Tester sich weigerten, Gutenberg nochmal anzuschauen.

Weiterbildung

Weil wir nicht alle Gutenberg Issues selbst lösen konnten, habe ich mich dafür entschieden, zu helfen und die Entwickler und Designer weiterzubilden.

 

Sami Keijonen und ich fingen damit an, das WordPress Accessibility Handbuch zu erweitern und zu reorganisieren, wir haben gute Vorgehensweisen und Methoden zum Testen von Code, Inhalt und Design hinzugefügt. Wir haben sehr viel geschrieben, so dass es jetzt beim Erstellen eines GitHub Issues so ist, dass der Autor auf eine Handbuch-URL verweisen und sagen kann „so wird das gemacht“.

 

An diesem Handbuch arbeiten immer noch Jaap Wiering und Daniel Koskinen, siehe auch der #accessibility-docs Channel auf Slack, hier kann man die Diskussion einsehen.

Wir haben über Testautomatisierung recherchiert. Dies ist immer noch eine nicht vollendete Arbeit, weil es schwierig aufzusetzen ist. Ich habe auf der Human Made Webseite einen Blogbeitrag über meine Erfahrungen mit automatisiertem Testen der Barrierefreiheit geschrieben, und ich habe meine Truppen versammelt, um dies auf eine höhere Ebene zu bringen.

Ausserdem haben wir eine Serie von Entwicklertalks über Barrierefreiheit bei Treffen und WordCamps gestartet.

Eine gute Sache, die man über alle diese Gutenberg-Vorbereitungen sagen kann ist, dass sie die Sichtbarkeit des a11y teams verstärkt haben, und es ist sehr gut zu sehen dass sie jetzt endlich Anerkennung für ihre Arbeit bekommen.

Handbuch für Assistive Technologien

Für Benutzer, die auf assistive Technologien  (AT) wie Screenreader oder Stimmerkennungssoftware angewiesen sind ist die Lernkurve von Gutenberg sehr hoch. Wenn man nicht den ganzen Bildschirm sehen kann, oder auf den Tastaturfokus angewiesen ist, dann ist Gutenberg sehr schwer zu erlernen.

 

Claire Brotherton hat angefangen dieses Handbuch zu schreiben und sie braucht die Hilfe von AT Experten. Siehe:  GitHub issue Manual for users of assistive technology #10373.

5.0 ist nah

Jetzt steht Gutenberg kurz vor der Veröffentlichung: wie barrierefrei ist Gutenberg?

In Andrea’s Worten (und ich stimme zu):

 

“Obwohl das Gutenberg Team hart daran gearbeitet hat, einige Grundlegende Features der Barrierefreiheit einzubauen (Fokus Management, Navigationshilfen) ist die generelle User Experience für Benutzer mit Handicap schrecklich kompliziert, das geht soweit dass der neue Editor für sie kaum benutzbar ist.

 

Der Hauptgrund für dieses generelle Fehlen von Barrierefreiheit steckt im generellen Design von Gutenberg, da Barrierefreiheit nicht in den Design Prozeß mit aufgenommen wurde.

 

Das Feedback von Barrierefreiheits-Benutzern wurde ständig bewertet, und Gutenberg ist tatsächlich ein Rückschritt im Grad der Barrierefreiheit im Vergleich mit dem vorigen Editor”

Andrea Fercia

Was ist schiefgelaufen

Ich habe diese Woche das Feedback bekommen, dass wir die GitHub Issues anders formulieren hätten sollen. Mir wurde gesagt, dass die Begründung, wieso das ein Issue war, ausführlicher hätte sein müssen, so dass die Entwickler besser motiviert gewesen wären, es zu lösen. Ich habe auch das Feedback bekommen dass manche Accessibility Issues zu groß waren, dass wir sie kleiner hätten machen sollen

Es wäre großartig gewesen, wenn dieses Feedback zeitnah in den Issues gekommen wäre, weil einige der Issues bereits über ein Jahr alt sind.

Im Nachhinein gesehen: was hätte ich anders hätte machen sollen:

 

Öfter und lauter kommunizieren, dass wir einen geschulten Gutenberg/React Entwickler viel früher im Prozess gebraucht hätten

Die Entwickler davon überzeugen, dass der Tastaturtest ein Muss ist

Andrea besser unterstützen, als er um eine zweite Meinung und um mehr Testen bat

Die AT-Tester davon überzeugen, es nochmal zu versuchen

Mehr Bemühungen darin investieren, Barrierefreiheitsexperten und Unternehmen zur Hilfe zu gewinnen

 

Vollzeit Entwickler

Ich bin sehr glücklich darüber, dass es jetzt einen dedizierten Entwickler von Automattic gibt, der 100 % an Barrierefreiheitsproblemen arbeitet. Ich wünsche Matthew MacPherson alles Gute, denn er wird es brauchen können. Ich hoffe, dass das a11y team ihn in allem unterstützen wird, was er braucht.

An Matt Mullenweg

Zu Matt Mullenweg möchte ich sagen: bitte passe besser auf deine Community auf. Schätze die Menschen, die ihre (eigene) Zeit investieren und die sehr hart daran arbeiten, WordPress so gut wie möglich zu machen. Ignoriere sie nicht und mach dich nicht über sie lustig, sondern sprich mit ihnen, führe sie, informiere sie. Sei nicht von der Community entkoppelt, sei ein Teil von ihr.

Danksagung

Es war ein Privileg, im Accessibility Team zu arbeiten. Ich kann ihnen allen hier nicht genug danken. Aber es gibt einige Leute, denen ich hier ein grosses Dankeschön aussprechen möchte:

 

Andrea Fercia, der hart und oft allein gegen den Strom arbeitet, was die GitHub Issues betrifft. Ich wünschte ich hätte dir mehr Unterstützung für das Testen geben können.

Claire Brotherton, die viel testet und angefangen hat, das Handbuch für assistive Technologien zu schreiben. Claire, du bist hier die unbesungene Heldin, du hast (in deiner eigenen Zeit) so viel hier getan. Mädchen, du rockst.

Adrian Roselli, der zweimal von den USA zum WordCamp nach Europa geflogen ist, um dem Accessibility Team zu helfen und Lösungen zu finden.

Eric Wright, der ein exzellentes Video darüber gemacht hat, wie schwierig es ist Gutenberg mit Dragon NaturallySpeaking zu benutzen.

Sami Keijonen, Jean-Baptiste Audras, Laken Hafner, Nic Bertino, Amanda Rush, @bemdesign, Chetan Prajapati und all die Leute im #accessibility channel, für ihre Beiträge und Diskussionen.

Morten Rand-Hendriksen, für seine Hilfe, Unterstützung, Netzwerken, Inspiration und Zeit, und dafür dass ich alle meine Zigaretten nach der Party in Belgrad in sein Gesicht rauchen durfte.

Was jetzt?

Ich verlasse weder WordPress noch die Barrierefreiheit, und Fakt ist, dass ich jetzt tatsächlich wieder an Barrierefreiheit arbeiten kann. Ich werde Reden halten und Workshops geben. Ich möchte außerdem Forschen und an Tickets arbeiten. Aber nach meinem eigenen Tempo.

Ich werde mich an Teilnehmertagen mit an den a11y-Tisch setzen, aber vielleicht gehe ich stattdessen lieber in ein Museum.

Für Level Level, die Firma für die ich jetzt arbeite, werde ich Workshops und Schulungen aufsetzen, in denen es um Web Accessibility und gute Code-Praktiken geht. Ich werde ausserdem den Designern, Content Managern und Entwicklern von Level Level helfen, die beste Agentur für barrierefreie WordPress-Seiten zu werden die es gibt. Lauter so Zeug das ich gern mache und das mir positive Energie gibt.

Ich wünsche euch alles Gute, und bitte meldet euch wenn ihr mein Wissen braucht oder wenn ihr einen Schwatz halten wollt oder ein Glas Wein mit mir trinken.

Liebe Grüße,

Rian

Author Rian Rietveld Posted on 9 October 2018

WordPress: 28% Marktanteil, aber Barrierefreiheit muss man suchen

Nahezu jeder, der sich heutzutage mit Webdesign beschäftigt, kommt an der freien Blog-Software WordPress nicht vorbei – auch diese Seite läuft mit WordPress.

Die WordPress-Erfolgsstory

Hier ist ein interessanter Artikel über die aktuelle Popularität von WordPress mit ganz erstaunlichen Statistiken:

Writing About WordPress? Here’s Where to Get Your Statistics From

Ich zitiere und übersetze mal ein paar Zahlenbeispiele:

  • WordPress beherrscht ca. 50-60 % des globalen CMS-Marktes

  • ca. 15.886.000 Websites insgesamt laufen mit WordPress

  • In jeder Sekunde werden ca. 17 WordPress-Beiträge weltweit veröffentlicht

Das  sind ganz erstaunliche Zahlen für eine an sich “kleine” OpenSource-Lösung, die vor Jahren als Blogsoftware für Endanwender angefangen hat. Inzwischen wird WordPress weltweit als CMS (Content Management Software) gehandelt. Darüber kann man trefflich streiten, aber das gehört hier nicht zum Thema. Fakt ist, dass WordPress eine Riesen-Erfolgsstory hingelegt hat, und die Popularität noch weiter wächst.

Die Kehrseite der Medaille

Nur ein verschwindend geringer Anteil der erhältlichen Themes (Designvorlagen) ist allerdings für die Erstellung barrierefreier Webseiten geeignet.

Auf wordpress.org werden gerade einmal 129 der über 14800 (Stand: Juli 2017)  frei erhältlichen Themes als “Für Barrierefreiheit geeignet” oder “Accessibility ready” geführt. Das ist eine klägliche Bilanz.

Und das ist nur die Statistik für die kostenlosen Themes, die professionell gegen Bezahlung erhältlichen Themes lasse ich hier mal aussen vor, das sind noch einmal ein paar10.000. Meine Erfahrung in vielen Projekten hat aber gezeigt, dass hier auch nur ein verschwindend geringer Anteil die Anforderungen der Barrierefreiheit nach WCAG 2.0 berücksichtigt.

Licht am Horizont?

Es ist allerdings eine Trendwende spürbar, das Thema Accessibility/Barrierefreiheit findet auch in der weltweiten WordPress-Gemeinde immer mehr Beachtung.

Im neuesten Release von WordPress (4.8.1) ist auch tatsächlich etwas an der Logik für die Alt-Texte für Bilder neu programmiert worden, man erhält jetzt eine Fehlermeldung wenn man vergißt den Alt-Text einzugeben. Ich muss mir dieses Feature noch genauer anschauen, aber zumindest bewegt sich da mal etwas in die richtige Richtung.

Die Logik für die Alternativtexte war nämlich in allen vorhergehenden Releases “buggy,” also mit einem schweren Fehler behaftet, da stimmte der Datenbankeintrag nicht mit dem tatsächlich verwendeten Alt-Text im visuellen Editor überein. Ich werde das in einem anderen Artikel noch einmal genauer überprüfen, es ist zu wünschen dass dieser kapitale Bug endlich bereinigt wurde.