Freund*innen der gepflegten Stimmungskodierung, die Barrierefreiheit ist nicht so die Stärke von euren „Tools“.
-
Freund*innen der gepflegten Stimmungskodierung, die Barrierefreiheit ist nicht so die Stärke von euren „Tools“. Eine Firma hat mich angefragt, für 200 € eine SKILL.md-Datei zu erstellen, die deren "KI"-Agenten an die Accessibility in Web-Projekten erinnert und definiert, was immer wieder neu beachtet werden muss.
Stattdessen hab ich das einfach unter einer freien Lizenz umsonst gemacht, und ihr findet es hier: https://github.com/KreerC/ACCESSIBILITY.md
In der Hoffnung, dass das ein bisschen dazu beitragen wird, dass vibecoded Projekte wenigstens ein bisschen benutzbarer werden, da sie (ob man das mag oder nicht) leider immer mehr Verbreitung finden werden.
Das Dokument unterscheidet sich genau gar nicht von *allen* gängigen Impulsvorträgen zu Web Accessibility, die es so gibt. *Das hier* wird niemanden Jobs kosten, außer die Leute, die gerne viel plappern ohne was zu wissen.
-
In der Hoffnung, dass das ein bisschen dazu beitragen wird, dass vibecoded Projekte wenigstens ein bisschen benutzbarer werden, da sie (ob man das mag oder nicht) leider immer mehr Verbreitung finden werden.
Das Dokument unterscheidet sich genau gar nicht von *allen* gängigen Impulsvorträgen zu Web Accessibility, die es so gibt. *Das hier* wird niemanden Jobs kosten, außer die Leute, die gerne viel plappern ohne was zu wissen.
@kc dumme Frage vielleicht. Aber, was ist der Punkt darin einer KI die Beschreibung einer Sache zu liefern, die sie ja, zumindest in meiner Erwartung, wissen sollte. Sollte es nicht reichen, beim Vibecoden als pre-prompt zu sagen " mach acessible" ?
Oder versehe ich das Konzept von KI hier falsch? -
In der Hoffnung, dass das ein bisschen dazu beitragen wird, dass vibecoded Projekte wenigstens ein bisschen benutzbarer werden, da sie (ob man das mag oder nicht) leider immer mehr Verbreitung finden werden.
Das Dokument unterscheidet sich genau gar nicht von *allen* gängigen Impulsvorträgen zu Web Accessibility, die es so gibt. *Das hier* wird niemanden Jobs kosten, außer die Leute, die gerne viel plappern ohne was zu wissen.
@kc das ist super.
Die Tage hatte Addy Osmani auch ein Skillset veröffentlicht. Dort sind sehr viele Codebeispiele gelistet. Aber auch negativ Beispiele, das sah ich kritisch. Muss Mal gucken wo ich deines demnächst verwende. Oder ein best off. Aber nicht vibe codend sondern als Unterstützung
https://github.com/addyosmani/web-quality-skills/tree/main/skills%2Faccessibility
-
@kc dumme Frage vielleicht. Aber, was ist der Punkt darin einer KI die Beschreibung einer Sache zu liefern, die sie ja, zumindest in meiner Erwartung, wissen sollte. Sollte es nicht reichen, beim Vibecoden als pre-prompt zu sagen " mach acessible" ?
Oder versehe ich das Konzept von KI hier falsch?@x2ero Das Trainingsmaterial ist in der Regel aus historischen Gründen selbst nicht barrierefrei und das Projekt an dem gearbeitet wird hat vielleicht andere Entscheidungen getroffen. Scheinbar muss man die Modelle „steuern" indem man ihnen alles Zeug und was das konkret heißt immer wieder in die Prompts steckt, damit sie die auf jeden Fall berücksichtigen und die Sachen richtig machen.
-
@kc das ist super.
Die Tage hatte Addy Osmani auch ein Skillset veröffentlicht. Dort sind sehr viele Codebeispiele gelistet. Aber auch negativ Beispiele, das sah ich kritisch. Muss Mal gucken wo ich deines demnächst verwende. Oder ein best off. Aber nicht vibe codend sondern als Unterstützung
https://github.com/addyosmani/web-quality-skills/tree/main/skills%2Faccessibility
@holger Ich testete das. Zumindest die Codex-Modelle kommen nicht wirklich gut zurecht mit den Beispielen in bestehenden Codebases, und sie abstrahieren daraus keine Nuancen.
Und „Moderate (fix soon)" is ein bisschen Quatsch weil das alles schon strukturelle Dinge sind.
-
@holger Ich testete das. Zumindest die Codex-Modelle kommen nicht wirklich gut zurecht mit den Beispielen in bestehenden Codebases, und sie abstrahieren daraus keine Nuancen.
Und „Moderate (fix soon)" is ein bisschen Quatsch weil das alles schon strukturelle Dinge sind.
@kc japp, wollte nur zeigen, was andere auch tun. Eigentlich wäre von Anfang an richtig, wichtiger. So hat das den Geschmack von einem Kunden der sagt, wir können ja noch fixen wenn wir verklagt werden.
-
In der Hoffnung, dass das ein bisschen dazu beitragen wird, dass vibecoded Projekte wenigstens ein bisschen benutzbarer werden, da sie (ob man das mag oder nicht) leider immer mehr Verbreitung finden werden.
Das Dokument unterscheidet sich genau gar nicht von *allen* gängigen Impulsvorträgen zu Web Accessibility, die es so gibt. *Das hier* wird niemanden Jobs kosten, außer die Leute, die gerne viel plappern ohne was zu wissen.
@kc Gute idee. In meinen vibecoding Experimenten musste ich bisher auch immer massiv nachkorrigieren. Ich bin nicht sicher ob die Anweisung für "use semantic HTML" taugt. Das gehörte bisher auch immer zu meinen eingangs projektanforderungen ans LLM und hat ironischerweise bei mir zu einer gehäuft schlechten Nutzung von ariaattributen als ersatz von semantic-HTML geführt . Es gibt so verdammt viel falsches Trainingsmaterial. Nein ich finde es trotzdem oder gerade deshalb gut.
-
In der Hoffnung, dass das ein bisschen dazu beitragen wird, dass vibecoded Projekte wenigstens ein bisschen benutzbarer werden, da sie (ob man das mag oder nicht) leider immer mehr Verbreitung finden werden.
Das Dokument unterscheidet sich genau gar nicht von *allen* gängigen Impulsvorträgen zu Web Accessibility, die es so gibt. *Das hier* wird niemanden Jobs kosten, außer die Leute, die gerne viel plappern ohne was zu wissen.
Ich mach das lieber selbst richtig und open source als dass da dann die ableistischen EyeAbles, AccessiBes und Userways ankommen und groß abcashen.
Ansonsten ist das Dokument auch für Accessibility-Neulinge in der Webentwicklung interessant, es ist alle sehr wichtigen Dinge aufs einfachste heruntergebrochen.
Wenn ihr das richtig und sinnvoll selbst lernen wollt, hab ich mal einen Vortrag dazu gehalten: https://media.ccc.de/v/38c3-software-accessibility-without-the-fuzz
-
Ich mach das lieber selbst richtig und open source als dass da dann die ableistischen EyeAbles, AccessiBes und Userways ankommen und groß abcashen.
Ansonsten ist das Dokument auch für Accessibility-Neulinge in der Webentwicklung interessant, es ist alle sehr wichtigen Dinge aufs einfachste heruntergebrochen.
Wenn ihr das richtig und sinnvoll selbst lernen wollt, hab ich mal einen Vortrag dazu gehalten: https://media.ccc.de/v/38c3-software-accessibility-without-the-fuzz
Auch mit diesem Skill wird KI für immer extrem beschissene Designentscheidungen und Code-Aufbauten erzeugen, weil das Web eben seit Jahren so unbarrierefrei wildgewachsen ist und *nirgends* gescheite Dokumentation existiert, wie Projekte das integrieren. Das hier ist nur ein Ansatz basierend auf meiner Berufserfahrung mit echten Menschen, wo oft Missverständnisse sind, und wo oft drauf hingewiesen werden muss.
Nutzt es verantwortungsvoll.
-
@x2ero Das Trainingsmaterial ist in der Regel aus historischen Gründen selbst nicht barrierefrei und das Projekt an dem gearbeitet wird hat vielleicht andere Entscheidungen getroffen. Scheinbar muss man die Modelle „steuern" indem man ihnen alles Zeug und was das konkret heißt immer wieder in die Prompts steckt, damit sie die auf jeden Fall berücksichtigen und die Sachen richtig machen.
-
W wando@troet.cafe shared this topic
A alsternerd@akkoma.alster.space shared this topic
S svenja@mstdn.games shared this topic
