Communitygithub.com

auditoría-de-accesibilidad

Habilidad de auditoría de accesibilidad WCAG 2.2 para Claude Code: hallazgos clasificados por severidad con citas de criterios de éxito.

¿Qué es auditoría-de-accesibilidad?

Esta habilidad para Claude Code permite realizar auditorías de accesibilidad web basadas en WCAG 2.2. Está diseñada para desarrolladores y testers que necesitan evaluar rápidamente la conformidad de una interfaz de usuario con los estándares de accesibilidad. La habilidad acepta como entrada capturas de pantalla, URLs, o fragmentos de HTML/JSX, y devuelve un informe estructurado con hallazgos clasificados por severidad (P0, P1, P2) y citas de los criterios de éxito de WCAG 2.2. Es útil porque automatiza gran parte del proceso de revisión, asegura consistencia al aplicar siempre los mismos 18 criterios, y evita sesgos al separar claramente lo que la entrada puede probar de lo que no. Funciona integrada en el flujo de trabajo de Claude Code, donde el modelo Lee el checklist de referencia, analiza la entrada, asigna severidad a cada hallazgo, y genera el informe en un formato estandarizado.

Compatible con✓Claude Code~Codex CLI~Cursor
npx skills add humbleteam/accessibility-audit

Preguntar en tu IA favorita

Abre un nuevo chat con esta habilidad de agente ya precargada.

Documentación

Auditoría de accesibilidad

Paso 1: identificar la entrada

Determina qué se proporcionó realmente antes de verificar nada:

  • Una captura de pantalla o imagen - procede con el alcance solo-de-captura (ver Paso 3).
  • Una URL - obtén la página si hay una herramienta de obtención disponible y usa el HTML renderizado como fuente de verdad. Si también hay una captura de pantalla de la página, usa ambas. Si no hay herramienta de obtención disponible, pide al usuario que pegue el HTML de la página en lugar de adivinar el marcado.
  • HTML, JSX u otro fragmento de marcado/componente - léelo directamente como fuente de verdad.
  • Cualquier otra cosa (una descripción simple, un enlace de Figma sin imagen exportada, un "revisa nuestra app" vago) - detente y pide una captura de pantalla, URL o marcado. No adivines una interfaz que no puedes ver.

Si se proporciona más de un tipo de entrada (por ejemplo, una URL más una captura de pantalla de uno de sus estados), usa ambas y verifica contra el alcance más amplio.

Paso 2: lee la lista de verificación

Antes de evaluar cualquier cosa, lee references/wcag22-checklist.md. Contiene los 18 criterios de éxito que esta auditoría verifica, uno por línea: número de SC, nombre, nivel, si una captura de pantalla sola puede verificarlo, y qué buscar. Reléelo en cada auditoría, incluso en una segunda dentro de la misma sesión, para que los criterios no se salgan silenciosamente de la memoria.

Criterios que cubre esta auditoría

SCNombreNivel
1.1.1Contenido no textualA
1.3.1Información y relacionesA
1.4.3Contraste mínimoAA
1.4.4Cambio de tamaño del textoAA
1.4.10ReflujoAA
1.4.11Contraste no textualAA
2.1.1TecladoA
2.1.2Sin trampa de tecladoA
2.4.4Propósito del enlace (en contexto)A
2.4.6Encabezados y etiquetasAA
2.4.7Foco visibleAA
2.4.11Foco no oscurecido (mínimo) - nuevo en WCAG 2.2AA
2.5.8Tamaño del objetivo (mínimo) - nuevo en WCAG 2.2AA
3.2.2Al recibir entradaA
3.3.1Identificación de erroresA
3.3.2Etiquetas o instruccionesA
3.3.8Autenticación accesible (mínimo) - nuevo en WCAG 2.2AA
4.1.2Nombre, función, valorA

Consulta references/wcag22-checklist.md para saber qué buscar bajo cada uno.

Paso 3: separa lo que la entrada puede probar de lo que no puede

Esta es la regla que mantiene la auditoría honesta. Nunca declares un aprobado o un fallo en un criterio que la entrada no puede demostrar.

Desde una captura de pantalla sola, PUEDES verificar:

  • 1.4.3 contraste mínimo - mide los colores del texto renderizado y el fondo.
  • 1.4.11 contraste no textual - mide iconos, bordes e indicadores de foco visibles.
  • 2.4.6 encabezados y etiquetas - confirma que los encabezados y las etiquetas de formulario están visualmente presentes y tienen sentido fuera de contexto.
  • 2.5.8 tamaño del objetivo - mide las dimensiones de los elementos táctiles contra el mínimo de 24x24 px CSS, cuando se conoce o indica la escala de la ventana gráfica.
  • 3.3.2 etiquetas o instrucciones - confirma que existen instrucciones visibles junto a las entradas que las necesitan.

Desde una captura de pantalla sola, NO PUEDES verificar, y debes listar bajo "No verificable con esta entrada":

  • 1.1.1 contenido no textual (el texto alternativo vive en el DOM, no en los píxeles).
  • 1.3.1 información y relaciones (estructura semántica).
  • 2.1.1 / 2.1.2 comportamiento del teclado y trampas de teclado.
  • 2.4.4 propósito del enlace cuando depende del contexto programático.
  • 2.4.7 / 2.4.11 visibilidad del foco, a menos que se haya proporcionado una captura de pantalla del estado de foco.
  • 3.2.2 al recibir entrada, 3.3.1 identificación de errores, 3.3.8 autenticación accesible - todos necesitan interacción o flujo, no una imagen estática.
  • 4.1.2 nombre, función, valor (necesita el árbol de accesibilidad).

Desde HTML, JSX o una página obtenida, verifica los 18 directamente contra el marcado: atributos alt, estructura de encabezados y puntos de referencia, asociaciones de etiquetas, roles y estados ARIA, tabindex y código de gestión de foco, y cualquier valor de color en línea que puedas resolver para calcular el contraste. Si no se incluye CSS, el contraste y el tamaño del objetivo aún caen en "no verificable" a menos que se den valores calculados.

Paso 4: asigna severidad

  • P0 - bloquea el uso. Un usuario no puede completar la tarea en absoluto. Falta de nombre accesible en una acción principal, una trampa de teclado, contraste tan bajo que el texto es ilegible, un control de formulario sin etiqueta alguna.
  • P1 - degrada el uso. La tarea es posible pero más difícil. Contraste por debajo del umbral AA pero aún legible, falta de indicador de foco visible, un objetivo por debajo del mínimo de 24x24 px CSS, texto de enlace vago ("haz clic aquí") sin contexto circundante.
  • P2 - fricción. Confusión menor o ineficiencia. Niveles de encabezado inconsistentes, bajo contraste en un elemento decorativo, instrucciones redundantes.

Paso 5: escribe cada hallazgo

Cada hallazgo necesita tres partes, en este orden:

  1. Observado - lo que realmente viste o leíste, no una inferencia. ("El botón 'Enviar' muestra texto blanco (#FFFFFF) sobre un fondo #7A9CC6.")
  2. Solución - concreta, no genérica. ("Oscurece el fondo a #3D5A80 o menos para alcanzar una relación de 4.5:1 contra el texto blanco.")
  3. Citación - WCAG 2.2 SC <número> (<nombre>, Nivel <A/AA>).

Formato de salida

Usa exactamente esta estructura:

# Auditoría de accesibilidad: <nombre o URL de lo revisado>

**Tipo de entrada:** captura de pantalla | URL | HTML/JSX
**Alcance:** <una línea sobre lo que realmente se verificó>

## P0 - bloquea el uso
1. **<título breve>**
   - Observado: <hecho>
   - Solución: <solución concreta>
   - WCAG 2.2 SC <x.x.x> (<nombre>, Nivel <A/AA>)

## P1 - degrada el uso
(misma estructura)

## P2 - fricción
(misma estructura)

## No verificable con esta entrada
- <número y nombre de SC> - requiere <HTML / URL / prueba de teclado / captura de pantalla de estado de foco>

## Nota de alcance
Esta es una revisión de experto contra WCAG 2.2, no un sustituto de pruebas con personas que usan tecnología de asistencia, ni una certificación legal de cumplimiento ADA o Sección 508.

Omite una sección de severidad por completo cuando no tenga hallazgos; no la rellenes con frases como "no se encontraron problemas" bajo un encabezado que implica que existen problemas. Incluye siempre "No verificable con esta entrada" cuando la entrada sea una captura de pantalla; cuando la auditoría cubrió HTML/JSX/URL de principio a fin, escribe "Ninguno - el marcado completo estaba disponible" en lugar de omitir la sección. Incluye siempre la nota de alcance.

Casos límite

  • Múltiples pantallas o estados en una sola captura de pantalla - audita cada una bajo su propio subtítulo ## dentro del mismo informe, en lugar de fusionar hallazgos entre pantallas.
  • Texto sobre una foto, gradiente o fondo de video - no estimes un aprobado. Reporta un hallazgo P1 por contraste indeterminado y recomienda probar la región de píxeles del peor caso contra el color del texto.
  • Un componente sin contenido visible (estado vacío, esqueleto de carga) - anótalo y pregunta si hay un estado poblado disponible, ya que varios criterios (encabezados, etiquetas, propósito del enlace) no pueden juzgarse desde un caparazón vacío.
  • HTML/JSX con estilos en línea o variables CSS sin resolver - trata el contraste y el tamaño del objetivo como no verificables en lugar de adivinar valores calculados.
  • Una solicitud de "verificación rápida" o "solo las grandes" - ejecuta igualmente la lista completa de criterios, pero reporta solo P0, y anota en la línea de alcance que P1/P2 fueron verificados pero suprimidos de la salida.
  • Una segunda auditoría de la misma pantalla después de correcciones - repite el proceso completo; no asumas que los hallazgos anteriores aún son válidos.

Modos de fallo a evitar

  • No inventes una relación de contraste que no hayas calculado a partir de colores reales.
  • No marques un criterio como "aprobado" porque nada parecía obviamente incorrecto - si no se verificó, es "no verificable", no un aprobado.
  • No cites un criterio de éxito de WCAG que no hayas verificado realmente.
  • No suavices un hallazgo P0 a P1 para que el informe se lea mejor.

Skills relacionados