El gran problema son los administradores de diseño que tratan una página web como papel , con un tamaño fijo, y quieren que los componentes de esa página web también tengan un tamaño fijo . Esa es una decisión de diseño muy, muy mala, porque rompe la capacidad de respuesta integrada de los navegadores web. Deliberadamente hace que las páginas web que han creado sean menos accesibles .

Y luego están orgullosos de eso .

El diseño receptivo es una mala solución a ese problema, porque en primer lugar no debería existir. La solución real, por supuesto, es eliminar el estilo, el CSS, que rompe la capacidad de respuesta. Pero dado que los gerentes de diseño insisten en obligar a los diseñadores y desarrolladores web a poner ese estilo en la página web, para romper la capacidad de respuesta, para destruir la accesibilidad, el diseño receptivo le da a uno una salida, y aunque es terriblemente malo, puede pasar la inspección. aseguramiento del cumplimiento de la accesibilidad. (Tienes eso, ¿ no?)

Veamos qué hace el diseño receptivo.

Supongamos que tiene una pantalla estrecha. Abre una página web. Te muestra una imagen, un texto, una imagen, un texto, uno debajo del otro, así:

Ahora abre esa misma página web en una pantalla ancha. Te muestra filas de imagen y texto, así:

Eso es lo que puede hacer el diseño receptivo: puede moverse y cambiar el tamaño de los componentes en la pantalla, según el ancho y la densidad de píxeles de la ventana gráfica. (Puede cambiar todos los estilos por completo, pero eso sucede rara vez).

¡Pero espera! ¡Hay más!

Los cambios comunes incluyen:

• Colapsar o mostrar barras laterales,
• Mostrando imágenes más pequeñas o más grandes,
• Usando un tamaño de fuente más grande o más pequeño,
• Provocar líneas que se envuelven a través de palabras que son demasiado anchas para caber en la pantalla,
• Hacer botones más grandes (suponiendo que los dispositivos más pequeños se operen con los dedos) o más pequeños (suponiendo que los dispositivos más grandes se operen con el mouse),
• Mover las etiquetas de los campos de junto a los campos de formulario superiores,
• Cambiar de un estilo de hipervínculo que obliga a uno a buscar hipervínculos, a uno que los hace destacar (asumiendo que los dispositivos más pequeños se operan con los dedos y no pueden pasar el puntero del mouse),
• ¡y más!

En lugar de preguntarle al navegador web quién es su proveedor, el CSS le pregunta qué tan ancha es la ventana gráfica, cuántos colores puede mostrar la pantalla y cuántos píxeles por pulgada muestra. Mozilla Developer Network tiene un excelente artículo sobre consultas de medios , que este artículo no va a repetir. Dirígete a MDN.

Esta técnica se anuncia como la mejor forma de abordar los problemas de accesibilidad causados ​​por las mismas personas. Que irónico.

La forma correcta de evitar estos problemas es, para empezar, no causarlos.

Por ejemplo: ¿por qué impediría que una imagen se mostrara en todo el ancho de la ventana gráfica? Lo que podría querer hacer es cambiar una imagen de alta definición adecuada para una pantalla de alta resolución por una de baja definición adecuada para una pantalla de baja resolución... pero ni siquiera puede suponer que las pantallas más estrechas tienen una menor resolución que las pantallas más anchas, dadas las pantallas de alta densidad que tienen algunos teléfonos inteligentes . Por lo tanto, si bien podría emplear una consulta de medios para ofrecer la mejor calidad de imagen , eso no tiene nada que ver con resolver problemas de accesibilidad.

Del mismo modo, no debe establecer el tamaño de fuente en unidades dependientes de la pantalla, como los píxeles. Debe establecerlo en unidades absolutas como puntos. (Configurarlo en relación con el ancho de la pantalla es el error más tonto: hace que las letras se vuelvan ilegiblemente pequeñas en pantallas estrechas de baja densidad).

Tampoco debe establecer los márgenes y los rellenos con píxeles. En su lugar, debe configurarlos usando n-widths y m-widths: en relación con el ancho de las letras.

Tampoco hay una buena razón para hacer que los botones sean pequeños para los usuarios de pantallas grandes. La suposición inherente de que todos pueden usar un mouse es terriblemente capaz. Si hace que los botones sean lo suficientemente grandes como para tocarlos con los dedos, un usuario de una pantalla grande aún puede usar esos mismos botones.

Oh, dices, pero entonces, ¿cómo haces una barra de herramientas llena de pequeños botones?

Bueno, tal vez no deberías hacer eso. Los creadores de barras de herramientas han encontrado formas de lidiar con la falta de espacio: menús desbordados y ajuste de línea . Los botones diminutos están hechos para personas que pueden usar punteros de mouse precisos. Muestran una total y absoluta falta de respeto por las personas que no pueden hacerlo, por la razón que sea.

Otros cambios incluyen colapsar una barra lateral. Si esa barra es de tan poca importancia que se puede contraer, seguramente se le puede ocurrir una mejor visualización. Tal vez omitirlo por completo .

Entonces… ¿nunca hay una buena razón para usar consultas de medios?

No. De hecho, hay 1 buena razón: saltos de palabra.

El inglés es un idioma con pocas palabras largas comunes. Las palabras largas que conoce se toman prestadas del latín y se usan en ciencias como la química para denotar compuestos químicos. Pero otros idiomas comúnmente tienen palabras largas . Y a muchos diseñadores les gusta que su página web muestre esas palabras sin obligar al usuario a desplazarse horizontalmente.

Para ese propósito, CSS tiene la capacidad de permitir que los navegadores web dividan una palabra en lugares aleatorios , en lugar de espacios y otros símbolos que no son letras. Pero no esperaríamos que eso sucediera en una pantalla ancha donde hay muchas oportunidades para encontrar un salto de palabra natural. (Hay excepciones, por supuesto, para palabras extremadamente largas).

Y, por lo tanto, está perfectamente bien aplicar las reglas antinaturales de ajuste de palabras solo en situaciones limitadas: una gran razón para usar consultas de medios.

Si encuentra otras buenas razones para las consultas de los medios, que no se emplean simplemente para evitar romper la accesibilidad, no dude en comunicarse y enriquecer este artículo con sus comentarios.

Sobre el Autor

Veltstra tiene 40 años de experiencia en el uso de herramientas y software mal diseñados, y ha convertido eso en una firme defensa de la usabilidad y la accesibilidad . Veltstra ha creado software durante más de 30 años, 25 de los cuales profesionalmente, siempre intentando que los productos sean utilizables y accesibles.

No existe ninguna discapacidad que no sea ignorada y marginada por una persona sin discapacidad, en algún lugar.