Hace unos días pregunté a Juanjo, que para quien no lo conozca, es un referente en cuanto a accesibilidad cómo podría mejorar la accesibilidad de IOKode.
Tras una agradable conversación por Twitter, me recomendó que la testase con la extensión Axe, la cual arrojó dos problemas, que ya han sido solucionados:
- Zoom desactivado en dispositivos móviles.
- Contraste de colores en los enlaces y en la lista de entradas.
El problema del zoom
Una etiqueta <meta> estaba prohibiendo hacer zoom en dispositivos móviles, algo que puede ser un problema no sólo para personas con problemas de vista, si no incluso para cualquiera que simplemente prefiera ver el contenido con un texto más grande.
Lo grave aquí fue que el HTML de este sitio lo he escrito yo mismo, y no me di cuenta del problema que esto puede suponer.
Sobre esto me gustaría destacar, que Safari en iOS permite hacer zoom independientemente de lo que ponga en la etiqueta <meta>, así que bravo a Apple en ese sentido.
El problema del contraste de colores
El CSS de IOKode tiene la media query prefers-color-scheme, por lo que los colores son distintos dependiendo del esquema de colores configurado en el sistema operativo. He modificado ligeramente los colores para que pasen la prueba en el esquema light. El color actual de los enlaces en la versión actual es más cercano al morado, frente al rosa anterior. El contraste con el fondo mejora, y a mí personalmente, me gusta mejor como queda ahora. En el esquema dark, se queda como estaba ya que pasaba la prueba sin problema.
A destacar en el listado de todas las entradas, las fechas antes tenían un color muted que se fundía con el fondo, sin apenas contraste. He desecho eso.
Como dato curioso, la herramienta Axe sigue marcando que en los elementos del header podría haber mal contraste de color dado que no puede comprobarlo porque hay una imagen del fondo, pero la imagen de fondo es el logo de IOKode, y no toca los elementos como el eslogan o los enlaces, así que entiendo que está también solucionado.
Recomendación final
Ambos problemas ya están solucionados en los dos últimos commits que he hecho sobre la plantilla, y han sido desplegados sobre iokode.blog.
Para terminar, me gustaría recomendar a todos los desarrolladores web que instalen la extensión, y prueben con ella todos sus sitios webs, y si como en el caso de IOKode, el CSS utiliza la media query prefers-color-scheme, entonces deberían de realizar la prueba dos veces, una con la configuración clara y otra con la configuración oscura.
Hay 1 comentarios en esta entrada. Pulsa aquí para comentar desde GitHub.
Voy a complementar esta entrada con un comentario a raíz de un tweet de Juanjo en que se pregunta en qué contextos puede ser buena idea desactivar el zoom, y si es correcto que un navegador se salte el estándar, aunque con ello mejore la accesibilidad.
Dado lo relacionado de ambas preguntas con este artículo, he decidido hacer un añadido en forma de comentario aquí para que esté disponible junto al artículo y no se pierdan en dos tweets.
¿En qué contextos tiene sentido desactivar el zoom?
Cuando se desarrolla una aplicación de iPhone utilizando su UI nativa (Cocoa Touch), esta no permite hacer zoom con pinza sobre los botones o la barra de navegación descuadrando la interfaz (y dependiendo de la aplicación, sí podría permitir zoom de pinza sobre el contenido). Desde los ajustes de accesibilidad del iPhone se puede configurar de forma global si se quieren botones o barra de títulos más más grandes, y esto afectaría de forma global a todas las aplicaciones desarrolladas con Cocoa Touch. Desconozco el mundo Android, pero imagino que también tendrán ajustes de accesibilidad similares que se aplique sobre aplicaciones que usen la UI nativa (¿Material Design?).
Por lo tanto, desactivar el zoom puede tener sentido en una aplicación web que intente emular el comportamiento de una aplicación nativa. Hacer zoom a una barra de título, una barra de navegación o un botón, descuadraría por completo la interfaz de esta aplicación web.
¿Es correcto que un navegador se salte el estándar, aunque sea por mejorar la accesibilidad?
Siguiendo con el caso anterior de las aplicaciones, las aplicaciones que usan UI nativa permiten configurar desde los ajustes del sistema operativo como se debería de renderizar algunas cosas tanto de accesibilidad como estéticas, por ejemplo botones más grandes, desactivar gradientes en barra de título, añadir un borde extra a los botones, color de alto contraste, etc.
Sin embargo, una aplicación web no puede leer estos ajustes para adaptarse a ello, y aunque pudiese, habría que ver hasta qué punto los desarrolladores harían el esfuerzo de leerlas y adaptar su interfaz. Con la interfaz nativa no tiene ningún esfuerzo ya que lo hace de forma automática el sistema operativo. Me parece por lo tanto lógico que a falta de una forma mejor de adaptar la interfaz de una aplicación web, se permita siempre hacer zoom sobre ella.
También me gustaría añadir que los documentos HTML se diseñaron para ser documentos, no aplicaciones (escribiré en el futuro un artículo de por qué el uso de la web como aplicaciones es en mi opinión una chapuza que se nos ha ido de las manos, pero esto se escapa del ámbito de este artículo).
Dado que son documentos, los documentos son susceptibles de ser interpretados de diferentes formas, dependiendo del hardware y el software.
Por ejemplo, con mucho que el estándar CSS diga que la propiedad
color: redsignifique que el texto se tenga que ver de color rojo, si utilizo una pantalla de tinta electrónica monocromática, el texto nunca se verá de color rojo, pues ese hardware no soporta mostrar colores.Mi conclusión sobre ello es que el bajo ciertas condiciones, el documento puede ser interpretado de diferente forma para la que está pensado, y por lo tanto, mi opinión es un rotundo sí, es correcto que en este caso en concreto, un navegador móvil se salte el estándar.