La accesibilidad dentro del sprint: refinamiento, revisión de código y deuda

En la lección «Shift-left» viste cómo escribir criterios de aceptación y una definición de hecho con accesibilidad, y en la de design systems, cómo conseguir componentes accesibles por defecto. Son necesarios, pero no bastan: un equipo puede tener una definición de hecho impecable y un buen sistema de diseño y seguir produciendo barreras si la accesibilidad no aparece en las conversaciones del día a día. Esta lección recorre las ceremonias de un equipo ágil (refinamiento, estimación, desarrollo con revisión de código, demostración y retrospectiva) y explica cómo gestionar la deuda de accesibilidad, es decir, las barreras conocidas que el producto arrastra.

Refinamiento: tres preguntas por historia

El refinamiento del backlog es el momento más barato para detectar riesgos. Basta con que alguien del equipo haga tres preguntas a cada historia antes de darla por lista para entrar en un sprint:

1. ¿Qué componentes usa? Si todo sale del design system, el riesgo es bajo. Si la historia necesita un componente nuevo o una variante, hay que decidir si se incorpora al sistema, con su revisión, o si es un caso puntual, y localizar el patrón APG (se abre en una ventana nueva) que le corresponde.
2. ¿Toca un flujo crítico? Acceso, registro, compra, pago, firma o cualquier trámite completo. Si la respuesta es sí, la historia necesita criterios de aceptación de accesibilidad específicos y prueba obligatoria con lector de pantalla.
3. ¿Introduce contenido o un tercero? Imágenes, vídeo, documentos descargables, un widget externo. Cada uno arrastra requisitos (texto alternativo, subtítulos, PDF etiquetado, evaluación del proveedor) que alguien debe tener asignados con nombre.

Cuando un componente es complejo y nadie en el equipo lo ha construido antes (un selector de fechas, un mapa interactivo, un editor de texto enriquecido), crea una spike: una tarea corta de investigación, con tiempo limitado, para prototipar la interacción con teclado y lector de pantalla antes de estimar la historia real.

Estimar con la accesibilidad dentro

La accesibilidad forma parte del trabajo de la historia, no es un trabajo adicional. Si el equipo estima con puntos de historia o con horas, la estimación incluye los estados de foco, la gestión del foco, los mensajes de error y las pruebas manuales. Con un design system maduro, ese coste es pequeño porque la mayor parte ya está resuelta en los componentes; sin él, es simplemente el coste real de hacer bien el trabajo.

Durante el desarrollo: revisión de código con lista fija

La revisión de código (code review) es la última oportunidad de detectar un problema antes de que entre en la rama principal. Incluye un bloque de accesibilidad en la plantilla de los pull requests (las solicitudes para integrar cambios en el código común) para que quien programa lo marque y quien revisa lo compruebe:

## Accesibilidad
- [ ] Usa componentes del design system (si crea uno nuevo, enlaza su patrón APG)
- [ ] Elementos nativos para acciones y enlaces; nada de div o span con onclick
- [ ] Probado solo con teclado: orden lógico, foco visible, sin trampas
- [ ] Nombres accesibles revisados en el árbol de accesibilidad del navegador
- [ ] axe sin violaciones en los estados nuevos (abierto, con error, vacío)
- [ ] Probado con lector de pantalla si añade una interacción nueva

La revisión no consiste solo en leer el código: la persona revisora abre el entorno de previsualización y recorre el cambio con el teclado. Dos minutos que detectan lo que el linter no ve. Este es un hallazgo típico en la revisión de los filtros de búsqueda de una tienda en línea:

<!-- Incorrecto: no es enfocable y no expone rol ni estado -->
<span class="filtro" onclick="alternar(this)">Envío gratis</span>

<!-- Correcto: botón nativo con su estado expuesto -->
<button type="button" class="filtro" aria-pressed="false">Envío gratis</button>

En la versión correcta, el script solo tiene que cambiar aria-pressed entre true y false al pulsar. El botón ya es enfocable, se activa con Enter y con Espacio, y el lector de pantalla lo anuncia como un botón de alternancia pulsado o no pulsado, con la fórmula que use cada lector (2.1.1 Teclado, 4.1.2 Nombre, función, valor).

Otra práctica eficaz es la programación en pareja: una persona con experiencia en accesibilidad trabaja junto a otra que no la tiene en la primera historia que toca un componente complejo. Es la forma más rápida de que el conocimiento deje de depender de una sola persona.

Demostración y retrospectiva

En la revisión del sprint, la demostración ante las partes interesadas, enseña al menos una funcionalidad nueva usando solo el teclado y, de vez en cuando, con lector de pantalla. Verifica en directo que funciona y normaliza ante dirección y negocio que la accesibilidad es parte de lo que se entrega. En la retrospectiva, añade una pregunta fija: ¿se ha escapado algún defecto de accesibilidad este sprint y en qué ceremonia debió detectarse? La lección «Operación» amplía esta idea a las incidencias de producción.

Si el equipo trabaja con Kanban en lugar de sprints, las mismas comprobaciones se convierten en políticas explícitas de las columnas del tablero: una tarjeta no pasa de «En diseño» a «Lista para desarrollo» sin revisión de diseño, ni de «En revisión» a «Hecho» sin el bloque de accesibilidad completado.

Deuda de accesibilidad: hacerla visible y pagarla

La deuda de accesibilidad es el conjunto de barreras conocidas que el producto mantiene: hallazgos de auditorías sin corregir, excepciones aprobadas en un lanzamiento, defectos heredados de componentes de terceros y atajos tomados con prisa. Como la deuda técnica, genera intereses: cada pantalla nueva que copia un patrón defectuoso multiplica el coste de corregirlo, y cada mes que pasa aumenta la probabilidad de una reclamación.

Registro de deuda

La deuda que no está escrita no existe para quien prioriza. Mantén un registro único, en el mismo gestor de incidencias y con una etiqueta propia, con estos campos:

Priorizar y reservar capacidad

Prioriza combinando impacto (la severidad), alcance (un defecto en un componente compartido o en un flujo crítico pesa más) y esfuerzo. Los defectos en componentes compartidos suelen ser los más rentables, porque una sola corrección resuelve todas sus apariciones. Para que la deuda baje de verdad, reserva una parte fija de la capacidad de cada sprint para pagarla y acuerda esa reserva de antemano con la persona responsable de producto: lo que se negocia sprint a sprint acaba perdiendo frente a la siguiente novedad.

Resumen

• En el refinamiento, tres preguntas por historia (componentes, flujo crítico, contenido o terceros) detectan los riesgos de accesibilidad; los componentes complejos merecen una spike previa.
• La accesibilidad se estima dentro de cada historia; las historias separadas «para hacerlo accesible» se aplazan y dejan que el defecto se copie.
• La plantilla de pull request incluye un bloque de accesibilidad, y la revisión de código incluye recorrer el cambio con el teclado.
• La demostración con teclado y la pregunta fija en la retrospectiva hacen visible la accesibilidad en cada sprint; en Kanban, se convierten en políticas de columna.
• La deuda de accesibilidad se registra con impacto, alcance y alternativa, se prioriza empezando por los componentes compartidos y se paga con una reserva fija de capacidad.