Descripción de la imagen: una pila de notas adhesivas rojas en una pared de cristal de oficina, con la de arriba marcada «DEUDA» en rotulador grueso y un tablero kanban difuminado al fondo — el marcador visual de la contabilidad de deuda de accesibilidad en una organización de ingeniería.

Tiempo de lectura: 11 minutos

Toda organización de ingeniería que haya superado sus primeros dieciocho meses mantiene un registro —formal o informal— de deuda técnica. La forma es familiar: una etiqueta en Jira, una hoja de cálculo, una revisión trimestral con un VP de ingeniería, una columna de gravedad, una columna de probabilidad y una llamada de triaje que decide qué se amortiza este trimestre y qué se aplaza. La contabilidad es aproximada, pero es real: el liderazgo sabe más o menos cuánta deuda acumula la base de código, dónde se concentra y cuánto cuesta ignorarla un trimestre más. La deuda de accesibilidad —el conjunto acumulado de fallos WCAG, implementaciones incorrectas de ARIA, trampas de teclado, etiquetas ausentes, déficits de contraste, regresiones de orden de foco y componentes inaccesibles desplegados en producción— es, en todo sentido significativo, deuda técnica. Se documenta en informes de auditoría del mismo modo en que la deuda de errores se documenta en herramientas de monitorización de errores. Se acumula de la misma manera: cada nueva funcionalidad construida sobre un componente inaccesible multiplica el coste de remediación. Genera intereses en forma de exposición a demandas colectivas, multas regulatorias y usuarios perdidos. Y, sin embargo, la mayoría de las organizaciones de ingeniería la registran en un libro contable paralelo que nunca llega a la revisión de deuda técnica.

Este ensayo propone incorporar la deuda de accesibilidad a la contabilidad de deuda de ingeniería que ya existe. Tres instrumentos concretos realizan el trabajo: una puntuación de gravedad inspirada en CVSS que combina la gravedad de las reglas de axe con la tasa de visitas al componente y un nivel de impacto en el usuario; un estimador de costes de remediación construido a partir de líneas de código modificadas y cobertura de archivos; y una vista de cartera que permite a un VP de ingeniería ver la deuda por componente y la deuda por pilar WCAG en el mismo cuadro de mando que ya muestra su backlog de errores P1. El argumento no es que la accesibilidad pertenezca a ingeniería en lugar de a diseño o producto —vive en los tres—. El argumento es que los líderes de ingeniería ya disponen de un marco de triaje competente para los riesgos que se acumulan en silencio, y la decisión correcta es someter la accesibilidad a ese marco en lugar de inventar uno paralelo que compita por atención.

El marco contable

Tómese como modelo el libro mayor de deuda técnica que una organización de ingeniería ya mantiene. En un libro sano, cada elemento de deuda lleva cinco atributos: un componente (dónde vive en la base de código), una puntuación de gravedad (cuán grave es la consecuencia si se explota o se alcanza), una señal de probabilidad (con qué frecuencia se toca realmente la superficie afectada en producción), un coste estimado de remediación (días de ingeniero, líneas de código, archivos implicados) y un compartimento de cartera (deuda de seguridad, deuda de rendimiento, deuda de dependencias, deuda de pruebas). El libro se revisa trimestralmente. Un gráfico de agotamiento rastrea la deuda total a lo largo del tiempo. Una pequeña fracción de la capacidad del equipo de ingeniería —típicamente entre el 10 y el 20 por ciento según la madurez de la organización— se reserva para amortizarla.

Los hallazgos de accesibilidad, tal como salen de una auditoría, no encajan de forma natural en ninguna de esas columnas. Un informe de auditoría típico enumera las violaciones por criterio de éxito WCAG («1.1.1 Contenido no textual: alt ausente»), la gravedad según la clasificación de axe-core o WAVE («crítico / serio / moderado / menor») y una referencia de página o captura de pantalla. No indica en qué componente vive la violación. No dice con qué frecuencia se visita realmente la página afectada. No estima el coste de remediación. Y no agrupa por nada más que el pilar WCAG, que es una taxonomía diseñada para informes de cumplimiento, no para el triaje de ingeniería. El primer trabajo del marco es traducir los hallazgos de auditoría a la misma forma de cinco columnas que usa el resto del libro mayor de deuda, para que la misma reunión de revisión pueda hablar de ambos.

Gravedad multiplicada por probabilidad

El Common Vulnerability Scoring System (CVSS), la puntuación de gravedad estándar del sector para vulnerabilidades de seguridad, se construye a partir de tres grupos de métricas: base (propiedades intrínsecas del fallo), temporal (estado de explotación y disponibilidad de parches) y ambiental (relevancia para el despliegue específico). La puntuación base combina una subpuntuación de explotabilidad con una subpuntuación de impacto y produce un número del 0 al 10. Las puntuaciones temporal y ambiental ajustan la base al contexto específico de la organización. Todo el aparato está diseñado para que un hallazgo genérico —«CVE-2024-XXXX, puntuación base 7,4»— pueda recalcularse localmente por un defensor que conoce lo que su propio despliegue realmente expone.

Una puntuación de gravedad de accesibilidad modelada sobre CVSS llevaría las mismas tres capas. La capa base es la calificación de gravedad de axe-core o Lighthouse para la regla que se violó: una violación «seria» en la regla «button-name» lleva una puntuación base en el rango de 7 a 8; una violación «moderada» en «landmark-one-main» lleva algo en el rango de 4 a 5. La capa base es la misma con independencia de si la violación está en una página de destino de marketing o en un flujo de pago. La capa ambiental aplica un multiplicador por la tasa de visitas al componente: una violación en la página de pago (que el 100 por ciento de los usuarios de pago alcanzan) recibe un multiplicador de 1,0; una violación en un artículo de centro de ayuda que visita el 4 por ciento de los usuarios recibe un multiplicador de 0,04. El multiplicador de tasa de visitas convierte un hallazgo genérico en uno escalado al tráfico real de la organización. La capa de impacto en el usuario aplica un multiplicador de nivel según qué usuarios de tecnología de apoyo quedan bloqueados: un atributo alt ausente en una imagen decorativa no bloquea a nadie (nivel 0); una etiqueta ausente en un campo de búsqueda bloquea a todos los usuarios de lector de pantalla (nivel 1); una trampa de teclado bloquea a todos los usuarios de solo teclado, incluidas personas que usan entrada de conmutador y control por voz (nivel 2 — el mayor radio de explosión).

La puntuación de gravedad combinada es el producto: base × tasa de visitas × nivel de impacto, normalizado a una escala de 0 a 10. El resultado es que un hallazgo axe «serio» (base 7) en una página de pago (tasa de visitas 1,0) que bloquea a todos los usuarios de lector de pantalla (nivel 1) puntúa aproximadamente 7,0 — un P1. El mismo hallazgo «serio» en una página de administración obsoleta (tasa de visitas 0,005) que bloquea al mismo público puntúa alrededor de 0,04 — un elemento de backlog. Un hallazgo axe «moderado» (base 4) en el hero de la página principal (tasa de visitas 0,9) que bloquea a todos los usuarios de teclado (nivel 2) puntúa alrededor de 7,2 — también un P1. La puntuación captura la intuición de que la gravedad sola no es suficiente: una violación grave en una página que nadie visita es menos urgente que una violación moderada en la página más visitada del producto. CVSS hizo el mismo movimiento para la seguridad hace una década. La accesibilidad merece el mismo tratamiento.

El estimador de costes de remediación

La otra mitad de la decisión de triaje es el coste. Una puntuación de gravedad P1 que cuesta 200 días de ingeniero remediarse se prioriza de forma diferente a una puntuación de gravedad P1 que cuesta 0,5 días de ingeniero. Los líderes de ingeniería hacen esta compensación implícitamente todo el día; el estimador de costes les da un número sobre el que debatir en lugar de una intuición. El estimador se construye a partir de dos señales disponibles en la propia base de código: líneas de código modificadas por corrección (LOC-modificadas) y cobertura de archivos — cuántos archivos cambiarían si la corrección se aplicara de forma coherente.

Una corrección de etiqueta ausente en un solo campo de entrada es un cambio de un archivo y dos líneas. Una corrección de etiqueta ausente en un componente de entrada compartido que se usa en 47 lugares sigue siendo un cambio de dos líneas en la fuente, pero la cobertura de archivos es 47, la superficie de QA son 47 pantallas y la revisión del sistema de diseño afecta a toda la biblioteca de formularios. Una corrección de trampa de teclado en un selector de fecha personalizado que solo existe en una ruta es un cambio pequeño. Una corrección de trampa de teclado en un selector de fecha personalizado que se ha copiado y pegado en las rutas de ocho equipos a lo largo de los últimos tres años es un cambio grande, porque la corrección coherente requiere o bien ocho parches paralelos o bien una consolidación en un único componente compartido primero. El estimador no necesita ser preciso. Necesita estar en el orden de magnitud correcto —un día de ingeniero, diez días de ingeniero, cincuenta días de ingeniero, doscientos días de ingeniero— para que la llamada de triaje pueda comparar dos remediaciones con formas diferentes.

Una heurística útil que el marco toma prestada de la estimación de costes de refactorización: el coste crece linealmente con las LOC-modificadas hasta aproximadamente 50 líneas y aproximadamente con la raíz cuadrada de la cobertura de archivos más allá de unos 5 archivos. Un cambio que afecta a 5 líneas en 1 archivo equivale a un día de ingeniero; la misma corrección replicada en 25 archivos equivale a aproximadamente cinco días de ingeniero, no veinticinco, porque las aplicaciones segunda a vigesimoquinta amortizan el diagnóstico y los costes de revisión. La escala de raíz cuadrada importa: es la razón por la que una corrección a nivel de sistema de diseño es mucho más barata por sitio de llamada que un parche por equipo, y es el argumento económico central para amortizar la deuda de accesibilidad a nivel de componente en lugar de a nivel de página.

La vista de cartera

Una vez que cada hallazgo de accesibilidad tiene una puntuación de gravedad y una estimación de costes, la organización de ingeniería dispone de una cartera —exactamente análoga a la cartera de vulnerabilidades de seguridad o la cartera de regresiones de rendimiento que ya vive en el cuadro de mando de ingeniería—. La cartera se corta de dos maneras. Deuda por componente suma la gravedad de todos los hallazgos que viven en un componente React o Vue dado, poniendo de relieve los componentes que acumulan más riesgo de accesibilidad por día de ingeniero de refactorización. Deuda por pilar suma la gravedad de los cuatro pilares WCAG (Perceptible, Operable, Comprensible, Robusto), poniendo de relieve qué clase de fallo tiene un peso estructuralmente bajo en las prácticas de diseño y revisión del equipo.

El corte deuda-por-componente es el que impulsa las decisiones de inversión trimestrales. Si el 60 por ciento de la gravedad total reside en quince componentes —lo cual es típico— entonces una inversión de ingeniería trimestral de 20 días de ingeniero en esos quince componentes retira aproximadamente el 60 por ciento de la gravedad, y esa retirada se acumula en cada página que usa esos componentes. El corte deuda-por-pilar es el que impulsa las decisiones de proceso: si el 70 por ciento de la gravedad reside bajo «Operable» (fallos de teclado, foco y límite de tiempo), la revisión de diseño del equipo está dejando pasar problemas Operables y la corrección es una lista de verificación de revisión de diseño, no un sprint de remediación. Si el 70 por ciento reside bajo «Perceptible» (texto alternativo, subtítulos, contraste, características sensoriales), la brecha está en la producción de contenido y la corrección es una salvaguarda en la herramienta de autoría, no un sprint de desarrollo. La vista de cartera convierte los hallazgos de auditoría en tesis de inversión, que es la forma en que los líderes de ingeniería realmente financian el trabajo.

Tres ejemplos específicos por sector

El mismo marco contable produce una priorización materialmente diferente en distintos sectores, porque el multiplicador de tasa de visitas y el nivel de impacto en el usuario son específicos de cada sector. Tres recorridos breves ilustran el punto.

Aplicación de consumo fintech

Una fintech de consumo (banco digital, neobróker, cartera de pagos) alberga un número pequeño de flujos de tráfico extraordinariamente alto —incorporación, comprobación de saldo, transferencia, historial de transacciones— que alcanza el 95 por ciento de los usuarios activos mensuales. También alberga una larga cola de pantallas de casos límite (gestión de cuentas conjuntas, designación de beneficiarios, exportación de declaraciones fiscales) que ven menos del 1 por ciento de los usuarios. Bajo la puntuación de gravedad, el multiplicador de tasa de visitas colapsa la larga cola casi por completo: una violación grave en una exportación de declaración fiscal puntúa por debajo de 0,1 incluso con un multiplicador de impacto de usuario de nivel 1. La cartera se comprime a quizás 30 componentes que producen el 90 por ciento de la gravedad total, todos ellos en los cuatro flujos principales. Los líderes de ingeniería de fintech generalmente tienen el presupuesto para retirar esa cartera comprimida en dos trimestres de inversión concentrada, y el telón de fondo regulatorio —la Ley de IA de la UE sobre toma de decisiones automatizada, más las penalizaciones del Artículo 13 de la EAA— convierte la inversión tanto en una cobertura de riesgo como en una ventaja competitiva frente a titulares cuyos flujos aún contienen trampas de teclado.

Plataforma de aprendizaje EdTech

Una plataforma EdTech (K-12 o educación superior) tiene la forma de tráfico opuesta: una larga cola de páginas de contenido (cada lección, cada tarea, cada evaluación) donde la tasa de visitas por página individual es baja, pero la huella acumulada es enorme. El multiplicador de tasa de visitas no colapsa la cartera como lo hace en fintech. Además, conlleva una amplificación del nivel de impacto en el usuario ausente en fintech: los estudiantes con discapacidad son una población protegida por ley federal en EE. UU. bajo la Sección 504 y la IDEA, y en la UE bajo la excepción educativa de la EAA que se incorpora gradualmente hasta 2027. El resultado es que una violación moderada en una sola página de lección —tasa de visitas 0,001, nivel de impacto 1— sigue puntuando a un nivel en el que no puede simplemente ignorarse, porque el patrón de violación se repite en aproximadamente 8.000 lecciones. La deuda EdTech se combate mejor en la capa de la herramienta de autoría, porque una sola corrección en el componente de plantilla de lección retira la violación en cada página generada a partir de esa plantilla. El corte deuda-por-componente casi siempre apunta a tres o cuatro componentes de plantilla que anclan toda la biblioteca de contenido.

Plataforma SaaS B2B

Una plataforma SaaS B2B (CRM, ERP, RR. HH., herramienta de desarrollo, observabilidad) tiene una tercera forma: interfaces de cuadrícula de datos de alta densidad, pantallas de administración de larga cola y flujos de configuración de integración que visita un número pequeño de usuarios de forma repetida. La tasa de visitas por página puede ser engañosa; el denominador correcto es el tiempo de sesión, no las visitas únicas, porque un usuario experto pasa seis horas al día dentro de la cuadrícula de datos. Con una tasa de visitas ajustada al tiempo de sesión, la cuadrícula de datos puntúa mucho más alto que las pantallas de estilo marketing, incluso cuando menos del 10 por ciento de los asientos la tocan. El nivel de impacto en el usuario también se amplifica: la contratación empresarial lleva cada vez más un requisito de RFP consciente de la accesibilidad, lo que significa que una sola violación de nivel 1 en la cuadrícula de datos puede hacer perder un contrato de seis cifras en la fase de cuestionario de contratación. Los líderes de ingeniería SaaS generalmente concluyen que la estrategia de amortización correcta es componente a componente dentro de la biblioteca de cuadrícula de datos, con cada versión publicada de la biblioteca que lleva una reducción de gravedad medible que el equipo de contratación puede citar en el próximo RFP.

Un cuadro de mando trimestral de ejemplo

Las organizaciones de ingeniería que realizan un seguimiento serio de la deuda técnica publican un gráfico de agotamiento trimestral en la presentación general de ingeniería: deuda total al inicio del trimestre, deuda retirada durante el trimestre, deuda añadida durante el trimestre (nuevos hallazgos de auditorías, nuevas violaciones introducidas por nuevas funcionalidades), deuda al final del trimestre. El cuadro de mando de deuda de accesibilidad lo replica exactamente. La métrica principal es la gravedad total ponderada — la suma de base × tasa de visitas × nivel de impacto en cada hallazgo abierto, en una escala normalizada de 0 a 10 agregada hasta un único número de cartera. Una métrica secundaria útil es la gravedad por mil páginas vistas, que controla el crecimiento del producto: un cuadro de mando que muestra la gravedad ponderada cayendo mientras las páginas vistas crecen es una señal de que el equipo está amortizando la deuda más rápido de lo que se introduce.

Los demás paneles del cuadro de mando se derivan directamente de los cortes de cartera. Los 10 principales componentes por deuda, con la gravedad actual y la estimación en días de ingeniero, más una anotación de «corregido este trimestre» en los componentes que abandonaron la lista. Deuda por pilar WCAG, como barra apilada que muestra la mezcla Perceptible/Operable/Comprensible/Robusto y cómo ha cambiado a lo largo de los últimos cuatro trimestres. Deuda añadida este trimestre, desglosada según si la adición provino de un nuevo hallazgo de auditoría (deuda latente existente que se descubrió) o de una nueva violación introducida en una funcionalidad desplegada durante el trimestre — ese segundo número es el que indica al liderazgo si la revisión de diseño del equipo y las herramientas de desplazamiento a la izquierda están funcionando. Previsión de agotamiento, que proyecta la velocidad del trimestre actual hacia adelante para estimar cuándo la gravedad total alcanza un umbral objetivo (típicamente la puntuación en la que los mayores riesgos de cumplimiento abiertos se mitigan y la próxima ronda de cuestionarios de contratación puede responderse sin caveat).

El cuadro de mando es conscientemente aburrido. Se parece a todos los demás cuadros de mando de ingeniería que un VP de ingeniería ya lee — mismos ejes, mismas convenciones, mismo ritmo trimestral. Ese es el punto. La deuda de accesibilidad ha vivido históricamente fuera del cuadro de mando de ingeniería porque carecía de una representación que los líderes de ingeniería pudieran leer de un vistazo. Al ponerla en el mismo cuadro de mando, con la misma forma, con la misma lógica de gravedad por probabilidad que el resto de la función de ingeniería ya usa, se elimina el coste cognitivo de tratar la accesibilidad como un caso especial. Se convierte en una categoría más de riesgo de ingeniería que se mide, se compensa y se agota según un calendario — que es lo que siempre ha sido.

Reflexiones finales

El marco anterior no cambia qué se considera un fallo de accesibilidad. WCAG lo define. No cambia qué usuarios se ven afectados ni qué exige la ley. El mapa regulatorio ya lo define. Lo que cambia es la forma de la información transmitida de los auditores a los líderes de ingeniería. Los hallazgos de accesibilidad que llegan como informes de auditoría en PDF se reencuadran como tickets de Jira con puntuaciones de gravedad, estimaciones de costes y etiquetas de componentes — la misma forma en que llega cualquier otro riesgo de ingeniería. El triaje se vuelve posible. El agotamiento se vuelve medible. La inversión trimestral se convierte en un número que el VP de ingeniería puede defender en la conversación de presupuesto.

También hay un efecto más suave. Los equipos de ingeniería son buenos manteniendo lo que pueden medir y malos manteniendo lo que no pueden. La accesibilidad ha pasado dos décadas sentada justo fuera del límite de medición — descrita en lenguaje WCAG, auditada en lenguaje de cumplimiento, pero nunca integrada en el lenguaje de deuda de ingeniería que impulsa las decisiones trimestrales. El coste de esa exclusión es visible en cada informe de auditoría que aterriza en el escritorio de un director y produce un único sprint general frenético de remediación seguido de otros doce meses de regresión. La solución no son más auditorías. La solución es poner la accesibilidad en el mismo libro contable que el resto del trabajo de ingeniería, con la misma matemática de gravedad, el mismo estimador de costes y el mismo ritmo trimestral. Los líderes de ingeniería que hacen esto dejan de sorprenderse con la próxima auditoría. La auditoría se convierte en la confirmación de lo que el cuadro de mando ya mostraba.