Empezamos a auditar accesibilidad en los proyectos de clientes y no nos gustó lo que encontramos
Hace cosa de dos meses metí el sitio de un cliente —una academia de idiomas online— en un lector de pantalla para probar algo random y no pude ni rellenar el formulario de contacto. El campo de teléfono no tenía label asociado, el botón de enviar era un div con un onclick, y el foco se perdía cada vez que se abría el menú móvil. Llevábamos año y medio manteniendo esa web. Nunca nadie lo había probado así.
Eso fue el detonante. A partir de ahí empezamos a meter una pasada de accesibilidad básica en cada proyecto nuevo y, poco a poco, en los que ya llevábamos de mantenimiento. Nada de certificaciones WCAG AA completas ni auditorías de tres semanas: no tenemos ni el tiempo ni, siendo sinceros, el cliente medio lo va a pagar. Pero sí un pase de una tarde con axe DevTools, navegación por teclado a pelo y, cuando el proyecto lo merece, VoiceOver en Safari.
Lo que encontramos fue peor de lo que esperaba. En ocho proyectos que revisamos entre abril y junio, todos menos uno tenían algún problema de contraste que suspendería un AA básico. Cinco tenían imágenes decorativas con alt mal puesto, o al revés, imágenes con información sin alt en absoluto. Tres tenían modales que atrapaban el foco de tal manera que era imposible cerrarlos con teclado. En un caso, una tienda online de menaje de cocina, el checkout entero dependía de hover, así que en móvil, con lector de pantalla, la compra era literalmente imposible de completar sin ver la pantalla.
No lo digo para quedar bien. Nosotros mismos habíamos escrito parte de ese código. El componente de acordeón que reutilizamos en media docena de sitios llevaba desde 2024 sin manejar aria-expanded correctamente. Bueno, lo manejaba, pero solo si el JS cargaba antes que el CSS, un bug tonto que nadie detectó porque nadie lo probó con teclado.
Lo que cambió después no fue un proceso enorme. Añadimos una checklist de diez puntos que se pasa antes de cada entrega: contraste con la extensión de Chrome, tabulación completa sin ratón, labels en todos los inputs, foco visible, headings en orden lógico (nada de saltar de h1 a h4 porque “queda mejor” visualmente), texto alternativo revisado a mano y no generado por el CMS de turno. Diez minutos, no una auditoría formal, pero pilla el ochenta por ciento de lo grave.
Lo que no hemos resuelto es cómo venderlo. Ningún cliente ha preguntado nunca por accesibilidad al pedir presupuesto, ni uno. Así que ahora mismo lo metemos incluido, sin cobrarlo aparte, y eso a la larga no es sostenible si el proyecto crece. Un cliente del sector público sí que lo pidió explícitamente por normativa, y ahí cobramos la auditoría completa como partida separada, que es como debería ser siempre.
Todavía no sé cómo plantear esa conversación con el resto sin que suene a que les estoy vendiendo miedo.