Lección 2 de 10 · 14 min de lectura · Revisado el 26/10/2026
El ciclo de vida accesible: fases, responsables y puertas de calidad
Las lecciones de este curso recorren el producto digital fase a fase: requisitos y diseño, componentes, trabajo diario del equipo, pruebas, lanzamiento, operación y evolución. Antes de entrar en cada una conviene tener el mapa completo. En esta lección verás qué pregunta de accesibilidad se responde en cada fase, qué entregable la deja por escrito, quién es responsable y qué puertas de calidad (quality gates, controles que hay que superar para pasar a la fase siguiente) impiden que un problema avance sin que nadie lo vea.
De la auditoría puntual al ciclo de vida
Muchas organizaciones gestionan la accesibilidad como un acontecimiento: se encarga una auditoría, llega un informe con cien hallazgos, se corrige una parte y, un año después, la siguiente auditoría encuentra otros cien. El problema no es la auditoría, que estudiaste a fondo en el nivel 4, sino que actúa sobre el resultado y no sobre el proceso que lo produce. Cada versión nueva vuelve a fabricar los mismos fallos porque nada ha cambiado en cómo se pide, se diseña, se construye y se publica.
Gestionar la accesibilidad en el ciclo de vida significa tratarla como una propiedad de calidad, igual que la seguridad o el rendimiento, con actividades, responsables y controles en cada fase. En el nivel 5 viste los roles de la organización y en el curso anterior, la estrategia; aquí bajamos al equipo de producto: qué hace cada persona, en cada fase, en un producto concreto.
Seis fases, seis preguntas
Cada organización nombra sus fases a su manera, pero casi todas pueden agruparse en seis:
| Fase | Pregunta de accesibilidad | Entregable | Responsable principal |
|---|---|---|---|
| 1. Descubrir y definir | ¿Quién lo usará, con qué tecnologías de apoyo y bajo qué obligaciones legales? | Ficha de contexto y cláusula de accesibilidad | Producto |
| 2. Diseñar | ¿Se puede percibir, entender y operar la interfaz tal como está dibujada? | Diseños anotados y revisados | Diseño (experiencia de usuario y visual) |
| 3. Construir | ¿El código expone semántica, teclado y estados correctos? | Componentes del design system y código revisado | Desarrollo |
| 4. Verificar | ¿Funciona de verdad con teclado, lector de pantalla y zoom? | Resultados de pruebas automáticas y manuales | QA |
| 5. Lanzar | ¿Podemos publicar y qué declaramos? | Decisión de salida, excepciones y documentación de conformidad | Producto, con QA y accesibilidad |
| 6. Operar y evolucionar | ¿Se mantiene la accesibilidad con contenido nuevo, terceros y cambios? | Monitorización, registro de incidencias y plan de evolución | Operaciones y producto |
Las lecciones siguientes desarrollan cada fila: requisitos y diseño en «Shift-left»; la construcción en «Design systems accesibles» y «La accesibilidad dentro del sprint»; la verificación en «QA y automatización»; el lanzamiento en su propia lección; y la operación y la evolución en «Operación» y «Productos existentes». Lo aprendido en la fase 6 vuelve a la fase 1 de la versión siguiente.
Infografía · Ciclo
Seis fases del ciclo de vida accesible
Cada fase responde a una pregunta de accesibilidad y termina en una puerta de calidad
- Fase 1: Descubrir y definirMarco legal, personas usuarias, plataformas y terceros
- Fase 2: DiseñarDiseños anotados con todos sus estados y revisados
- Fase 3: ConstruirComponentes del design system y revisión de código
- Fase 4: VerificarPruebas automáticas y manuales con tecnologías de apoyo
- Fase 5: LanzarCriterios de salida, excepciones y documentación
- Fase 6: Operar y evolucionarMonitorizar, atender incidencias y aprender para la versión siguiente
Tras la fase 6, el ciclo vuelve a empezar por la fase 1.
Leer la infografía como texto
Ciclo de seis fases que se repite en cada versión del producto. Fase 1, descubrir y definir: marco legal, personas usuarias, plataformas, tecnologías de apoyo y terceros. Fase 2, diseñar: diseños anotados con todos sus estados y revisados con una lista fija. Fase 3, construir: componentes del design system y revisión de código con un bloque de accesibilidad. Fase 4, verificar: pruebas automáticas en el pipeline y pruebas manuales con tecnologías de apoyo. Fase 5, lanzar: criterios de salida, excepciones documentadas y documentación de conformidad. Fase 6, operar y evolucionar: monitorización, gestión de incidencias y aprendizaje que vuelve a la fase 1 de la versión siguiente. Entre cada fase y la siguiente hay una puerta de calidad con criterio, evidencia, persona que decide y consecuencia si no se cumple.
La fase olvidada: descubrir y definir
Es la fase que menos se mira y la que más condiciona el resto. Antes de la primera historia de usuario, el equipo responde cuatro preguntas en una ficha de contexto:
- Marco legal. ¿Es un servicio del sector público, sujeto al RD 1112/2018 (PDF, se abre en una ventana nueva) con la EN 301 549 (PDF, se abre en una ventana nueva) como referencia técnica? ¿Es un servicio cubierto por la Ley 11/2023 (PDF, se abre en una ventana nueva), como el comercio electrónico, los servicios bancarios para consumidores, los servicios de transporte de viajeros o los libros electrónicos? ¿Se venderá a administraciones que exigirán la EN 301 549 en sus pliegos? La respuesta fija el nivel exigido, los plazos y la documentación que habrá que producir al lanzar.
- Personas usuarias. ¿Qué perfiles lo usarán y en qué contextos? Un trámite para personas mayores y una app de transporte que se usa de pie en un andén plantean necesidades distintas. Es el momento de planificar la investigación con personas usuarias con discapacidad del curso N7-C4.
- Plataformas y tecnologías de apoyo. Navegadores, sistemas operativos, app nativa o híbrida, y la matriz de tecnologías de apoyo con la que se probará: por ejemplo, NVDA con Chrome y Firefox, JAWS si hay usuarios corporativos, VoiceOver en macOS e iOS, TalkBack en Android, zoom y texto grande del sistema.
- Dependencias de terceros. Pasarela de pago, firma electrónica, mapas, chat, gestor de cookies, reproductor de vídeo. Cada una es un riesgo que conviene evaluar antes de comprometerse con ella.
Ejemplo
Una entidad financiera prepara una app para contratar depósitos. En la ficha de contexto anota: servicio bancario para consumidores, cubierto por la Ley 11/2023 desde el 28 de junio de 2025; referencia técnica WCAG 2.2 AA y capítulo 11 de la EN 301 549 para la app; matriz de pruebas con VoiceOver en iOS, TalkBack en Android, texto grande del sistema y control por voz; dependencia crítica, el módulo de verificación de identidad por vídeo de un proveedor externo. El equipo pide al proveedor un informe de conformidad y una demostración con lector de pantalla antes de firmar, descubre que la captura del documento de identidad no da instrucciones accesibles y lo resuelve en la negociación, con una cláusula y una fecha, no en producción.
Quién hace qué: responsabilidades por criterio
«La accesibilidad es cosa de todos» es cierto y, dicho así, inútil: si es de todos, nadie la tiene en su lista de tareas. El W3C publica un recurso para ello, el Accessibility Roles and Responsibilities Mapping (ARRM), que reparte las comprobaciones entre roles y distingue entre responsabilidad principal, secundaria y de contribución. La idea clave: para cada criterio, una persona responde de que se cumpla y otras contribuyen. Una asignación orientativa:
| Criterio | Responsable principal | Contribuyen |
|---|---|---|
| 1.1.1 Contenido no textual | Contenidos (redacta el texto alternativo) | Diseño (marca qué imágenes son decorativas); desarrollo (implementa el atributo) |
| 1.4.3 Contraste (mínimo) | Diseño visual (define los pares de color) | Design system (tokens); desarrollo (aplica los tokens) |
| 2.4.3 Orden del foco | Desarrollo | Diseño de interacción (anota el orden previsto) |
| 3.3.1 Identificación de errores | Diseño de interacción y contenidos (dónde aparece el error y qué dice) | Desarrollo (asociación con el campo y anuncio) |
| 4.1.2 Nombre, función, valor | Desarrollo | Design system (componentes que obligan a pasar el nombre) |
Error frecuente
Concentrar la accesibilidad en una sola persona experta que lo revisa todo. En pocos meses es un cuello de botella, el equipo deja de aprender porque «ya lo mirará ella» y, cuando esa persona se va, el conocimiento se va con ella. La persona experta debe diseñar el proceso, formar y resolver los casos difíciles, no ser la única que comprueba.
Puertas de calidad entre fases
Una puerta de calidad es un control explícito en la transición entre dos fases. Cada puerta necesita cuatro elementos: un criterio verificable, la evidencia que lo demuestra, la persona que decide y lo que ocurre si no se cumple.
| Puerta | Criterio | Evidencia | Si no se cumple |
|---|---|---|---|
| Diseño → desarrollo | Pantallas revisadas con la lista de 12 puntos y anotadas con todos sus estados | Lista de revisión completada en el archivo de diseño | La historia vuelve a diseño y no entra en el sprint |
| Desarrollo → QA | Pipeline de accesibilidad en verde y prueba de teclado de quien programa | Informe de axe del pull request y casilla de la plantilla marcada | El cambio no se integra en la rama principal |
| QA → lanzamiento | Criterios de salida cumplidos y pruebas manuales hechas | Registro de pruebas con tecnologías de apoyo | No se lanza, o se lanza con una excepción aprobada |
| Lanzamiento → operación | Documentación de conformidad y soporte preparados | Declaración o informe actualizados; guion de soporte | Se aplaza el anuncio público |
Las puertas no deben convertirse en burocracia. Si una comprobación puede automatizarse, como el pipeline, automatízala; si exige criterio, como la revisión de diseño, que sea breve y con una lista fija. Una puerta que tarda más de lo que aporta acaba saltándose.
Punto clave
Cada fase del ciclo tiene una pregunta de accesibilidad, un entregable que la responde, una persona responsable y una puerta de salida. Si en tu organización falta alguno de esos cuatro elementos en alguna fase, es por ahí por donde se escapan los defectos.
Pruébalo tú
Piensa en un producto en el que trabajes ahora. Dibuja una tabla de seis filas, una por fase de esta lección, y tres columnas: entregable de accesibilidad que existe hoy, persona responsable y puerta de salida. Marca las celdas vacías. Suelen quedar vacías las primeras filas y la última; guarda la tabla para completarla al final del curso.
Resumen
- Auditar al final actúa sobre el resultado; integrar la accesibilidad en el ciclo de vida actúa sobre el proceso que produce los fallos.
- El ciclo se organiza en seis fases (descubrir y definir, diseñar, construir, verificar, lanzar, operar y evolucionar), cada una con su pregunta, su entregable y su responsable.
- La fase de definición fija el marco legal, las personas usuarias, la matriz de tecnologías de apoyo y los terceros críticos, y condiciona todo lo demás.
- Cada criterio tiene un responsable principal y otros que contribuyen; el ARRM del W3C ofrece un modelo para repartirlos.
- Las puertas de calidad, con criterio, evidencia, decisor y consecuencia, impiden que los defectos avancen hacia las fases más caras.
Comprueba lo que has aprendido
Esta lección se puede leer libremente. Para hacer su test de 3 preguntas, los ejercicios prácticos con páginas reales, guardar tu avance y optar al examen y al certificado, matricúlate en el curso.
Matricularme · nivel 7 (179 €)