Revision de Accesibilidad de Codigo

El Problema

Las fallas de accesibilidad excluyen al 15% de la poblacion mundial y exponen a las empresas a responsabilidad legal. Los desarrolladores construyen dropdowns personalizados que solo funcionan con mouse, usan div-soups que los lectores de pantalla no pueden parsear, y eligen combinaciones de colores que desaparecen para usuarios con daltonismo. La mayoria de estos problemas son invisibles durante el desarrollo.

El Prompt

Revisa el siguiente codigo frontend para cumplimiento de accesibilidad. Actua como un auditor WCAG 2.2 AA examinando el codigo fuente.

FRAMEWORK: [ej. React, Vue, Astro, HTML/CSS]
TIPO DE COMPONENTE: [ej. menu de navegacion, formulario, dialogo modal, tabla de datos]

CODIGO:
[pegar codigo del componente aqui]

Audita contra estos criterios WCAG 2.2 AA:

1. **Estructura Semantica**
   - Se usan elementos HTML correctos (button no div[onClick], nav, main, header)?
   - La jerarquia de encabezados es logica (h1 → h2 → h3, sin niveles saltados)?
   - Las listas estan marcadas como ul/ol, no secuencias de div?

2. **Navegacion por Teclado**
   - Todos los elementos interactivos son alcanzables con Tab?
   - El orden de foco es logico (sigue el layout visual)?
   - Los modals/dropdowns se cierran con Escape?
   - Hay indicador de foco visible en cada elemento interactivo?
   - Existen trampas de teclado (el foco entra pero no puede salir)?

3. **Uso de ARIA**
   - Los roles, estados y propiedades ARIA se usan correctamente?
   - Los widgets personalizados siguen los patrones WAI-ARIA?
   - Se usan regiones aria-live para actualizaciones de contenido dinamico?

4. **Accesibilidad Visual**
   - Los colores de texto cumplen contraste 4.5:1 (3:1 para texto grande)?
   - La informacion se transmite por mas que solo color?
   - Los objetivos tactiles son al menos 44x44px?

5. **Formularios**
   - Cada input tiene un label visible y asociado?
   - Los campos requeridos estan indicados programaticamente (aria-required)?
   - Los mensajes de error estan vinculados a los inputs (aria-describedby)?

6. **Medios e Imagenes**
   - Las imagenes tienen texto alt significativo?
   - Las imagenes decorativas tienen alt="" o role="presentation"?

Para cada problema, proporciona:
- **Criterio WCAG**: ej. 2.1.1 Teclado, 4.1.2 Nombre Rol Valor
- **Severidad**: Critico (bloquea acceso) / Serio / Moderado / Menor
- **Impacto**: Que usuarios estan afectados
- **Fix**: Codigo corregido

Ejemplo de Salida

## Revision de Accesibilidad: 6 problemas encontrados

### Critico — WCAG 2.1.1: Dropdown Inaccesible por Teclado
Ubicacion: src/components/Dropdown.tsx:8
Problema: Dropdown personalizado usa div con onClick — inalcanzable por teclado.
Fix:
  <button aria-haspopup="listbox" aria-expanded={isOpen} onClick={toggle}>
    Seleccionar opcion
  </button>
  <ul role="listbox" aria-label="Opciones">
    {options.map(opt => (
      <li role="option" aria-selected={opt === selected} tabIndex={0}>{opt}</li>
    ))}
  </ul>

Cuando Usar

Ejecutar en cada componente UI antes del merge — especialmente formularios, navegacion, modals y widgets interactivos. Critico antes de lanzar sitios publicos con mandatos de accesibilidad (EU EAA 2025, ADA).

Tips Pro

• Probar un componente a la vez — los problemas de accesibilidad se acumulan en contexto de pagina.
• Pedir narracion de lector de pantalla — “Recorre este componente como lo anunciaria un lector de pantalla, paso a paso.”
• Combinar con herramientas automatizadas — esta revision encuentra lo que axe/Lighthouse no detecta: orden logico de foco y patrones ARIA correctos.