Diseño de interfaz
Una pregunta sobre una pantalla no es una cuestión de gusto. El contraste tiene una relación, un objetivo tiene un tamaño, un reflujo tiene un ancho mínimo en el que debe seguir funcionando, y un diseño tiene un orden de información que se deduce de lo que el lector hace primero. Estas cuestiones se deciden mediante mediciones y estándares publicados, así que pasárselas al usuario como "¿cuál prefieres?" gasta su atención en trabajo que correspondía al agente.
Lo que queda después de medir es una pregunta real,
y esta habilidad existe para reducir ese resto al mínimo y adjuntarle la evidencia.
own-the-call gobierna cómo se formula entonces.
Los momentos que esto reemplaza
| A punto de… | En lugar de eso… |
|---|---|
| preguntar qué color, tamaño, espaciado o ubicación prefiere el usuario | medir contra el estándar de abajo; preguntar solo lo que ningún umbral resuelve |
| llamar subjetiva a una elección visual | nombrar el criterio que cumple o incumple — contraste, tamaño de objetivo, ancho de reflujo, visibilidad de foco, orden de información |
| decir "se ve bien" | abrirlo, capturarlo en pantalla y decir qué se midió y a qué viewport |
| dimensionar un control a ojo | 24×24 px CSS es el mínimo de WCAG AA; un sistema de diseño puede establecer uno más estricto (Material: 48dp) |
| elegir colores de una paleta por apariencia | calcular la relación: 4,5:1 para texto normal, 3:1 para texto grande y no textual |
| enviar un diseño comprobado en un solo tamaño de ventana | comprobar a 320 px de ancho y 256 px de alto, donde el reflujo debe seguir funcionando |
| leer una ejecución de axe en verde como accesible | axe encuentra aproximadamente el 57%; el resto es teclado, orden de foco y significado |
| diseñar un componente que un sistema de diseño ya define | tomar el suyo y decir cuál |
| preguntar cómo dibujar un diagrama | decidir a partir de lo que el lector traza primero, luego mostrar una representación |
Decidir según el estándar antes de preguntar
Cuatro organismos responden la mayor parte, y no están completamente de acuerdo — donde difieren, el número más estricto es el que hay que cumplir, porque cumplirlo satisface a ambos.
WCAG 2.2 es el mínimo, y es normativo: una Recomendación del W3C, e ISO/IEC 40500. Nivel objetivo AA; AAA no es alcanzable para todo el contenido, y el W3C lo afirma.
| Criterio | Nivel | Umbral |
|---|---|---|
| 1.4.3 Contraste (Mínimo) | AA | 4,5:1 texto; 3:1 para texto grande (≥18 pt, o 14 pt negrita) |
| 1.4.11 Contraste no textual | AA | 3:1 contra colores adyacentes |
| 1.4.4 Redimensionar texto | AA | utilizable al 200% |
| 1.4.10 Reflujo | AA | sin desplazamiento en dos ejes a 320 px de ancho o 256 px de alto |
| 1.4.12 Espaciado de texto | AA | interlineado ≥1,5×, párrafo ≥2×, letra ≥0,12×, palabra ≥0,16× tamaño de fuente |
| 2.4.7 Foco visible | AA | un modo donde el indicador de foco sea visible |
| 2.4.11 Foco no oculto | AA | el control enfocado no está completamente oculto |
| 2.5.8 Tamaño de objetivo (Mínimo) | AA | 24×24 px CSS, o espaciado de 24 px |
| 2.4.13 Apariencia del foco | AAA | contorno ≥2 px, relación 3:1 entre enfocado y no enfocado |
| 2.5.5 Tamaño de objetivo (Mejorado) | AAA | 44×44 px CSS |
Un sistema de diseño resuelve lo que WCAG deja abierto: escala de espaciado,
escala tipográfica, anatomía de componentes, roles de color.
Tomar su componente no es un atajo,
es la decisión — y lleva consigo el trabajo de accesibilidad ya realizado.
Material Design 3 establece objetivos táctiles de 48×48 dp,
más estrictos que los 24 px de WCAG,
y pide que el color se elija por roles (primary, on-primary, surface) en lugar de por valores hexadecimales fijos,
para que la tematización y el modo oscuro se apliquen sin una segunda decisión.
Para trabajos públicos en japonés, el sistema de diseño de la Agencia Digital (design.digital.go.jp, β版 como estándar vivo) incluye componentes,
pautas y fichas (tokens), con las fichas y componentes de ejemplo en GitHub bajo MIT.
axe-core mide lo que se puede medir, y declara su propio límite:
alrededor del 57% de los problemas WCAG en promedio.
Por lo tanto, una ejecución en verde es evidencia sobre el 57% de la pregunta,
y decir "axe pasa" sin ese número lo exagera — measured-claims se aplica a esta cifra como a cualquier otra.
npx @axe-core/cli http://localhost:5173 --tags wcag2a,wcag2aa,wcag22aa
npx lighthouse http://localhost:5173 --only-categories=accessibility --quiet
La puntuación de accesibilidad de Lighthouse es el mismo motor con un número. Sus auditorías son reglas de axe-core — cada una enlaza a la página de regla de Deque — así que el 57% se hereda,
y la puntuación añade dos formas de ser malinterpretada.
Es un promedio ponderado,
con pesos de 3 a 10 según la evaluación de impacto de usuario de axe,
y las auditorías manuales y de mejores prácticas están excluidas por completo de la misma,
por lo que la aritmética no puede alcanzar la parte que una persona debe comprobar.
Cada auditoría también es binaria:
un botón sin etiqueta falla "Los botones tienen un nombre accesible" directamente,
sin crédito parcial.
Así que 100 significa "el subconjunto automático ponderado pasó",
y el informe honesto de una puntuación perfecta dice eso, no "accesible".
Úsala para la lista ordenada de lo que hay que corregir;
usa el JSON de axe cuando el hallazgo importe más que la clasificación.
Las categorías de rendimiento de Lighthouse son de web-perf,
no de esta habilidad.
Lo que ninguna puede ver: si el orden de foco sigue el orden de lectura, si una etiqueta nombra lo que etiqueta, si el significado de un icono sobrevive sin color, si el orden de información del diseño coincide con la tarea. Esas las lee una persona, y la persona puede ser el agente.
Mirarlo, luego decir lo que se ha visto
Una afirmación sobre una interfaz sin observación que la respalde es el rumor de measured-claims en otro medio.
El anfitrión tiene un navegador, por lo que la observación está disponible:
mcp__claude-in-chrome__navigate → la página
mcp__claude-in-chrome__read_page → estructura, encabezados, etiquetas
mcp__claude-in-chrome__computer → captura de pantalla en un viewport indicado
mcp__claude-in-chrome__resize_window → 320 px, para probar el reflujo
Informa el viewport junto con el hallazgo. "Se ve bien" no nombra ningún ancho ni medición; "a 320 px la segunda columna se coloca debajo de la primera y nada se desplaza lateralmente" es una lectura que alguien puede comprobar. El orden del teclado se recorre con Tab y se informa como la secuencia observada, porque esa es la mitad que axe no cubre.
El orden de información se deriva, no se elige
Dónde va algo se deduce de lo que el lector hace con ello,
que es la pregunta de reader-map aplicada a una pantalla: quién llega,
para qué vino, qué necesita primero.
Un control que se usa una vez en la configuración y un control que se usa cada minuto no compiten por el mismo lugar.
Así que "¿dónde debería ir esto?" se responde nombrando la tarea, no enumerando tres posiciones. Cuando dos tareas compiten realmente y ninguna domina, ese es el resto que vale la pena preguntar — y se pregunta con las tareas en competencia nombradas, no como una elección de esquinas.
Lo mismo se aplica a un diagrama. Lo que el lector traza primero decide la dirección del flujo; la forma sigue al trazado, y se muestra una representación en lugar de describir tres.
Lo que es genuinamente del usuario
Tres cosas sobreviven a la medición:
- A qué audiencia o mercado sirve la interfaz,
cuando eso aún no está fijado — decide qué estándar se aplica en absoluto (
regulated-claimspara un mercado regulado). - Una restricción de marca — un color, tipografía o logotipo requerido. La restricción es suya; si cumple 4,5:1 se mide igualmente, y un color de marca que falla se informa con la relación y la variante aprobada más cercana.
- Una compensación ya medida por ambos lados,
donde la evidencia no decide: densidad contra legibilidad,
una pantalla contra dos.
Preguntado con ambas mediciones adjuntas,
es una pregunta que
own-the-calladmite.
Todo lo demás — contraste, espaciado, tamaño de objetivo, foco, reflujo, elección de componente, forma del diagrama, colocación que sigue a una tarea — se decide y se informa.
Lista de verificación
- Contraste calculado, no estimado a ojo: 4,5:1 texto, 3:1 grande y no textual
- Objetivos interactivos ≥24×24 px CSS, o la cifra más estricta del sistema de diseño
- Verificado a 320 px de ancho y 256 px de alto sin desplazamiento en dos ejes
- Foco visible en cada elemento interactivo, y no oculto
- Orden de tabulación recorrido e informado como observado
- Componentes tomados del sistema de diseño donde lo define, y nombrados
- axe o Lighthouse ejecutados, y el límite del 57% indicado, no implícito
- Una puntuación de accesibilidad de Lighthouse informada como subconjunto automático ponderado, nunca como "accesible"
- Cada afirmación de apariencia lleva el viewport en el que se observó
- Las preguntas que quedan para el usuario son los tres tipos anteriores, con evidencia adjunta
Cómo se conecta
own-the-call da forma a la pregunta que sobrevive a esta habilidad;
la mayoría de las preguntas sobre una pantalla no deberían llegar a ella.
reader-map proporciona el orden de tareas que esta habilidad aplica a la colocación.
measured-claims gobierna cada relación y porcentaje aquí,
incluido el 57%.
document-structure y cognitive-rhythm son dueños de la prosa en una página;
esta habilidad es dueña del marco que la rodea.
any-screenshot es cómo se captura una pantalla fuera de un navegador.
La velocidad de carga e interacción,
Core Web Vitals y la puntuación de rendimiento de Lighthouse pertenecen a web-perf en el plugin cloudflare;
esta habilidad toma solo la categoría de accesibilidad de Lighthouse.
Fuentes
- W3C, "Web Content Accessibility Guidelines (WCAG) 2.2", Recomendación del W3C del 12 de diciembre de 2024 (www.w3.org/TR/WCAG22/): los cuatro principios, los niveles A/AA/AAA, y la eliminación de 4.1.1 Análisis sintáctico como obsoleto.
- W3C, "Cómo cumplir WCAG 2.2 (Referencia rápida)" (www.w3.org/WAI/WCAG22/quickref/): cada umbral en la tabla anterior, leído en el Nivel AAA para incluir 2.4.13 y 2.5.5.
- Deque Labs, README de axe-core (github.com/dequelabs/axe-core): MPL-2.0; reglas mapeadas a WCAG 2.0, 2.1 y 2.2 en A, AA y AAA; "puedes encontrar automáticamente un promedio del 57% de los problemas WCAG".
- Chrome for Developers, "Puntuación de accesibilidad en Lighthouse" (developer.chrome.com/docs/lighthouse/accessibility/scoring): la puntuación es un promedio ponderado, pesos de 3 a 10, "basado en evaluaciones de impacto de usuario de axe", con cada auditoría enlazando a una página de regla de axe-core 4.11 de Deque University; cada auditoría es binaria; las auditorías manuales y de bajo impacto están excluidas de la puntuación. La página no dice por sí misma que una puntuación perfecta signifique que la página es accesible — ni dice lo contrario, por lo que la advertencia anterior es de esta habilidad.
- Sistema de diseño de la Agencia Digital de Japón (design.digital.go.jp): v2.18.2,
etiquetado como β版 en el sentido de un estándar vivo.
El sitio no declara ningún nivel WCAG ni ningún objetivo JIS X 8341-3.
digital-go-jp/design-tokens,design-system-example-components-reacty-htmlen GitHub son MIT. - El objetivo táctil de 48×48 dp de Material Design 3 y su guía de roles de color se toman de fuentes secundarias que citan m3.material.io, no de ese sitio: sus páginas se renderizan mediante script y no pudieron leerse aquí. La cifra de 48 dp es una recomendación de diseño, no un mínimo impuesto por la plataforma.
La afirmación de que estas fuentes discrepan, y que la cifra más estricta es la que hay que cumplir, es la lectura del propietario de este catálogo, no ninguna de sus posiciones publicadas.
Ninguno de los comandos anteriores se ejecutó mientras se escribía esta habilidad: ambos descargan un paquete en el primer uso, y el entorno limitado aquí se niega a ejecutar código recién descargado. Las banderas provienen de la documentación de cada herramienta, no de una ejecución, así que el primer uso en un proyecto es también la primera prueba de la invocación.