Todos los equipos con los que he trabajado en quince años han dicho que la accesibilidad importa. Los que realmente la sostuvieron bajo presión de plazos tenían algo en común: la accesibilidad vivía en código y herramientas, no en intenciones. Esta es la configuración que uso, y dónde la IA ayuda y dónde perjudica.
El HTML semántico es el 80% del trabajo
Antes de ARIA, antes de las auditorías: usa el elemento que significa lo que es. Un button para acciones, a para navegación, elementos label reales en los inputs, encabezados en orden. La mayoría de las fallas de accesibilidad que veo en SaaS B2B no son exóticas — son sopa de div con manejadores de clic. Cuando reviso componentes generados por IA, esto es lo primero que reviso, porque los LLM entrenados con la web abierta absorbieron mucha sopa de div. Producirán marcado semántico si tu prompt y tu base de código lo modelan así, y reproducirán basura si eso es lo que los rodea. Tu código existente es un prompt.
Decisiones de diseño que son decisiones de accesibilidad
Tres que aparecen constantemente en mi trabajo de fintech y marketplace:
- Contraste a nivel de token. No audites el contraste pantalla por pantalla; valídalo una vez, en la paleta. Cada combinación de color del sistema de diseño se revisa cuando se define el token. Después de eso, cualquier pantalla construida con tokens hereda el cumplimiento. Este es todo el argumento a favor de los tokens con dientes.
- Los estados de foco se diseñan, no se dejan por defecto. Los usuarios de teclado en software empresarial no son un caso extremo — los power users de herramientas B2B densas viven en el teclado. Diseño el anillo de foco con el mismo cuidado que el estado hover, y hago un recorrido solo con teclado de cada flujo antes de darlo por terminado. Toma diez minutos y siempre encuentra algo.
- Mensajes de error que dicen qué hacer. "Entrada inválida" le falla a todos, y le falla más duro a los usuarios de lector de pantalla, porque no pueden mirar alrededor buscando contexto. Vincula el error al campo de forma programática (
aria-describedby) y escríbelo como una instrucción: qué estaba mal, qué ingresar en su lugar.
Dónde la IA realmente ayuda
Los flujos de trabajo acelerados por IA han hecho mejor mi práctica de accesibilidad, no peor — pero solo de formas específicas:
- Auditar a escala. Puedo pasar una revisión orientada a WCAG sobre toda una librería de componentes en una tarde: un modelo marca candidatos, yo verifico cada uno. El recall del modelo es excelente; su precisión requiere mi criterio.
- Patrones ARIA a demanda. Acertar de memoria un combobox o un patrón de disclosure es propenso a errores. Generarlo a partir del patrón documentado de ARIA Authoring Practices y luego probarlo con un lector de pantalla real supera hacerlo a mano.
- Revisión cross-model. Mi regla fija — quien escribe no revisa — atrapa regresiones de accesibilidad a las que el modelo autor es ciego. Un segundo modelo revisando código generado ha detectado labels faltantes, orden de foco roto y botones solo-ícono sin nombre accesible.
Lo innegociable
Ninguna pasada automatizada, con o sin IA, reemplaza usar la interfaz como la usan los usuarios afectados. Recórrela con Tab. Activa VoiceOver. Haz zoom al 200%. Evidencia por sobre intenciones: una checklist que dice "accesible" es una afirmación; una grabación de recorrido con teclado es una prueba.
La accesibilidad no es una capa de cumplimiento que agregas. Es lo que significa "funciona", dicho por completo.