¿Qué diferencia hay entre los términos tipografía y fuente?

Gracias al podcast de Don Serifa (y más en detalle, en el artículo De la definición de tipografía (Boletín 14)) me doy cuenta de que dos términos que utilizaba indistintamente, en realidad no significan lo mismo. Hablo de tipografía y fuente. Aquí van un para de definiciones inexactas, pero útiles para distinguirlas.

Tipografía
Tipo de letra. Diseño de los caracteres de un sistema de escritura que comparten un diseño visual común
Fuente
Representación física (tipos de metal, madera,…) o digital (ficheros True Type Font [TTF], OpenType Font [OTF], Embedded Open Type [EOT], Web Open Font Format [WOFF],…) de una tipografía.

¿Ejemplos de tipografías? Garamond, Bodoni, Century Expanded y Helvetica (lectura complementaria en Las fuentes de Massimo Vignelli). Utilizando como analogía la teoría de Platón, sería el mundo de las ideas.

¿Ejemplos de fuentes? Cualquiera de los ficheros alojados en nuestros dispositivos o en internet que se utilizan para materializar esas tipografías en programas, documentos o sitios webs. Y sí, también los tipos de plomo guardados en los cajones de un mueble de imprenta.

Ocho viejos errores que siguen sin solucionarse en la web actual

Pasan los años, avanzan los estándares, evolucionan los navegadores, vienen nuevos desarrolladores y nuevas paradigmas de desarrollo (con abundante e incluso excesivo javascript, que no falte), pero hay errores que, a pesar del paso del tiempo, siguen estando presentes. Aquí van algunos:

Error 1: No identificar el idioma (lang) de una página adecuadamente

Es un pequeño detalle, pero muy importante. Si una página está en inglés (en), español (es), francés (fr), chino (zh), esukera (eu), catalán (ca), gallego (gl),… debe estar especificado en el código fuente. Por ejemplo <html lang="lt"> para una página en latín.

Simplificando mucho: para el valor del atributo lang se emplea un valor ISO-639-1. También se puede añadir el código del país tras un guión, como lang="es-es" para español de España. Pero puede ser bastante más complejo, como se puede consultar en Tags for Identifying Languages.

Error 2: No incluir un título apropiado para la web (title), ni para el contenido (h1)

Los elementos title y h1 nos ofrecen la posibilidad de resumir el contenido de una página web en unas pocas palabras (a personas y buscadores). Es una irresponsabilidad no utilizarlo adecuadamente. Tal vez, y salvo excepciones, una buena elección sea usar el título del documento para el h1, el mismo literal acompañado del nombre del dominio para el título.

Error 3: Usar textos ambiguos en enlaces (por ejemplo «aquí»)

El clásico error: usar términos como texto de un enlace que no tiene ningún significado leído fuera de contexto. ¿A qué me refiero? Usar textos como «aquí», «enlace» ó «página» no aportan nada de información.

Si para saber dónde nos lleva un enlace tenemos que leer el párrafo entero o la frase en la que está el vínculo, cometemos un grave error doble:

  • Hacemos perder el tiempo a los usuarios
  • Perdemos una buena oportunidad de mejorar el posicionamiento web.

Mi consejo: usar el título del documento de destino como texto del enlace.

Curiosidad SEO: hace años al buscar «aquí» en Google nos mostraba la página de descarga de Adobe Acrobat Reader. El obvio motivo es la infinidad de vínculos con el texto «aquí» que enlazaban esa página. De ahí la importancia para el posicionamiento de los enlaces.

Error 4: No diferenciar apropiadamente los enlaces mediante estilos

Otro serio problema: no diferenciar con claridad, los enlaces del texto que le rodea. ¿Dónde puedo hacer click, tocar? En no pocas ocasiones, al prescindir del clásico subrayado, perdemos un factor importante para diferenciar un enlace de un texto normal. En ocasiones el único.

Hay un porcentaje importante de usuarios con discromatopsia ( incapacidad para distiguir ciertos colores). Y en general, desde el punto de vista de la accesibilidad, es una mala práctica usar el color para transmitir información: por ejemplo que la única forma de distinguir un enlace sea por el color del texto.

Obviamente hay situaciones, como menús de navegación y enlaces con apariencia de botones, en los que el subrayado no es necesario. Pero en el resto de los casos, recomiendo subrayar los enlaces. Facilita mucho a los usuarios encontrarlos y evita frustración… por no hablar de evita perder visitas.

Error 5: No incluir alternativa textual (alt) en las imágenes

En HTML5 también está figcaption, pero alt sigue teniendo toda su vigencia e importancia: describir textualmente una imagen, ya sea para las personas o para los buscadores es una obligación moral y técnica.

Error 6: Insuficiente contraste entre el texto y el fondo

Entiendo que el color (y el contraste) es una forma que funciona para destacar unos elementos sobre otros. Pero se sobrepasa con demasiada frecuencia el límite del contraste mínimo: pensad que se pueden dar situaciones de iluminación nada óptimas (el móvil en la calle acompañado de un pequeño tamaño del texto), discapacidades visuales (la edad, la mencionada discromatopsia que dificulta diferenciar colores,…) y no tiene sentido incluir un texto que no se puede leer en cualquier contexto.

Siendo más concreto: no entiendo (ni comparto), el uso de fondo oscuro (casi negro) con un texto minúsculo en color gris medio.

¿Cómo remediarlo? con herramientas como contrastchecker.

Error 7: Que la web no se visualice apropiadamente en un teléfono móvil

La aparición del iPhone (2007) ha sido sin duda un hito en el desarrollo de la web móvil. Más de diez años más tarde, no tiene sentido que una web no se visualice apropiadamente en un teléfono móvil corriente.
Sorprende, que en numerosos casos, hay más usuarios que acceden a una web desde un teléfono móvil que desde ordenadores de sobremesa. Pensemos además en que pueden tener una conexión lenta, o ciertas restricciones en el uso de datos (que se consumen con mucha facilidad).
La cifra de personas que acceden a una web desde un teléfono móvil debería ser uno de los datos más importantes a la hora de desarrollar web y pensar que un exceso de recursos (kilobityes de imágenes, scripts, estilos,…) repercute negativamente y aleja a los posibles usuarios.

Error 8: Que no cumpla unos requisitos mínimos de accesibilidad.

Las WCAG 1.0 se publicaron como recomendación en el año 1999. La segunda versión (WCAG 2.0), se publica en el 2008 y la última (WCAG 2.1), en el año 2018. La legislación ha ido, con cierto retraso, siguiendo los pasos del W3C, pero ahí tenemos en Europa y España las últimas novedades (leer Disponible la UNE-EN 301549:2019 de accesibilidad para tener algo más de información).

Impedir o dificultar el acceso a una web a una parte nada despreciable de personas, es una imprudencia. Y si entramos en términos morales, una discriminación inmerecida. Si el argumento moral no funciona, tal vez sea más convincente el asunto de la pérdida de visitas o beneficios por ventas, oportunidades de negocio o publicidad.

Apunte final: la mayor parte de los errores aquí mencionados están muy relacionados con la accesibilidad. Da para una pensada en profundidad.

El botón de los 300 millones de dólares. Diseñar un botón como ejercicio

El botón de los 300 millones de dólares

¿Conocéis la vieja historia del botón de los 300 millones de dólares que contó Jared M. Spool en el 2009 (The $300 Million Button)? Es interesante. Cómo al cambiar, entre otras cosas, el texto de un botón, mejoró en 300 millones de dólares las ventas anuales en una web de comercio electrónico.

¿Qué ocurrió? ¿cómo pudo afectar tanto a las ventas el cambio de un botón?
Contexto: en una web de comercio electrónico, al comenzar el proceso de compra tras tener el carro con la compra deseada, aparecía un formulario en el que se pedía el usuario, la contraseña, y la posibilidad de entrar en la página web (para confirmar la dirección de entrega y el medio de pago) o la de darse de alta. Ah, y también el enlace de olvido de contraseña.

Es decir, algo como:

Campo de usuario, contraseña, botón de acceso y vínculos de olvidé mi contraseña y darme de alta.
Recreación libre del formulario del carro de la compra.

¿Qué problemas podían haber (recordemos, año 2009)? De todo tipo:

  • Usuarios que no quieren registrarse en la web (sólo querían comprar).
  • Usuarios dados de alta que dudan cuál es la dirección de correo electrónico que tienen como usuario.
  • Usuarios que se habían dado de alta con varias direcciones de correo electrónicas diferentes.
  • Usuarios que no recuerdan la contraseña.

La consecuencia: en esa página se producía un cuello de botella que impedía finalizar la compra.

La solución: tras realizar pruebas con usuarios, pasa por cambiar el literal de un botón (de «darse de alta» a «continuar»), e incluir un texto indicando que se puede comprar sin darse de alta.

El resultado: 15 millones más de ventas en un mes, y 300 millones en un año (de ahí el sugerente título del artículo para los que se excitan con dólares).

Diseñando un botón: un elemento fundamental

Siempre me ha intrigado el proceso que está detrás de la toma de decisiones en un diseño. El porqué.

Porque se supone que detrás de una decisión de diseño (particularizando en una página web: fuente, tamaño, color, posición, rejilla,…) debería haber motivos que fundamentan esa decisión. ¿Cómo ejercitar esa habilidad o conocimiento?

What if, instead of trying to design an entire page with dozens of elements (nav, text, input controls, a logo, etc.), we consciously started by designing the simplest thing possible? We deliberately limit the playing field to one, tiny thing and see what we learn? Let’s try.

What is the simplest possible element? I vote that it’s a button.

The King vs. Pawn Game of UI Design — Erik D. Kennedy

Enumeremos algunas características de un simple botón:

  • tamaño
  • texto
  • fuente
  • tamaño y efecto de la fuente
  • color de fondo (¿gradiente de colores?)
  • color del texto
  • acompañar o no de un icono
  • padding (separación del texto y el borde)
  • margen (separación entre el botón y el resto de los elementos)
  • forma (esquinas cuadradas, redondeadas, radio de la redondez)
  • tipo de acción que realiza (continuar un proceso, acción «peligrosa», acción neutra, acción principal, acción secundaria,…)

Podemos delegar varias características al estilo por defecto que tenga el navegador (en el caso de una página web), o a algún framework con posibles síntomas de vigorexia.

O podemos diseñar un simple botón. Con el objetivo de cumplir los requisitos del proyecto (real o ficticio). Intentando argumentar cada característica. Me parece un ejercicio muy saludable.

¿Qué falla en un diseño? El test de Can’t Unsee

Hace casi diez años (sí diez años), publiqué por el blog diseño, creatividad y dos test en el que hacía referencia a dos test de Andy Rutledge de los que se podía aprender mucho: en un test aparecía la solución, en otro había que investigar más… . Al final, una de las conclusiones es que la lectura de Universal Principles of Design, Revised and Updated era muy recomendable para conocer las respuestas al test y mucho más.

Con diferencia, Universal Principles of Design es el libro con el que más he aprendido.

Hoy recomiendo dar un vistazo a Can’t Unsee. Un test en el que vemos dos versiones sutilmente diferentes en el que hay que elegir aquella opción de que está mejor diseñada. ¿La diferencia? En ocasiones es muy sutil: es cuestión de detalles. Y ya sabemos…

Los detalles no son detalles, son lo que define el diseño.

Charles Eames

Disponible la UNE-EN 301549:2019 de accesibilidad web y aplicaciones móviles

Ya está disponible la UNE-EN 301549:2019, la norma sobre accesibilidad web y aplicaciones móviles. Primero de pago en la Asociación Española de Normalización (une.org: UNE-EN 301549:2019) y más tarde en el portal de Administración Electrónica de forma gratuita en formato PDF, administracionelectronica.gob.es: UNE-EN 301549:2019.

Se anunció en Disponible la Norma UNE-EN 301549:2019 en el PAe.

¿Qué es la UNE-EN 301549:2019?

En pocas palabras es una norma técnica sobre la accesibilidad de los sitios web y aplicaciones para dispositivos móviles de los organismos del sector público. En la norma se establecen los condicionantes, con respecto a su accesibilidad, que deberán cumplir todos los sitios web y aplicaciones móviles del sector público: estatal, regional, local, universitario, etcétera incluyendo también a los de los servicios gestionados por éstos entes como centros sanitarios y educativos, bibliotecas públicas, tribunales y órganos constitucionales, etcétera.

Origen de la norma UNE-EN 301549:2019

De nuevo, simplificando mucho, la cadena que empieza por las recomendaciones del W3C sobre la pautas de accesibilidad del contenido web, al final influye en la legislación europea (Directiva UE 2016/2012) que a su vez se traslada a la legislación española (el Real Decreto 1112/2018 traspone la directiva europea). Con respecto a la legislación, está “todo” dicho. Con respecto a los normas técnicas (o estándares),… se redactan diferentes versiones de la EN 301 549 (a día de hoy, la última, que incluye la versión WCAG 2.1 es la EN 301 549 V2.1.2) que a su vez se traslada a la norma española: la UNE-En 301549:2019 de la que estamos hablando.

La norma, de casi 200 páginas, presenta una serie de requisitos para diferentes contextos:

  • Requisitos genéricos
  • Comunicación bidireccional por voz
  • Video
  • Hardware
  • Web
  • Documentos no web
  • Software
  • Documentación y servicios de apoyo
  • Acceso a servicios de emergencia

Tiene también dos tablas, una que muestra los criterios de accesibilidad de páginas webs (Tabla A.1) y otra sobre accesibilidad de aplicaciones móviles (Tabla A.2).

Por último, el anexo C, determinación de conformidad, recoge los medios necesarios para determinar la conformidad con los requisitos individuales que figuran en el cuerpo del documento. Casi cien páginas en el que aparecen todos los requisitos –algunos, recordemos, originarias de las WCAG 2.1–, y las condiciones para superar o no los requisitos de accesibilidad.

Importancia de la UNE-EN 301549:2019

Sin duda, la UNE-EN 301549:2019 es un documento de gran importancia, no sólo para los profesionales y empresas relacionados con la Administración Pública (se tiene que aplicar), también en general, para los que están interesados en la accesibilidad web: el hecho de proponer unas pruebas para verificar o no el cumplimiento de los requisitos (y pautas) creo que tiene mucho valor, ya que, aparte de saber cómo comprobar los requisitos, permitirá evitar, en cierta medida, los sesgos que surgen al interpretar los requisitos.

Modelo europeo de declaración de accesibilidad para el sector público

Como epílogo, ya que reunimos de forma indirecta algunas novedades de los últimos meses sobre accesibilidad web (por ejemplo, la versión 2.1 WCAG), menciono otro documento, también importante: recomendaciones para realizar el modelo europeo de accesibilidad. Hablamos de “ése enlace” que pone accesibilidad en el pie de las webs. El documento puede servir de referencia y no sólo para las webs (y aplicaciones móviles) de las administraciones públicas.

 

Un para de detalles importantes: En las administraciones públicas debe tener el 20 de septiembre del 2019 (para sitios nuevos) o el 20 de septiembre del 2020 (para las webs ya publicadas) un ente (persona, grupo, departamento, unidad,…) encargado de recibir las comunicaciones sobre requisitos de accesibilidad, que además de poder presentarse mediante un correo electrónico o formulario, debe tener al menos un canal complementario, que puede ser u teléfono o una oficina física.

Otra unidad, departamento, grupo… que debe existir es la Unidad Responsable de Accesibilidad (artículo 16 del Real Decreto 1112/2018 ya mencionado).

La pregunta final: ¿se cumplirá?

Referencias