Zugängliche Palette: HSL in Farbsystemen nicht mehr verwenden

 (wildbit.com)
2 Punkte von GN⁺ 2023-08-30 | 1 Kommentare | Auf WhatsApp teilen
  • Die bisherige Farbpalette von Postmark hatte uneinheitliche wahrgenommene Helligkeit je nach Farbe, und Kontrastverhältnisse zwischen Stufen ließen sich schwer vorhersagen, sodass die von WCAG empfohlenen Kontraste jedes Mal manuell geprüft werden mussten
  • HSL/HSV sind lediglich einfache Umwandlungsmodelle von RGB und spiegeln die menschliche Wahrnehmung von Helligkeit und Sättigung nicht wider; für die Auswahl einzelner Farben sind sie brauchbar, für den Aufbau eines Farbsystems aber ungeeignet
  • CIELAB und LCh sind wahrnehmungsgleichmäßige Farbräume, die so entworfen wurden, dass numerische Änderungen eher den empfundenen Änderungen entsprechen, wodurch sich Farbstufen mit derselben Helligkeit konsistenter erzeugen lassen
  • Accessible Palette ist eine App, die auf Basis von LCh durch Anpassung von Helligkeit, Kontrastverhältnis, Hue-Korrektur und Übernahme bestehender Markenfarben konsistente Paletten erzeugt
  • Man sollte sowohl das Kontrastverhältnis nach WCAG 2.1 als auch APCA aus dem Working Draft von WCAG 3 prüfen, um sowohl die aktuellen Richtlinien einzuhalten als auch auf künftige Änderungen des Kontrastalgorithmus vorbereitet zu sein

Probleme im Farbsystem von Postmark

  • Die bisherige Postmark-Palette hatte zwei Probleme
    • Blau und Rot wirkten deutlich dunkler als Gelb und Grün, die wahrgenommene Helligkeit war also nicht konsistent
    • Das Kontrastverhältnis zwischen Farbvarianten ließ sich schwer vorhersagen, sodass nicht leicht erkennbar war, ob ein Farbpaar die Empfehlungen der WCAG erfüllt
  • Jedes Mal, wenn ein Farbpaar ausgewählt wurde, musste das Kontrastverhältnis manuell überprüft werden, und oft bestand die Gefahr, dass das in der Praxis gar nicht geschah
  • Die Ursache lag sowohl in den Grenzen des HSL-Farbmodells selbst als auch darin, dass Design-Tools bessere Alternativen nicht ausreichend unterstützten

Warum HSL nicht zu Farbsystemen passt

  • RGB ist ein Modell, das widerspiegelt, wie Bildschirme funktionieren, aber kein besonders intuitives Modell dafür, wie Menschen Farben auswählen
  • HSL und HSV/HSB sind Alternativen, die in den 1970er Jahren entwickelt wurden, um RGB näher an die Art anzulehnen, wie Menschen über Farben nachdenken
    • HSL steht für Hue, Saturation, Lightness
    • HSV/HSB steht für Hue, Saturation, Value beziehungsweise Brightness
  • Damals waren die Rechenkosten präziserer Modelle hoch, daher opferten HSL und HSV wahrnehmungsbezogene Genauigkeit zugunsten der Rechengeschwindigkeit
  • Dadurch sind HSL und HSV letztlich nur einfache mathematische Umwandlungen von RGB und bilden die vom Menschen empfundene Helligkeit oder Sättigung nicht zuverlässig ab
  • Ein Beispiel: Eine Farbstufe mit Saturation 100 und Lightness 50 in HSL hat im Modell überall dieselbe Helligkeit, tatsächlich wirkt Blau #00F aber viel dunkler als Gelb #FF0 oder Cyan #0FF
  • In HSL werden vollständig gesättigte Farben auf die Maximalwerte von RGB abgebildet und auf dem Hue-Kreis bei Lightness 50 angeordnet, während Lightness 0 und 100 jeweils Schwarz und Weiß entsprechen
    • Hellere oder dunklere Varianten werden erzeugt, indem mit Weiß oder Schwarz „gemischt“ wird
    • Die vertikale Mittelachse bildet neutrale Farben beziehungsweise Graustufen mit Saturation 0

CIELAB und LCh

  • Schon zu der Zeit, als HSL und HSV formalisiert wurden, gab es mit CIELAB bereits eine bessere Alternative
  • Die International Commission on Illumination, also die CIE, definierte 1976 den CIELAB- beziehungsweise L*a* b*-Farbraum
  • CIELAB ist ein wahrnehmungsgleichmäßiger Farbraum, der so gestaltet wurde, dass numerische Änderungen ähnlichen wahrgenommenen Farbänderungen entsprechen
    • Anders als RGB wurde er so entworfen, dass er den gesamten Bereich sichtbarer Farben umfasst
    • Die Lightness-Komponente L* ist eng an die menschliche Wahrnehmung von Helligkeit angepasst
  • CIELAB besteht aus drei Achsen
    • Der L*-Wert definiert 0 als Schwarz und 100 als Weiß
    • Die a*-Achse ist die Gegenfarbachse Grün–Rot; negative Werte gehen in Richtung Grün, positive in Richtung Rot
    • Die b*-Achse ist die Gegenfarbachse Blau–Gelb; negative Werte gehen in Richtung Blau, positive in Richtung Gelb
  • CIELCh, LCh oder Lch(ab) ist die zylindrische Darstellung von CIELAB
    • Anstelle von a* und b* werden Chroma und der Hue-Winkel verwendet
    • Die Lightness bleibt unverändert
  • Der Hue-Winkel von LCh ähnelt dem Hue in HSL, ist aber nicht identisch
    • HSL/HSV setzen die drei additiven Primärfarben Rot, Grün und Blau auf H=0, 120, 240°
    • LCh setzt Rot, Gelb, Grün und Blau auf h=0, 90, 180, 270°
  • Es gibt auch einen ähnlichen Farbraum namens HCL oder LCh(uv), der im Unterschied zu LCh(ab) für Chroma eine gleichmäßige Skala von 0 bis 100 hat

Wie Farbstufen in LCh erstellt werden

  • Anders als HSL/HSV passt LCh zwar in einen Zylinder, füllt ihn aber nicht vollständig aus
  • Manche Kombinationen aus Lightness, Chroma und Hue ergeben Farben, die nicht existieren können
    • Ein Beispiel ist dunkles, hoch gesättigtes Gelb
  • Je näher eine Lightness-Skala an Schwarz oder Weiß kommt, desto geringer wird die Zahl der Farben, die Menschen noch unterscheiden können
  • Reale Bildschirme können zudem nicht das gesamte sichtbare Farbspektrum darstellen
    • Der sRGB-Farbraum steht für typische Displays und umfasst nur etwa ein Drittel des LCh-Farbraums
    • Auch CSS ist zumindest derzeit auf diesen Bereich beschränkt
  • Betrachtet man eine HSL-Farbstufe mit Saturation 100 und Lightness 50 aus Sicht von LCh, ist Gelb am hellsten und Blau am dunkelsten
    • Grün ist fast dreimal so hell wie Blau und etwa doppelt so hell wie Rot
  • Erzeugt man die Skala in LCh mit demselben Lightness-Niveau neu, wirkt die Helligkeit über die Farben hinweg visuell konsistent
    • Weil sich Chroma unterscheidet, können manche Farben stärker gesättigt sein als andere
    • Für Hinweis- und Warnfarben kann es sogar wünschenswert sein, dass sie stärker gesättigt sind als die Standard-Textfarbe; in einem Farbsystem kann dieser Unterschied nützlich sein
  • Wenn auch Chroma konsistenter angeglichen wird, lassen sich selbst im begrenzten sRGB-Farbraum weiche, stimmige Skalen erzeugen

Grenzen von Design-Tools und Accessible Palette

  • Figma, Sketch und Adobe XD unterstützen derzeit weder CIELAB noch LCh
  • Für Figma gibt es die Plugins LCH color picker und Chromatic, sie reichten jedoch nicht aus, um ein flexibles Farbsystem aufzubauen
  • Das benötigte Tool musste drei Bedingungen erfüllen
    • Beim Erzeugen von Farbvarianten Helligkeitskonsistenz bewahren
    • Das Kontrastverhältnis zwischen Stufen kontrollieren können
    • Flexibel genug sein, um bestehende Markenfarben zu übernehmen
  • Nachdem die Bibliothek Chroma.js mit guter LCh-Unterstützung gefunden wurde, wurde ein einfaches Tool gebaut, das per Code neue Paletten erzeugt
  • Nach interner Nutzung und dem Teilen mit einigen Bekannten wurde das Tool als App Accessible Palette veröffentlicht
  • Accessible Palette ist eine App zum Erstellen von Farbsystemen mit konsistenter Helligkeit und vorhersagbaren Kontrastverhältnissen über alle Farbstufen hinweg

Wie Accessible Palette funktioniert

  • Wenn eine Ausgangsfarbe angepasst oder eine Farbe aus einem bestehenden Design eingefügt wird, berechnet das Tool anhand von Chroma und Hue dieser Farbe eine Skala über mehrere Lightness-Stufen
  • Lightness ist vollständig anpassbar und lässt sich sowohl für helle als auch für dunkle Paletten verwenden
    • Sie kann fein abgestimmt werden, um bestehende Markenfarben einzubeziehen
    • Bei Postmark sollten die am häufigsten verwendeten Farben der bestehenden Palette erhalten bleiben: Gelb #FFDE00, Blau #007DCC, Grün #4FC47F
    • Deren Lightness-Werte 88.6, 75.2 und 50.6 wurden jeweils als Helligkeit für die Levels 200, 400 und 600 verwendet
  • Das Kontrastverhältnis hängt von der Lightness ab und wird für jedes Level sowohl nach der empfohlenen Methode aus WCAG 2.1 als auch mit dem neuen Algorithmus aus dem Working Draft von WCAG 3.0 berechnet
    • Standardmäßig wird der Kontrast aller Farben gegenüber weißem Hintergrund gemessen
    • Es kann aber auch ein beliebiges Farbfeld ausgewählt werden, um das Kontrastverhältnis relativ zu dieser Farbe zu messen
  • Levels können im RGB- oder CIELAB-Farbraum erzeugt werden
    • Je nach Fall können die Ergebnisse unterschiedlich ausfallen, daher lohnt sich das Experimentieren
    • Im Farbsystem von Postmark verringerte die Verwendung von CIELAB bei hellem Rot den Violettstich, erhöhte ihn bei Blau aber
  • Manche Farben benötigen über den gesamten Bereich hinweg eine Hue-Korrektur
    • Helles Gelb bekommt beim Abdunkeln einen Grünstich
    • Um es etwas stärker in Richtung Orange zu verschieben, wird eine negative Hue-Korrektur verwendet
  • Die App aktualisiert während der Nutzung die URL, um Änderungen zu speichern
    • So lässt sie sich mit dem Team teilen oder später in Figma-Bibliotheken und CSS-Farbvariablendateien referenzieren
  • Beispielpaletten sind unter anderem die neue Postmark color palette, eine auf Google’s Material Design basierende Palette und eine auf TailwindCSS basierende Palette verfügbar
    • Diese Beispiele sind keine exakten Reproduktionen der Originale, sondern Alternativen, die von den ursprünglichen Farben und Helligkeitsstufen inspiriert sind

Kontrastberechnung und WCAG

  • Accessible Palette zeigt zwei Kontrastwerte, weil die Methode aus WCAG 2.1 Grenzen hat
  • WCAG 2.1 berechnet das Kontrastverhältnis, indem die Luminanz der Vordergrundfarbe durch die Luminanz der Hintergrundfarbe geteilt wird
  • Diese Formel liefert eine lineare Reaktion, Menschen nehmen Kontraste zwischen hellen Farben jedoch stärker wahr als Kontraste zwischen dunklen Farben
  • In realen Beispielen kann ein Muster, das die Empfehlungen von WCAG 2.1 erfüllt, schwerer lesbar sein als eines, das als „unzureichender“ Kontrast markiert ist
  • Das W3C kennt dieses Problem, und Andrew Somers startete 2019 eine öffentliche Diskussion
  • Der von Andrew Somers vorgeschlagene neue Arbeitsalgorithmus wurde Teil des WCAG 3 Working Draft, außerdem entstand der APCA Contrast Calculator
  • APCA steht für Advanced Perceptual Contrast Algorithm und ist wahrnehmungsbezogen genauer; außerdem berücksichtigt er Schriftgröße und Schriftstärke
  • Accessible Palette verwendet APCA und setzt als minimale Empfehlung für gut lesbaren Text einen Wert von 60 an
    • Das entspricht ungefähr der bisherigen Empfehlung von 4.5:1 aus WCAG 2.1
  • Das Kontrastverhältnis nach WCAG 2.1 ist damit nicht völlig nutzlos
    • Im mittleren Farbbereich ist es weiterhin recht genau
    • Insgesamt ist der neue Algorithmus aber eine deutliche Verbesserung
  • Der Ansatz aus WCAG 3 ist noch ein Working Draft und kann sich im Lauf der Zeit ändern
  • Wer sowohl aktuelle Richtlinien einhalten als auch auf zukünftige Änderungen vorbereitet sein will, sollte beim Aufbau eines Farbsystems beide Leitlinien gemeinsam berücksichtigen

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2023-08-30
Hacker-News-Kommentare

  • Bei typischen Displays und Drucksystemen muss man davon ausgehen, dass gesättigtes Rot und Blau tatsächlich dunkler sind als Grün.
    Je nach Farbraum unterscheidet sich die genaue Formel, aber häufig wird Grayscale = 0.299R + 0.587G + 0.114B zitiert; in diesem Fall hat das hellste reine Rot etwa 30 % und reines Blau 11 % Helligkeit, sodass helles Rot in den meisten Fällen fast ein Widerspruch in sich ist.
    Man kann solche Farben verwenden, aber sie werden zwangsläufig immer dunkel wirken. Wenn man einfach nur Kontrastregeln anwendet, kann man zwar Barrierefreiheit erreichen; wenn man aber auch ein ansprechendes Ergebnis möchte, sind die im Artikel behandelten Techniken deutlich im Vorteil.
    Auch beim Erstellen von Rot-Cyan-Stereobildern wie https://en.wikipedia.org/wiki/Anaglyph_3D sind Bäume und Gras zwar grün, haben aber tatsächlich einen hohen Rotanteil, wodurch die Kanalbalance gut ist und sowohl Tiefenwirkung als auch Farbe gut herauskommen.
    Referenz: https://www.dynamsoft.com/blog/insights/image-processing/ima...

    • Das erinnert an die Zeit der NTSC-Broadcast-Safe-Bereiche und an Kunden, die Rot allzu sehr liebten.
      Es war immer schwierig zu erklären, dass wunderschöne rote Artworks im Fernsehen überhaupt nicht schön aussehen würden, besonders wenn es für Broadcast gedacht war.
      Selbst wenn es nicht für Broadcast war, konnte Rot außerhalb der Spezifikation noch einige Frames lang nachleuchten und aussehen, als würde es wie eine aufgeschnittene Kehle verlaufen.
    • Hier sind mehrere Dinge falsch.
      Wenn du die Antworten gelesen hast, antworte, dann kann ich ein paar Punkte genauer erklären.

  • Mich stört schon lange, dass Beispiele, die tatsächlich die WCAG-2.1-Empfehlungskriterien erfüllen, schwerer zu lesen sind als Beispiele mit einem „unzureichenden“ Kontrastverhältnis.
    Ich frage mich, warum die Formel der „Barrierefreiheitsrichtlinien“ standardisiert wurde, obwohl sie eher den gegenteiligen Effekt hat.

    • Es ist etwas bedauerlich, dass es für die im Bereich Kontrast-Barrierefreiheit am weitesten verbreiteten Algorithmen und Richtlinien keine peer-reviewte Grundlage gibt.
      Das gilt für 2.1 ebenso wie für den nächsten Standard; bei einem so einflussreichen Bereich würde ich mir wünschen, dass die Branche strengere Forschung fördert.
    • Ich erinnere mich, dass es innerhalb von W3C/WCAG Bestrebungen gab, die Formel zur Kontrastbewertung zu ändern.
      Vielleicht gab es aber auch nur entsprechende Forderungen, und sie wurden noch nicht offiziell übernommen.

  • Der beste Text, den ich zu diesem Thema gesehen habe, ist https://www.handprint.com/HP/WCL/color1.html.
    Er ist enorm lang, man sollte also damit rechnen, einen ganzen Tag dafür zu brauchen.
    Es mag überraschen, aber auch beim hübschen Einfärben von Logs in ClickHouse verwenden wir einige Ideen aus diesem Text: https://github.com/ClickHouse/ClickHouse/blob/master/base/ba...

    • Die konkrete Methode, diese ANSI-Farben in RGB umzuwandeln, war schwer zu finden; tatsächlich scheinen es nur Farbanforderungen zu sein, die von den Terminal-Einstellungen abhängen.
      Ich frage mich, ob du teilen kannst, welche RGB-Werte ihr für die einzelnen im Code festgelegten Nachrichtentypen erwartet.

  • Ich habe Eugene auf Figmas Config-Konferenz getroffen; er gab Designern viele ähnliche Praxistipps und war wirklich freundlich sowie jemand, dem Design und Barrierefreiheit ernsthaft am Herzen liegen.
    Was ich an diesem Artikel besonders loben möchte, ist APCA, das wahrscheinlich den Farbkontrastalgorithmus von WCAG 2 ablösen wird.
    Auch bei der internen Barrierefreiheitsüberarbeitung von Figma haben wir APCA verwendet, und dadurch wurde das Endergebnis deutlich besser.
    Eugene zeigt sehr gut Fälle, in denen WCAG 2 scheitert, und genau solchen Fällen sind wir in der Praxis immer wieder begegnet.
    Der zentrale Rat lautet: Farben richtig abzustimmen ist wirklich schwer.
    Tools helfen, aber irgendwann muss man seinen Augen vertrauen.
    Letztlich sind solche Tools nur mathematische Annäherungen daran, wie das Auge Farbe wahrnimmt; der endgültige Maßstab ist nicht der Algorithmus, sondern das menschliche Auge.
    An den Stellen, an denen Tools oder Algorithmen unpassende Ergebnisse liefern, sollte man besser nachjustieren oder zu den Grundlagen zurückkehren.

    • Ich würde gern genauer verstehen, was damit gemeint ist, dass ihr bei Figmas interner Barrierefreiheitsüberarbeitung APCA verwendet habt.
      Heißt das, dass ihr nur APCA genutzt und Inhalte ignoriert habt, die der WCAG-2-Farbkontrastalgorithmus als kontrastarm markiert?
    • Ich habe eine Rot-Grün-Sehschwäche, und die grundlegende Barrierefreiheit von Figma ist so gut, dass ich nie über gesonderte Barrierefreiheitsanpassungen nachgedacht habe.
      Gut gemacht.

  • Ich möchte auch HCT vorstellen
    Ein Farbraum, der entwickelt wurde, um Material You zu ermöglichen; er kombiniert den hier erwähnten Helligkeitsmesswert mit einem modernen farbwissenschaftlichen Farbraum
    LAB/LCH stammt aus dem Jahr 1976
    Er macht Design intuitiver: Man muss nur wissen, dass eine T-Differenz von 40 die WCAG-Kriterien für Buttons erfüllt und 50 die Kriterien für Text

    • Interessant
      Ich frage mich, wie HCT im Vergleich zu https://www.hsluv.org/comparison/ abschneidet
      Ähnlich wie bei HCT wird es hier durch die L-Differenz einfacher, kontrastierende Farben auszuwählen
      Im selben Zusammenhang würden mich auch Gedanken zu https://www.myndex.com/APCA/ und zum Vorgehen interessieren, wenn dies zum Standard wird
      Da der Kontrastwert zwischen zwei Farben davon abhängt, welche Farbe Vordergrund und welche Hintergrund ist, scheint es inzwischen nicht mehr auszureichen, nur die T-Differenz zu vergleichen
    • Ich frage mich, ob es gute Materialien gibt, um HCT zu lernen
      Angenommen, eine Anwendung braucht zum Beispiel Rot, Gelb, Blau, Orange, Grün und Violett, also 6 Farben, die den 3 Primärfarben und 3 Komplementärfarben entsprechen
      Welche Farben genau das sind, ist nicht so wichtig; aber wenn man möchte, dass diese 6 einigermaßen unterscheidbar sind und zugleich in der Helligkeit, vielleicht sogar in der Sättigung, ähnlich abgestimmt sind: Wie sollte man vorgehen?
      Gelb ist sehr hell und Blau sehr dunkel, daher gibt es wohl keine exakte Antwort, sondern man muss sich einer Näherung annähern
      Ich frage mich, ob es Tools oder Tutorials gibt, mit denen man so etwas lernen kann
    • Ich frage mich, ob es irgendwo eine öffentliche Spezifikation gibt
      Gefunden habe ich nur den Code von material-color-utilities auf GitHub
      Beim Blick in den Code wirken die Berechnungen deutlich komplexer als bei OkLab, insbesondere die Richtung von HCT nach RGB

  • Nicht nur, dass der Artikel oklab/oklch auslässt; auch die Behauptung, Web/CSS unterstütze nur sRGB, ist falsch
    Die CSS-Funktion color() unterstützt mehrere Farbräume

    • Ich bin der Autor
      Der Artikel wurde vor 2 Jahren veröffentlicht, und als ich mit der Arbeit am Tool begann, war die OkLCH-Spezifikation noch gar nicht erschienen
      Heute würde ich statt LCH OkLCH wählen, weil es einige Probleme von LCH behebt
    • CSS Color Module Level 4 befindet sich noch im Stadium eines Empfehlungsentwurfs
      „Unterstützt“ heißt hier genauer gesagt eher „unterstützt, außer in Microsoft Edge (Chromium) und Pale Moon (Goanna)“
      https://test.csswg.org/harness/results/css-color-4_dev/group...
    • Ich habe oklab und mehrere Farbräume aus der LAB-Familie direkt verwendet; Oklab eignet sich hervorragend, um es mit einfachen Berechnungen zuzuschneiden
    • Es gibt auch ein Farbmodell, das auf Oklch aufgebaut ist
      Allerdings verwendet es statt Helligkeit das Kontrastverhältnis von APCA, also WCAG 3: https://github.com/antiflasher/apcach

  • oklab könnte eine bessere Alternative zu LCh sein
    https://bottosson.github.io/posts/oklab/

    • Es weicht ziemlich weit von den ursprünglichen Annahmen ab
      Der Helligkeitskanal ist im Vergleich zu allen anderen Farbräumen invertiert, und L hat nichts mit dem L in LCH oder LAB zu tun
      Sein Erfolg hat in gewisser Weise sogar zu mehr intellektueller Verarmung geführt
      Im ursprünglichen Blogbeitrag gibt es sehr vieles, das korrigiert werden müsste, und die Argumentation gerät ab dem Punkt stark aus der Spur, an dem mit Gradienten unter Verwendung von CAM16 UCS Genauigkeit behauptet wird
    • Dieses Playground visualisiert 16 Farbräume, darunter LCh und OKLAB, erstaunlich gut: https://color-playground.ardov.me/spaces-3d
    • Es ist nicht perfekt, aber ich habe in einigen Situationen oklab und oklch für Farbinpolation verwendet, und die Ergebnisse waren visuell deutlich zufriedenstellender als Interpolation in RGB oder HSL
    • Ich nutze OkLab auf meiner Website zufriedenstellend; es ist für die Augen deutlich angenehmer als die Farbpalette, die ich zuvor mit CIELAB verwendet hatte

  • Wenn CIELAB-Werte auf Wahrnehmungsänderungen basieren, frage ich mich, wie das mit Barrierefreiheit zusammenspielt
    Muss man sich Sorgen machen, dass solche Wahrnehmungsformeln vermutlich anhand normalen Sehvermögens erstellt wurden?
    Ich frage mich auch, ob es je nach Art der Farbsehschwäche variieren kann, oder ob das gar nicht das Problem ist
    Ich versuche, Diagramme so barrierefrei wie möglich zu machen, habe aber über Farbe nie wirklich etwas gelernt; ich befolge nur Ratschläge und kann sie nicht selbst herleiten
    Es kann also gut sein, dass das eine dumme Frage ist

    • Ich habe in diesem Bereich gearbeitet
      Kontrast verändert sich nichtlinear
      Simulationen lassen sich ziemlich leicht anwenden, und die Simulation von Machado et al. ist nur eine Matrixtransformation

  • Der Artikel platziert die Erklärung weiter unten, aber APCA Contrast, der gut lesbare Kontrasttest im Entwurf des WCAG-3-Standards, ist für manche Farben deutlich fairer als das Kontrastverhältnis aus WCAG 2.1
    Ein gut lesbarer Artikel zur Farbtheorie hinter wahrgenommenem Kontrast: https://www.smashingmagazine.com/2022/09/realities-myths-con...
    Eine knappe Erklärung von APCA: https://typefully.com/u/DanHollick/t/sle13GMW2Brp

    • APCA funktioniert gut, aber die Lizenz ist sehr seltsam und restriktiv
      Bevor man es für irgendetwas verwendet, sollte man sich diesen Punkt genau ansehen und entscheiden, ob man es wirklich nutzen kann

  • Wo ist der Code?
    Ich brauche einen Algorithmus, der nicht nur in einem Webformular, sondern in jeder Art von Software verwendbar ist.