Auditoría de accesibilidad
Saber que una página 'tiene problemas de accesibilidad' sirve de poco; saber que un botón específico no tiene nombre accesible y se ubica en un punto concreto del DOM es lo que realmente se puede corregir. Este endpoint evalúa una URL contra los criterios de éxito de WCAG y devuelve cada fallo vinculado al elemento exacto que lo causó, para que un desarrollador abra el reporte y empiece a corregir en vez de buscar.
Ejecútela online
Ejecute esto en nuestros servidores con su cuenta. Las herramientas gratuitas corren en su navegador; esta cobra de su saldo del KIT según el precio de arriba.
La distancia entre una política y una página que funciona
La mayoría de las organizaciones ya tiene una política de accesibilidad en papel; muchas menos han verificado que una página en particular realmente la cumpla. La brecha no suele ser negligencia: la revisión manual de accesibilidad es lenta y especializada, mientras que una página cambia cada vez que se edita un componente, se agrega una imagen sin texto alternativo, o un campo de formulario pierde su etiqueta durante un rediseño. web.accessibility existe para que revisar una página sea tan rápido como publicarla, de modo que la accesibilidad se verifique con la misma frecuencia que todo lo demás y no una vez al año durante una auditoría.
Qué devuelve un escaneo
Haga POST a /web/accessibility con una URL, reciba un task_id de inmediato y obtenga un reporte estructurado por webhook firmado o mediante un enlace firmado cuando la tarea asíncrona termine. Cada fallo está vinculado a un criterio de éxito de WCAG, una severidad, una descripción en lenguaje llano del problema y un selector que apunta al elemento exacto de la página responsable —una imagen sin texto alternativo, un campo de formulario sin etiqueta asociada, un texto con contraste demasiado bajo contra su fondo— de modo que la corrección queda localizada y no solo descrita en abstracto.
Qué puede detectar un escaneo automatizado y qué no
Las pruebas automatizadas de accesibilidad maduraron en la última década hasta convertirse en una primera pasada confiable para un conjunto bien definido de verificaciones —texto alternativo faltante, contraste de color, etiquetado de formularios, estructura de encabezados, uso incorrecto de ARIA— el tipo de problemas objetivamente detectables solo con el marcado. Complementa, no reemplaza, una revisión humana con tecnología asistiva, ya que algunos criterios, como si un texto alternativo realmente tiene sentido o si un flujo con teclado se siente natural, requieren un juicio que un script no puede emitir; el escaneo es la capa rápida y repetible que atrapa la mayoría verificable, para que el tiempo de revisión humana se dedique a lo que de verdad lo necesita.
Su lugar en el ciclo de entrega de software
Los equipos que tratan la accesibilidad como un requisito de construcción y no como un añadido de último momento ejecutan esto sobre las páginas nuevas antes de lanzarlas y otra vez después de rediseños importantes, ya que una página que pasó una revisión puede retroceder en silencio la próxima vez que se actualice una librería de componentes. Con precio por solicitud más por URL, escanear un lote de páginas cuesta en proporción directa a cuántas se revisen, lo que hace realista cubrir un sitio completo en vez de revisar unas pocas páginas al azar y esperar que el resto aguante.
Qué puede hacer con ella
Verificación de páginas antes del lanzamiento
Un equipo de desarrollo escanea cada página nueva antes de publicarla para detectar texto alternativo faltante, campos sin etiqueta y problemas de contraste mientras aún son baratos de corregir.
Revisión de regresiones tras un rediseño
Un equipo vuelve a escanear las páginas clave después de un rediseño visual para confirmar que la nueva librería de componentes no reintrodujo en silencio fallos que ya se habían corregido.
Diligencia debida de proveedores en compras
Una organización escanea las páginas de producto de un proveedor antes de firmar un contrato para documentar brechas de accesibilidad como parte de la revisión de compras.
Monitoreo continuo de todo el sitio
Un sitio de contenido grande programa escaneos recurrentes sobre sus páginas de mayor tráfico para detectar rápido los fallos que introducen los editores de contenido.
Preguntas frecuentes
¿Cómo audito la accesibilidad de una página con la API?
Envíe la URL de la página por POST a /web/accessibility, guarde el task_id devuelto y reciba el reporte de fallos por webhook o mediante un enlace firmado válido por 24 horas.
¿Es gratis la API de auditoría de accesibilidad?
No, no hay plan gratuito ni prueba; cuesta $0.040 por solicitud más $0.001 por URL, y una tarea fallida nunca se cobra.
¿El reporte indica qué elemento causó cada fallo?
Sí, cada fallo incluye un selector que apunta al elemento específico de la página responsable, no solo una descripción del problema.
¿Pasar este escaneo significa que una página cumple totalmente con WCAG?
Confirma que la página pasa las verificaciones detectables automáticamente; algunos criterios de WCAG requieren juicio humano y no se pueden verificar por completo solo con un escaneo automatizado.
¿Qué criterios de WCAG revisa?
El conjunto de criterios de éxito que son detectables de forma confiable solo con el marcado, como texto alternativo, contraste de color, etiquetado de formularios, estructura de encabezados y uso de ARIA; consulte la referencia del endpoint para la lista completa vigente.
¿Puedo escanear varias páginas a la vez?
Sí, tiene precio por solicitud más por URL, y puede encolar una solicitud por cada página para cubrir todo el sitio.
¿Ya está disponible este endpoint?
Sí, está en producción y aceptando solicitudes.
¿Se conservan los datos de la página escaneada después?
No, el contenido de la página y los resultados se eliminan después del período de retención y nunca se usan para entrenamiento.
Para desarrolladores — acceso por API
Todo lo de esta página está disponible por programación. Esta sección es para equipos que quieren integrarlo en sus sistemas; el resto puede usar la herramienta de arriba sin más.
Endpoint de API
¿Prefiere automatizarlo? Un POST autenticado crea la tarea; el resultado llega por webhook o enlace firmado. La misma capacidad también se ejecuta aquí en la web, y pronto desde nuestra app, el email y Telegram.
Llámela desde su stack
curl -X POST https://api.kit.forhosting.com/web/accessibility \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"url":"https://ejemplo.com"}'const res = await fetch("https://api.kit.forhosting.com/web/accessibility", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"url": "https://ejemplo.com"
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/web/accessibility",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"url": "https://ejemplo.com"
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/web/accessibility", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"url":"https://ejemplo.com"}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"url":"https://ejemplo.com"}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/web/accessibility", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)Ejemplo de solicitud
{
"url": "https://ejemplo.com"
}Ejemplo de respuesta
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "web.accessibility",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}La API es asíncrona: la llamada devuelve un task_id al instante y el resultado llega por webhook. El polling está limitado a 1 req/s por tarea.
Precio
Precio publicado — sin tokens ni créditos inventados. Una tarea fallida no se cobra.
Límites
timeout_sec | 30 |
max_crawl_pages | 25 |
Errores
| HTTP | Código | Significado |
|---|---|---|
401 | unauthorized | API key ausente o inválida. |
402 | insufficient_balance | El saldo no cubre el precio de la tarea. |
404 | unknown_type | El tipo de tarea no existe. |
429 | rate_limited | Demasiadas peticiones. Use el webhook en vez de sondear. |
422 | task_failed | La tarea falló tras 3 reintentos. No se cobra. |