← Volver a Elyfront
06 / CALIDADV0.1 · SKILL INDEPENDIENTE

Ely Accesibilidad

Que la interfaz se pueda usar, no sólo mirar.

Cuándo usarla

Cuando necesitás que la navegación, los controles y los cambios de estado sean claros más allá del puntero.

Identifica y corrige barreras de semántica, teclado, foco y formularios. Comprueba los recorridos afectados y distingue cada tipo de evidencia.

Qué aporta al proyecto

  • Semántica y nombres accesibles
  • Recorrido de teclado y gestión de foco
  • Correcciones de formularios y feedback dinámico
PROBALA EN TU PROYECTO

Empezá con
este pedido.

Usá $ely-accessible-frontends para revisar este flujo de registro. Corregí las barreras de teclado, foco, etiquetas y errores, y explicá qué pudiste verificar.

Instalá la carpeta ely-accessible-frontends en ~/.codex/skills/ para invocarla en Codex.

Leer las instrucciones completas de la skill
---
name: ely-accessible-frontends
description: "Detecta y repara barreras de accesibilidad en frontends: semántica, teclado, foco, nombres accesibles, formularios y estados dinámicos. Úsala para construir o corregir flujos utilizables con distintas formas de interacción; no emite certificaciones de cumplimiento."
---

# Ely Accesibilidad

Haz que el flujo solicitado se pueda comprender y completar con teclado, ampliación y tecnología de asistencia. Conserva la intención visual y las herramientas del proyecto; corrige la causa semántica o de comportamiento antes de añadir atributos.

## Encontrar la barrera real

Identifica qué tarea debe completar la persona y recórrela en la interfaz renderizada. Examina orden del DOM, controles, estados vacíos, validación y actualizaciones asíncronas. Prioriza bloqueos del recorrido sobre advertencias que no afectan a ese uso. Registra cada hallazgo como **acción → barrera observable → impacto → reparación verificable**.

Utiliza controles HTML nativos y componentes accesibles existentes cuando encajen. Un `div` con `role="button"` no adquiere por ello activación por teclado, deshabilitado ni comportamiento de formulario. No añadas ARIA para compensar una estructura que puede resolverse con HTML.

## Reparar el recorrido

- **Orden y comprensión:** mantén el orden de lectura coherente con el recorrido visual; títulos, landmarks y nombres deben orientar. No cambies el orden del DOM con `tabindex` positivos para simular el diseño.
- **Nombres y estados:** cada acción tiene un nombre que explica su función; la etiqueta visible debe estar representada en él. Expón selección, expansión, deshabilitado y ocupación cuando sean relevantes. Oculta duplicados decorativos, no la única explicación del contenido.
- **Teclado y foco:** todas las acciones son alcanzables y operables, el foco es visible y no queda detrás de un header fijo. Mantén un orden predecible. Restringe el foco solo cuando el patrón es modal; devuelve el foco al origen o a un sucesor lógico si ese origen desapareció.
- **Formularios:** vincula etiquetas y ayudas con campos. Tras un error, conserva los datos, asocia mensajes concretos al campo y ofrece una ruta comprensible para corregirlos. No conviertas cada pulsación en una alerta.
- **Cambios dinámicos:** conserva el foco cuando sigue siendo válido. Anuncia resultados o errores que de otro modo pasarían inadvertidos, sin leer toda la página ni duplicar el anuncio del control. No fuerces foco por cada actualización de datos.
- **Adaptación:** prueba ampliación y ancho reducido con texto real, nombres largos y contenido localizado. Evita clipping de texto y desplazamiento bidimensional innecesario. Diferencia información también por texto, forma o estructura cuando el color sea insuficiente.

Para reparar diálogos, formularios, controles compuestos o anuncios de estado, lee [references/interaction-repairs.md](references/interaction-repairs.md). Si necesitas un patrón ARIA especializado, consulta la documentación primaria vigente para ese patrón; no inventes atajos de teclado ni afirmes que una implementación parcial lo satisface.

En interfaces animadas, conserva acceso a todo el contenido y las acciones con movimiento reducido. Evita que elementos transparentes o fuera de pantalla sigan recibiendo foco. Proporciona alternativas a gestos complejos; no uses el hover como único acceso a información necesaria.

## Verificar y explicar los límites

Repite el recorrido con teclado, revisa los nombres y estados en el árbol de accesibilidad cuando el navegador lo permita, y comprueba reflujo y foco visible. Las herramientas automáticas ayudan a descubrir problemas; no validan por sí solas usabilidad, orden lógico ni una experiencia real con lector de pantalla.

Prueba con un lector de pantalla si está disponible y el alcance lo justifica. Si solo inspeccionaste el árbol de accesibilidad, dilo de esa forma. No afirmes cobertura de tecnologías, navegadores o criterios que no probaste. Si el usuario pide evaluar una norma concreta, verifica su versión y los criterios aplicables en fuentes oficiales.

Entrega las reparaciones y la evidencia del flujo comprobado, con cualquier barrera pendiente. Evita sellos, porcentajes arbitrarios o declaraciones de certificación a partir de una revisión parcial. Publicar o cambiar sistemas externos requiere el alcance autorizado por el usuario.