La accesibilidad del sitio web siempre ha sido importante, pero hoy en día, cuando tenemos normas y regulaciones claras de los gobiernos en la mayoría de los países, se vuelve aún más crucial respaldar esas normas y hacer que nuestros proyectos sean lo más accesibles posible.
La recomendación del W3C proporciona 3 niveles de conformidad: A, AA y AAA. Estar en el AA nivel, entre otros requisitos, tenemos que proporcionar una forma de aumentar el tamaño de fuente del sitio:
1.4.4 Cambiar el tamaño del texto: A excepción de los subtítulos y las imágenes de texto, se puede cambiar el tamaño del texto sin tecnología de asistencia hasta en un 200 por ciento sin pérdida de contenido o funcionalidad. (Nivel AA)
Busquemos soluciones para esto y tratemos de encontrar la mejor que podamos.
Actualización (25/09/17): Resulta que WCAG no requiere una solución personalizada de cambio de tamaño de texto además de lo que proporcionan los agentes de usuario. Solo tenemos que asegurarnos de que un sitio web se vea bien como resultado del cambio de tamaño. Sin embargo, si aún queremos escalar elementos por cualquier motivo, a continuación se muestra un análisis exhaustivo de los diferentes métodos para hacerlo.
Solución incompleta: CSS zoom
La primera palabra que surge cuando hablamos de cambio de tamaño es zoom. CSS tiene un zoom propiedad y hace exactamente lo que queremos: aumenta el tamaño.
Echemos un vistazo a un patrón de diseño común (que usaremos para el resto de este artículo): una barra horizontal de navegación que se convierte en un ícono de menú en un cierto punto de interrupción:
Eso es lo que queremos que suceda. No se ajusta y todo el menú se convierte en un icono de menú en un punto de interrupción específico.
El GIF a continuación muestra lo que obtenemos zoom enfoque aplicado al elemento de menú. Creé un conmutador que permite seleccionar diferentes tamaños y aplica un nivel de zoom apropiado:
Echa un vistazo al Pen aquí si quieres jugar con él.
El menú sale del área visible porque no podemos aumentar mediante programación el ancho de la ventana gráfica con el zoom ni podemos ajustar el menú debido al requisito. El icono de menú tampoco aparece, porque el tamaño de la pantalla no ha cambiado, es el mismo que antes de hacer clic en el conmutador.
Todos estos problemas, además, zoom Firefox no es compatible en absoluto de todos modos.
Solución incorrecta: Transformaciones de escala
Podemos obtener en gran medida el mismo efecto con transform: scale como llegamos con zoom. Excepto, transform es más compatible con los navegadores. Aún así, tenemos exactamente los mismos problemas que tenemos con zoom: el menú no encaja en el área visible y, lo que es peor, también va más allá del área visible vertical porque el diseño de la página se calcula en base a una escala inicial de 1 factor.
Vea el Pen Font-switcher-wrong-scale de Mikhail Romanov (@romanovma) en CodePen.
Otra solución incompleta: rem y html font-size
En lugar de hacer zoom o escalar, podríamos usar rem como unidad de tamaño para todos los elementos de la página. Luego podemos cambiar su tamaño modificando html elementos font-size propiedad, porque por su definición 1rem igual a html‘s font-size valor.
Esta es una solución bastante buena, pero no del todo perfecta. Como puede ver en la siguiente demostración, tiene los mismos problemas que los ejemplos anteriores: en un punto no encaja horizontalmente porque el espacio requerido aumenta pero el ancho de la ventana gráfica permanece intacto.
Vea el Pen Font-switcher – wrong-rem de Mikhail Romanov (@romanovma) en CodePen.
El problema, en cierto sentido, es que las consultas de los medios no se ajustan al cambio de tamaño. Cuando aumentamos de tamaño, las consultas de medios deben ajustarse en consecuencia para que el efecto en el mismo lugar ocurra antes del cambio de tamaño, en relación con el contenido.
Solución de trabajo: emule el zoom del navegador con Sass mixin
Para encontrar inspiración, veamos cómo la función nativa de zoom del navegador maneja el problema:
¡Guau! Chrome comprende que el zoom en realidad cambia la ventana gráfica. Cuanto mayor sea el zoom, más estrecha será la ventana gráfica. Lo que significa que nuestras consultas de medios realmente surtirán efecto como esperamos y necesitamos.
Una forma de lograr esto (sin depender del zoom nativo, porque no hay forma de que accedamos a eso para nuestros controles en la página como lo requiere AA) es actualizar de alguna manera los valores de consulta de medios cada vez que cambiamos el tamaño de fuente.
Por ejemplo, supongamos que tenemos un punto de interrupción de consulta de medios en 1024px y realizamos un 200% zoom. Deberíamos actualizar ese punto de interrupción a 2048px para compensar el nuevo tamaño.
¿No debería ser esto fácil? ¿No podemos simplemente configurar las consultas de medios con rem unidades de modo que cuando aumentemos la font-size las consultas de medios se ajustan automáticamente? Lamentablemente no, ese enfoque no funciona. Intente actualizar la consulta de medios de px a rem en este bolígrafo y ver que nada cambia. El diseño no cambia los puntos de interrupción después de aumentar el tamaño. Eso es porque, de acuerdo con los estándares, tantoremy em Las unidades en las consultas de medios se calculan en función del valor inicial de html elemento font-size que es normalmente 16px (y puede variar).
Las unidades relativas en las consultas de medios se basan en el valor inicial, lo que significa que las unidades nunca se basan en los resultados de las declaraciones. Por ejemplo, en HTML, el em la unidad es relativa al valor inicial de ‘font-size.
Podemos usar el poder de Sass mixin¡Sin embargo, s para evitar esto! Así es como lo haremos:
- usaremos una clase especial en
htmlelemento para cada tamaño (font-size--s,font-size--m,font-size--l,font-size--xl, etc.) - usaremos un especial
mixin, que crea una regla de consulta de medios para cada combinación de punto de interrupción y tamaño y que tiene en cuenta tanto el ancho de pantalla como la clase de modificador aplicada ahtmlelemento - envolveremos el código con esto
mixinen todas partes queremos aplicar una consulta de medios.
Así es como esto mixin mira:
$desktop: 640px;
$m: 1.5;
$l: 2;
$xl: 4;
// the main trick is here. We increase the min-width if we increase the font-size
@mixin media-desktop {
html.font-size--s & {
@media (min-width: $desktop) {
@content;
}
}
html.font-size--m & {
@media (min-width: $desktop * $m) {
@content;
}
}
html.font-size--l & {
@media (min-width: $desktop * $l) {
@content;
}
}
html.font-size--xl & {
@media (min-width: $desktop * $xl) {
@content;
}
}
}
.menu {
@include media-desktop {
&__mobile {
display: none;
}
}
}Y un ejemplo del CSS que genera:
@media (min-width: 640px) {
html.font-size--s .menu__mobile {
display: none;
}
}
@media (min-width: 960px) {
html.font-size--m .menu__mobile {
display: none;
}
}
@media (min-width: 1280px) {
html.font-size--l .menu__mobile {
display: none;
}
}
@media (min-width: 2560px) {
html.font-size--xl .menu__mobile {
display: none;
}
}Entonces, si tenemos n puntos de interrupción y m tamaños, generaremos n veces m reglas de consulta de medios, y eso cubrirá todos los casos posibles y nos dará la capacidad deseada para usar consultas de medios aumentadas cuando se aumente el tamaño de fuente.
Consulte el lápiz a continuación para ver cómo funciona:
Vea Pen Font-switcher, a la derecha de Mikhail Romanov (@romanovma) en CodePen.
Inconvenientes
Sin embargo, existen algunos inconvenientes. Veamos cómo podemos manejarlos.
Mayor especificidad en los selectores de consultas de medios.
Todo el código dentro de la consulta de medios obtiene un nivel adicional de especificidad porque va dentro html.font-size — x selector. Entonces, si optamos por el enfoque móvil primero y usamos, por ejemplo, .no-margin modificador en un elemento, entonces el estilo normal del escritorio puede vencer al modificador y se aplicarán los márgenes del escritorio.
Para evitar esto podemos crear el mismo mixin para móvil y envolver con nuestro mixins no solo en el escritorio, sino también en el código CSS para dispositivos móviles. Eso equilibrará la especificidad.
Otras formas son manejar cada caso especial con un enfoque individual aumentando artificialmente la especificidad o creando mixin con la funcionalidad deseada (sin margen en nuestro ejemplo) y colocándolo no solo para dispositivos móviles sino también en cada código de punto de interrupción.
Mayor cantidad de CSS generado.
La cantidad de CSS generado será mayor porque generamos el mismo código CSS para todos los tamaños.
Esto no debería ser un problema si los archivos están comprimidos con gzip (y ese suele ser el caso) porque maneja muy bien el código repetido.
Algunos marcos de front-end como Zurb Foundation utilizan puntos de interrupción integrados en las utilidades de JavaScript y las consultas de medios CSS.
Eso es difícil. Personalmente, trato de evitar las características de un marco que depende del ancho de la pantalla. El principal que a menudo se puede pasar por alto es un sistema de cuadrícula, pero con el aumento de flexbox y grid, ya no veo que sea un problema. Consulte este excelente artículo para obtener más detalles sobre cómo construir su propio sistema de red.
Pero si un proyecto depende de un marco como este, o no queremos luchar contra el problema de la especificidad pero aún queremos ir con AA, entonces consideraría deshacerme de los elementos de altura fija y usar rems junto con alterar el html elemento font-size para actualizar el diseño y las dimensiones del texto en consecuencia.
¡Gracias por leer! Por favor, avíseme si esto ayuda y qué otros problemas enfrentó de conformidad con el requisito 1.4.4 de accesibilidad del W3C para cambiar el tamaño del texto.