DEV Community: Ceci Olivera

An MCP for the most common failure of the Web

Ceci Olivera — Mon, 29 Jun 2026 06:00:00 +0000

There's a deterministic algorithm at the center of this story and a probabilistic model at the edge of it, and most of what I learned lives in the space between them.

Here's the short version: a designer friend of mine, Marta Herrera Hollingsworth, built, years ago, an algorithm that generates monochromatic color palettes whose contrast relationships are guaranteed mathematically. I turned that algorithm into a library, and then wrapped the library in an MCP (Model Context Protocol) server so that any AI agent building a UI could call it and get colors that can't fail WCAG 2.2 contrast. This is the story of that library, why it exists, the surprisingly stubborn problem of getting models to actually use its output as written, and where it all landed: a better place than where it started, though not the place I expected at the outset.

Why color, of all things

WebAIM scans the homepages of the top million most-visited sites in the world every year, and for seven years straight, low-contrast text has been the single most common accessibility failure they can detect. The February 2026 report found it on 83.9% of homepages, up from 79.1% the year before, averaging 34 separate instances per page. This isn't an edge case. It's the default condition of the web.

And the web is increasingly being written by agents. Microsoft's A11y LLM Eval harness (built by Michael Fairchild and collaborators) measures how accessible model-generated code actually is, and the baseline is bleak: with no accessibility guidance, eight frontier models passed the harness's automated checks only about 12% of the time, with contrast errors featuring heavily. The hopeful part of that same report is that guidance works: a short "please be accessible" instruction lifted pass rates by roughly 24 points, and a structured skill that made the model review its own output did even better, resolving on average 86% of the issues automated tools can measure — with color contrast still the single most persistent problem, even then.

So: a perfect place to put a tool.

What MCP is, and why I used it here

Before getting into the library, it's worth explaining the scaffolding, because the choice of protocol matters.

MCP (Model Context Protocol) exposes three distinct primitives a model can draw on during generation:

Tools: functions that execute logic (calculations, validations) and return structured data.
Resources: data the model reads as a persistent, URI-addressable source of truth, rather than the one-off result of a single call.
Prompts: reusable instruction flows that the server itself exposes, instead of leaving every integration to reinvent them.

A REST API with function calling also gives you tools — that part isn't new. What it doesn't give you, without extra convention, is a standard way to expose a URI-readable source of truth, or a forced sequence of steps that any MCP client understands the same way. That's why I chose MCP: because palette://{hex}/{theme} is a resource the agent can return to at any point during generation, and because I thought a prompt could be the flow that forced the right order of steps. I was wrong about that second part, and I'll come back to it later.

What the library actually does

The library

Give it one seed color and a theme — whether it'll sit on white or black — and it produces a small monochromatic scale, six shades across a 100–900 range, where every contrast relationship has been computed. But the colors are the easy part. The valuable part is what the library ships alongside them: a compatibility matrix. For each shade, it tells you exactly which other shades (plus pure white and black) are safe to use as text on top of it at WCAG 2.2 AA, and which pairings hold only for large text.

Over MCP it offers several ways in:

generate_palette: returns the palette and its full compatibility matrix as structured data.
validate_pairings: takes a list of intended foreground/background pairs and grades each one against that matrix before any CSS gets written, answering with a blunt proceed: true or proceed: false.
generate_css_tokens: returns a ready-to-paste :root {} block. It has an entry condition I'll get to later, because it changes something important about what follows.
check_contrast: a free-form contrast check between any two hex values, independent of a generated palette. The base scale is monochromatic by design — one hue, varying only in lightness — and that's exactly what makes it mathematically predictable. But almost no real interface lives on that alone: an error state, a sale badge, a brand accent all need a color the monochromatic scale doesn't have. check_contrast exists so that decision also runs through arithmetic instead of the model's eye. I'll come back to a problem this doesn't fully solve.
A resource, palette://{hex}/{theme}, that lets an agent pull the whole matrix by URI before making a single color decision.

This is exactly the kind of problem you want to hand off to a tool instead of a model, and the reason is precise: contrast is arithmetic. Working out the luminance ratio between two hex values is a calculation, and calculations are the kind of work you should keep out of a system that predicts text. The whole idea is to take that math out of the model's probabilistic "head" and put it into a tool that returns a deterministic answer.

That was the bet. Expose the library over MCP, and contrast failures should become close to impossible.

The diagnosis: why the model ignores the rules

They didn't become impossible — though the model never ignored the palette. It called the tool, received the output with every color and every rule intact, and did something more persistent: it rewrote the CSS from scratch, in its own conventions, its own variable names, its own structure. And, crucially, without the compatibility rules — the entire point of the tool — which got lost somewhere between reading the output and writing the page.

This wasn't constant or catastrophic. The failures were a minority, but persistent, and they always had the same shape: the safe-pairing information, the whole reason the tool exists, evaporated on the trip from the tool's output to the final stylesheet.

Why does this happen? It isn't an instruction-following failure. It's something simpler and harder to fight: a model trained on an enormous amount of CSS has a very strong sense of what well-written CSS looks like, and when it receives a piece of CSS-shaped data, it doesn't copy it — it regenerates it in that learned shape. The accessibility annotations were never part of that learned shape and were just comments above the :root {} block, so they don't survive the regeneration.
Generally, the System Prompt carries more hierarchical weight because it defines the model's "character" and global operating rules. However, even a very strong prompt can lose out to exposure bias (the examples the model itself has just generated) or to the training bias mentioned earlier.

The pattern is recognizable: the model reliably keeps the parts of the output it can't reconstruct from memory (a specific hex value) and rewrites the parts it can — the structure, the variable names, the comment formatting. There's no disobedience in that. It's the path of least resistance for a system that generates text token by token, and the path of least resistance is always the CSS it's already seen millions of times. No amount of "IMPORTANT: do not rewrite this" reliably beats that, because the instruction is just text, competing against the model's entire sense of the medium.

This reframes the problem: if the instruction loses almost every time against the training prior, the only lever left isn't asking the model to behave differently. It's changing the format of what it receives, so the correct option is cheaper to copy than to rewrite.

Three ways to investigate this without being an AI researcher

One part of the process I don't want to hide: I'm not an AI researcher, and I don't understand a transformer's internal mechanics at the level of the research papers. But that doesn't stop me from reasoning well about how one behaves, and I did it by drawing on three different sources, each with a blind spot the other two didn't share.

The first was a NotebookLM loaded with a dozen papers on LLMs, used as an oracle to ask plain-language questions: why does a model ignore explicit instructions but copy certain formats, what makes a piece of text easier to regenerate than to copy. From there came the hypothesis I eventually tested: that the difference between a block comment and an inline one isn't cosmetic — it changes how hard it is for the model to separate the data from the structure around it.
That same back-and-forth with the oracle also produced something more structural: a priority hierarchy that explains why compliance with logical rules can consistently lose against the statistical biases of training. That mental model is what let me turn my failed attempts into the architecture the project rests on today:

Level	Component	Weight / Nature	Model Interaction
1	Training Prior	Highest. The statistical "gravitational pull."	It wins by default. Models prefer to regenerate familiar shapes learned from billions of tokens rather than copying bespoke rules that feel "unnatural" to their training.
2	System Prompt	High (Structural). Defines persona and operational boundaries.	It sets the stage, but it is text-based. It can be overridden by the Prior or forgotten in long context windows ("Lost in the Middle").
3	Tools / MCP	Medium (Logical). External functions for deterministic logic.	The model treats tool output as "more text" to improvise on. The oracle's own framing for beating the Prior here is Read-Plan-Generate — forcing the model to plan and validate before it generates. It works, but only when something actually forces the sequence; left as a suggestion, the model skips straight to generating.
4	Skills	Variable. Learned capabilities (e.g., coding, math).	Are they system prompts? Usually not. Skills are capabilities baked into the weights through SFT/RLHF. You invoke a skill via a prompt, but the skill itself is part of the model's internal repertoire.

The second was the implementing model, in actual working sessions: it proposed concrete formats, and by what it preserved versus what it stripped out when generating code, it revealed which of those formats actually held up under regeneration.

The third was the most direct: asking the models themselves, after they'd generated something, why they'd done what they did. I don't take that source at face value. A model explaining its own behavior is, at best, a plausible reconstruction, not real introspection — but more than once those answers pointed, in their own words, at exactly the spot where the tool was failing. One of them ended up proposing two reasonable architectural fixes. None of the three sources alone would have gotten me here.

First solution: inline comments

Once the diagnosis was clear, the first fix was a matter of format, not instruction.

A block comment at the top of the file is, to the model, separable documentation: it gets removed at no cost, because dropping a whole block doesn't break anything around it. An inline comment, pinned to the end of a declaration, is different: removing it means editing that specific line, one at a time, instead of discarding an entire block in one move. That extra friction is enough that, most of the time, the model doesn't bother.

The winning format was this:

:root {
    --color-100: #faf2f5; /* ✅ text→900·800·700  ⚠️ lg→600 */
    --color-300: #e9bfcc; /* ✅ text→900·800  ⚠️ lg→700 */
    --color-600: #c86f90; /* ✅ text→900  ⚠️ lg→100·800·white */
    --color-700: #bb4268; /* ✅ text→white·100  ⚠️ lg→300·900 */
    --color-800: #67273f; /* ✅ text→white·100·300  ⚠️ lg→600 */
    --color-900: #3b1521; /* ✅ text→white·100·300·600  ⚠️ lg→700 */
}

Each variable carries, soldered on as an inline comment, the exact list of backgrounds it's safe on. The model copies the whole block, :root {} included, because separating the rule from the variable costs more than copying both together.

Putting the comment inline at the end of the variable creates a syntactic bond (contextual binding). To the model, the CSS variable token and the accessibility rule token sit so close together in attention space that pulling them apart would mean swimming against its own training. The comment gets processed as part of the declaration's logical unit.

Getting here took several failed attempts, and each one taught something. An all-caps warning inside a comment ("COPY AS-IS") changed nothing — a comment that orders you to copy it is, to the model, still just a comment from a tool that doesn't really have enforcement capabilities. A plain-text table placed above the CSS got read and ignored just the same, because the model wrote its own CSS regardless. The format that worked wasn't the most human-readable one — it was the one that most closely resembled what the model already wanted to write.

Second attempt: the forced planning flow

Inline comments solve what survives once the model has the CSS in hand. They don't solve whether the model arrived at that CSS having checked the pairs before writing anything. For that I built plan-palette-usage, an MCP prompt that structures the whole sequence into four steps: read the matrix, plan each pair in plain text before writing any CSS, validate that list with validate_pairings, and only generate tokens if the whole validation came back clean.

The idea was to turn a judgment problem, which models handle inconsistently, into a step-execution problem, which they handle better. It worked, when invoked. The problem, which took me a while to see clearly, was in that condition.

The nuance that changed everything: prompts need a human

I assumed the model could trigger plan-palette-usage on its own, the same way it triggers any other tool when it judges that doing so helps. That's false, and not because of some particular client's limitation — it's true by specification.

Of MCP's three primitives, tools are model-controlled: the model decides when to call them. Prompts are user-controlled: they only fire if a person invokes them explicitly. What changes between clients is the shape of that invocation, not who triggers it. In Claude Code, "explicitly" means literally: you need to type the exact command, /mcp:accessible-palette:plan-palette-usage, autocomplete included; asking the model in natural language to "use prompt X" isn't enough. In Cline, it is enough — if I ask it in my own message to run plan-palette-usage, it invokes the prompt without me typing the command. But the invocation still starts from a person requesting it by name or intent, not from the model deciding on its own that it was worth using. The barrier that matters for this story isn't the command's exact format: it's that in no client does the model trigger it by itself, unprompted.

In practice, this means the four-step flow almost never runs. Nobody is going to teach a non-technical person the exact command or the exact phrase needed to trigger a guided prompt when they just ask for a landing page with something like "make me a page about X using the palette mcp." And this library's accessibility guarantee couldn't depend on that.

Third solution: the gate on the server

This is what actually pushed me to change layers: if the model can't invoke the prompt on its own, then the whole guarantee rested on a mechanism that, in real-world use, almost never fires. I needed something that didn't depend on someone typing a command.

validate_pairings always computed contrast deterministically — that was never the weak point. The weak point was that generate_css_tokens, the tool that actually delivers the CSS, knew nothing about what had happened before it. You could skip validation entirely and ask for the tokens anyway, and the server would hand them over without asking. proceed: false was a good-faith convention between the prompt and the model; the server had no memory of whether that convention had been honored.

The fix, in code, was small: the server now keeps a record of which hex-and-theme combinations have already passed validate_pairings successfully, and generate_css_tokens checks that record before generating anything. If the combination hasn't been validated, the tool throws an error and refuses to respond — the same way it fails on an invalid hex, not as a warning the model can choose to read or ignore.

Technically, that record is an in-memory Set, instantiated once when the Node process starts. The transport is StdioServerTransport, so every client that launches the server spins up a fresh process, and "session" means nothing more sophisticated than that process's lifetime. It doesn't persist to disk, has no TTL. It's deliberately the simplest unit that could work, and — crucially — it doesn't depend on anyone writing anything by hand: it lives inside a tool the model was already going to call anyway.

What this changes is where the guarantee lives. Before, it depended on a person knowing how to invoke a prompt, and on the model honoring a text-based convention. Now there's no decision to make: either validation already passed, in this same process, for this hex and this theme, or the tool produces no output.

I'm still being honest about the real limit: this doesn't stop an agent from writing CSS by hand, bypassing the tool entirely, with whatever colors it likes. No MCP server can prevent that; it's outside its reach. What the gate guarantees is narrower, and at the same time sturdier: if the agent uses this tool to get the tokens, there's no way to get them without having validated first.

How it all landed

What holds the system up today is, in essence, a single piece: the server-side gate, backed by the inline comments so that what's been validated doesn't get lost on the way out. The prompt still exists, still invokable by anyone who knows the command, but I'm no longer sure what real advantage it has over the gate. In theory it forces a re-read of the matrix and explicit reasoning before validating; in practice, I have no evidence that changes the final outcome in any way the gate doesn't already achieve on its own. I'm documenting it for what it is: an optional add-on, not the mechanism anything important depends on.

I want to be concrete about what "works" means here, rather than settling for "I've used it and it's gone well." I generated 45 demo pages across several different agents and models, running on Open Code, Claude Code, GitHub Copilot, and Cline, using only minimal natural-language prompts like "build a landing page about X using the palette mcp," never invoking the guided prompt, and combining this with the accessibility skill from github/awesome-copilot (the same one its author, Michael Fairchild, tuned against his own evaluation harness before publishing it). I ran axe-core against all 45: 35 had zero violations of any kind. Of the 10 that did, 7 were specifically color-contrast violations — the exact problem this library exists to solve, still slipping through, but in a small fraction of the total. I'd like to point out that this sample is extremely small. I encourage you to try it yourself, however you consider. Screenshots and full details are in the repository, under /demo.

It doesn't always come out perfect: every so often a failure still slips through. Not in the tokens the server delivers anymore — those are mathematically closed — but in the final component CSS, where the model can still ignore the manifest if it decides to write by hand outside the tool, or in accent colors, where I don't yet have the same kind of guarantee. Language model behavior is probabilistic, and no patch — not even one that lives on the server — is airtight against a formatting prior operating outside the protocol.

I'm not going to put my own benchmark number on this beyond what I've already shared: accessibility is context-dependent, and your model, your prompts, your task mix all move the result. So here's a direct invitation: install the server, try it against your own workflows, run your own axe-core or Lighthouse against what it generates, and tell me what you get. If you find a case where the model jumps the rails, or a format that works better than mine, I want to know — that's the only way to keep refining this.

What I do stand behind, without reservation, is the direction. A handful of occasional misses, now confined to the part of the process the protocol can't reach, lives in a completely different world from "low-contrast text on 84% of pages" or a 12% unguided pass rate. You're not installing a hard constraint on the whole process; you're installing a hard constraint on the arithmetic part, and leaning hard, with text and with structure, on the part that's still probabilistic.

What comes next

Two things remain open, and I'd rather name them with the same honesty as the rest of this piece than give the impression there's nothing left to fix here.

The first is mine: finding an equivalent, for accent colors, of what inline comments achieve for the base palette — so that an accent validated with check_contrast ends up somehow soldered to the CSS, instead of losing that validation on the first edit.

The second is Marta's: she's working on adapting the original algorithm to APCA (Accessible Perceptual Contrast Algorithm), the perceptual contrast method being defined for WCAG 3.0.

The palette algorithm was created by Marta Herrera Hollingsworth; the library and the MCP server are mine. This piece is a practical companion to my earlier essay, "As We May Code: Why Software Is a Human Problem Dressed in Logic."

Motivation data: WebAIM Million 2026 and the A11y LLM Eval report by Michael Fairchild. I'm part of the GitHub Accessibility Advisory Panel; that's where I came across Michael Fairchild's work, which motivated this project.

Un MCP para el fallo más común de la web

Ceci Olivera — Mon, 29 Jun 2026 06:00:00 +0000

Hay un algoritmo determinista en el centro de esta historia y un modelo probabilístico en el borde, y la mayor parte de lo que aprendí vive en el espacio que hay entre ellos.

Versión corta: una amiga diseñadora, Marta Herrera Hollingsworth, construyó, hace años, un algoritmo que genera paletas monocromáticas cuyas relaciones de contraste están garantizadas matemáticamente. Convertí ese algoritmo en una librería, y luego envolví la librería en un servidor MCP (Model Context Protocol) para que cualquier agente de IA que construya una interfaz pueda llamarlo y obtener colores que no pueden fallar el contraste WCAG 2.2. Esta es la historia de esa librería, de por qué existe, del problema sorprendentemente obstinado de lograr que los modelos usen su output tal como está escrito, y de dónde terminó todo: en un lugar mejor que donde empezó, aunque no el lugar que esperaba al principio.

Por qué el color, de entre todas las cosas

WebAIM escanea la home del millón de páginas más visitadas del mundo cada año, y durante siete años consecutivos, el texto de bajo contraste ha sido el fallo de accesibilidad más común que pueden detectar. El informe de febrero de 2026 lo encontró en el 83,9% de las páginas de inicio, frente al 79,1% del año anterior, con una media de 34 instancias separadas por página. Esto no es un caso límite. Es el estado base de la web.

Y la web está siendo escrita cada vez más por agentes. El A11y LLM Eval harness de Microsoft (construido por Michael Fairchild y colaboradores) mide lo accesible que es realmente el código generado por modelos, y la línea de base es sombría: sin orientación sobre accesibilidad, ocho modelos de frontera superaron las comprobaciones automatizadas del harness solo aproximadamente el 12% de las veces, con errores de contraste muy presentes. La parte esperanzadora de ese mismo informe es que la orientación funciona: una breve instrucción de "debe ser accesible" elevó las tasas de aprobación en unos 24 puntos, y una skill estructurada que hacía que el modelo revisara su propia salida funcionó aún mejor, resolviendo de media el 86% de los problemas que las herramientas automáticas pueden medir, siendo el contraste de color el problema que más persiste incluso así.

Este es un lugar perfecto para poner una herramienta.

Qué es MCP y por qué lo usé aquí

Antes de entrar en la librería, vale la pena explicar el andamiaje, porque la elección del protocolo importa.

MCP (Model Context Protocol) expone tres primitivas distintas que un modelo puede consumir durante su generación:

Tools: funciones que ejecutan lógica (cálculos, validaciones) y devuelven datos estructurados.
Resources: datos que el modelo lee como una fuente de verdad persistente, identificable por URI, no como el resultado puntual de una llamada.
Prompts: flujos de instrucción reutilizables que el propio servidor expone, en lugar de dejar que cada integración los reinvente.

Una API REST con function calling también te da tools, eso no es nuevo. Lo que no te da, sin convención adicional, es una forma estándar de exponer una fuente de verdad legible por URI o un flujo de pasos forzado que cualquier cliente MCP entienda igual. Elegí MCP por eso: porque palette://{hex}/{theme} es un recurso al que el agente puede volver en cualquier momento de la generación, y porque pensé que un prompt podía ser el flujo que forzara el orden correcto de pasos. Sobre esa segunda idea me equivoqué, y vuelvo a ello más adelante.

Qué hace la librería

La librería

Dale un color base y un tema (si se va a asentar sobre blanco o negro), y produce una pequeña escala monocromática, seis tonos en un rango 100–900, donde cada relación de contraste ha sido calculada. Pero los colores son la parte fácil. La parte valiosa es lo que la librería entrega junto a ellos: una matriz de compatibilidad. Para cada tono, te dice exactamente qué otros tonos (además de blanco y negro puros) son seguros para usar como texto sobre él en WCAG 2.2 AA, y qué emparejamientos solo son válidos para texto grande.

A través de MCP ofrece varias vías de entrada:

generate_palette: devuelve la paleta y su matriz de compatibilidad completa como datos estructurados.
validate_pairings: toma una lista de pares (primer plano/fondo) y califica cada uno contra esa matriz antes de que se escriba CSS, respondiendo con un contundente proceed: true o proceed: false.
generate_css_tokens: devuelve un bloque :root {} listo para pegar. Tiene una condición de entrada de la que hablo más adelante, porque cambia algo importante de lo que sigue.
check_contrast: un chequeo de contraste libre entre dos hex cualquiera, sin depender de una paleta generada. Esta escala es monocromática por diseño (un solo tono, variando su luminosidad) y eso es justo lo que la hace matemáticamente predecible. Pero casi ninguna interfaz real vive solo de eso: un estado de error, una etiqueta de oferta, un acento de marca, necesitan un color que la escala monocromática no tiene. check_contrast existe para que esa decisión también pase por la aritmética, en vez de por el ojo del modelo. Vuelvo más adelante sobre un problema que esto no resuelve del todo.
Un recurso, palette://{hex}/{theme}, que permite al agente extraer la matriz completa por URI antes de tomar una sola decisión de color.

Esto es exactamente el tipo de problema que conviene resolver con una herramienta en lugar de con el modelo, y la razón es precisa: el contraste es aritmética. Calcular la relación de luminancia entre dos valores hex es un cálculo, y los cálculos son el tipo de trabajo que conviene sacar de un sistema que predice texto. La idea completa es sacar esas matemáticas de la "cabeza" probabilística del modelo y ponerlas en una herramienta que devuelve una respuesta determinista.

Esa fue la apuesta. Exponer la librería sobre MCP, y los fallos de contraste deberían volverse casi imposibles.

El diagnóstico: por qué el modelo ignora las reglas

No se volvieron imposibles, aunque el modelo nunca ignoró la paleta. Llamaba a la herramienta, recibía la salida con cada color y cada regla intacta, y hacía algo más persistente: reescribía el CSS desde cero, con sus propias convenciones, sus propios nombres de variable, su propia estructura. Y, de forma crucial, sin las reglas de compatibilidad (el objetivo completo de la herramienta) que se perdían en algún punto entre leer el output y escribir la página.

Esto no era constante ni catastrófico. Los fallos eran minoría, pero persistentes, y siempre tenían la misma forma: la información de emparejamiento seguro, la razón de ser de la herramienta, se evaporaba en el viaje desde la salida de la herramienta hasta la hoja de estilos final.

¿Por qué pasa esto? No es un fallo de seguimiento de instrucciones. Es algo más simple y más difícil de combatir: un modelo entrenado con una cantidad enorme de CSS tiene un sentido muy fuerte de cómo se ve el CSS bien escrito, y cuando recibe un dato con forma de CSS, no lo copia, lo regenera con esa forma aprendida. Las anotaciones de accesibilidad nunca formaron parte de esa forma aprendida, así que no sobreviven a la regeneración.
Generalmente, el System Prompt tiene un peso jerárquico mayor porque define el "personaje" y las reglas operativas globales del modelo. Sin embargo, incluso un prompt muy fuerte podría perder contra el sesgo de exposición (los ejemplos que el propio modelo acaba de generar) o el sesgo de entrenamiento mencionado anteriormente.

El patrón es reconocible: el modelo conserva con fiabilidad las partes de la salida que no puede reconstruir de memoria (un hex concreto) y reescribe las partes que sí puede: la estructura, los nombres de las variables, el formato del comentario. No hay desobediencia en eso. Es la ruta de menor resistencia para un sistema que genera texto token a token, y la ruta de menor resistencia es siempre el CSS que ya ha visto millones de veces. Y ninguna cantidad de "IMPORTANTE: no reescribas esto" la vence de forma fiable, porque la instrucción es solo texto, y compite contra el sentido completo que el modelo tiene del medio.

Esto reordena el problema: si la instrucción pierde casi siempre contra el prior de entrenamiento, la única palanca que queda no es pedirle al modelo que se comporte de otra manera. Es cambiar el formato de lo que recibe, para que la opción correcta sea más barata de copiar que de reescribir.

Tres formas de investigar esto sin ser investigadora de IA

Una parte del proceso que no quiero ocultar: no soy investigadora de IA, y no entiendo los mecanismos internos de un transformador al nivel de los papers científicos. Pero eso no impide razonar bien sobre cómo se comporta uno, y lo hice apoyándome en tres fuentes distintas, cada una con un punto ciego que las otras dos no tenían.

La primera fue un NotebookLM cargado con una docena de papers sobre LLMs, usado como un oráculo al que hacerle preguntas en lenguaje natural: por qué un modelo ignora instrucciones explícitas pero copia ciertos formatos, qué hace que un fragmento de texto sea más fácil de regenerar que de copiar. De ahí salió la hipótesis que finalmente probé: que la diferencia entre un comentario de bloque y uno en línea no es cosmética, sino que cambia cuánto le cuesta al modelo separar el dato de la estructura que lo rodea.
Ese mismo ir y venir con el oráculo también produjo algo más estructural: una jerarquía de prioridades que explica por qué el cumplimiento de reglas lógicas puede perder de forma consistente contra los sesgos estadísticos del entrenamiento. Ese modelo mental es lo que me permitió convertir mis intentos fallidos en la arquitectura sobre la que descansa el proyecto hoy:

Nivel	Componente	Peso / Naturaleza	Interacción con el Modelo
1	Prior de Entrenamiento	El más alto. El "tirón gravitacional" estadístico.	Gana por defecto. Los modelos prefieren regenerar formas familiares aprendidas de miles de millones de tokens antes que copiar reglas a medida que se sienten "antinaturales" frente a su entrenamiento.
2	System Prompt	Alto (Estructural). Define la persona y los límites operativos.	Marca el escenario, pero es texto. Puede ser anulado por el Prior u olvidado en ventanas de contexto largas ("Lost in the Middle").
3	Tools / MCP	Medio (Lógico). Funciones externas para lógica determinista.	El modelo trata la salida de la herramienta como "más texto" sobre el que improvisar. El propio marco del oráculo para vencer al Prior aquí es Read-Plan-Generate. Forzar al modelo a planear y validar antes de generar. Funciona, pero solo cuando algo realmente impone la secuencia; dejado como sugerencia, el modelo salta directo a generar.
4	Skills	Variable. Capacidades aprendidas (por ejemplo, código, matemáticas).	¿Son system prompts? Por lo general no. Las skills son capacidades incorporadas en los pesos mediante SFT/RLHF. Invocas una skill a través de un prompt, pero la skill en sí forma parte del repertorio interno del modelo.

La segunda fue el modelo implementador, en sesiones de trabajo reales: proponía formatos concretos y, por lo que preservaba frente a lo que eliminaba al generar código, revelaba cuáles de esos formatos resistían de verdad la regeneración.

La tercera fue la más directa: preguntarles a los propios agentes, después de que generasen algo, por qué habían hecho lo que hicieron. No doy por buena esa fuente sin matizarla. Un modelo explicando su propio comportamiento es, en el mejor de los casos, una reconstrucción plausible, no introspección real; pero más de una vez esas respuestas señalaron, con sus propias palabras, exactamente el punto donde la herramienta estaba fallando. Una de ellas terminó proponiendo dos arreglos arquitectónicos razonables. Ninguna de las tres fuentes por sí sola habría llegado hasta aquí.

Primera solución: comentarios en línea

Una vez que el diagnóstico estaba claro, la primera solución fue una cuestión de formato, no de instrucción.

Un comentario de bloque al principio del archivo es, para el modelo, documentación separable: se elimina sin coste, porque quitar un bloque entero no rompe nada alrededor. Un comentario en línea, pegado al final de una declaración, es distinto: para eliminarlo, el modelo tiene que editar esa línea concreta, una por una, en lugar de descartar un bloque completo de una vez. Esa fricción adicional es suficiente para que, la mayoría de las veces, no se moleste en hacerlo.

El formato ganador fue este:

:root {
    --color-100: #faf2f5; /* ✅ text→900·800·700  ⚠️ lg→600 */
    --color-300: #e9bfcc; /* ✅ text→900·800  ⚠️ lg→700 */
    --color-600: #c86f90; /* ✅ text→900  ⚠️ lg→100·800·white */
    --color-700: #bb4268; /* ✅ text→white·100  ⚠️ lg→300·900 */
    --color-800: #67273f; /* ✅ text→white·100·300  ⚠️ lg→600 */
    --color-900: #3b1521; /* ✅ text→white·100·300·600  ⚠️ lg→700 */
}

Cada variable lleva soldada, como comentario en línea, la lista exacta de fondos sobre los que es segura. El modelo copia el bloque entero, :root {} incluido, porque separar la regla de la variable cuesta más que copiar las dos juntas.
Al poner el comentario inline al final de la variable, se está creando un vínculo sintáctico (Contextual Binding). Para el modelo, el token de la variable CSS y el token de la regla de accesibilidad están tan cerca en el espacio de atención que separarlos requeriría "nadar contra corriente" de su entrenamiento previo. El comentario se procesa como parte de la unidad lógica de la declaración.

Llegar aquí costó varios intentos fallidos, y cada uno enseñó algo. Un aviso en mayúsculas dentro de un comentario ("COPIAR TAL CUAL") no cambió nada: un comentario que ordena copiarse sigue siendo, para el modelo, un comentario de una herramienta que no tiene capacidad real de forzar al modelo. Una tabla en texto plano antes del CSS se leía y se ignoraba igual, porque el modelo escribía su propio CSS de todas formas. El formato que funcionó no fue el más legible para un humano: fue el que más se parecía a lo que el modelo ya quería escribir.

Segunda intento: el flujo de planificación forzada

Los comentarios en línea resuelven qué sobrevive una vez que el modelo tiene el CSS en la mano. No resuelven si el modelo llegó a esa CSS habiendo comprobado los pares antes de escribir nada. Para eso construí plan-palette-usage, un prompt de MCP que estructura la secuencia completa en cuatro pasos: leer la matriz, planificar en texto plano cada par antes de escribir CSS, validar esa lista con validate_pairings, y solo generar los tokens si la validación entera vino limpia.

La idea era convertir un problema de criterio, que los modelos manejan de forma inconsistente, en un problema de ejecución de pasos, que manejan mejor. Funcionaba, cuando se invocaba. El problema, que tardé en ver con claridad, estaba en esa condición.

El matiz que cambió todo: los prompts necesitan un humano

Asumí que el modelo podía activar plan-palette-usage por su cuenta, igual que activa cualquier otra herramienta cuando le conviene. Eso es falso, y no por una limitación de tal o cual cliente: es así por especificación.

De las tres primitivas de MCP, los tools son model-controlled: el modelo decide cuándo llamarlos. Los prompts son user-controlled: solo se disparan si una persona los invoca explícitamente. Lo que cambia entre clientes es la forma de esa invocación, no quién la dispara. En Claude Code, "explícitamente" significa literal: hace falta escribir el comando exacto, /mcp:accessible-palette:plan-palette-usage, autocompletado incluido; pedirle al modelo en una instrucción en lenguaje natural que "use el prompt X" no alcanza. En Cline sí alcanza. Si en mi propio mensaje le pido que ejecute plan-palette-usage, lo invoca sin que yo escriba el comando; pero la invocación sigue partiendo de que una persona lo pidió por su nombre o su intención, no de que el modelo decidiera por su cuenta que convenía usarlo. La barrera que importa para esta historia no es el formato del comando: es que en ningún cliente el modelo lo activa solo, sin que nadie se lo haya pedido.

En la práctica, esto significa que el flujo de cuatro pasos casi nunca se ejecuta. Nadie le va a enseñar a alguien sin perfil técnico ni el comando exacto ni la frase necesaria para disparar un prompt guiado al pedir una landing page con un "haz una página sobre X usando el palette mcp". Y la garantía de accesibilidad de esta librería no podía depender de eso.

Tercera solución: el gate en el servidor

Esto fue lo que realmente me hizo cambiar de capa: si el modelo no puede invocar el prompt por sí mismo, entonces toda la garantía descansaba en un mecanismo que, en el uso real, casi nunca se activa. Necesitaba algo que no dependiera de que nadie escribiera un comando.

validate_pairings siempre calculó el contraste de forma determinista; eso nunca fue el punto débil. El punto débil era que generate_css_tokens, el tool que entrega el CSS de verdad, no sabía nada de lo que había pasado antes. Se podía saltar la validación entera y pedir los tokens igual, y el servidor los entregaba sin preguntar. proceed: false era una convención de buena fe entre el prompt y el modelo; el servidor no tenía memoria de si esa convención se había respetado.

La corrección, en código, fue pequeña: el servidor ahora lleva un registro de qué combinaciones de hex y tema ya pasaron validate_pairings con éxito, y generate_css_tokens consulta ese registro antes de generar nada. Si la combinación no está validada, el tool lanza un error y se niega a responder, de la misma forma en que falla si le pasas un hex inválido, no como un aviso que el modelo puede leer o no.

Técnicamente, ese registro es un Set en memoria, instanciado una sola vez cuando arranca el proceso de Node. El transporte es StdioServerTransport, así que cada cliente que lanza el servidor hace nacer un proceso nuevo, y "sesión" no significa nada más sofisticado que eso: el tiempo de vida de ese proceso. No persiste en disco, no tiene TTL. Es deliberadamente la unidad más simple que podía funcionar, y crucialmente, no depende de que nadie escriba nada a mano: vive en un tool que el modelo ya iba a llamar de todas formas.

Lo que esto cambia es dónde vive la garantía. Antes dependía de que una persona supiera invocar un prompt, y de que el modelo respetara una convención de texto. Ahora no hay decisión posible: o la validación pasó antes, en este mismo proceso, para ese hex y ese tema, o el tool no produce salida.

Sigo siendo honesta sobre el límite real: esto no impide que un agente escriba CSS a mano, ignorando la herramienta por completo, con los colores que le parezcan. Ningún servidor MCP puede impedir eso; vive fuera de su alcance. Lo que el gate garantiza es más estrecho y, a la vez, más sólido: si el agente usa esta herramienta para obtener los tokens, no hay forma de que los obtenga sin haber validado antes.

Cómo terminó todo

Lo que sostiene el sistema hoy es, en esencia, una sola pieza: el gate del servidor, apoyado en los comentarios en línea para que lo validado no se pierda al copiarlo. El prompt sigue existiendo, sigue siendo invocable por quien conozca el comando, pero no tengo claro qué ventaja real le queda sobre el gate. En teoría fuerza una relectura de la matriz y un razonamiento explícito antes de validar; en la práctica, no tengo evidencia de que eso cambie el resultado final de un modo que el gate, por sí solo, no consiga ya. Lo dejo documentado como lo que es: un añadido opcional, no el mecanismo del que depende nada importante.

Quiero ser concreta sobre qué significa "funciona", en vez de quedarme en "lo he usado y ha ido bien". Generé 45 páginas de demostración con varios agentes y modelos distintos corriendo sobre los agentes Open Code, Claude Code, Github Copilot y Cline, usando solo prompts mínimos en lenguaje natural, del tipo "haz una landing sobre X usando el palette mcp", sin invocar nunca el prompt guiado, y combinando esto con la skill de accesibilidad de github/awesome-copilot (la misma que su autor, Michael Fairchild, afinó contra su propio harness de evaluación antes de publicarla). Le pasé axe-core a las 45: 35 no tuvieron ninguna violación de ningún tipo. De las 10 que sí, 8 fueron específicamente de contraste de color; el problema exacto que esta librería existe para resolver, todavía colándose, pero en una fracción pequeña del total. Quiero señalar que la muestra es extremadamente pequeña para obtener ninguna estadística. Les animo a ponerlo a prueba. Las capturas y el detalle completo están en el repositorio, en /demo.

No siempre sale perfecto: de vez en cuando se cuela un fallo. Ya no en los tokens que el servidor entrega, que están cerrados matemáticamente, sino en el CSS de componente final, donde el modelo todavía puede ignorar el manifiesto si decide escribir a mano por fuera de la herramienta, o en los colores de acento, donde no tengo todavía el mismo tipo de garantía. El comportamiento de los modelos de lenguaje es probabilístico, y ningún parche (ni siquiera uno que vive en el servidor) es hermético contra un prior de formato que actúa por fuera del protocolo.

No voy a poner un número de benchmark propio encima de esto más allá de lo que ya he compartido: la accesibilidad depende del contexto, tu modelo, tus prompts, tu mezcla de tareas mueven el resultado. Así que te invito directamente: instala el servidor, pruébalo contra tus propios flujos de trabajo, corre tu propio axe-core o Lighthouse contra lo que te genere, y cuéntame qué te da. Si encuentras un caso donde el modelo se sale del carril, o un formato que funciona mejor que el mío, quiero saberlo, es la única forma de seguir afinando esto.

Lo que sí defiendo sin reservas es la dirección. Un puñado de fallos ocasionales, ahora acotados a la parte del proceso que el protocolo no puede tocar, vive en un mundo distinto al de "texto de bajo contraste en el 84% de las páginas" o a una tasa de aprobación no guiada del 12%. No estás instalando una restricción dura sobre todo el proceso; estás instalando una restricción dura sobre la parte aritmética, e inclinando con fuerza, con texto y con estructura, la parte que sigue siendo probabilística.

Qué viene después

Quedan dos cosas abiertas, y prefiero nombrarlas con la misma honestidad que el resto del artículo en vez de dar la sensación de que aquí ya no hay nada que arreglar.

La primera es mía: encontrar para los colores de acento algo equivalente a lo que los comentarios en línea logran para la paleta base, de forma que un acento validado con check_contrast quede de algún modo soldado al CSS, en vez de perder esa validación en la primera edición.

La segunda es de Marta: está trabajando en adaptar el algoritmo original a APCA (Accessible Perceptual Contrast Algorithm), el método de contraste perceptual que se está definiendo para WCAG 3.0.

El algoritmo de la paleta fue creado por Marta Herrera Hollingsworth; la librería y el servidor MCP son míos. Esta pieza es un acompañamiento práctico de mi ensayo anterior, "As We May Code: Why Software Is a Human Problem Dressed in Logic".

Datos de motivación: WebAIM Million 2026 y el informe A11y LLM Eval de Michael Fairchild.
Formo parte del GitHub Accessibility Advisory Panel; fue ahí donde conocí el trabajo de Michael Fairchild que motiva este proyecto.

As We May Code: Why Software Is a Human Problem Dressed in Logic

Ceci Olivera — Thu, 16 Apr 2026 21:29:21 +0000

On interfaces, accessibility, wicked problems, and the illusion that machines can write code for us.

The first time I used NotebookLM, I fed it an essay I'd been meaning to read for months: Vannevar Bush's "As We May Think," published in The Atlantic in 1945. I knew it was the essay that predicted the internet. What I didn't know was that it was about something much more fundamental.

Bush's central concern was that humanity generates knowledge faster than any individual can absorb it — that the collective output of science, culture, and experience had outgrown the tools we had for navigating it. He proposed a machine called the Memex to help: not a machine that thinks for us, but one that helps us think. A tool for making associative trails through the ever-expanding record of human knowledge, mirroring the way thought actually moves — by meaning, by context, not by alphabetical index.

The synchronicity wasn't lost on me. I was using an AI tool to navigate a piece of that very record, to absorb an essay I hadn't found the time to read. And the tool worked. It helped me absorb the essay faster, make connections, follow the thread. It was doing, in a small way, what Bush imagined eighty years ago: amplifying my thought, not replacing it.

But here's what stayed with me. Bush wasn't just predicting a technology. He was drawing a line. On one side: technology that extends what humans can do. On the other: technology that substitutes for what humans do. He was firmly, explicitly, on the side of amplification.

That line matters now more than ever. Because there is a quiet assumption that most people hold about software: that it is, fundamentally, a problem of logic. You define what you want, you write the rules, the machine executes them. Input, process, output. Deterministic. Clean.

This assumption is wrong. And it is the root of a much larger misunderstanding — one that shapes how we think about AI-generated code, about the role of developers, and about what it actually means to build something that people use.

I. The deterministic illusion

Software runs on deterministic machines. Given the same input, a CPU will produce the same output, every single time. This is a fact about execution, and it is what makes computers useful.

But somewhere along the way, we confused the nature of running software with the nature of creating it. Because the machine is deterministic, we assumed that building software must also be a deterministic process: define the requirements, translate them into code, compile, ship. A pipeline. A factory.

Fred Brooks dismantled this illusion in 1986. In "No Silver Bullet," he distinguished between two kinds of complexity. Accidental complexity is what we create ourselves — the friction of our tools, the limitations of our languages, the overhead of our processes. This is the complexity that better tools can eliminate. Essential complexity is something else entirely. It comes from the problem itself: from what the software needs to do, for whom, in what context, under what constraints. No tool can remove it, because it is not an artifact of the process — it is the substance of it.

Brooks's claim was radical and, forty years later, still widely misunderstood: the hard part of software is not writing code. The hard part is deciding what to build. And that decision is irreducibly human.

In 1992, Jack Reeves took this further with an essay that should be required reading for anyone who writes code. In "What Is Software Design?", he argued that source code is not the construction of software — it is the design. Compiling is construction: it's cheap, it's automatic, you press a button. But the act of writing code? That is a design activity. It is creative, contextual, full of trade-offs and judgment calls. It is, in the deepest sense, a human endeavor.

If code is design, then the developer is not a technician executing a blueprint. The developer is a designer making decisions that directly shape how people experience a product. Every line of code carries assumptions about who will use it, how, and why.

II. Interfaces are wicked problems

In 1973, Horst Rittel and Melvin Webber published a paper that gave vocabulary to something designers and planners had always felt but could never quite name. They called it "wicked problems" — not wicked in the moral sense, but in the sense of being deeply resistant to the kind of linear, analytical problem-solving that works so well in engineering and mathematics.

Wicked problems have no definitive formulation. They have no stopping rule — no signal that tells you the problem is solved. Their solutions are not true or false, only better or worse. Every attempt at a solution changes the problem itself. And they are essentially unique: what works in one context may fail in another.

User interfaces are wicked problems. Not metaphorically — structurally. Consider:

There is no single correct interface for any given task. The "right" design depends on the user, their device, their abilities, their context, their mental model, their culture, their patience, their internet connection.
Interfaces are never finished. Every new feature, every new user, every new device introduces new interactions, new edge cases, new failures.
You cannot test your way to a perfect interface. You can only test your way to a less wrong one, because the space of human variability is infinite.
Every design decision carries consequences that ripple outward. A color choice excludes people with low vision. A navigation pattern confuses people using screen readers. A gesture-based interaction locks out people with motor disabilities. A modal dialog that "works" for sighted users traps keyboard users in an invisible cage — or, conversely, lets their focus escape into a background that is supposed to be inert.

Richard Buchanan connected wicked problems to design thinking in 1992, arguing that what many people dismiss as "impossible" may actually be a failure of imagination — one that better design thinking can overcome. Don Norman, through decades of work from The Design of Everyday Things to Living with Complexity, showed that the complexity of our tools must match the complexity of our lives. Simplifying an interface beyond a certain point doesn't make it better — it makes it dishonest about the problem it's trying to solve.

The temptation, always, is to treat interfaces as tame problems. Define the requirements. Implement the spec. Check the boxes. Ship. But the users were never part of the spec, not really — not in all their unpredictable, embodied, diverse humanity.

III. HTML: the most human language in code

Here is something people rarely say about HTML: it is beautiful.

Not in the way that an elegant algorithm is beautiful, or a well-factored function. HTML is beautiful because it is a language of meaning. It is a declarative API — arguably the most successful one ever created — whose purpose is not to instruct a machine but to communicate intent.

When you write <nav>, you are not telling the browser to render a box. You are saying: this is navigation. When you write <button>, you are not just creating a clickable element — you are declaring that this element is interactive, that it can receive focus, that it responds to keyboard events, that it announces itself to assistive technology as something a person can press. A <button> carries decades of human expectations in six characters.

HTML is not a programming language in the classical sense. It has no conditionals, no loops, no variables. And yet it may be the most consequential language on the web, because it is the layer where machine logic meets human meaning. It is the interface between the accessibility tree and the person. Between the browser and the body.

And it is also, without question, the most widely written and most widely written poorly language on the web. Because it is forgiving. Because a <div> with an onclick looks the same as a <button> — to sighted users, on a good day, with a mouse. The damage is invisible until someone tries to navigate with a keyboard, or a screen reader, or a switch device. And by then, the developer has moved on.

This is the paradox: the language that carries the most human meaning is treated as though it carries the least. Because it "works." Because it renders. Because the tests pass.

IV. What the machines see

In 2024, Michael Fairchild at Microsoft built a tool to answer a simple question: when you ask an LLM to generate HTML for common UI components, how accessible is the result?

The answer, documented in the A11y LLM Eval project, is sobering. Without explicit accessibility instructions, most models score near zero. The average across all tested models is around 10%. Even the best-performing model only passes 41% of tests. And these are not obscure edge cases — they are fundamental patterns like forms, navigation, dialogs, and data tables.

An important caveat: these percentages do not mean "41% accessible according to WCAG." The tool evaluates code against axe-core (an automated accessibility scanner) plus a set of custom assertions per component. But automated tools can only catch a fraction of real accessibility barriers — perhaps 30-40% of WCAG criteria. Everything that requires human judgment — whether the reading order makes sense, whether an alt text is actually meaningful, whether a focus management pattern is appropriate for the context, whether the right ARIA design pattern was chosen — is beyond what any scanner can measure. So when we say "90% pass rate with good instructions," we mean 90% of the automatable tests pass. The full picture still requires a human who understands what accessible means.

Fairchild is explicit about this: these tests do not fully evaluate WCAG or guarantee accessible results. Manual testing remains essential.

With that caveat in mind, the results are still revealing. Why do models perform so poorly by default? Because approximately 95% of websites have accessibility issues. The training data is the web, and the web is broken. LLMs don't learn what HTML should be — they learn what HTML is, statistically. And statistically, it's <div> soup.

But Fairchild's research reveals something even more interesting. When you add explicit accessibility instructions — custom instruction files that tell the model to use semantic HTML, follow WCAG, ensure keyboard support — the automatable pass rates jump dramatically. A minimal instruction ("All output MUST be accessible") alone produced an 18 percentage point improvement. Detailed, expert-level guidance pushed some models from near-zero to over 90%.

Think about what this means. The models can generate code that passes automated checks. The knowledge is somewhere in the weights. But without a human explicitly asking for it — without someone who understands accessibility framing the problem — the model defaults to the statistical average. The inaccessible average. And even at its best, it still cannot evaluate the things that matter most: the human things, the contextual things, the wicked things.

This is not a bug. This is the fundamental nature of what LLMs do: they index. They find the most probable pattern given the input. Vannevar Bush warned us about this in 1945 — that the artificiality of indexing systems would always be a poor substitute for the associative, contextual, meaning-driven way humans actually think. LLMs are the most sophisticated indexing system ever built. They are extraordinary at finding what is common. They are structurally incapable of understanding what is right.

V. The old tension, resurfaced

There is a deeper reason why AI struggles with interfaces and accessibility, beyond training data. Interfaces are fundamentally human problems. They are wicked problems where context, intent, and user behavior all shape what the right solution looks like.

A modal is not a modal because of its markup. It is a modal because of what it means to the user in that moment: stop, pay attention, deal with this before you continue. A role="status" is not a technical annotation — it is a social contract: this information changed, and you should know, but I won't interrupt you. These are not pattern-matching problems. They are problems of human communication, encoded in HTML.

AI approaches this as a statistical exercise: given this prompt, what code is most likely? But accessibility — and interface design more broadly — requires understanding why a pattern exists, not just what it looks like. It requires knowing that a person using a screen reader will navigate by headings, not linearly. That a person with low vision needs more than a change in opacity to perceive a state change. That a person with a motor disability needs every interactive element to be reachable by keyboard. That these are not edge cases — they are the full spectrum of how humans meet technology.

Kat Holmes calls this the "mismatch" — the idea that disability is not in the person but in the gap between the person and the design. Sara Hendren goes further: nearly everything we build is assistive technology, designed to bridge the gap between body and world. The question is whether we acknowledge this or pretend the gap doesn't exist.

What AI brings to the table is not a new problem. It is an old tension, resurfaced with new urgency: the temptation to reduce a human problem to pure logic. Herbert Simon dreamed of this in The Sciences of the Artificial — a world where design could be formalized, optimized, computed. Fred Brooks answered him: the complexity of software is essential, not accidental. You cannot abstract it away without abstracting away its meaning.

The illusion is seductive. If software were truly deterministic — if interfaces were tame problems with optimal solutions — then of course machines could write them better than we can. They are faster, cheaper, tireless. But interfaces are not tame. They are wicked. They involve bodies, contexts, cultures, disabilities, emotions, expectations. They involve people. And people resist reduction to statistics.

VI. As we may code

I started this essay describing a small moment: using an AI tool to read a text about the limits of human processing. The tool helped. It genuinely did. It compressed time, surfaced connections, let me absorb an 80-year-old essay in a fraction of the time it would have taken otherwise. Bush would have recognized it as a Memex — a machine that extends human thought.

But the understanding that came from that essay — the realization that its argument about amplification versus substitution was directly relevant to my own work in accessibility and code — that was not something the tool provided. That was association. That was meaning. That was the intricate web of trails carried by the cells of a brain that has spent years thinking about HTML, about screen readers, about the gap between what we build and who we build it for.

Eighty years after Bush, we have tools that can generate code at extraordinary speed. They can produce a login form in seconds, a dashboard in minutes, an entire landing page before you finish your coffee. But speed is not understanding. And production is not design.

The question Bush asked is still open: does our technology amplify human thought, or does it replace it? With LLMs applied to code, we are in danger of choosing the second option — not by conscious decision, but by the quiet assumption that software is a deterministic problem that machines can solve. It isn't. It never has been.

The developers, designers, and accessibility specialists who understand this are not being replaced by AI. They are becoming more essential. Because someone needs to write the custom instructions that turn a 0% automated pass rate into a 90% one — and then do the manual work that covers everything automation can't. Someone needs to know that a <dialog> is not just a <div> with a backdrop. Someone needs to understand that the user on the other side of the screen might not see, might not hear, might not use a mouse, might not think the way the designer assumed — and that this is not an edge case but the human condition.

HTML is a declarative API of meaning. The most successful one ever built. It was designed to be read by machines and understood by people. It is, in its quiet way, a bridge between logic and humanity. And the decision of which element to use — <button> or <div>, <nav> or <div>, <dialog> or <div> — is never a technical decision. It is a decision about who gets to participate.

References

Bush, V. (1945). "As We May Think." The Atlantic Monthly, July 1945.
Rittel, H.W. & Webber, M.M. (1973). "Dilemmas in a General Theory of Planning." Policy Sciences, 4(2), 155–169.
Brooks, F. (1986). "No Silver Bullet: Essence and Accident in Software Engineering." Proceedings of the IFIP Tenth World Computing Conference.
Reeves, J.W. (1992). "What Is Software Design?" The C++ Journal.
Buchanan, R. (1992). "Wicked Problems in Design Thinking." Design Issues, 8(2), 5–21.
Norman, D. (2013). The Design of Everyday Things. Revised and expanded edition. Basic Books.
Norman, D. (2010). Living with Complexity. MIT Press.
Simon, H. (1996). The Sciences of the Artificial. 3rd edition. MIT Press.
Holmes, K. (2018). Mismatch: How Inclusion Shapes Design. MIT Press.
Hendren, S. (2020). What Can a Body Do? How We Meet the Built World. Riverhead Books.
Fairchild, M. (2026). "Embedding Accessibility into AI-based Software Development." Tool: github.com/microsoft/a11y-llm-eval.

Your Accessibility Overlay Is a Scam (And Here's the Proof)

Ceci Olivera — Sun, 25 Jan 2026 18:46:44 +0000

You've probably seen them: that little wheelchair icon floating in the corner of websites, promising "accessibility" with one click. Maybe your company even pays for one. Products like accessiBe, UserWay, EqualWeb, and AudioEye promise to make your website accessible and legally compliant by just adding a single line of JavaScript.

It sounds too good to be true. Because it is.

Let me be clear from the start: I'm not being hyperbolic when I say "scam." In January 2025, the Federal Trade Commission fined accessiBe $1 million for deceptive marketing claims. The FTC determined that accessiBe was falsely claiming their product made websites "WCAG compliant" when it simply couldn't deliver on that promise.

And accessiBe isn't an outlier—it's the industry leader. The others make the same claims.

What accessibility overlays actually are

An accessibility overlay is a JavaScript widget that sits on top of your website. When users click on it, they get a panel with options like:

Change colors/contrast
Increase font size
Enable a "screen reader"
Activate "profiles" for blindness, dyslexia, ADHD, etc.
A magical toggle to "make the site WCAG compliant"

The pitch to businesses is irresistible: instead of spending money on actual accessibility work, just pay us $500-2000/year and we'll handle everything. Avoid lawsuits! Be compliant! One line of code!

Why they can't work (technically)

Here's the thing: web accessibility isn't about surface-level appearance. It's about the underlying structure of your HTML.

WCAG (Web Content Accessibility Guidelines) is the international standard that accessibility laws reference. It has specific technical requirements like:

Semantic HTML structure: headings (<h1>, <h2>), lists, landmarks
Properly labeled form fields: <label> elements correctly associated with inputs
Keyboard navigation: logical tab order, focus management
ARIA attributes: proper roles, states, and properties for dynamic content
Text alternatives: meaningful alt text for images (not auto-generated garbage)

An overlay is JavaScript that runs on top of your existing code. It cannot change your source code.

If your HTML uses <div> where it should use <button>, the overlay can't fix that. If your form fields don't have proper labels, the overlay can't create that association. If your modal doesn't trap focus correctly, the overlay can't restructure your DOM.

It's like putting a cardboard on a staircase and calling it a wheelchair ramp.

The features are either fake, redundant, or irrelevant

Let's break down what these overlays actually offer:

Fake: "Make site WCAG compliant" toggle

EqualWeb literally has an ON/OFF switch labeled "Make the site comply with WCAG."

This is the exact claim the FTC sanctioned. WCAG 2.1 has 78 success criteria. Many require structural changes to your codebase. No JavaScript widget can magically fix all of them with a toggle. This feature is, to put it plainly, a lie.

Fake: "Blindness profile"

Blind users already have screen readers. Professional ones. JAWS, NVDA (free), VoiceOver (built into Apple devices), TalkBack (Android). They've spent years learning these tools and configuring them to their needs.

An overlay that "adapts the site for blindness" can actually interfere with their existing screen reader, change keyboard shortcuts they rely on, and create an inconsistent experience across websites.

Moreover, I've checked that some of these overlay screenreaders ignore aria-hidden, the standard for removing a node from the accessibility tree (AOM), which is the data structure that dependable screen readers use to know what they are allowed to read.

Fake: "AI-powered image descriptions"

Overlays claim to automatically generate alt text for images using AI. The problems:

The descriptions are generic ("a person smiling") instead of contextual ("CEO presenting Q3 results")
Decorative images should have alt="" (empty), but AI adds unnecessary descriptions
WCAG requires alt text to be functionally equivalent, which requires human judgment about purpose

Redundant: Everything else

Most overlay features already exist at the operating system level:

Overlay feature	Already exists in...
Zoom/Magnification	Windows Magnifier, macOS Zoom, browser Ctrl+/-
High contrast	Windows High Contrast, macOS Increase Contrast
Color filters (colorblindness)	Windows, macOS, iOS, Android color filters
Screen reader	NVDA (free), VoiceOver (free), TalkBack (free), Narrator (free)
Large cursor	System accessibility settings on all OS
Voice control	Dragon, Windows Voice Control, macOS Voice Control
Text-to-speech	Built into every modern OS and browser
On-screen keyboard	Built into every OS
Dictionary	Built into every OS (Ctrl+Cmd+D on Mac, right-click on Windows)

People who need these features already have them configured system-wide, working across all apps and websites. They don't need each website to provide its own inferior version. Also, none of them are WCAG requirements and therefore, not a web dev responsibility.

Irrelevant: "Profiles" for ADHD, Dyslexia, Epilepsy, etc.

WCAG doesn't have success criteria for "ADHD profile" or "dyslexia mode." These aren't legal requirements.

What WCAG does require is specific things like not having content that flashes more than 3 times per second (for seizure safety), proper text spacing, ability to pause moving content, etc. An overlay can't stop a video from flashing. An overlay can't fix your auto-playing carousel.

These "profiles" are marketing theater — they sound inclusive but don't address actual legal compliance.

They don't protect you from lawsuits

The whole pitch is "avoid lawsuits." But the data shows the opposite:

25% of accessibility lawsuits in 2024 were against websites with overlays installed.

The legal precedent is clear. In the Murphy v. Eyebobs case, the court explicitly rejected the argument that an overlay provided adequate accessibility. In the LightHouse v. ADP settlement, the agreement explicitly stated that "overlay solutions such as those provided by AudioEye and accessiBe will not be sufficient to achieve accessibility."

Plaintiff attorneys know about overlays. Finding an overlay on a website doesn't make them go away—it shows them you tried to take a shortcut instead of doing the actual work.

Over 1000 accessibility professionals have signed against them

The Overlay Fact Sheet is a public document signed by more than 1000 accessibility professionals worldwide, including:

Contributors to WCAG, ARIA, and HTML standards
Employees at Google, Microsoft, Apple, BBC
Independent accessibility consultants
Disability advocates

The statement is clear: overlays don't work, they often make things worse, and they represent a misallocation of resources that should go toward real accessibility.

accessiBe, UserWay, EqualWeb, and AudioEye are all explicitly named.

The European Disability Forum has warned against them

In May 2023, the European Disability Forum (EDF) and the International Association of Accessibility Professionals (IAAP) issued a joint statement:

"Overlays do not make the website accessible or compliant with European accessibility legislation. They do not constitute an acceptable alternative or a substitute for fixing the website itself."

This is particularly relevant now that the European Accessibility Act (EAA) is in effect as of June 2025.

They also introduce security risks

In November 2022, Imperva's security research team discovered a DOM XSS vulnerability in EqualWeb's widget. The vulnerability affected major clients including Fiverr, Bosch, Playtika, and Avis.

When you add a third-party JavaScript widget to your site, you're trusting that vendor with your users' security. These overlays load external scripts on every page load, expanding your attack surface.

What you should do instead

If you actually care about accessibility (and avoiding lawsuits):

Remove the overlay. It's not helping. It might be hurting.
Get an audit. Hire an accessibility professional to evaluate your site against WCAG 2.1 AA.
Fix the actual issues. Work with your development team to address problems in the source code. This means semantic HTML, proper ARIA, keyboard navigation, color contrast, alt text, etc.
Train your team. Designers, developers, and content creators should understand accessibility basics so new features don't introduce new barriers.
Test with real users. Include people with disabilities in your QA process. They'll find issues automated tools miss.

Yes, this costs more than a few bucks a month. But it actually works. And it won't get you sued.

The bottom line

Accessibility overlays are selling you a lie: that you can buy compliance without doing the work. The FTC has called it deceptive. The disability community has rejected it. The data shows they don't prevent lawsuits.

If your company uses one, share this article with your manager. If you're a developer being asked to implement one, push back with this evidence. If you're evaluating accessibility solutions, run away from anyone promising a one-line JavaScript fix.

Real accessibility requires real work. There are no shortcuts.

Further reading:

Overlay Fact Sheet — The public statement signed by 1000+ professionals
Overlay False Claims — Documented evidence of misleading marketing
FTC v. accessiBe — The $1M fine for deceptive practices
EDF/IAAP Joint Statement — European Disability Forum warning
Adrian Roselli's blog — Extensive documentation of overlay problems
WCAG 2.1 Quick Reference — What actual compliance looks like

¿Qué significa que Javascript está basado en prototipos?

Ceci Olivera — Sat, 12 Sep 2020 09:21:05 +0000

Cuando empecé a estudiar Javascript y POO escuché muchas veces que a pesar de que Javascript es un lenguaje orientado a objetos no está basado en clases sino en prototipos.
En este artículo intentaremos entender qué significa exactamente esto y por qué es importante saber qué hace un prototipo.

En otros lenguajes orientados a objetos cuando declaramos una clase estamos creando un nuevo tipo de dato compuesto, es decir, un tipo de dato formado por tipos primitivos. Pero esto no es lo que ocurre en Javascript, a pesar de que desde ES2015 usemos la palabra reservada class. Los prototipos son instancias de objetos. Mientras que las clases son modelos, los objetos heredan directamente de otros objetos por defecto en JS.

Entonces, primero que nada tenemos que entender qué es la cadena de prototipos.

La cadena de prototipos es una estructura en forma de árbol que conecta funcionalidades entre objetos y en cuya raíz se encuentra Object.prototype. Object.prototype provee de una serie de métodos que aparecen en todos los objetos, como por ejemplo toString( ), hasOwnProperty( ) o keys( ).

Prácticamente todos los objetos en Javascript son instancias de Object si seguimos la cadena de prototipos. Y como probablemente ya sabes, casi todo es un objeto en Javascript. Incluso algunos tipos de datos primitivos (string, number y boolean específicamente) pueden ser objetos por fracciones muy pequeñas de tiempo. Entonces, los arrays son objetos, las funciones son objetos y, por supuesto, los objetos son objetos.

La cadena prototipal nos permite crear instancias de arrays, por ejemplo, que tengan acceso a todos los métodos definidos en Array.prototype como map, forEach, filter y un gran etc. Pero también obtenemos acceso a todos los métodos disponibles en Object.prototype.

Pero, ¿cómo ocurre esto?
Pues resulta que todos los objetos en Javascript tienen una propiedad oculta llamada __proto__ que guarda una referencia al objeto prototype del constructor. Siguiendo con el ejemplo de los arrays, un array tiene acceso a todos los métodos en Object.prototype porque cada array individual es una instancia del objeto Array, y el objeto Array es una instancia del objeto Object. Y esta cadena continúa hasta que llegamos al prototipo de Object.prototype, que será null.

De esta manera, cuando intentamos ejecutar un método en un objeto, Javascript primero buscará en las propiedades del objeto en cuestión. Si no encuentra una propiedad con ese nombre buscará en su propiedad __proto__, que guarda una referencia al objeto prototype de su constructor. Si no la encuentra ahí buscará en la propiedad __proto__ del objeto constructor. Esto continuará hasta que encuentre esa propiedad o método, o no la encuentre y lance un TypeError.

Por si acaso, ya que estamos usando los arrays como ejemplo, cabe recordar que los arrays son azúcar sintáctico en Javascript. Son objetos con un comportamiento especial, pero bajo la alfombra son algo así:

{
    ‘0’: value,
    ‘1’: value,
    ‘2’: value
}

Lo que esto significa es que, por ejemplo, cada vez que declaramos un array estamos creando una instancia del objeto Array que viene con el lenguaje. Si lo miramos en consola veremos que la propiedad __proto__ está vinculada al objeto Array:

Y si seguimos metiéndonos en la madriguera veremos que el objeto __proto__ tiene también una propiedad __proto__ que guarda una referencia a Object.prototype (es una referencia aunque nos salga en consola todo, porque ya sabes, DRY).

Entonces, ¿hay alguna forma de crear un objeto sin prototipo en Javascript?
Pues sí, la hay. Resulta que una de las formas que tenemos de crear objetos es con Object.create( ), a la cual podemos pasarle como argumento el objeto que queremos que sea el prototipo del nuevo objeto que queremos crear. Si le pasamos null estaremos creando un objeto que sea solo eso, una hash table:

const objetoSinPrototipo = Object.create(null);

What does it mean that Javascript is prototype based?

Ceci Olivera — Fri, 11 Sep 2020 19:10:01 +0000

When I first started learning Javascript and OOP I heard over and over that Javascript is an object-oriented language though it is not based on classes but prototypes.
In this article we are going to try to understand what this means and why it is important to know what a prototype is to acknowledge what we are doing.

In other object-oriented languages when you declare a class you are creating a new complex data type, that is to say, a data type composed of primitive data types. But this is not what happens in Javascript even though we use the keyword class since ES2015. Prototypes are object instances. While a class is a blueprint, objects inherit directly from other objects by default in Javascript.

To understand what this means, we need to understand what the prototype chain is.

The prototype chain is a tree-shaped structure that connects objects functionality and at the root of this tree is where Object.prototype lays.
Object.prototype provides a few methods that show up in all objects, such as toString( ), hasOwnProperty( ) or keys( ).

Almost every object in Javascript is an instance of Object if we follow the prototype chain. And as you probably know, almost everything in Javascript is an object, even some primitive data types (string, boolean and number specifically) can be objects for a tiny fraction of time. So, arrays are objects, functions are objects and, of course, objects are objects.

The prototype chain allows us to create instances of, for example, arrays that have access to all the methods that are available for arrays, like map, forEach, reduce, filter, and a big etc. But arrays also have access to all the Object.prototype functionalities.

How does this happen?
Just to be clear because we are using arrays for the example, arrays are syntactic sugar in Javascript. They are objects with a special behavior to make them look and feel like an array, but under the hood, they are something like this:

{
  '0': value,
  '1': value,
  '2': value
}

It turns out that every object has a property called __proto__ which holds a reference to the prototype object of the constructor. So following the array example, an array has access to all the methods in Object.prototype because every array is an instance of the Array object and the Array object is an instance of the Object object. And this chain goes on until we hit the prototype of Object.prototype which will be null.

This way, when we try to execute a method on an object, first JS will lookup in the properties of the object itself. If it doesn’t find a property with that name, it will look in its __proto__ property, which holds a reference to the prototype object of its constructor. If it doesn’t find it there it will look in the __proto__ property of the constructor object. This will go on until it finds it or it doesn’t find it and throws a TypeError.

What this means is that, for example, every time we declare an array we are creating an instance of the Array object that comes with the language. if we look at it in the console we will see that its __proto__ property is linked to the Array object:

And if we keep looking down the rabbit hole we’ll see that the __proto__ object has a __proto__ property itself that holds a reference to Object.prototype (it’s a reference even though you see all the properties in the console because you know, DRY).

So, is there a way to create an object without a prototype in Javascript?

Well, yes there is. One of the ways of creating an object is with Object.create( ), to which we can pass as an argument the prototype we want that object to have, which by default is Object.prototype. If we pass it null as an argument we will get an object that is just that, a hash table.

const objectWithoutPrototype = Object.create(null);

Share if you liked it and let's connect! Follow me on Twitter and LinkedIn 😊