Declaración de accesibilidad de kadabra.net
Este sitio se construyó apuntando a WCAG 2.1 nivel AA. Acá está el estado real, lo que sabemos que todavía no cumple y cómo reportarnos una barrera.
Ruta de navegación
Declaración de accesibilidad
Reportar una barrera
Estado de conformidad
Estado: parcialmente conforme con WCAG 2.1 nivel AA. Parcialmente conforme quiere decir que la mayor parte del sitio cumple el estándar, que hay partes que todavía no, y que esas partes están enumeradas más abajo con nombre y apellido.Fecha de esta declaración: 30 de agosto de 2026. Última revisión: 30 de agosto de 2026. Método de evaluación: autoevaluación interna del equipo de Kadabra.No vamos a escribir «totalmente conforme» hasta que haya una auditoría hecha y fechada. Declarar conformidad total y que alguien se choque con una barrera a los cinco minutos es peor que no declarar nada, y más todavía en una consultora que vende accesibilidad.
Qué medimos, y qué nos obligó a cambiar
Calculamos el contraste de cada combinación de colores de nuestra marca antes de usarla. Publicamos las filas que fallan tal cual salieron:
Mediciones de contraste de la paleta
Veredicto y uso
Verde mint sobre blanco
1.9 a 1
No llega. Prohibido como texto en todo el sitio.
Blanco sobre verde mint
No llega.
Blanco sobre el turquesa del gradiente de marca
1.8 a 1
Por eso el gradiente puro es decorativo y nunca lleva texto.
Azul de marca sobre blanco
4.07 a 1
Solo sirve para titulares grandes. Para enlaces y texto chico usamos un azul un paso más oscuro, que da 4.78 a 1.
Verde mint sobre navy
7.8 a 1
Pasa con holgura, y por eso el verde solo aparece sobre fondo oscuro.
Blanco sobre navy
14.7 a 1
Pasa con amplio margen.
Además: el velo sobre las fotos de las cabeceras usa un modo de mezcla que nunca aclara el fondo, así que el texto blanco mantiene al menos 4.9 a 1 sobre cualquier fotografía. Todos los elementos interactivos tienen foco visible. Las transiciones respetan la preferencia de movimiento reducido del sistema operativo.
El detalle, sin maquillaje
Detalle de la evaluación de accesibilidad de kadabra.net
Qué evaluamos y con qué
La revisión combina dos cosas, porque ninguna alcanza sola.Revisión manual con teclado. Recorremos cada página con la tecla de tabulación, sin mouse: orden de foco, foco visible, trampas de teclado, jerarquía de encabezados, textos alternativos y etiquetas de formulario.Herramientas automatizadas. Detectan contraste insuficiente, atributos faltantes y errores de marcado. Cubren aproximadamente un tercio de los criterios de WCAG; el resto solo se ve a mano. Cuando alguien dice que su sitio «pasó la herramienta», está hablando de ese tercio.La herramienta automatizada es axe-core (versión 4.13.0), corrida contra un Chromium real controlado por Playwright (versión 1.50.0). Todavía no hicimos una prueba dedicada con lector de pantalla.
Limitaciones conocidas de este sitio
Estas son las que ya conocemos y están documentadas. No es una lista cerrada.El contenido se arma en el navegador. Las páginas se construyen con componentes que se renderizan del lado del cliente. Con JavaScript deshabilitado o bloqueado por política del organismo, no hay contenido para leer.Las tipografías de marca todavía no están autoalojadas. Hasta que lo estén, dependen de un servicio externo y puede haber un salto visual mientras la fuente llega. Los textos usan una tipografía de sistema como respaldo, así que el contenido se lee igual.Hay combinaciones del brandbook que no llegan a AA. Están medidas, publicadas más arriba y prohibidas en el sistema de diseño, así que no aparecen en el sitio. Lo que sigue pendiente es corregirlas en los materiales impresos y en las presentaciones.Primera revisión automatizada completa: 30 de agosto de 2026, axe-core sobre las 66 páginas del sitio, contra las reglas WCAG 2.0 A/AA, 2.1 AA y 2.2 AA. Resultado: cero violaciones firmes. Nota de método: en algunas corridas, axe reportó una falsa violación de contraste en el botón «Preferencias» del aviso de cookies; medido a mano, el motivo es que ese aviso entra con una animación de aparición de 420 milisegundos y a veces la herramienta mide el color a mitad de esa animación, antes de que llegue a su opacidad final. El color final del texto sí cumple AA. Esta primera revisión no incluyó documentos PDF, vídeo de terceros ni componentes de proveedores externos porque el sitio todavía no publica ninguno de los tres.
Tecnología de la que depende el sitio
Este sitio depende de HTML, CSS y JavaScript. Sus componentes se escriben en React y TypeScript. La accesibilidad se apoya en HTML semántico y en los atributos de accesibilidad estándar del navegador; no usamos widgets propietarios ni marcos de terceros para la navegación.
Norma de referencia
Apuntamos a WCAG 2.1 nivel AA: es el nivel que suelen exigir los pliegos del Estado uruguayo. Los componentes que construimos para clientes sostienen el mismo estándar, no como extra sino como requisito de entrega.En Uruguay rige además el Decreto N.º 406/022 (22 de diciembre de 2022), reglamentario del artículo 88 de la Ley N.º 19.924, que exige accesibilidad digital basada en WCAG a los organismos del Estado, los Gobiernos Departamentales, los Entes Autónomos, los Servicios Descentralizados y las personas de derecho público no estatal. Hoy alcanza al sector público, no a Kadabra como empresa privada —el propio decreto habilita al Poder Ejecutivo a extenderlo a sectores privados puntuales, pero todavía no lo hizo con el nuestro—. Lo sostenemos igual, sin estar obligados, porque es el estándar que ya les exigimos a los organismos públicos con los que trabajamos.
Cómo reportarnos una barrera
Si encontrás algo que no podés usar, escribinos a hello@kadabrait.net y contanos tres cosas: en qué página fue, qué estabas intentando hacer y con qué tecnología de apoyo (lector de pantalla, ampliador, navegación por teclado o por voz).Respondemos en 10 días hábiles. Si la barrera es nuestra, en esa misma respuesta te damos una fecha de corrección. Si no la podemos corregir, te decimos por qué y cómo llegar a esa información por otra vía.
Agendá 30 minutos