Accesibilidad Web y Estándares WCAG

WCAG 2.1 se organiza en torno a cuatro principios, recordados por el acrónimo POUR. Perceptible: los usuarios deben poder percibir toda la información y los componentes de la UI a través de al menos un sentido. Requisitos: todas las imágenes tienen texto alternativo descriptivo; todo el contenido de video tiene subtítulos; el color no es la única forma de transmitir información (por ejemplo, los estados de error usan texto o iconos además del color rojo); el texto mantiene suficiente contraste de color con su fondo (relación 4.5:1 para texto normal; 3:1 para texto grande en cumplimiento AA). Operable: toda la funcionalidad debe ser operable solo con el teclado (los usuarios con discapacidades motoras que no pueden usar un mouse deben poder navegar, activar y completar todos los flujos de trabajo usando Tab, Enter, las teclas de flecha y Escape). Requisitos: los estados de enfoque son claramente visibles; no hay trampas de teclado (el usuario siempre puede salir de cualquier elemento de la UI); enlaces para saltar la navegación para usuarios de lectores de pantalla. Comprensible: la interfaz debe ser comprensible en su lenguaje, comportamiento y manejo de errores. Requisitos: el idioma de la página se especifica en el HTML; los campos de formulario tienen etiquetas visibles; los mensajes de error identifican claramente qué salió mal y cómo solucionarlo; el comportamiento de la UI es predecible (no hay cambios de contexto inesperados al enfocar). Robusto: el contenido debe ser interpretado de forma fiable por las tecnologías de asistencia. Requisitos: HTML semántico (usar jerarquía de encabezados, elementos de referencia, roles ARIA apropiadamente); los elementos de formulario tienen etiquetas asociadas; los componentes interactivos personalizados implementan el patrón ARIA correcto.

Las pruebas de accesibilidad requieren una combinación de escaneo automatizado y pruebas manuales: las herramientas automatizadas encuentran aproximadamente el 30-40% de los problemas de WCAG; las pruebas manuales con tecnologías de asistencia e investigación de usuarios con discapacidad encuentran el resto. Herramientas de prueba automatizadas: Axe (extensión de navegador + integración CI, la herramienta automatizada más utilizada y precisa); WAVE (extensión de navegador de WebAIM, buena para la anotación visual de problemas); Lighthouse (integrado en Chrome DevTools, incluye auditoría de accesibilidad). Las pruebas automatizadas deben ejecutarse en el pipeline de CI en cada pull request, fallando la compilación si se introducen nuevas violaciones de accesibilidad. Protocolo de pruebas manuales: auditoría de navegación con teclado (navegar por cada flujo de trabajo usando solo el teclado: Tab para avanzar, Shift+Tab para retroceder, Enter/Espacio para activar, Escape para cerrar). Documentar cualquier trampa o ruta rota. Pruebas con lector de pantalla: probar con NVDA + Firefox (Windows, gratuito) y VoiceOver + Safari (macOS, integrado). Navegar por los flujos de usuario principales e identificar cualquier elemento que no se anuncie correctamente, tenga contexto faltante o cree confusión. Verificación de contraste de color: usar una herramienta de análisis de contraste de color (ColorContrastChecker, aplicación Colour Contrast Analyser) en todas las combinaciones de texto/fondo en el sistema de diseño y el producto. Pruebas de usuario con personas con discapacidades: sesiones trimestrales de usabilidad con 2-3 usuarios con discapacidades relevantes (visuales, motoras, cognitivas) proporcionan las ideas cualitativas que las herramientas automatizadas no pueden generar.

Una Plantilla Voluntaria de Accesibilidad del Producto (VPAT) es un documento estandarizado, publicado por el Consejo de la Industria de Tecnología de la Información (ITI), que describe cómo un producto cumple con cada criterio de WCAG 2.1 y los requisitos de la Sección 508 (la ley federal de accesibilidad de EE. UU.). Los equipos de adquisición empresariales y gubernamentales requieren un VPAT completado (formalmente llamado Informe de Conformidad de Accesibilidad, ACR) como parte de la evaluación del proveedor. Sin un VPAT, muchos acuerdos en los sectores gubernamental, de atención médica, servicios financieros y educación son descalificados automáticamente, el equivalente al cuestionario de seguridad para la accesibilidad. Secciones del VPAT: para cada criterio de éxito de WCAG, el VPAT registra: Soporta (el producto cumple completamente el criterio); Soporta Parcialmente (el producto cumple algunos, pero no todos los requisitos con explicación); No Soporta (el producto no cumple este criterio con explicación); y No Aplicable (el criterio no se aplica a este tipo de producto). Honestidad y precisión del VPAT: un VPAT que afirma "Soporta" para criterios que el producto no cumple es una responsabilidad legal. El VPAT debe prepararse con una combinación de resultados de auditoría de accesibilidad (pruebas automatizadas + manuales) y revisión legal. Product Ops coordina la producción del VPAT, contratando a un consultor de accesibilidad externo para la auditoría, al equipo legal para la revisión y manteniendo una cadencia de actualización trimestral a medida que el producto cambia (un VPAT de más de 12 meses sin actualizaciones se considera poco fiable por los equipos de adquisición).