La accesibilidad afecta a casi todas las etapas de un proyecto. Esto suele explicarse diciendo que la accesibilidad es necesaria antes, durante y después de realizarlo. Es una forma elegante de ilustrar que la accesibilidad debe tenerse en cuenta en la fase de planificación, durante el desarrollo y como parte del Control de Calidad (QA) cuando el proyecto ya está en marcha.
Esta simplificación es útil para explicar que la accesibilidad no es solo una preocupación durante la implementación; pero como toda simplificación, es inexacta porque puede inducir a error. Aclaremos algunos de estos malentendidos.
La accesibilidad en la fase de planificación va más allá del diseño visual
Muchas directrices se aplican específicamente al diseño visual, como las que se engloban bajo el principio general de ser Perceptible. Pero incluso estas están estrechamente ligadas a la arquitectura de contenidos y a la redacción.
Para tener un sitio web fácil de entender, lo habitual es tener en cuenta la complejidad del texto mediante alguno de los modelos y fórmulas existentes (como las pruebas de legibilidad de Flesch-Kincaid, que se basan en la longitud de las palabras y las frases para asignar una puntuación entre 0 y 100, donde 100 corresponde a un texto fácil de leer y 10 o menos a un texto extremadamente difícil).
Esto también se aplica a la navegación. Una estructura con muchas categorías muy pobladas y varios niveles de subcategorías es más difícil de recorrer que una navegación sencilla de un solo nivel.
También se aplica a cualquier proceso, como el de compra. Es mejor pedir a los usuarios solo la información mínima necesaria para realizar una compra, y preguntar después si desean crear una cuenta con los datos facilitados, y no al contrario. Esto reduce la fricción, lo que favorece la conversión, pero facilitar las cosas también ayuda a los usuarios que, de otro modo, podrían sentirse abrumados.
Siempre merece la pena tener presente que los pasos que pedimos a los usuarios no tienen por qué coincidir con los pasos que tienen lugar en nuestra empresa. A menudo podemos simplificar el trabajo de los usuarios centrándome en lo que quieren conseguir y gestionando el resto internamente.
La accesibilidad durante el desarrollo va más allá del código
En la fase de implementación, las cosas empiezan a concretarse. En esta etapa es más fácil detectar cuando algo desentona. Además, por el mero hecho de estar en contexto, los componentes son más fáciles de analizar.
Si tenemos un elemento superpuesto (un botón), independientemente de dónde aparezca en pantalla, su orden de tabulación depende de su posición dentro del HTML. Si el botón activa un modal, este debe colocarse dentro del DOM de forma que su orden de navegación por teclado (comúnmente conocido como orden de tabulación) tenga sentido. O bien, si es un modal a pantalla completa, hay que deshabilitar temporalmente el resto de la navegación. Aunque hayamos diseñado el botón y el modal como un componente cohesionado, puede que sea necesario implementarlos en partes distintas del HTML para que la navegación por teclado funcione como se pretende.
Esto cobra mayor importancia cuando utilizamos un enfoque atómico del diseño, en el que los componentes se diseñan de forma aislada y pueden necesitar ajustes al aplicarse en distintos contextos. Estos ajustes pueden ser variaciones visuales o implementaciones de código completamente diferentes.
No es necesario que esto implique una comunicación constante entre diseñadores y desarrolladores (algo que siempre genera cierto recelo). Simplemente tener en cuenta la accesibilidad puede allanar el camino.
La accesibilidad tras el lanzamiento del proyecto va más allá del QA
Una vez en marcha, si todo se ha hecho correctamente, solo hay que estar atentos a los errores, ¿verdad? Ni mucho menos.
Uno de los principales factores de la accesibilidad es el contenido, ya que los proyectos digitales son sistemas vivos que cambian, crecen y se adaptan. Los textos cuidadosamente elaborados para desarrollar y lanzar el sitio convivirán pronto con contenido nuevo o necesitarán una actualización cuando queden desactualizados. Y la accesibilidad del nuevo contenido requiere la misma atención que el contenido original.
El contenido nuevo mantiene un proyecto al día, pero también es un riesgo. El contenido continuo para el blog y la presencia en redes sociales de una empresa es, al mismo tiempo, una forma de crecer de manera orgánica y un pozo sin fondo de entropía. El nuevo contenido aporta nuevas perspectivas, pero también nuevos problemas. Algo tan sencillo como la necesidad de recontextualizar contenido antiguo cuando se incorpora contenido nuevo puede resultar una carga si no somos metódicos.
Por ejemplo, si queremos ampliar nuestra audiencia creando contenido informativo o educativo sobre temas técnicos o académicos complejos, debemos encontrar la manera de incluirlo junto al contenido más preciso y técnico de forma que no colisione ni entre en conflicto con la voz y el tono utilizados en cada uno de ellos. Si utilizamos contenido llano y accesible solo en una parte del proyecto, el resto resultará más confuso o, en el peor de los casos, disonante para los usuarios.
Cada nuevo contenido debe ser coherente con su contexto, tanto en fondo como en tono, y también en su implementación. Una imagen que resume a la perfección un tema complejo puede ser adecuada para ciertas plataformas. Pero es necesario adaptarla a un elemento textual o interactivo, según su contexto, para que tenga sentido para el usuario.
Conclusión
En el artículo La accesibilidad no es solo una buena experiencia de usuario, escribí sobre cómo la accesibilidad y la experiencia de usuario no pueden abordarse simplemente en la misma conversación. Esto no significa que la estrategia de experiencia de usuario y los esfuerzos en materia de accesibilidad deban estar reñidos. Necesitamos entender cómo se manifiesta la accesibilidad en cada aspecto de un proyecto para evitar el conflicto.
Esto se malinterpreta a veces como un escenario ideal, solo posible si la empresa va muy bien y quiere invertir algo de dinero en accesibilidad. La realidad es que esta es la forma eficiente de hacer accesibles los proyectos. Lo que hace que la remediación de accesibilidad resulte abrumadora es, por lo general, que está desconectada del proceso habitual. Ya sabemos cómo es la planificación, pero ¿qué ocurre cuando surge un problema fuera de nuestro plan original? Siempre lleva más tiempo y es más costoso, y suele arrojar peores resultados que la alternativa.
Fran Rosa. Desarrollador sénior, especialista en accesibilidad y defensor del desarrollo centrado en las personas
Al remediar problemas de accesibilidad en un proyecto existente, las incorporaciones suelen aceptarse sin reservas. Si se pide añadir alternativas textuales, elementos visuales, instrucciones o subtítulos a un vídeo, rara vez surge algún conflicto. Incluso la aplicación de patrones ARIA (Accessible Rich Internet Applications) complejos nunca genera objeciones.
Sin embargo, en ocasiones la remediación exige replantear ciertos componentes, modificarlos o rechazar alguna implementación existente. Y esto genera más fricciones.
Es comprensible, ya que la remediación implica admitir que algo está mal (en términos de accesibilidad) y debe rehacerse. Este tipo de cambios puede hacer que un proyecto supere sus plazos.
La accesibilidad consiste en cumplir un estándar, y algunos de los criterios son muy específicos y no admiten discusión. Así que no siempre es solo cuestión de "añadir más".
ARIA es un buen ejemplo de ello. Existe una colección de atributos y patrones que podemos utilizar, pero de formas muy concretas. Un principio fundamental es que "ningún ARIA es mejor que un ARIA mal implementado", lo que significa que una mala implementación puede ser peor para los usuarios que ninguna implementación en absoluto.
Al planificar la accesibilidad desde el principio, un enfoque minimalista es el óptimo. Por ejemplo, algunos elementos HTML tienen roles y atributos ARIA implícitos. Los elementos de formulario HTML nativos en el navegador utilizan atributos ARIA implícitos como aria-checked. El uso de elementos semánticos adecuados (<head>, <main>, <footer>, <nav>, o <article>…) añade muchos roles ARIA implícitos a la estructura de un sitio.
Es un viejo chiste que la primera página de la World Wide Web ya era accesible porque es simplemente HTML sin imágenes ni estilos. Como en la mayoría de los chistes, hay una verdad en su fondo. La forma en que los distintos navegadores implementan los componentes HTML sigue estándares estrictos, por lo que una implementación uniforme a nivel del sector probablemente mejorará a una personalizada (si es una opción).
Podemos crear interfaces complejas con componentes personalizados y hacerlas accesibles. Pero debemos ser conscientes de los compromisos que asumimos y ofrecer una alternativa que sea tan buena como los componentes nativos que sustituimos. Y según el informe WebAIM Million 2026, "las páginas con ARIA presentaban significativamente más errores (59,1 de media) que las páginas sin ARIA (42 de media)".
Un enfoque minimalista es más fácil de mantener, generalmente más robusto entre navegadores y reduce el riesgo de errores. La complejidad puede ser inevitable en algunos proyectos, pero nunca debería ser la opción por defecto.
Fran Rosa. Desarrollador sénior, especialista en accesibilidad y defensor del desarrollo centrado en las personas
Cómo usamos el color en el diseño de un sitio web puede dar lugar a problemas de accesibilidad. Y aunque éstos parecen, en principio, fáciles de solucionar, pueden llevar mucho trabajo si no se tuvieron en cuenta desde el principio en el diseño.
Hay dos aspectos que son los más importantes para evaluar si tenemos problemas con el color: contraste y uso del color.
Contraste
Es la más frecuente, y podemos encontrar sitios web en los que no existe casi ninguna página sin problemas de este tipo.
El principio es muy simple: el contraste entre el texto y el fondo debe ser de 4.5:1 como mínimo para el texto base, o 3:1 para textos grandes (en general, textos de 18pt o más, o de 14pt o más si están en negrita, o tamaños equivalentes para alfabetos chino, coreano y japonés) para el nivel AA, y de 7:1 y 4.5:1 respectivamente para el nivel AAA.
Parece que sólo bastaría con elegir colores adecuados para el diseño, pero eso a veces no es tan sencillo.
El problema más fácil de solucionar es dejar de intentar esconder o disimular algunas partes del contenido. Por ejemplo, con textos legalmente obligatorios o confirmaciones de aceptación de condiciones. Creamos todo un diseño pensando en lo que queremos comunicar y podemos caer en la tentación de poner en un color que destaque menos las partes que creemos que no encajan con el tono general de nuestro sitio.
Si hacemos eso, no estamos eliminando el contenido ni la obligación de tenerlo, sólo estamos haciendo más difícil su lectura por razones estéticas. Pero debemos ser capaces de diseñar sitios web que sean, al mismo tiempo, visualmente atractivos y funcionales.
Otro problema que ocurre con frecuencia es que los colores corporativos o de la marca no tienen un buen contraste. Por ejemplo, cuando adaptamos colores de una marca que se diseñó para colores impresos a pantalla, los colores no siempre son adecuados. Los colores impresos son sustractivos, con lo que mezclar colores da un resultado más oscuro, mientras que los colores en pantalla son aditivos, y ocurre lo contrario. Por eso intentar copiar un color exactamente en pantalla no siempre funciona, aunque lo haga en papel. Este error es fácil de corregir a nivel técnico, pero requiere más trabajo desde el punto de vista del diseño.
Uso del color
Además de usar colores con buen contraste, no podemos usar el color para trasladar información o distinguir elementos.
Por ejemplo, en un formulario. Marcar en rojo un campo si hay un error está bien, porque señalamos el error donde ocurre, pero no podemos usar ese rojo como única indicación del error. Debemos usar texto u otros elementos visuales para indicarlo.
O si tenemos una lista de opciones, señalar cuáles están seleccionadas sólo con un cambio en el color del fondo no es suficiente. Debemos usar elementos como iconos adicionales (por ejemplo) para poder distinguirlo aunque no podamos percibir el color.
Esta norma suele costar un poco más de entender porque, a veces, visualmente es muy claro y fácil de percibir un cambio o información mediante el color, y parece obvio. Pero algunas personas no pueden percibir el color, o lo hacen de manera distinta, por lo que la interpretación del uso del color no es siempre tan obvia como puede parecernos.
Conclusión
El uso del color afecta la accesibilidad de un sitio web tanto por las cualidades de los colores escogidos como por la intencionalidad de su uso para mostrar la información. Y solucionarlo implica, a veces, repensar qué colores usamos y cómo; esto puede ser una tarea compleja. Pero al final siempre obtenemos un diseño mejor, más útil y adecuado para un sector más amplio de nuestro público.
Fran Rosa. Desarrollador sénior, especialista en accesibilidad y defensor del desarrollo centrado en las personas
No. Desafortunadamente, no podemos automatizar la accesibilidad. Y no es probable que eso cambie en el futuro.
Ya existen herramientas que analizan automáticamente la accesibilidad de un sitio web. Por ejemplo, WAVE es un conjunto de herramientas que nos ayuda a identificar fallos en el cumplimiento de las pautas de accesibilidad. Si usamos una de sus extensiones para diferentes navegadores, tenemos una lista de posibles incumplimientos mientras navegamos por la misma página, señalando el punto donde se incumple y con información sobre cómo solucionarlo.
Otro ejemplo es Axe-core. Es una herramienta de código abierto que podemos usar para analizar automáticamente un sitio web completo. También tenemos una lista de incumplimientos con información precisa sobre cómo localizarlos. Estos son solo dos ejemplos de herramientas gratuitas, pero existen muchas otras herramientas y servicios de pago.
Entonces, ¿por qué no podemos automatizar la accesibilidad en un sitio web?
Primero, porque las herramientas generalmente informan de un incumplimiento, pero no necesariamente son capaces de solucionarlo. El ejemplo más sencillo es con las imágenes. Una herramienta nos indica que una imagen no tiene texto alternativo, pero no puede valorar si esa imagen es puramente decorativa o no, ni qué texto alternativo sería apropiado.
Y puede que estés pensando: ¿Y no puede una IA ver lo que hay en la imagen? Y la respuesta es sí, más o menos. Porque el texto alternativo de una imagen depende de una decisión humana intencionada de usar esa imagen, y hay que conocer esa intención para ofrecer un buen texto alternativo.
Un ejemplo: uno de los miembros del equipo de una empresa recibe un premio, y publicamos una foto en el blog de la compañía. En esa foto vemos a «dos personas, una de ellas con un premio en la mano». ¿Sería ese un buen texto alternativo? Porque si lo publicamos para dar a conocer que alguien ha ganado ese premio, tendríamos que incluir su nombre, mencionar que forma parte del equipo de la empresa, y si el premio está relacionado con un proyecto de la empresa, probablemente mencionarlo también. Todo depende de la intención que teníamos al publicar esa foto.
Otra razón por la que las herramientas automáticas a veces no son suficientes es porque hay errores (incluso los que son errores en el código) que son imposibles de detectar.
Otro ejemplo: si tenemos en una parte del sitio web una navegación por pestañas, la implementación requiere relacionar cada pestaña con su contenido correspondiente, marcar cuál está activa o visible en ese momento, hacer que sea navegable con el teclado, etc. Puedes ver ejemplos completos de una implementación del patrón de pestañas en la Accessible Rich Internet Applications (ARIA) Authoring Practices Guide. Si hemos hecho toda la implementación correctamente y sólo se nos ha olvidado marcar qué pestaña está activa, una herramienta automática podría reconocer el patrón de implementación e indicar la parte que falta.
Pero si sólo lo hemos implementado visualmente sin añadir ninguna de las partes necesarias en el código, ¿cómo puede saber la herramienta automática que estamos implementando una navegación por pestañas?
Esas limitaciones hacen que automatizar la detección de problemas de accesibilidad sea muy útil, pero insuficiente. Nos puede ayudar a detectar descuidos y mejorar el desarrollo e implementación de nuevos contenidos, pero no puede detectar todo ni ofrecer soluciones. Y podemos caer en el error de pensar que si una herramienta automática no detecta ningún fallo es porque no hay ninguno, cuando no necesariamente es así. Las herramientas nos ayudan, pero no sustituyen ni el conocimiento ni factores humanos como la intención.
Fran Rosa. Desarrollador sénior, especialista en accesibilidad y defensor del desarrollo centrado en las personas
El documento que marca las pautas sobre las que se mide la accesibilidad de sitios web y aplicaciones móviles se conoce como «Pautas de Accesibilidad para el Contenido Web» (conocidas frecuentemente como WCAG por sus siglas en inglés).
Este documento se usa como referencia para desarrollar proyectos digitales accesibles y auditar la accesibilidad de los que ya existen. Por eso, para incluirse en el documento, las pautas deben cumplir dos criterios:
- Ser problemas de acceso importantes que afecten a personas con discapacidades especialmente (es decir, que van más allá de los problemas de usabilidad que afectan a todo el mundo)
- Ser verificables, para que se pueda medir su conformidad con un alto nivel de fiabilidad
Las leyes que regulan los sitios que están obligados a ser accesibles se basan en ese documento.
Algo que a veces genera un poco de confusión es que las pautas se dividen en tres niveles: A, AA y AAA. Y éstos son acumulativos, lo que significa que para cumplir el nivel AA (que es la recomendación habitual y el que mencionan las leyes) hay que cumplir todas las pautas de los niveles A y AA. También es posible que algunas no apliquen. Por ejemplo, las que hacen referencia a contenidos de audio y/o vídeo no aplican si el sitio no tiene ese tipo de contenido.
Los niveles se asignan según lo esencial que es cada pauta, si es posible cumplirla en distintos tipos de sitios y contenidos, y si es razonable que los creadores de contenido la cumplan. Así, las pautas A son mínimos que eliminan obstáculos básicos; las pautas AA son el estándar que mejora la accesibilidad para un mayor rango de personas; y las pautas AAA son el nivel más alto de exigencia, y no es realista esperar que todos los tipos de contenido las cumplan.
Si analizamos las pautas para elementos interactivos o formularios, la expectativa de conocimiento en el uso de código es mayor que para pautas como el uso de imágenes o colores, ya que es razonable pensar que quien implementa interactividad o formularios en un sitio web tendrá conocimientos de código suficientes para cumplir con los criterios.
Los niveles existen porque el trabajo riguroso que se hace al crear las pautas no sólo se centra en cómo afectan a las personas que van a usar ese sitio web, sino que también tiene en cuenta la tarea de implementarlas. Y aunque, generalmente, nos centramos en la obligación de cumplir ciertas pautas, tenemos acceso a una lista amplia de criterios significativos y medibles, y los niveles son información añadida para su cumplimiento.
Fran Rosa. Desarrollador sénior, especialista en accesibilidad y defensor del desarrollo centrado en las personas
En una conversación reciente con un diseñador experto en diseño digital y experiencia de usuario, comenté que, generalmente, no es buena idea considerar la accesibilidad y la experiencia de usuario al mismo tiempo. Su respuesta fue que la accesibilidad no es más que una buena experiencia de usuario para todo el mundo. Aunque es una bonita manera de expresarlo, sigo creyendo que es un error considerar la accesibilidad como parte de la experiencia de usuario.
Para empezar, cómo evaluamos una y otra es muy diferente. Aunque existen buenas prácticas, la experiencia de usuario se mide en cada proyecto según cómo una persona percibe, usa y completa satisfactoriamente ciertas tareas. En ese sentido, estar satisfecho con el resultado o conseguir lo que queremos inicialmente no tiene por qué ser lo mismo.
Aquí es importante conocer un poco la historia de la experiencia de usuario como disciplina. Aunque podemos considerar algunos avances en ergonomía o psicología como precursores, fue en 1982 cuando surgió el concepto de Interacción Persona-Ordenador, centrado en hacer la interacción posible y efectiva. A partir de la publicación de las «10 heurísticas de usabilidad» de Jakob Nielsen y Rolf Molich en 1989, el término usabilidad se popularizó centrándose en reducir errores y mejorar la eficiencia.
La experiencia de usuario es un concepto de Don Norman, cuando trabajaba en Apple en 1993, y se centraba en analizar los sistemas que se diseñaban de manera holística y siempre desde el punto de vista del usuario. Aquí hay un cambio esencial en el enfoque, porque lo que el usuario piensa, experimenta o siente se convierte en la principal métrica del éxito. Durante la primera década de los años 2000, se extiende la idea de que todos los procesos y decisiones deben medirse desde esa experiencia del usuario.
Esto es revolucionario, sobre todo desde el punto de vista comercial, pero también hace más difíciles algunas conversaciones. Por ejemplo, un concepto que nace de esta manera de entender el diseño es la «interfaz de usuario optimista» (el artículo «True Lies Of Optimistic User Interfaces» de Denys Mishunov sobre el tema, en inglés). Este concepto se basa en la idea de que, cuando interactuamos con una interfaz en un móvil, en lugar de esperar a recibir la respuesta del servidor, lo mejor es mostrar en la interfaz que se ha completado la tarea, aunque no sea verdad, para que el usuario lo perciba como algo instantáneo, y que si finalmente hay un error, se puede mostrar luego. Es algo muy habitual en redes sociales cuando reaccionamos a un contenido con un «me gusta» o añadiendo un comentario y vemos instantáneamente cómo se añade aunque aún no se haya enviado al servidor.
En este caso la interfaz nos está mintiendo para vendernos una ilusión de inmediatez, porque se considera que el efecto positivo de ver la interacción de manera instantánea supera al efecto negativo de que esa interacción acabe desapareciendo luego por algún fallo. Y es que al mezclar tantas partes del proceso y disciplinas dentro de la misma olla, la experiencia de usuario siempre acaba siendo una negociación entre muchos factores.
Cuando hablamos de accesibilidad, los criterios suelen ser más rígidos. ¿Está el componente bien implementado para usarse con un lector de pantalla? ¿Puede el usuario detener o pausar vídeos o animaciones? ¿Existe texto alternativo para contenidos como imágenes o elementos multimedia? La respuesta suele ser un sí o un no, no hay negociación. En accesibilidad, no es aceptable tener un botón demasiado pequeño o un contraste de color inadecuado porque el usuario tenga una experiencia emocional distinta.
Por eso, aunque integrar la accesibilidad en diferentes partes del proceso (como el diseño o el desarrollo) facilita que un proyecto en continua evolución siga siendo accesible, también hay que entender que los criterios de accesibilidad son mínimos indispensables que deben cumplirse y no unos objetivos que se puedan negociar junto con otras consideraciones.
Fran Rosa. Desarrollador sénior, especialista en accesibilidad y defensor del desarrollo centrado en las personas