Tend A11y — *el heraldo*

Tend A11y — el heraldo

Encuentra el único problema de accesibilidad, UX o tono de copia de mayor prioridad en el marcado de este repositorio, corrígelo mínimamente, verifica y devuelve el diff para revisión. Un problema por ejecución.

0. Cargar configuración

• Lee .claude/tend/config.yaml. Usa skills.a11y (globs prohibidos, notes). Este skill no tiene módulos de capacidad — omite completamente la compuerta de módulos, no hay paso de compuerta modules: aquí.
• ¿Sin configuración? Ejecuta en nivel core: suposiciones base de SvelteKit + TS, límites incorporados conservadores (nunca toques lockfiles, CI, .env, config). Emite una vez: "ejecuta tend-onboard para afinar". Continúa.

1. Triaje

LECTURA OBLIGATORIA references/scan-core.md.

• Establece el conjunto de límites: los skills.a11y.off-limits de la configuración más las barreras incorporadas (nunca toques lockfiles, configuración de CI, .env, config del proyecto ni lógica de backend/rutas de API — este skill es solo de presentación).
• Establece los puntos de entrada: los archivos de marcado de este repositorio — componentes .svelte, rutas +page.svelte / +layout.svelte, o los archivos de plantilla que use el stack. Revisa skills.a11y.notes en busca de un directorio de librería de componentes con nombre (por ejemplo, src/lib/components/ui) — si existe, sus exportaciones son la lista objetivo "usa esto en lugar de HTML plano" para la Fase 2.
• Lee 1 o 2 componentes existentes antes de escanear para aprender las convenciones reales de librería de componentes y de estado/carga del repositorio — necesitas el patrón real antes de poder llamar desviación a una violación.

Criterio de finalización: conjunto de límites conocido, convención de librería de componentes (si existe) identificada, globs de puntos de entrada identificados.

2. Escanear — orden de prioridad, detente en el primer acierto real

Ordenado de mayor valor (más silencioso para los usuarios) a menor — detente en el primer acierto real respaldado por evidencia:

1. HTML interactivo plano donde existe un equivalente en la librería de componentes — un <button>/<a>/<input> junto a una exportación Button/Link/Input en otra parte del repositorio.
2. Elementos interactivos solo con icono o principalmente con icono que carecen de un nombre accesible — sin aria-label, sin texto oculto visualmente, sin respaldo title.
3. <img> sin alt — el atributo faltante es la violación; un alt="" intencionalmente vacío en una imagen decorativa no lo es.
4. Entradas de formulario sin una etiqueta asociada — sin label for=, aria-label o prop de etiqueta de la librería de componentes. Audita el recuento renderizado, no solo la plantilla: las entradas generadas dentro de un bucle ({#each} o equivalente) producen N controles anónimos en tiempo de ejecución.
5. role="button" (o un onclick desnudo en un elemento no interactivo) que carece del manejador de teclado correspondiente — onkeydown para Enter + Espacio. El <button> nativo obtiene esto gratis; esto solo se aplica al escape de elemento plano.
6. Feedback de éxito/error/carga asíncrono renderizado como un elemento plano y sin anunciar — sin role="alert"/role="status", sin aria-live, y sin un primitivo de banner/toast de librería de componentes existente ya utilizado en otra parte del repositorio.
7. Una acción destructiva (eliminar/borrar/reiniciar) sin un paso de confirmación antes de que surta efecto.
8. Violaciones de tono de copia, verificadas contra la lista de permitidos/prohibidos impulsada por la configuración (skills.a11y.notes, o un documento de tono del proyecto al que apunte). Si no existe una lista específica del repositorio, recurre a valores predeterminados genéricos: un suavizador imperativo como "Por favor" precediendo una instrucción de validación/error ("Por favor, introduce un nombre" vs. "Introduce un nombre"), o un signo de exclamación innecesario en copia rutinaria de confirmación/instrucción. Escanea tanto el texto del marcado renderizado como los literales de cadena dentro de bloques <script> — la copia asignada a una variable, pasada a una llamada de toast/alert, o establecida mediante .textContent/.innerText vive en bloques de script, no solo en el marcado, y un grep solo de marcado pasará por alto las cadenas de validación reales.

3. Corregir — un cambio atómico

Antes de editar, responde:

1. ¿Es esto genuinamente poco claro o inaccesible para un usuario real (lector de pantalla, solo teclado o alguien que lee el tono) — no una preferencia estilística mía?
2. ¿La corrección toca solo presentación/copia — sin lógica, sin backend, sin nueva dependencia?
3. ¿Ya existe un equivalente de librería de componentes para este patrón? Si es así, úsalo en lugar de improvisar la corrección con HTML plano (no coloques role="alert" en un <div> plano si el repositorio ya tiene un componente de estado/banner que lo lleva).

Verificación base: ejecuta el lint/typecheck del repositorio (y el conjunto de pruebas si es rápido) antes de editar — anota cualquier fallo preexistente para no atribuirlos incorrectamente después.

Presupuesto de tamaño: ≤50 líneas cambiadas para una corrección de marcado/estructural, ≤10 líneas para una corrección puramente textual; un componente o página por ejecución.

Nunca toques rutas prohibidas. Si la corrección real requiriera tocar una, detente e informa por qué en lugar de forzarla a través de otra parte.

4. Verificar y presentar

Vuelve a ejecutar lint/typecheck (y pruebas, si las ejecutaste en el paso 3) — aborta solo si tu cambio introduce un nuevo fallo; los fallos preexistentes no son tuyos para corregir aquí. Muestra el diff. DETENTE — no hagas commit, no abras un PR.

NUNCA

• NUNCA marques o corrijas más de un problema por ejecución En su lugar: Detén el escaneo en el primer acierto real, corrígelo y preséntalo. Por qué: Los diffs por lotes de accesibilidad/copia son difíciles de revisar individualmente y ocultan qué corrección específica causó una regresión.

• NUNCA improvises una corrección con HTML plano cuando ya exista un equivalente en la librería de componentes En su lugar: Usa el componente Button/Input/Link/banner de estado del propio repositorio. Por qué: Una corrección paralela hecha a mano crea un segundo patrón inconsistente en lugar de converger en el que el resto del repositorio ya utiliza — la próxima auditoría lo volverá a marcar como desviación.

• NUNCA inventes una regla de tono de copia que no esté respaldada por skills.a11y.notes o un valor predeterminado genérico y claramente etiquetado En su lugar: Usa la lista de permitidos/prohibidos impulsada por la configuración, o indica explícitamente que estás recurriendo a un patrón predeterminado genérico. Por qué: Una regla inventada sobre la marcha no es reutilizable ni auditable en la próxima ejecución, y puede contradecir el estilo real del repositorio.

• NUNCA escanees solo el marcado y omitas los bloques <script> para las cadenas de copia En su lugar: Busca también literales de cadena dentro de bloques <script> — la copia de validación y feedback se asigna frecuentemente allí, no se escribe directamente en la plantilla. Por qué: La cadena real orientada al usuario es a menudo una variable interpolada en la plantilla; un grep solo de marcado coincide con el sitio de interpolación, no con el texto infractor real, y no informa nada que corregir.

• NUNCA toques rutas prohibidas ni hagas commit o abras un PR En su lugar: Respeta skills.a11y.off-limits más las barreras incorporadas; detente después de presentar el diff. Por qué: El trabajo de este skill termina en "diff verificado, listo para revisión humana" — hacer commit o tocar rutas excluidas elimina la compuerta de revisión de la que depende todo el flujo de trabajo.

Archivos

• references/scan-core.md — verificaciones principales (cargadas en la Fase 1)
• evals/ — aserciones de ai-forge-eval