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 PROYECTOEmpezá con
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.