Skip to content
Melo Podcasts Home
CategoriesLanguagesFollowing

Episode 718 · Working Draft

Revision 718: WCAG: Pass, Fail oder kommt drauf an?

30 Jun 2026 · 1 hr 15 min

Play episode WhatsApp Download

Episode notes

Wir sprechen mit Patrick H. Lauke (LinkedIn, Mastodon, Bluesky) und Peter Krautzberger (LinkedIn, Mastodon) über die WCAG, ihre Success Criteria und die Frage, warum ein Standard, der auf den ersten Blick sehr eindeutig wirkt, in der Praxis oft viel Interpretationsspielraum lässt. Wir sprechen darüber, warum WCAG 2.x trotz ihrer Schwächen weiterhin die Grundlage vieler Audits und gesetzlicher Anforderungen ist, wie sich neue Erfolgskriterien additiv an ältere anhängen, warum das nicht immer elegant ist und wie Patrick im WCAG-GitHub-Repository und der Backlog-Arbeit versucht, offene Fragen…

Transcript

Read the transcript · about 10,180 words, follows along as you listen

Ich gucke, wo die Probleme sind bei WCAG und ich bin sehr aktiv auf GitHub und versuche halt diese Grauzonen ein bisschen mehr zu definieren. WCAG, wie gesagt, an sich versucht es immer noch so binär darzustellen. Das ist also entweder du hast einen Pass oder du hast einen Fail. Ich habe doch eher den Eindruck, dass die neueren Success-Criteria im Allgemeinen ein bisschen klarer sind als die älteren. Revision 718. Wir sind heute zu dritt. Und aus dem Team bin ich dabei. Das bedeutet, wir haben heute zwei Gäste.

Da hätten wir zum einen den Patrick Lauke. Hallo Patrick. Hallo. Und den Peter Krautsberger. Hallo Peter. Hallo. Peter, du warst ja erst kürzlich bei uns in der Sendung. Patrick, du, wir haben nachgeguckt, bist schon, also warst auch bei uns. Aber das ist schon sehr, sehr, sehr lange her. Also unglaublich lange her. Nämlich am 6. Oktober 2013 war das. Da haben wir mit dir unter anderem über Touch-Events gesprochen, an denen du auch gerade wieder arbeitest, an einer Erweiterung zusammen mit anderen beim W3C.

Erzähl doch mal, wer du bist und was du machst und Peter, vielleicht du auch nochmal gleich. Ja, Patrick Lauke. Ich arbeite momentan seit, ich glaube, den letzten sechs Jahren oder so bei Tetralogico. Das ist eine Accessibility-Consulting-Bude hier in England. Und davor im früheren Leben habe ich für eine andere Accessibility-Firma gearbeitet, und dann ganz im Mittelalter, als noch alles schwarz-weiß war, habe ich für Opera gearbeitet, für den Browser-Hersteller.

Genau, unter anderem haben wir uns ja auch getroffen, als du das Thema Smart-TVs, und Webbrowser auf Smart-TVs beagert hast, so hinsichtlich schwarz-weiß. Ja. Genau, genau. Das waren die Zeiten, wo ich durch Deutschland oft, durchgereist bin an diesen verschiedenen Konferenzen, so JavaScript Days und PHP-Conf und so weiter. Ja, und Jackery Vienna. Oh ja, genau. Und das war auch noch der gute Opera, der gute alte mit Presto-Engine. Genau. Schnüff.

Ja, Peter, genau, du bist ja jetzt regelmäßiger Gast bei unseren ARIA-Glücksrädern. Das stimmt, ja. Mein Name ist Peter Krautsberger. Ich wohne und arbeite in Bonn. Ich bin selbstständig, wie man so schön sagt, selbstunständig und arbeite primär im akademischen Verlagswesen. Was jetzt sehr wenig dynamisch klingt und manchmal auch ist. Ja, und ich habe letztens gelernt, dass du nicht nur im Bereich Accessibility unterwegs bist, sondern auch dich ausgehend hast und Meinungen hast zu MathML.

Das ist ja auch ein Thema, das ich gerne mal beackern würde. Also können wir mal gucken, ob wir das ... Genau. Aber heute wollen wir sprechen über die WCAG oder WCAG, je nachdem, wie man möchte. Und da, also das ist ja im Prinzip, diese Accessibility-Checkliste. Gegen die man prüft, ob ein Webauftritt barrierefrei ist oder nicht. Und da wollen wir einfach im Speziellen über die Success-Kriteria, also die verschiedenen Aspekte sprechen, die man eben erfüllen muss und, ob die vielleicht alle so optimal sind und wo die vielleicht Ermessensspielraum haben oder vielleicht auch mal irgendwie ein Griff ins Klo sind.

So ungefähr kann man das wahrscheinlich sagen, oder? Ja, genau. Ja, also die WUKAG ist ja relativ, also die ist ja schon, ich weiß nicht, wann ist die 1.0 herausgekommen? Also die erste Fassung? Also die 1.0, das war, das war glaube ich vor meiner Zeit, ich will gar nicht mal lügen, es könnte 1999 sein, will ich mal so sagen, ich gucke gerade mal. Äh, 99, genau. Ich habe erst mit Web so gegen 2000, 2001 angefangen. Also, wie gesagt, das war vor meiner Zeit.

Und ja, das war die guten alten Accessibility Guidelines, die so Sachen hatten wie, es muss auch ohne JavaScript funktionieren, weil damals JavaScript noch nicht so verbreitet war. Und sehr viele Kriterien damals, die sagten, bis zu dem Punkt, an dem User Agents das unterstützen, musst du das machen. Also da waren so Sachen wie, du konntest keine leeren Textfelder zum Beispiel haben in Forms, du musstest immer irgendwas da, irgendein Content mit liefern.

Ich weiß noch, das hat mich immer so irritiert, weil dann als User musste halt dann das immer löschen. Und da habe ich dann mal so ein bisschen erforscht, warum war das überhaupt so? Und ich glaube, es kam raus, irgendwie ein bestimmter Browser mit einem bestimmten, Screenreader auf OSX hatte das nicht verstanden. Wenn da also ein Textfeld ist, das keine Value hatte, hat das einfach übersprungen. Und aus dem Grund wurde das dann als Erfolgskriterium verewigt, dass jeder das halt so machen muss, damit doch dieser Arme, der eine User, der diese Kombination benutzt, keine Probleme hat.

Also das waren interessante Zeiten. Ja, die Zeiten gibt es ja nicht mehr. Also mittlerweile sagt man ja, nimmt man da jetzt keine Rücksicht drauf, glaube ich, was irgendwelche Versionen von Screenreadern oder Browsern irgendwie können oder nicht können. Das betrachtet man ja jetzt eher sozusagen als Thema für die dann zum Reparieren. Genau, das ist so ein bisschen so Handwave. Das ist so mein Lieblingswort in Englisch immer. Das ist so ein bisschen so, ja, ja.

Passt schon. In WCAG 2 heißt es halt, man muss als Developer Accessibility Supported Sachen benutzen. Aber da wird auch nicht groß ins Detail gegangen, was heißt es jetzt? Was heißt Accessibility Supported? Heißt es jetzt jeder gängige Version von einem Browser mit jeder gängigen Version von einem Screenreader oder, die letzten fünf Versionen oder was passiert jetzt, wenn einer kommt und sagt, ja, ich laufe noch auf OS2 Warp mit, was weiß ich was, Netscape 4.

Tja, da kann man das dann verantworten und sagen, ja, wenn das da nicht funktioniert, darfst du das überhaupt nicht machen. Es ist aber alles so ein bisschen, ja, als Exercise für den Reader rauszufinden, was heißt eigentlich Accessibility Supported. Ja, ich meine, das will man auch nicht definieren. Man kann sich da ja eigentlich nur in die Nesseln setzen. Genau, aber das ist halt wieder so einer von diesen Punkten, wo es viele Sachen in WCAG hat, wo es halt undefined ist. Und je nachdem, wen du dann fragst, kriegst du eine andere Antwort.

So nach dem Motto, darf ich das jetzt machen? Ja, nein, nein, es kommt drauf an. Und das ist so ein bisschen der Leitfaden von meinen ganzen Rants über die Jahre mit WCAG. Es sieht so aus, on the face of it sieht WCAG so aus, dass es also sehr alles sehr spezifisch definiert ist, alles ist sehr klar, alles ist objektiv, das ist so der Anschein von Objektivität, aber sobald du da ein bisschen so, an der Oberfläche kratzt, findest du sehr viele Aspekte, wo es dann doch sehr subjektiv wird mit der ganzen Sache und das bringt dann halt Probleme mit sich, und halt Du fragst zwei Experten und kriegst dann drei Antworten, wenn es auf irgendwas ankommt.

Weil es einfach wahrscheinlich Raum lässt und Dinge nicht ausdefiniert. Und dann ist es up for interpretation so ein bisschen. Genau. Ich finde das immer aber auch spannend. Also. Ich kriege da immer so starke Jura-Gefühle, weil ich genug Juristen kenne. Und da ist natürlich auch das Motto, zwei Anwälte, drei Meinungen, ist ja ein alter Witz dort. Und es kommt darauf an, so oder so. Und insofern finde ich das immer, dass ich etwas Reizvolles an der WCAG, dass sie so einen gewissen Interpretationsspielraum hat, der sich eben auch mit der Zeit bewegt, ohne dass man es berühren muss.

So wie man das ja auch bei Gesetzen hat, bei denen eben dann die Interpretationen von Gerichten durchaus mit der Zeit gehen können. Ich finde da auch viel Gutes daran. Klar, also ich finde es auch gut. Aber es sind natürlich auch all diese Probleme, ohne Frage. Ja, ich finde es gut, aber was ich nicht gut finde, sind Leute, die das nicht einsehen und die dann drauf harren, nee, nee, so muss es sein, das ist so geschrieben und so muss es interpretiert werden.

Und eben diese Arbeit, wir haben ja gerade so vor der Aufnahme darüber geplaudert, ich gucke, wo die Probleme sind bei WUCAG Und ich bin sehr aktiv auf GitHub und versuche halt diese Grauzonen ein bisschen mehr zu definieren. Und da kommst du immer auf diese, ja, nee, so muss es sein, so wurde es geschrieben, so ist es interpretiert worden. Und klar, jeder wird es doch verstehen, dass das impliziert ist, dass das so sein muss. Und es macht mir halt immer großen Spaß, dann zu sagen, nee, okay, hier sind die Probleme, du kannst es so oder so interpretieren.

Was machen wir jetzt? Müssen wir irgendwas definieren? Weil sonst haben wir halt zwei verschiedene Antworten. Und das ist halt, WUKAG, wie gesagt, an sich versucht es immer noch so binär darzustellen. Das ist also entweder du hast einen Pass oder du hast einen Fail. So, okay, WCAG 2, das ist was, wo man momentan bei für WCAG 3 wird das ein bisschen anders konstruiert werden, dass da halt so mehr so verschiedene Grade an, wie accessible ist dein Teil.

Aber ja, für 2.0 ist es ja wirklich nur, du machst einen Fehler irgendwo und, theoretisch hast du dann, du bist nicht WCAG 2 compatible oder compliant. Und das ist halt so das Problem, weil es halt auch WCAG referenziert wird von verschiedenen Legislations, von verschiedenen Gesetzen, ist es immer dann so eine Sache, dass dann halt Developer oder Kunden, die wollen dann auf Teufel komm raus. Ein Clean Bill of Health kriegen. Die wollen alles, dass es alles okay ist, dass es alles gut aussieht, Dass sie halt nicht illegal ihre Webseite haben momentan.

Und es ist halt so diese Spannung, die sich dann bildet. Wenn WCAG an sich nicht direkt mit Gesetzen in Verbindung wäre, wenn es halt nur Guidelines wären, die halt für sowas wie Best Practices sind, wird es wahrscheinlich viel einfacher sein, weil da könnte man dann viel eher ein bisschen Flexibilität direkt in die Spezifikation mit einbauen, anstatt, den Eindruck zu geben, dass es halt alles sehr präzise definiert ist und dann später dann in the real world siehst du dann, dass das halt doch nicht so klappt.

Sorry, ich bin schon am Ranten. Ach, ist schon alles gut. Du siehst dann ja an mich Probleme bei zwei Seiten. Das eine ist die Kundschaft, die gerne unbedingt möchte, dass es sozusagen dahin gebogen wird, dass sie dies alles erfüllen. Und dann gibt es die Gruppe der WUCAG-Experten, die Sachen testen und die dann, sagen wir mal, Goldplating erwarten. Also übermäßig große Anstrengungen, obwohl die Anforderungen ganz klar eben geringer sind, weil sie nur bestimmte Anforderungen stellen und darüber hinaus eben nichts.

Und dem Worte nach hätte man das erfüllt, aber dann kommt halt der Berater an oder der Tester und sagt, nein, ich möchte gerne dies und das noch haben, weil so meinten die das eigentlich. Und ich weiß, dass die das so weinten. Genau, genau. Und ich glaube, ein extra Problem für Firmen, die Accessibility als Service anbieten, ist auch, du als Service Provider willst dann nicht irgendwie Mist bauen, dass dann irgendwie der Kunde wird dann verklagt und auf einmal sagt der Kunde, nee, du, ich habe den Patrick gefragt, der hat mir ein Audit gemacht und der meinte, ja, alles tipptopp und es passt WCAG.

Und dass dann irgendwie die Anwälte bei mir an der Tür klopfen und sagen. Jetzt musst du dafür zahlen, vor allem jetzt in Sachen, Europa mit EAA, dass da viel geredet wird über Jahr, 10.000 Euro und hier und da, was da alles für Bußen bezahlt werden müssen, wenn, dein Service nicht accessible ist. Das gibt dann halt auch viel Druck auf Auditors, also auf Leute, die diese Audits machen als Service. Das ist dann auch ein Problem. Du willst dann nicht zu gutmütig sein und sagen, ja, passt schon.

Da ist zwar ein Problem, aber in the real world hat es keinen Effekt auf niemanden. Da bist du dann schon dazu fast gezwungen zu gucken, ja, ich werde jetzt ganz kniebohrerisch durch die Webseite oder die Application oder was weiß ich gehen mit den Success Criteria und, eben gucken, kann ich das eventuell, wenn ich jetzt so ein bisschen so schiele, ist das ein Failure, wenn ich das so umgele. Interpretiere und das ist halt das Problem. Also da sind so viele verschiedene, Directions, die aufeinandertreffen.

Motivationen, genau. Vom Kunden, vom Developer und auch von den Leuten, die diese Audits machen. Und auch natürlich Leute, die einen Audit machen, die wollen halt auch zeigen, dass sie ihr Geld wert sind. Von dem her, wenn jetzt ein Kunde irgendwie für meinen Service zahlt, will er auch was dann zurückhaben. Und wenn ich dann sage, okay, ja, ist eigentlich alles schon okay, dann werden sie dann nächstes Mal auch denken, ja, da brauche ich den Patrick doch gar nicht.

Ja, genau, so wie so Betriebsprüfer, die müssen immer was finden, also auch egal, wie perfekt alles ist. Aber in dem Zusammenhang eine total praktische Frage, wie ist denn das mit so Haftpflicht in dem Bereich? Ich meine, jetzt nach dem EAA, gibt es da Angebote für Auditors, dass die sich versichern können? Also die typische Berufshaftpflicht? Ja, muss ich ehrlich sagen, da ich nur angestellt bin, das überlasse ich meinen Bossen, dass die sich da schlau machen. Aber gibt es schon, oder? Wahrscheinlich.

Aber das ist schon eine Thematik, mit der sie sich beschäftigen müssen. Ich weiß nur von meiner eigenen Erfahrung, wenn wir Sachen wie diese ACRs machen, also diese Accessibility Conformance Reports, was auch viele Leute VPAT nennen, obwohl VPAT ist die Template. Das ist so ein bisschen so Dr. Frankenstein und Frankensteins Monster. Aber wenn wir so ein ACR schreiben, da haben wir auch so ein bisschen so ein Boilerplate am Anfang, der sagt, okay, diese ACR wurde von unserer Firma gemacht, an dem und dem Datum, mit diesen und diesen speziellen Kriterien, dass wir halt nur diese Browser getestet haben oder diese Screenreader benutzt haben.

Und wenn dann, weil der Kunde kriegt dann dieses ACA und das ist dann deren Eigentum, die können das ruhig gerne, wenn es denen nicht gefällt, wenn die meinen, nee, sieht ein bisschen schlimm aus, wir könnten es vielleicht ein bisschen verschönern. Dass wir halt sagen, okay, ja, statt das Not Support machen wir es doch auf Supports oder Partially Supports. Dann haben wir auch ganz klar Klauseln in unseren Verträgen, die sagen, okay, das kannst du machen, aber dann nimmst du unseren Namen raus, weil das sieht halt schlimm aus für uns, wenn es auf einmal irgendwie irgendwas passiert und die werden verklagt oder es wird groß auf Publicity gemacht.

Ja, schaut euch an, diese Website tönt groß, dass sie accessible sind, aber sie sind sie nicht, dass wir dann ein bisschen unseren Hintern retten, falls sowas passiert. Aber ich nehme schon an, das wird dann sehr viele verschiedene Klauseln halt haben in Sachen, okay, wenn der Kunde jetzt verklagt wird, was passiert uns? Aber wie gesagt, ich bin da zum Glück am Not-A-Lawyer und das überlasse ich meinen Bossen. Aber hat man da mal von irgendwem was gehört, dass das passiert wäre?

Also ich denke immer so ein bisschen so, dass es so wie dein Steuerberater, wenn der dann einen Fehler macht, das ist am Ende trotzdem dein Problem, weil du ja am Ende nochmal drüber geguckt hast und deine Unterschrift, also ist das vielleicht auch so? Weiß ich nicht. Nee, da wüsste ich jetzt direkt nicht. Ich nehme auch an, falls irgend so was ist, wird es wahrscheinlich nicht groß publiziert sein. Die werden das wahrscheinlich außerhalb vom Gericht dann mit viel Geld und Bußen und was weiß ich was gesettelt haben. Das ist also nichts jetzt.

Public Knowledge wert. Aber ja. Ja, wir haben ja auch noch keine wirklichen, Gerichtsverfahren zum IAA zumindest. Nee, da wird so viel endgültigen, keine rechtskräftigen. Genau, man hört so Sachen wie irgendwas in Frankreich ist, glaube ich, der erste Case gekommen, aber ich habe mich da nicht groß mit beschäftigt. Ich muss ehrlich sagen, dieser Aspekt von Accessibility interessiert mich eigentlich nicht so sehr. Mir geht es mehr darum, okay, wir machen jetzt halt sicher, dass Sachen für, alle Menschen funktionieren, ob sie jetzt Behinderung haben oder nicht.

Und wie kann man WCAG interpretieren? Das ist so mein Vorteil. Wenn es dann um Gesetzesgebung geht, da bin ich dann immer... Genau, nur zur Infoersinn, der in der Folge die letzte Woche publiziert, muss man sagen, sein wird, wenn diese rauskommt, da haben wir mit der Nina Gerling über den Stand des BFSG, also des EAA, jetzt ein Jahr später mal gesprochen, auch sehr hörenswert. Super, ja. Genau. Erzähl doch mal, wo siehst du in der aktuellen WCAG, was die 2er-Version ist? Ich glaube, 2.3 ist aktuell, oder? 2.2. 2.2, okay.

Was sind so deine Lieblings-Success-Kriterien, Erfolgskriterien, die aber sehr wischiwaschi sind, wo es einfach öfter Probleme gibt, wie auch immer die geartet sind? Und sei es, dass die Unterschiede interpretiert werden oder dass die unterspezifizieren. Hast du da ein paar Beispiele? Ja, hast du ein paar Stunden Zeit? Nee, also wir haben es ja auch vorher besprochen. Ich habe da so eine Präsentation, die ich jetzt schon, glaube ich, zum dritten Mal aufgeklappert habe und ein bisschen renoviert habe und wieder gegeben habe.

Das erste Mal war es 2019, glaube ich, in Kanada bei der Accessibility Toronto. Und ich habe es dann noch, glaube ich, ein zweites Mal gemacht bei der gleichen Konferenz. Und gerade vor ein paar Wochen hatte ich das für Global Accessibility Day als Online-Session gemacht für eine Firma in Deutschland, interessanterweise. Aber ja, ich habe da so eine Präsentation, wo ich da so meine Favorites von, Success Criteria abklappe. Fast in jedem Erfolgskriterium gibt es potenziell Probleme, wenn man hart genug drauf schaut.

Also selbst bei den ganz einfachen, wenn man schon beim allerersten 1-1-1, wo es darum geht, Alternativtexte zu haben. Es erzählt dir zwar ganz genau, ja, für jedes Nicht-Text-Element, das du hast und das irgendwie so einen Sinn hat, das so Content weitergibt. Ich muss da auch sicherstellen, dass eine Alternative vorhanden ist für Leute, die das Bild nicht sehen. Was auch interessant ist, 1.1.1 geht auch auf Audio zum Beispiel. Wenn jetzt meine Webseite irgendwie Audiosignale benutzt, um irgendwie mir was beizukriegen als User, da ist 1.1.1 auch mit dabei.

Aber ja, das geht so ins Detail, aber es erklärt dir dann halt nicht, was ist eine gute Alternative. Und das kann man natürlich, logisch, man kann es ja nicht so definieren in einem Standard. So, I'll know it when I see it. Ich weiß, wenn ich sehe. Aber schon bei dem ersten, allerersten Success Criterion kann man schon drüber diskutieren. Und wir haben ja seit 20 Jahren oder was diskutieren wir in verschiedenen Kreisen über diese Sachen. Ist das ein guter Alternativtext? Ich habe jetzt hier, was weiß ich, das Bild von dem Speaker und den Speaker-Namen daneben.

Kann ich das Bild als dekorativ empfinden. Einige werden dir sagen, ja, natürlich, weil wenn ich das Bild so nicht sehe, kriege ich immer noch die Information, weil du hast ja den Speaker-Namen als Text daneben. Und da gibt es dann halt andere, die dir sagen werden, nee, ich als blinder Screen-Reader-User, ich möchte unbedingt wissen, wie der Patrick aussieht, dass er keine Haare hat und irgendwie so einen grauen Haar hat. Oder vielleicht auch, wie alt die Person wohl ist. Genau, oder Hautfarbe oder was weiß ich was.

Also da kann man sich schon drüber streiten und das ist das allererste Success Criterion und da gibt es insgesamt, haben wir glaube ich, wie viel? 50, 52, ich weiß jetzt nicht mehr, Success Criterion. Und ja, die haben alle so ihre kleinen Knackpunkte, wo, wie gesagt, auf einmal wird es subjektiv, aber es wird dir nicht so sehr erklärt. Und das hat auch Situationen, wo es halt, wenn du es so logisch durchdenkst, dass da ganz interessante Resultate rauskommen.

Zum Beispiel, ich glaube, eins der 2 ist, glaube ich, bei 2.1 oder bei 2.2. Nee, 2.1 kam es raus und 2.2 hat es nochmal nachgemacht mit Target Size. Also wie groß soll das? Genau, interaktive Elemente, dass die groß genug sind. Ich glaube, bei 2.1 kam die AAA-Version raus mit den ganz großen. Und 2.2 hat es dann, glaube ich, noch mit der AA, mit den kleineren, rausgebracht. Da muss man vielleicht noch kurz erklären, dass je nachdem, welches sozusagen, Gütelevel man erreichen will, muss man dann, also wenn man AAA haben will, dann muss man eben all die Kriterien erfüllen, die es gibt.

Bei AA werden es dann weniger und bei Single A noch weniger. Genau, genau. Also das Target Size gibt es also in zwei Versionen. Eins ist ein bisschen relaxter und eins ist sehr spezifisch. auf eine bestimmte Größe. Aber so wie diese Target Size-Erfolgskriterien geschrieben wurden, das wollte dir dann damals keiner sagen. Aber theoretisch könntest du einen Link haben, der einmal ein Pixel groß ist, also nur ein einziger Pixel, Quadratpixel. Solange du genug Platz lässt um den Pixel rum.

Ist das ein Pass. Okay, da hast du dann halt einen Ein-Pixel-Link. Kein Mensch kann den benutzen, aber wenn du nur auf was, was in der, in WCA geschrieben ist, was, wenn du dem folgst, ist das kein Problem. Das ist ein Usability-Problem anstatt ein WCA-Problem. Aber das ist ja eine andere Kategorie von, sagen wir mal, löchrigen Kriterien. Das eine ist ja wirklich eben, dass sie dann irgendwann aufhören, Dinge auszudefinieren und dann auf die Uhr gucken und weg müssen.

Und dann muss man eben selber überlegen, wie man jetzt den Alternativtext ausformuliert oder entscheidet. Und das ist ja wirklich, da kann man das ja dann so ein bisschen gamen. Also so ein bisschen so wie der Manuel Matusowitsch, als der da mal irgendwann eine Webseite gebaut hat, die komplett alle Tests durchläuft, aber tatsächlich ja komplett inaccessible war. Genau. Und eben so diese Sachen. Ich weiß noch, damals, gerade bevor es publiziert wurde mit diesem Target Size, hatte ich das so als Beispiel für das Understanding-Dokument vorgeschlagen.

Okay, können wir dann halt zeigen den Leuten, okay, du kannst es so klein machen wie in einem Pixel-Link, dann musst du aber genug Platz machen. Und so viele von den Leuten, die da mitgewirkt haben, die da mitgeschrieben haben am Standard, haben so gesagt nach dem Motto, du hast zwar recht, aber können wir das nicht ein bisschen verschweigen, weil sonst kommen die Leute auf die Idee, dass das okay ist. Aber ich bin da immer sehr pragmatisch und sage, du, wenn das die Realität ist, müssen wir es auch schreiben.

Aber eben, das sind dann so diese Diskussionen, die wir oft haben. Du hast zwar recht, aber können wir es nicht irgendwie unter den Teppich kehren? Mhm. Und genau, du hast ja auch gesagt, dass die 2.1 hat die eingeführt, hast du gesagt, und 2.2, also die 2.2, hat das dann nochmal erweitert. Das ist ja auch so ein Ding bei der WCAG, dass. Die bestehende Kriterien, also zumindest bei diesen Minor Releases, dann nicht irgendwie nachträglich fixen, sondern die lieber neue Kriterien dazu packen, um dann diese Lücken zu schließen.

Das ist ja auch irgendwie interessant. Das ist immer die Idee, das ist so, ja, es muss backwards compatible sein, weil die Idee ist halt, wenn ich jetzt als Unternehmen, als Kunde, wenn ich meine Webseite auf 2.2. Jetzt fit mache, aber in der Gesetzesgebung, wo ich momentan agiere, verlangt man immer noch nur noch 2.1 oder 2.0. Dass ich da halt trotzdem accessible bin dass ich also nicht dadurch, dass ich die neue Version benutzt habe auf einmal nicht kompatibel bin mit der Gesetzestellung und, die Idee ist gut, aber ja eben dadurch, dass man immer nur additiv Änderungen machen kann und nicht auch irgendwann mal sagen kann, Leute, das war schon in 2002 war das scheiße. Können wir das jetzt nicht auch mal rausnehmen oder umschreiben?

Das ist leider ein Problem, weil man kann sehr viele Sachen halt patchen mit einem extra Success Criterion. Aber das Ganze wird dann immer obtuse. Vor ein paar Wochen hatte ich so einen Fall mit Drugging Movement. Das ist einer der neuen Kriterien, N22. 2, was also sagt, okay, dass deine User-Interface, du kannst dich nicht darauf verlassen, dass ein User, Dragging machen kann, ob es mit der Maus ist oder mit dem Finger auf dem Totscreen, weil einige User haben halt Tremors, die können nicht so akkurat Sachen auf dem Bildschirm oder mit der Maus, schnappen und irgendwo hin tun.

Oder es kann auch sein, dass sie halt ein Input-Device benutzen, das das gar nicht zulässt. Was weiß ich, so ein Mouth-Stick oder ein Headwand, wo sie halt einen Touchscreen bedienen mit so einem Stift praktisch, der im Mund oder am Kopf angebracht ist. Die können dann so Dragging halt nicht machen, weil das geht halt nicht in dem Kontext. Okay, also einerseits haben wir Dragging Movement, aber in WCAG 2.1 hatten wir schon Pointer Gestures. Und die Definition von Gestures hatte ...

Zum Teil Sachen, die praktisch ein Dragging-Movement sind, wenn es also darum geht, um zum Beispiel einen Slider zu bewegen. Da waren Beispiele im Understanding-Dokument, wo es darum ging mit einem Slider, dass ein Slider ein Problem ist für Pointed-Gestures. Aber jetzt haben wir halt Dragging-Movement und da war dann so ein großer Überschnitt zwischen den zwei SCs und es war halt überhaupt nicht klar, jetzt mit 2.2, wenn ich sowas auf einer Seite entdecke, wo kann ich das als Problem identifizieren?

Ist es jetzt ein Dragging-Movement-Problem? Ist es ein Pointer-Gestures-Problem? Ist es beides? Ist es keins? Und da waren sehr viele verschiedene Nuancen, die dann irgendwie in der Interpretation waren und ich habe das vor kurzem ein bisschen hoffentlich vereinfacht und halt... Einmal gesagt, okay, bis zu dem Punkt ist es ein Dragging und alles andere ist eine Gesture. Und ja, diese Slider sind keine Pointer-Gesture, weil, und da habe ich dann so ein bisschen Erklärung gegeben, warum das nicht als Gesture ist.

Also eine Gesture sind dann so schnelle, was weiß ich, so ein Swipe, aber nicht ein Dragging. Das ist dann halt direkt nur noch unter Dragging-Movement. Und sorry, das war jetzt sehr, sehr spezifisch als Beispiel. Aber wie hast du das gefixt? Also hast du das quasi, konntest du das in der Spec dann verlewigen und das kommt dann mit der nächsten Version raus? Das ist immer das Interessante, weil WCAG an sich ist ja in verschiedene Teile aufgebaut. Du hast die normative Spezifikation, die also dieser Success-Criteria auflistet.

Ja, genau. Und dazu kommt dann ein Understanding-Dokument und die Techniken. Und die sind informative, die sind also nicht normativ. Das heißt theoretisch, dass diese Dokumente, die können auch verändert werden. Und obwohl die verändert werden, haben die keinen Einfluss drauf, ob die jetzt ein Success-Quaterion pass oder fails. Also die sollten nicht irgendwie so scharf uminterpretieren, dass auf einmal der Sinn von dem Normativen irgendwie umgedreht wird.

Es ist also immer so ein komischer Seiltanz, den du machen musst und du guckst halt immer an das Dein Ding. Wie weit kann ich das so erklären? Das ist die Idee hinter diesen Success Criterion und so könnte man das so interpretieren. Ohne jetzt direkt sagen zu können, okay, das ist ein Past, das ist ein Fail. Du musst dann immer so ein bisschen so ganz, ganz vorsichtig vorgehen. Und was ich jetzt gemacht habe mit dem Pointed Gestures und Dragging Movement.

Weil das ganze Problem, die ganze Problematik mit diesen Slidern war nicht im normativen Teil von der Spezifikation, sondern im Understanding, konnte ich das dann umbauen. Dann habe ich also die Understanding für beide Dokumente ein bisschen so umgekrempelt, einige Beispiele umgeschrieben oder von einem Understanding ins andere getan. Ja, und da konnte ich es machen. Aber es gibt viele Situationen, wo auf einmal kann man das nicht fixen, indem man nur so informative Änderungen macht.

Und das sind dann halt die Probleme. Da kannst du dann vorschlagen, dass du ein Erratum machst, was meistens heißt, okay, wir meinen das immer so, wir haben es aber nur nicht so hingeschrieben. Und bei der nächsten Version sollte das umgeschrieben werden, dass es also direkt so im normativen Text ist. Dann wird der Punkt selbst gefixt und nicht noch im Weiteren zugefügt. Aber das ist so ein Thema, weil da wird momentan sehr viel diskutiert. Sollen wir jetzt daran arbeiten, dass wir noch ein WUCAG 2.3 machen oder sollen wir, uns konzentrieren auf WUCAG 3.0, was ja die nächste große, tolle Version sein wird, an dem schon seit zehn plus Jahren gearbeitet wurde?

Und ich muss ehrlich sagen, das wird zwar viel gearbeitet in WCAG 3, aber ich kann es mir gut vorstellen, dass ich, bevor ich in Rente gehe, dass das noch nicht. Die aktuelle Version sein wird, an die ich mich richten muss. Ja. Also, ja. Und das ist halt so mein Blickpunkt dazu ist, okay, ich würde gerne WCAG 2, 2, 2, 3 fixen momentan. Weil das ist die Realität. Also ich jetzt Tag ein, Tag aus, wenn wir Odits machen bei uns, das ist halt das, an das wir uns richten.

Stimmt einfach, ne? Genau, genau. Nee, von dem her, das ist so der Grund, weil viele fragen mich immer, warum investierst du so viel Zeit und Energie in diese Updates für 2.02? Weil ich es halt brauche, Tag ein, Tag aus. Und diese Fragen, die immer aufkommen, wo ich dann versuche, diese Sachen zu klären. Das sind meistens Fragen, die bei uns in der Firma aufkommen oder in Diskussionen online auf Slack und so weiter. Das sind so Sachen, die ich überall immer sehe, wo halt Real-World-Probleme vorkommen oder wie interpretiere ich das?

Oder ist das jetzt ein Problem mit dem Success-Criterium oder dem? Und jedes Mal, wenn ich sowas sehe, da kommt dann so, oh, toll. Da schreibe ich gleich eine neue Issue und vielleicht einen Pull-Request, dass wir das ein bisschen klarifizieren können. Oder klären, wäre das richtige Wort, nicht klarifizieren. Patrick. Würdest du sagen, also ich meine, wir haben eben, eben hast du über dieses schöne, Sizing-Problem mit dem Ein-Pixel-Link gesprochen, aber ich habe doch eher den Eindruck, dass die neueren Success-Quiteria im Allgemeinen ein bisschen klarer sind als die Älteren.

Täuscht das? Oder wie siehst du das? Also ich denke zum Beispiel, zum Beispiel erinnere ich mich eben auch daran, dass irgendwie vor kurzem eine Diskussion war über die Inline-Exception. Und ob das so, da war so eine Diskussion bei euch auf dem Tracker über Table of Contents, also Inhaltsverzeichnisse. Und ob jetzt ein Link in einem Absatz, der aber ganz alleine in dem Absatz ist, ist das jetzt Inline-Exception oder nicht? Ich musste sofort unsere Design-Systeme für die Kunden angucken.

Oh Gott, habe ich das übersehen? Nein, war alles fein. Aber trotzdem habe ich das Gefühl, der ist an sich relativ gut erarbeitet worden mit 2.2. Aber wenn ich dann sowas wie, was ist das, 131, Info und Relationships, was so... Alles ist, da habe ich so das Gefühl, da ist einfach, da sind die Tore weit offen. Ja, ich glaube, der Titel, der ist ja allein schon, der gibt ja alles hier, alles und nichts. So viele Techniken und so viel, dass man nicht interpretieren kann.

Ich glaube, das ist wahrscheinlich eher ein Effekt von dem, wo wir gerade drüber geredet haben, dass man halt immer nur additiv Änderungen machen kann. Viele von den ganz großen und sehr vagen Success-Criterien sind die Original-Criterien von 2.0, also eben 1.3.1 oder 4.1.2 ist das andere, wo man immer, du kannst wahrscheinlich fast jedes Problem in diese zwei Kästchen oder beide sogar, in beide Kästchen einsortieren. Aber dadurch, dass dann halt, okay, wir können jetzt halt, wenn da ein Problem ist, können wir nur ein neues Success-Criterium machen.

Es wird dann halt immer kleiner, die Scope von den neuen Success-Criterien. Das ist also immer, ja, okay, wir wollen halt nur dieses eine kleine Problem machen. Von dem her sind die ein bisschen besser definiert von dem her. Aber ich würde sagen, qualitativ sind auch viele Probleme immer bei den neuesten Success-Criterien. Als ein Beispiel zum Beispiel Reflow. Ich weiß jetzt gar nicht mehr die Nummer davon. Aber Reflow ist so vom Prinzip her ganz, ganz gut, weil die Idee war, wenn ich jetzt ein Low-Vision-User bin auf einem Desktop, ich muss Sachen sehr groß machen, bis zu so 400, 500 Prozent zoomen.

Und wenn ich irgendwie was lesen will, will ich nicht in zwei verschiedene Richtungen strollen müssen. Also das halt Text, vor allem halt Text, dass da ein Umbruch gemacht wird, dass ich das halt auch in einem kleinen Viewport sehen kann. Und von der Idee her ganz gut, aber so wie das dann am Ende definiert wurde mit. Ja, wenn es vertikaler Content ist, dass der 320 CSS-Pixel breiter Viewport, dass es da einen Umbruch gibt, ohne dass ich in zwei Richtungen scrollen muss und so.

Das wurde alles sehr, sehr spezifisch geschrieben. Ich hatte mal als Beispiel gesagt, ja, okay, das ist jetzt so, wie es geschrieben wurde, ist es nur bei 320 CSS Pixel. Wenn jetzt mein Bildschirm 321 ist oder 319, dann ist die normative Definition nicht mehr valide. Da muss ich mich nicht mehr drum kümmern. Ich könnte also... Oder auch die Zwischengrößen. Genau, die Zwischengrößen. Weil da könnte ich dann, wenn ich jetzt auf Teufel komm raus, einen grünen Checkmark haben will, könnte ich sogar sagen, okay, wir machen jetzt eine Version, die wirklich nur bei 320 CSS Pixel perfekt funktioniert.

Aber danach müssen wir uns nicht mehr drum kümmern. Und wir machen halt was, was weiß ich, was mit unserem Layout. Weil ja, alle Leute haben ja einen großen Bildschirm mit 4K und die haben ja viel Platz. Die Idee ist gut, aber so wie es dann definiert wurde, hat es dann noch mehr Probleme damit. Da hätten sie es, das war so die Diskussion damals, das war, wir können nicht verlangen, dass Webseiten an sich responsive Design machen, weil das wäre eigentlich die Antwort dazu.

Du machst halt, du stellst sicher, dass der Content von deiner Webseite sich an alle möglichen Situationen ausrichtet, die der User hat. Und dann ist es dann kein Thema, ob der User jetzt 400% Zoom hat oder 500% oder was weiß ich. Bis zu einem bestimmten Punkt ist dann immer so das Thema auch, okay, heißt das jetzt, dass ich jetzt ein... Zehn Pixel breiten Viewport darf ich dann nicht mehr scrolling. Das hält sich dann eben in Grenzen und halt diese Common Sense Grenzen zu finden, das ist dann immer das Problem.

Aber so wie es ja jetzt momentan geschrieben ist, das war mehr so ein Kompromiss und die Folgen darauf sind, wir haben glaube ich jetzt ein Understanding-Dokument für Reflow. Das sind wahrscheinlich so zehn Seiten, wenn du die ausdrucken willst, die versuchen, ein bisschen mehr Kontext zu geben. Ja, wann ist es okay, dass ich horizontale und vertikale Scrollbars habe? Wann nicht? Und dann gibt es dann das Problem, was machen wir jetzt, wenn wir WCAG für App-Odits benutzen?

An sich ist ja nicht darauf ausgerichtet, dass du Android- oder iOS-Apps mittestest, aber jeder macht es. Das ist so das böse Geheimnis. Und da kannst du ja nicht sagen, okay, 320 CSS-Pixel, das hat ja kein Device mehr heutzutage, der 320 CSS-Pixel hat. Also was machst du jetzt mit diesem Reflow? Schaust du mehr drauf. Was der Sinn dahinter war und dass das erfüllt ist oder hältst du dich an das Normative, wie es geschrieben wurde? Und das ist halt so dieser Knackpunkt momentan.

Da gibt es auch eine Gruppe zu, ne? Ja, genau. Die M-R-T-F. Mobile Accessibility Task Force, genau. Ich habe mal den linken Po. Den können wir vielleicht in e-show-nouts packen. Für die, die sich das anschauen wollen. Ja. Und da hat es auch vor Jahren hat es schon ein WCAG-2-ICT-Dokument, das versucht, okay, sozusagen, ja, WCAG ist nicht auf ICT, also Information, ich weiß gar nicht mehr, was das C ist, Information Technology, also Programme, also was nicht Web ist, wie man das uminterpretieren kann, damit man auch Audits für normale Programme wie auch Apps auf Handys, aber die haben sich auch einen abgekrampft, um zu versuchen zu erklären, okay, das funktioniert halt auf dem Handy nicht so oder in der Application.

Ist das ein bisschen anders? Da hat es keinen User-Agent. Wie kann man das dann interpretieren? Oder Sachen wie, hat die Seite einen Titel, Page-Title? Das kannst du so, wie es geschrieben ist, kannst du das nicht direkt auf eine Applikation interpretieren, weil das ist ja nicht eine Seite, die innerhalb von einem Browser ist, wo du oben den Seitentitel siehst, sondern es ist, eine ganze Applikation selbst. Und ja, das sind so diese Probleme. Hatte ich nicht auch immer was gehört, dass irgendwie in der neuen WUCAG das auch nicht mehr Page genannt wird, sondern View oder sowas?

Genau, das ist einer der ersten Ansätze, weil theoretisch soll WUCAG 3, wenn es irgendwann mal rauskommt im Jahr 3000, soll es sich auch für Software und was weiß ich, iOS und Android Apps, soll es sich auch darstellen. Da wohlfühlen, dass man das halt auch für solche Sachen benutzen kann. Was ja eh schon passiert. Genau, genau. Also die Realität selbst. Und ja, und diese Neudefinition, die in WCAG EM, da gebt ihr gleich den Link dazu, neu definiert wird.

Und ja, die große Neuigkeit ist, dass man nicht mehr von Page redet, was ja wirklich sehr, Anno 2000, WCAG 2.0 ist, dass man halt mehr auf Views und Screens, Views und solche Terminologien benutzt. Weil die Idee, dass ja damals war alles aus Holz, nee, war alles eine URL und alles ist eine Seite, funktioniert selbst bei Web-Content heutzutage nicht mehr. Wenn du, sagen wir mal, Single-Page-Apps hast, ist ja alles nur eine Page. Was machst du jetzt, wenn du ein Audit machst, wenn du das evaluierst?

Nimmst du das, als wäre das ein einziges Sample oder machst du, was jeder andere Auditor heutzutage schon auch macht und du machst dann halt separate logische Blöcke draus und sagst, ja, erst testen wir die Home-View und dann testen wir die. Downloadsview und so weiter. Also das Konzept ist ja eigentlich relativ logisch. Man kann, wenn ich jetzt so eine Application sehe, kann ich es wahrscheinlich in verschiedene Seiten auseinanderbrechen. Aber ja, normativ heißt es immer, alles bezieht sich auf eine Page und eine Page ist eine einzige unique URL.

Und ja, Das Konzept ist halt veraltet. Mhm. Und ich habe mich eben auch gefragt, würde es denn, wäre es nicht hilfreich, wenn bevor wieder neue Kriterien irgendwie dran gepflanscht werden oder überhaupt, wenn jetzt irgendwie an einem Overhaul gearbeitet wird, wie eben bei der 3.0-Version, dass man dann tatsächlich, diese Liste erstmal Leuten gibt, also so wie man das halt kennt bei QA-Testern, die ja auch irgendwie schaffen, die ja sehr erfinderisch sind.

Und da wirklich ein Gespür für haben, wo sie den Finger reinstecken müssen, um Dinge kaputt zu kriegen. Also dass man da vielleicht erstmal mehr machen müsste, damit es dann, wenn es dann fertig gemacht wird, dass man dann auch wirklich keine Überraschung mehr erlebt im Nachhinein. Ja, also an sich ist es ja mit eingebaut oder die Theorie wenigstens ist, dass das halt mit dem W3C-Publication-Modell schon funktioniert. Weil momentan ist halt WCAG 3 immer noch in Draft.

Wenn es dann soweit ist, dass die Working Group denkt, okay, ich glaube, wir sind jetzt an dem Punkt angelangt, wo das gut ist, dann wird es in den nächsten Step getan, was, oh, ich weiß jetzt gar nicht mehr, welche da ist, First Public Working Draft. Und dann werden halt Kommentare von der Community erfragt. Das ist halt, jeder kann dann seinen Senf dazugeben und sagen, ja, das passt, das passt nicht. Und, Kommt halt darauf an, wie genau sich die Leute in der Community das angucken, ob sie es auch versuchen, dann wirklich, ja, wir nehmen das jetzt für einen Test-Drive und wir versuchen mal die nächsten fünf, sechs Audits, die wir machen, auf Basis von den neuen Kriterien, vom neuen Standard zu machen.

Schauen wir mal, wo die Pain-Points sind. Das ist dann immer so die Frage, weil wir sehen viel, selbst mit WCAG 2 ging ja genau durch die gleiche Strecke in Sachen Public Comments und so weiter. Und jetzt sind wir immer noch da, dass wir neue Probleme finden, die selbst seit 20 Jahren noch nicht klar waren und auf einmal kommst du an den Punkt ran und sagst, ja okay, das ist jetzt nicht klar. Das Problem ist halt, du kannst sehr viele Permutationen haben von, wie etwas gemacht wird, neue Techniken kommen, neue Devices, alles ist neu.

Und dann findet man neue Probleme, die man gar nicht wusste, dass die da sind in den Success Criteria. Aber ja, die Idee ist da, dass das erstmal getestet wird, bevor es jetzt der Standard wird und bevor das dann in ein Gesetz mit eingebaut wird. Aber ja, kommt halt drauf an. Wie ist denn das? Kleine technische Deep Dive. Von einer Working Group zur anderen. Das habe ich am Anfang ganz vergessen. Ich sitze, was vielleicht für den Kontext für die ZuhörerInnen relevant ist, dass ich in der ARIA Working Group sitze und ein Co-Editor von der ARIA-Spezifikation bin.

Wir sind gerade dabei, 1.3 in die nächste Public Working Draft zu machen. Also dann die Second oder wie auch immer. Die andere. Und da ist natürlich, also da ist das Prozedere, so bei den User Agent Oriented, Specs, habe ich das Gefühl, die W3C hat ja ein ziemlich stringentes Programm, das so abgespult wird. Dann gibt es zig Checklisten, dann gibt es Tag Review, dann gibt es Internationalization Review, dann gibt es Accessibility Review und so weiter und so fort.

Privacy, Security und so weiter. Bei WCAG ist es wahrscheinlich ganz anders, oder? Ich meine, ihr seid ja so ein bisschen woanders positioniert. Ihr redet nicht über die User Agents so sehr, sondern irgendwie über die Gesetze. Gibt es dann auch so ein formales Prozedere bei euch? Ich muss zugeben, das ist auch wieder so der Teil, wo ich ganz gerne ignorant bleibe bei unserem Working Group. Also für die längste Zeit war ich zwar ein Mitglied vom Accessibility Guidelines Working Group, aber ich habe mich dann immer schön ferngehalten, weil.

Jede Woche so unsere zweistündige Meetings, die oft wirklich nur eine Talkshow sind, wo dann halt Leute sehr, sehr gerne reden. Also ich sollte ja nichts sagen, ich rede ja auch immer gerne, aber wo wenig gemacht wird, muss ich ehrlich sagen. Und mein Interesse war immer da mehr direkt im GitHub rumbasteln und hier ist eine PR und hier eine neue Issue und sowas. Ich bin jetzt seit ein paar Monaten aktiver geworden, weil endlich nach langen Jahren, wo ich praktisch drum gebettelt habe, eine Taskforce gemacht wurde, speziell um diese ganzen hunderte von Issues, die bei WCAG offen waren auf GitHub, die endlich mal ein bisschen abzuarbeiten.

Also das ist jetzt die WCAG 2 Backlog Task Force. Und da habe ich endlich gesehen, ich glaube. Vor zehn Jahren hatte ich schon mal die Idee angebracht und endlich haben sie es vor ein paar Jahren gemacht, dass da wirklich auch aktiv an diesem Technical Debt, den wir seit Jahren hatten mit WCAG, Ich glaube, letztes Mal, wo ich geguckt hatte, damals waren es, glaube ich, sieben oder achthundert Open Issues und ein paar hundert Po-Requests. Und es waren, glaube ich, so um die 200 Branches auf dem GitHub-WCAG-Repository.

Da habe ich auch gesagt, Leute, also entweder wir machen jetzt alles zu, wir machen jetzt, was zwar nicht gute Form ist, aber dass wir halt Bankruptcy deklären und sagen, okay, wir können das nicht abarbeiten. Oder dass wir halt irgendwas machen und endlich hat es jetzt diese Gruppe und da bin ich jetzt aktiv, schön aktiv gewesen und seit Januar diesen Jahres bin ich auch einer der Facilitators, von der Gruppe. Also, dass ich offiziell einer von den Leuten bin, die so ein bisschen die Arbeit leiten.

Und ja, ich versuche so, ich habe ein bisschen so das Tempo ein bisschen erhöht. Und ich mache sehr viel so nebenbei, dass ich Issues, ein Triage mache, dass ich gucke, okay, das ist eine gute Issue. Oft bin ich auch der, der dann am Ende die Poll-Request selbst macht. Also es ist so ein bisschen so eine Arbeitsgruppe nur für mich. Aber es hat auch Leute, die aktiv sind in der Gruppe und die dann helfen mit Reviews. Wir machen jetzt jede Woche, schauen wir, dass wir so um die fünf bis zehn neue Pull-Requests oder Issues abarbeiten und dass wir so ganz langsam ein bisschen so, wenigstens ein bisschen Licht am Ende des Tunnels sehen in der ganzen Sache.

Und ich glaube, seit wir angefangen haben vor, ich glaube, zwei Jahren hat es angefangen mit der Arbeit, haben wir so um die, ich glaube, 800 oder so Pull Requests und Issues abgearbeitet, weil viele sind ganz einfache Sachen, so hier fehlt ein Komma oder das Wort hier ist nicht ganz okay, können wir es nicht ändern. Und am anderen Ende des Spektrums sind halt so Sachen wie, wo wir vorher diskutiert haben mit, okay, müssen wir jetzt ein Beispiel geben, dass halt ein Link auch mit einem Einpixel-Link, dass es auch funktioniert, ja, nein. Oder.

Dieser Erfolgskriterion hat zwei Interpretationen, welche von den zwei ist jetzt die richtige. Und das sind so mehr die größeren Work-Items, an denen wir arbeiten. Aber nee, es ist so ein, von allen etwas, ganz einfache Sachen und auch ganz, ganz komplizierte Sachen. Aber nee, wir sind dabei, ein bisschen mehr so Licht in den Schatten zu bringen. Eine Sache, wo ich ganz froh bin drüber, wir haben es geschafft, fast alle dieser Branches entweder zu killen, weil die irgendwie nur hängen geblieben sind irgendwo, oder zu gucken, okay, das bezieht sich auf diesen Pull-Request, ist der noch relevant, der ist von 1999, okay, oder das bezieht sich noch auf WCAG 2.0, ist nicht mehr relevant, können wir es schließen, Oder halt, okay, ja, das Problem.

Was diese Pull-Request versucht zu lösen, ist immer noch da. Fangen wir entweder neu an oder können wir es modifizieren, dass es jetzt auch, mergeable ist, heutzutage in der letzten Version. Und ja, es hält mich bis sie. Und es ist so mehr so mein Ziel, wo ich viel drin investiere. Wie das Ganze dann später aussieht, so in der Working Group selbst und wie das Ganze abgearbeitet wird, Das überlasse ich gerne dann den Chairs und Editors, vom Working Group selbst.

Ich weiß aber, eins der großen Probleme, die Wokang immer hatte, war, viele der Spezifikationen, wie du auch schon sagtest, sind oft sehr technisch. Und dann hast du als Kriterium am Ende, um zu sagen, ist diese Spezifikation, jetzt mature enough oder nicht, dass du halt wenigstens zwei oder drei, verschiedene Implementationen hast, dass du also in drei verschiedenen Browsern funktioniert das. Okay, das ist gut für eine Spezifikation. Mit WCAG, weil es sich halt auf Content bezieht, ist es dann schon ganz komisch, weil einige interpretieren das als, ja, können wir wenigstens drei große Webseiten finden, die das richtig machen, ja oder nein. aber das ist so ein Chicken-and-Egg-Problem.

Du kannst nicht sagen, okay, ja. Das Problem wurde schon gelöst von drei großen Seiten. Ja, wenn es gelöst ist, brauchen wir wahrscheinlich auch kein Success-Criterion. Oder es ist was ganz Neues. Klar hat es noch keiner gemacht. Und wann werden sie es machen? Das ist so diese komische Situation mit WCAG. Es ist an sich keine technische Spezifikation, so wie viele andere, wie ARIA oder Pointer-Events, wo ich auch aktiv bin. Die beziehen sich alle sehr auf die Technologie selbst. Da kann man das schon, sehr viel präziser sein mit, okay, ist da jetzt Support für das oder nicht.

Ja. Ja, aber deine Motivation ist ja dann im Endeffekt wirklich, dass du darauf hinarbeitest, dir deine Arbeit und die deiner KollegInnen, einfach leichter zu machen, dass du dich nicht immer mit dem gleichen Käse rumschlagen muss und einfach irgendwie das Gefühl hast, so hey, unsere Arbeit entwickelt sich da auch so ein bisschen weiter. Genau, und dass es halt klar ist. Und dass wir, ob es jetzt Leute bei mir in der Firma oder bei einem Competitor in einer anderen Firma, dass wir wenigstens die gleiche Interpretation haben von Sachen.

Da kann man dann, kann man sich immer noch drum streiten. Wir finden immer was, wo wir uns streiten können. Ja, Raum ist ja immer für sowas. Genau, aber halt wenigstens, dass wir die Basis für unseren Streit ist wenigstens klar, dass wir halt, direkt die gleiche Interpretation haben von dem, worüber wir diskutieren. Genau, und das Fazit soll auf jeden Fall jetzt nicht sein für unsere Hörerschaft, dass WUCAG irgendwie doof ist, sondern das ist sozusagen immer noch.

Der beste Leitfaden, den wir haben. Aber er ist, nicht perfekt, ist über die Zeit eben auch gewachsen, das Web selber hat sich verändert und da nagt natürlich der Zahn der Zeit an dieser Spezifikation, die dann aber ja immer wieder sozusagen erweitert wird. Wir haben ja gelernt, warum die Kriterien selbst nicht nochmal angefasst werden im Nachhinein, aber dann eben kommen neue dazu. Genau, also ja, aber es ist doch gut, zu hören, dass sich da auch was tut und ich glaube, dass das auch ein guter Ansatz ist, einfach so ein bisschen die Gegenwart zu fixen, anstatt die Luftschlösser zu bauen, die da WCAG 3.0 heißen und wo man eben nicht weiß.

Also ich meine, da freuen wir uns da trotzdem alle drauf, wenn es irgendwann mal kommt. Nee, du, da sind sehr gute Ansätze mit dabei, aber wie gesagt, bis es irgendwann auch mal ein bisschen solide wird, das Ganze, und bis es dann irgendwann in einem Gesetz referenziert wird, das wird noch eine gute Langeweile dauern. Ja, kann man das sehen. Das Gefühl. Burkak 2 ist Flexbox und Burkak 3 ist Grid. Das ist immer so mein mentales Bild dafür. Wir probieren euch vielleicht total tolle Dinge, also erweitert die Perspektive und die Dimensionalität, aber sozusagen das Workhorse ist immer noch etwas neuer und tut den Job und lässt uns Dinge bauen.

Oder es ist so mehr so, ja, WUKANG 3 ist so, dass alles ist Virtual Reality und es wird alles toll. Aber es ist ja vielleicht auch gut, ich weiß nicht, manchmal ist das ja so, dass wenn man sozusagen das tolle Neue hat, dann gibt es auch ganz viele, die dann dahin rennen und sich damit beschäftigen und dann sozusagen. Von denen nichts mehr zu sehen ist und man in Ruhe dann seine Bahn ziehen kann mit der Eltern-Spezifikation, weil einfach weniger Leute dann da irgendwie abnerven, weil die ja alle lieber bei dem neuen hippen Scheiß mitmachen.

Genau. Und einer der guten Aspekte ist auch, ich habe jetzt viel darüber geredet, über unsere WCAG-2-Taskforce für Backlog. Viele der Leute, die da in der Taskforce sind, sind auch beim WCAG-3 aktiv. Also viele der Aspekte, wo wir dann diskutieren und sagen, okay, das ist nicht so klar, können wir das ummodeln oder hier hat es einen Gap, den müssen wir füllen. Diese Diskussionen fließen dann auch hoch in WCAG 3. Also das ist glücklicherweise, also Probleme, die wir finden, da wird schon WUKA3 vorgewarnt. Das ist also okay, wir hatten Stress, um das in zwei zu definieren.

Vielleicht fangen wir dieses Mal Tabula Rasa an, dass wir uns nicht wieder so in die Ecke malen mit diesen Problemen. Also von dem her ist also glücklicherweise ist es dann nicht, wenn drei rauskommt, war alles umsonst, was ich gemacht habe, sondern hoffentlich hat es auch viel Impuls gehabt und dann Sachen für die nächste Version ein bisschen besser zu machen. Und vielleicht abschließend noch die Frage, so der Ladebalken von WCAG 3.0, wo steht er gerade? So bei zwei, fünf Prozent oder zehn gefühlt?

Es kommt immer darauf an, wen du fragst. Es sind sehr, sehr optimistische Leute sind da am Werk und die denken, ja, ja, es ist wahrscheinlich noch ein Jährchen oder so, bis wir irgendwas haben, wo wir dann… So ein bisschen wie bei Fusionsreaktoren. Genau, es ist immer so um die Ecke. Also ich persönlich glaube, das ist so 30 Prozent. Es wird noch viel diskutiert. Ich weiß nur, was war es? Wahrscheinlich vor zehn Jahren oder was war ich ein bisschen aktiv, als die gerade den Namen erfunden hatten mit Silver, dass das so clever war.

Das AU, das ist AG, das ist Argentum, das ist Silber ist. Da waren sie ganz stolz drauf. Ja, aber dann hatten sie, glaube ich, für Monate lang hatten sie daran gearbeitet. Da waren die auch erschöpft erstmal nach dieser tollen Idee. Genau, genau. Und glaube, am Ende haben sie es dann alles, was sie gemacht hatten bis dahin, wurde dann weggeschmissen und das Ganze wurde nochmal neu angefangen. Also ich habe diese Adventure schon seit zehn plus Jahren miterlebt.

Und ja, schauen wir halt mal. Ja, ich bin gespannt. Ja, aber cool, dass wir mal so ein bisschen über die WCAG gesprochen haben, weil genau das haben wir wohl schon mal gemacht, aber jetzt auch nicht so allzu häufig. Und die ist ja im Grunde die Grundlage für diese ganzen Audits und alles, was wir bauen. Und andere Gesetzesgebungen, die setzen sich drauf. Also EAA in Europa ist, referenziert ja EN. 301549. Und das ist ja praktisch WCAG. Also so mit drei Sprüngen bist du schon, selbst beim europäischen Accessibility bist du wieder bei WCAG.

Oder BitWi, B-I-T-V, weiß nicht, wie das oft in Deutschland. B-I-T-V, ja. BTV ist ja auch an sich WCAG oder RGAA in Frankreich. Also diese ganzen verschiedenen lokalen Gesetzesgebungen und Standards. Irgendwann landest du oft immer bei WCAG. Und von dem ist es sehr, sehr foundational, sich mit dem Thema ein bisschen zu beschäftigen. Ja, macht ja auch Sinn. Also ich meine, es ist ja international, wird ja daran gearbeitet und wir haben ja gehört, wie lange man braucht, um.

So eine Guideline aufzubauen und das dann irgendwie mehrfach zu schaffen, das geht ja gar nicht. Es hat etwas von einer Verfassung. Ja. Und jetzt schreibt eine neue, ist nicht einfach. Genau, wir verlinken und verweisen auch nochmal auf deinen Talk, also der sozusagen der Aufhänger war, der heißt These aren't the success criteria you're looking for, wo du so ein bisschen eben bei denen, die so ein bisschen vage sind, auf die eingehst, wie auch auf die, die man sozusagen hacken kann, wo man irgendwie nicht alle Eventualitäten sich dagegen gewappnet hat und man im Prinzip die austricksen kann.

Genau, ganz interessant. Und weil man eben auch über die Kriterien dann nochmal lernt. Die haben wir normalos ja auch gar nicht irgendwie alle auf dem Schirm. Also ihr könnt ja die Nummern und Unternummern kennt die auswendig. Ich heutzutage gar nicht mehr. Ich bin schon, ich bin immer, ich sage selbst bei unseren internen Audits, du bist bis auf die paar, die ich jeden Tag benutze, komm mir nicht mit so ein paar Nummern, sag mir einfach, welche du meinst. Was du willst, genau.

Ja, super. Genau, so machen wir das. Und die anderen Themen, die ganzen anderen Links habe ich auch eingesammelt, die kommen dann auch in die Shownotes rein. Super. Genau. Ja, und wie ist das? Also kann man sich einbringen auch bei der WUKAK? Also wenn ihr irgendwie tatkräftige Unterstützung haben wolltet, wäre das irgendwie was, auf das ihr scharf seid? Oder sagt ihr so, uh, das ist ja so ein delikates Thema, da muss man auch schon irgendwie.

Da kann nicht jeder irgendwie mitmachen. Also es ist halt so, theoretisch musst du halt ein Mitglied vom W3C sein oder von einer Firma, um da direkt beim Working Group mit dabei zu sein. Aber da das Ganze ja über GitHub sehr, sehr public ist, was ja auch schön ist, weil vor Jahren war das alles so ein bisschen so geheim. Du musstest genau wissen, wo du da hingehst. Aber jetzt ist alles schön offen. Da würde ich sagen, wenn du Lust und Zeit hast und dir wirklich langweilig ist, kannst du so wie der Peter, kannst du die ganzen Diskussionen verfolgen, die so passieren.

Ich mache dir noch einen Link auf unser ... Gitterprepo, das habe ich gerade ausgesucht. Das habe ich gerade ausgesucht. Ah ja, ja, gerne. Das habe ich vor kurzem auch public gemacht. Wir haben herausgefunden, das war ein Privatgesetz, dass das nur W3C-Member sehen. Aber da das wirklich nur als Board benutzt wird, um auf Public Issues und Poll Requests zu weisen, habe ich gesagt, komm, machen wir das Ganze public. Da können die Leute halt sehen, statt mich immer zu fragen, was ist mit meiner Issue? Die hatte ich vor ein paar Wochen, habe ich eine Issue geschickt oder ein Pull-Request.

Habt ihr die schon abgearbeitet? Und da sage ich, ja, guck mal, hier sind die anderen 500, an denen wir noch basteln. Du bist irgendwo in der Line unten dran. Da habe ich dann gesagt, okay, machen wir es Public. Da kann ich die Leute drauf verweisen. Aber warte mal, ja, da habe ich den Link hier. Genau, aber da muss man kein W3C-Mitglied sein. Nee, genau. Ich dachte erst so, huch, da muss man ein Mitglied sein. Nee, da kannst du, weil das alles auf GitHub ist und Public, kannst du gerne reinspringen, kannst auch neue Issues machen.

Kannst sagen, okay, ich als normalsterblicher Nicht-W3C-Member habe da dieses Problem oder wie interpretiere ich das? Im schlimmsten Fall, ich versuche momentan auch Sachen, die wirklich nur Fragen sind, mehr in die GitHub-Diskussionen zu schieben. Aber wenn es wirklich was ist, wo wir sagen können, okay, das ist nicht klar oder das muss noch klarifiziert werden oder geklärt werden im Dokument selbst, dann machen wir dann auch gerne dann Issues und dann Pull Requests draus und so.

Also ja, wer Lust und Zeit hat und kein Leben, so wie ich, kann sich gerne da reinhauen. Sag ich noch kurz, Patrick, Invited Experts habt ihr aber auch, oder? Ja, beim Accessibility Working Group haben wir. Für die, die den Begriff nicht kennen, in der W3C kann man auch als Ehrenamtler sozusagen, den Weg reinfinden, wenn man eingeladen wird in eine Working Group, ohne zu einem Paying Member zu gehören, so wie meiner einer. Ich mache das ohne bezahlt zu werden. Wer das also auch mag, der kann sich auch so verdingen.

Man muss halt Zeit reinstecken und je nachdem kostet es auch, wenn man so bei diesen Face-to-Face-Meetings dann mit dabei sein will, die muss man selber zahlen. Ja, da gibt es tatsächlich inzwischen auch Support-Funds. Die Lippendien gibt es, ja. Da ist die W3C auch besser geworden. Also da lohnt es sich auch, wenn man so ein bisschen ernsthafter die ehrenamtliche Arbeit machen will, sollte man sich nicht davon abschrecken lassen, dass man nicht zu einem der großen oder kleinen Namen, die sich die Mitgliedschaft leisten können, dazu gehört.

Ich sage immer, ich bin ein aninvited Expert. Aber ja, mich kriegt man nicht runter. Ja, du bist immer schon da. Ja, genau. Das finde ich immer witzig. Bei uns, bei der Arbeit, intern, bei unserem Slack, sobald irgendwer eine Frage hat in Sachen, ja, wie interpretiere ich das? 90% der Zeit kann ich denen dann einfach direkt einen Link auf irgendeine Issue, die ich 2020 oder was irgendwo gefeilt habe, sage ich, ja, hier wurde alles diskutiert. Das ist dann immer so. Oder selbst wenn ich suche, finde ich meine eigenen Pull-Requests oder Issues und sage, ach, scheiße.

Ja, nice. Super. Genau, also wenn es ansonsten noch Fragen gibt, wie immer verlinken wir unsere beiden Gäste in den Shownotes und genau, wenn ihr die Folge gut fandet, dann tut es kund. Und dann würde ich sagen, hören wir uns nächste Woche wieder und da geht es, auch um eine EU- Regelung, aber um eine ganz andere, nämlich den EU-AI-Act. Genau, da haben wir Florian Sovade zu Gast und der wird uns darüber was erzählen. Ich bin gespannt. Dann macht's gut. Vielen Dank, dass ihr dabei wart. Hat mich gefreut. Ja. Ebenso.

Schönen Abend und genau, wir gucken mal, wann wir das. Wann ihr hier wieder vorbeischaut. Also genau, einen Glücksrad haben wir ja schon einen Termin in der Zukunft gesetzt. Ich glaube allerdings, wann war es im September oder so? August. Also es dauert ein Weilchen. Und mit dir, Patrick, kriegen wir auf jeden Fall auch noch mal was auf die Beine gestellt. Ja, wenn nicht wieder in 13 Jahren oder sowas. In 13 Jahren, genau. Wenn WCAG 3, die erste Version rauskommt vielleicht, weiß nicht.

Das wäre doch super. Lass uns dann für den 13 Jahren für das Release verabreden. Wie ich dann im Rollstuhl hier, im Altersheim sage ich, ja, da ist es. Genau, und wenn die vorher releasen wollen, musst du natürlich bremsen dann. Da musst du dich dann da rein zecken und dann auf die Bremse treten. Genau, genau. Super, alles klar. Dann macht's gut, schönen Abend und bis bald. Jo, tschüss.

Transcript supplied by the publisher with the episode.

Podcast

Working Draft

Vanessa Otto, Peter Kröner et al. · Tech & Science · German

Deutschsprachiger Podcast über Webentwicklung — HTML, CSS, JavaScript, Browser-APIs und alles rund ums moderne Web.

More from Working Draft All episodes →

  1. 17 Jul 2026 · 33 min

    On Tour @ #headinthecloud – What does a Fossil-Free Internet look like? With Chris Adams

    We caught up with Chris Adams (LinkedIn / Bluesky / Mastodon) at mittwald’s Head in the Cloud festival to talk about one of the less visible aspects of our industry: the energy that powers the internet. Chris is Director of Tech and Policy at the Green Web Foundation, where he works on making the web less dependent on fossil fuels and helping the industry understand the environmental impact of our digital infrastructure. SHOWNOTES [00:00:27] WHAT DOES A FOSSIL-FREE INTERNET LOOK LIKE IN GERMANY? Chris starts by explaining why Germany is such an interesting place to discuss a fossil-free…

  2. E720 · 14 Jul 2026 · 1 hr 6 min

    Revision 720: ARIA-Glücksrad – von abstrakten Rollen und konkreten Problemen

    Wir spielen wieder ARIA-Glücksrad und sprechen mit Paweł Masarczyk (Mastodon), Peter Krautzberger (LinkedIn / Mastodon) und Marco Bretschneider (Mastodon) über ARIA-Rollen und -Attribute, die uns unser Glücksrad ausspuckt. Daniela Kubesch (LinkedIn / Bluesky / Mastodon) musste leider erneut aussetzen, und Paweł wurde später von seiner Internetverbindung aus der Runde gewürfelt. Wir arbeiten uns durch abstrakte Landmark-Rollen, praktische Landmark-Navigation, die Rolle option, aria-required, ariaNotify() und schließlich role="form". Dabei geht es wie immer darum, was die Spezifikation meint,…

  3. 10 Jul 2026 · 22 min

    On Tour @ #headinthecloud – Der Ransomware-Angriff auf guenstiger.de mit Torben Mallwitz

    Wir waren dieses Jahr erneut auf der Head in the Cloud von mittwald in Espelkamp unterwegs und haben dort mit Torben Mallwitz über einen Vortrag gesprochen, den man so vermutlich nur selten auf einer Konferenz hört. Torben, CTO von guenstiger.de, hat sehr offen darüber berichtet, wie das Unternehmen im April 2025 Opfer eines Ransomware-Angriffs wurde und welche technischen, organisatorischen und menschlichen Herausforderungen die folgenden Tage und Wochen geprägt haben. SHOWNOTES [00:00:27] RANSOMWARE, REALITÄT UND WIEDERHERSTELLUNG Am Morgen des 23. April 2025 begann für das Team von…

  4. E719 · 7 Jul 2026 · 1 hr 15 min

    Revision 719: Der EU AI Act, mit Florian Sowade

    Wir haben diese Revision mit Florian Sowade über den EU AI Act gesprochen. Florian hat sich in die Regulierung eingelesen und erklärt uns, was die EU damit eigentlich regulieren will, welche Risikokategorien es gibt und warum der Act nicht primär ein Verbot von KI ist. Gemeinsam sortieren wir ein, welche Pflichten schon gelten, welche noch kommen, warum Hochrisiko-Anwendungen anders behandelt werden als alltägliche KI-Tools und weshalb gerade Transparenz, Schulungspflichten, Trainingsdaten, Deepfakes und Auditierbarkeit in der Praxis noch viele offene Fragen aufwerfen. SHOWNOTES [00:01:03]…

  5. 3 Jul 2026 · 23 min

    On Tour @ #headinthecloud – Die Website der Zukunft mit André Richter

    Wir waren dieses Jahr erneut auf der Head in the Cloud von mittwald in Espelkamp unterwegs und haben die Gelegenheit genutzt, mit André Richter über die Zukunft der Website zu sprechen. André ist seit den frühen Tagen des Webs im Agenturumfeld unterwegs und beschäftigt sich heute als Director Digital Experience mit der Frage, wie Unternehmen auch in einer von KI geprägten Welt digital relevant bleiben können. SHOWNOTES [00:00:26] DIE WEBSITE DER ZUKUNFT Sterben Websites aus? Für André Richter lautet die Antwort: nein, aber sie verändern sich grundlegend. Die klassische Vorstellung einer…

  6. E717 · 23 Jun 2026 · 1 hr 28 min

    Revision 717: Ein Jahr BFSG, mit Nina Gerling

    Wir sprechen mit Nina Gerling über das erste Jahr nach dem Inkrafttreten des Barrierefreiheitsstärkungsgesetzes (BFSG). Nina bringt mehr als 20 Jahre Erfahrung im Bereich digitale Barrierefreiheit mit und berichtet aus ihrer Arbeit als Beraterin, Auditorin und Mitglied verschiedener Accessibility-Communities. Gemeinsam schauen wir darauf, welche Auswirkungen das BFSG in der Praxis hat, welche Produkte und Dienstleistungen tatsächlich betroffen sind und wo sich bereits erste Herausforderungen, Missverständnisse und Schlupflöcher zeigen. Außerdem sprechen wir darüber, warum Barrierefreiheit…

  7. E716 · 16 Jun 2026 · 1 hr 12 min

    Revision 716: Agentic Engineering statt Vibe Coding

    Wir sprechen über Agentic Engineering und die Frage, wie sich KI-gestützte Softwareentwicklung gerade verändert. Dabei geht es weniger um klassisches Vibe Coding und mehr um die Orchestrierung von Agents, Tools und Workflows, die uns bei Planung, Umsetzung und Betrieb von Software unterstützen können. Anhand unserer eigenen Erfahrungen diskutieren wir aktuelle Werkzeuge, den Umgang mit Skills, MCPs und Agenten sowie die Herausforderungen, die beim Einsatz von KI im Entwicklungsalltag entstehen. UNSER SPONSOR Alle reden von Automation – aber wo betreibst du eigentlich deine Tools? Egal ob n8n…

  8. E715 · 2 Jun 2026 · 1 hr 9 min

    Revision 715: Hörendenfragen zu PWAs, Tailwind und Browsern

    Wir setzen unsere Hörendenfragen aus Revision 703 fort und sprechen diesmal ausführlich über den Zustand von PWAs im Jahr 2026 sowie über die Frage, warum sich Browser gefühlt kaum noch weiterentwickeln. Dabei landen wir bei Install-Prompts, App-Stores, Browser-Engines, alternativen Suchmaschinen und der immer gleichen Chromium-Basis unter vielen modernen Browsern. Außerdem diskutieren wir über neue Browser-Ideen wie den OpenAI Atlas Browser, schauen auf die Rolle von Projekten wie Electron und Tauri und fragen uns, ob echte Browser-Innovation heute überhaupt noch stattfindet oder ob sich…

  9. E714 · 26 May 2026 · 1 hr 21 min

    Revision 714: Kirby, KI und die Verantwortung langlebiger Software, mit Bastian Allgeier

    Wir sprechen mit Bastian Allgeier (Web / Mastodon / Bluesky / LinkedIn) darüber, wie sich Kirby nach mehr als 14 Jahren weiterentwickelt und was es bedeutet, ein kommerzielles CMS langfristig zu pflegen. Dabei geht es um Verantwortung gegenüber Kundinnen, Kunden und Community, um Wartbarkeit, Refactoring und die Frage, warum Beständigkeit gerade in schnelllebigen Zeiten ein eigenes Feature ist. Außerdem diskutieren wir, wie sich KI auf CMS-Entwicklung, Content-Workflows, Plugins, Support und Produktentscheidungen auswirkt. Bastian beschreibt, warum Kirby KI nicht als fest eingebautes…

  10. E713 · 19 May 2026 · 1 hr 8 min

    Revision 713: ARIA-Glücksrad – von Dialogen, Definitionen und Datepickern

    Wir drehen wieder am ARIA-Glücksrad und sprechen mit Daniela, Paweł und Peter Krautzberger über Rollen und Attribute, die man im Alltag teils nie sieht, teils besser nicht selbst nachbauen sollte. Dabei geht es um abstrakte Rollen, Menü-Patterns, deaktivierte Zustände, Dialoge, Präsentationswerkzeuge und einige ARIA-Fallen, die erst in Kombination mit Screenreadern richtig sichtbar werden. Diesmal müssen wir leider auf unser Runden-Mitglied Marco verzichten. SHOWNOTES [00:02:33] ARIA SECTIONHEAD ROLE Die erste gezogene Rolle ist eine abstrakte ARIA-Rolle. sectionhead ist nicht für Autorinnen…

Take it with you

The Melo app keeps playing with the screen off, works in the car and on your watch, wakes you to your station, and browses the whole catalogue offline. Free, no ads, no account.

Get it on Google Play