Checklist de accesibilidad para un MVP

Define la frontera antes de fijar el diseño

Identifica usuarios, contextos, plataformas y recorrido completo. Incluye necesidades relacionadas con discapacidad en investigación y riesgo, no como auditoría final genérica. Elige el estándar interno aplicable y busca asesoramiento cualificado si las obligaciones dependen de jurisdicción, sector o contratación. Esta guía no es consejo legal.

No concedas al MVP una exención automática. Un producto estrecho puede usar controles semánticos, lenguaje claro, orden de foco y diseño adaptable desde la primera implementación. Detente y pide especialista en salud, seguridad, finanzas, empleo, servicio público u otro dominio relevante, o cuando el equipo no pueda interpretar el estándar para una interacción crítica.

Inventaría el recorrido y los tipos de contenido

Lista encabezados, regiones, controles, formularios, validación, tablas, medios, gráficos, gestos, arrastre, límites de tiempo, autenticación y actualizaciones dinámicas. Para cada uno registra nombre, rol, estado, instrucciones y vía equivalente si una modalidad excluye. Incluye vacío, error, carga, éxito y recuperación.

Crea una base en dispositivos y navegadores representativos con teclado, zoom y texto ampliado, contraste alto cuando proceda, lector de pantalla y movimiento reducido. El escaneo automático encuentra algunos patrones pero no juzga orden de lectura, etiquetas, instrucciones ni resultado. Registra versiones, pasos manuales y barreras.

Planifica arreglos en componentes y criterios

Prioriza barreras del resultado central, después defectos repetidos y contenido. Integra semántica, foco, asociación de errores, contraste, objetivos táctiles, subtítulos o alternativas y adaptación en componentes. Evita versiones accesibles paralelas cuando una interfaz mantenida pueda servir, porque dos caminos divergen.

Añade criterios observables a stories y una puerta común de accesibilidad. Asigna responsables de diseño, contenido e ingeniería. Prueba temprano con componentes reales. Si investigas con personas con discapacidad, hazlo éticamente y compensa mediante el proceso normal sin tratar una muestra pequeña como prueba universal.

Acepta el recorrido con evidencia por capas

Combina herramientas basadas en estándares, revisión de código y pruebas manuales. Verifica teclado o pulsador, foco, nombres y anuncios, zoom y reflow, contraste, preferencias de movimiento, recuperación de errores y servicios de plataforma. Documenta entorno, evidencia, fallos y excepciones. Un score o una sola tecnología no demuestra accesibilidad completa.

Define la aceptación con evidencia observable, por ejemplo un recorrido probado, una compilación aprobada, controles reproducibles, un runbook de incidentes y un traspaso verificado. Nada de eso demuestra retención, ingresos o encaje de mercado. Separa evidencia de entrega, aprobación de proveedores externos y resultado comercial.

Mantén accesibilidad tras el lanzamiento

Publica limitaciones y una ruta de soporte accesible cuando proceda, con responsables y fechas. Conserva scripts, reglas de componentes y auditorías en los sistemas y repite controles tras cambios de dependencias, diseño u OS. Incluye accesibilidad en incidentes y transferencia. La ausencia de quejas no demuestra ausencia de barreras.

Mantén repositorios, dominios, tiendas, analítica, organizaciones cloud y credenciales de producción bajo propiedad explícita de la empresa. Concede acceso limitado y revocable y ensaya el traspaso antes de la factura final. La etiqueta del proveedor importa menos que la capacidad de otra persona autorizada para inspeccionar, desplegar, recuperar y continuar el producto.

Criterios de decisión

Aplica las mismas preguntas a cada opción antes de elegir.