Si es interactivo, tienes que destacar el foco

Focus styles don't have to be ugly! Focus styles are an integral part of any mature design system. This talk will discuss the intersection of WCAG compliance and Inclusive Design, as well as new focus-related CSS selectors. Additionally, strategies for how to effectively implement them in your organization will be discussed.

Una nueva forma de esconder contenido accesible

En A new (and easy) way to hide content accessibly se explica una nueva forma de esconder visualmente un contenido, pero que siga siendo accesible. Después de un largo análisis, la mejor solución es:

.visuallyhidden {
    border: 0;
    clip: rect(0 0 0 0);
    height: auto; /* new - was 1px */
    margin: 0; /* new - was -1px */
    overflow: hidden;
    padding: 0;
    position: absolute;
    width: 1px;
    white-space: nowrap; /* 1 */
}

La importancia de resaltar el foco

En Focusing on Focus Styles se explica la importancia de resaltar el foco en las páginas web:

Not everyone uses a mouse to browse the internet. If you’re reading this post on a smartphone, this is obvious! What’s also worth pointing out is that there are other forms of input that people use to get things done. With these forms of input comes the need for focus styles. 

People are complicated. We don’t necessarily perform the same behaviors consistently, nor do we always make decisions that make sense from an outsider’s perspective. Sometimes we even do something just to… do something. We get bored easily: tinkering, poking, and prodding things to customize them to better suit our needs, regardless of their original intent. 

People are also mortal. We can get sick and injured. Sometimes both at once. Sometimes it’s for a little while, sometimes it’s permanent. Regardless, it means that sometimes we’re unable to do things we want or need to do in the way we’re used to. 

People also live in the world. Sometimes we’re put into an environment where external factors conspire to prevent us from doing something the way that we’re accustomed to doing it. Ever been stuck at your parents’ house during the holidays and had to use their ancient-yet-still-serviceable desktop computer? It’s like that.

Y se explica el uso de :focus, :focus-within y :focus-visible.

Las imágenes de fondo con CSS y la accesibilidad

Usar las imágenes de fondo con CSS está muy bien, ofrece varias ventajas como poder emplear sprites y así reducir el tiempo de carga de una página web.

¿Todo son ventajas? Pues no, su uso y abuso puede afectar a la accesibilidad de una página web.

¿Cuál es el problema y cómo se resuelve? Se explica muy bien en CSS Background Images and Accessibility.

El contenido oculto

Lo de ocultar cierto contenido de una página web para que lo vean ciertos usuarios, pero otros no, en general no es una buena práctica. Dificulta el desarrollo, dificulta el mantenimiento, y al final puede ser un desastre. Por ello, no hay que abusar de esta posibilidad, pero a veces sí que es una buena solución para ciertos problemas/soluciones (por ejemplo, para ofrecer los enlaces de saltar contenido). Pero se tiene que hacer bien.

El artículo Do not use display:none to visually hide content intended for screen readers nos explica que usar display:none para que no se vea cierto contenido, pero con el propósito de que esté disponible para los usuarios que utilicen un lector de pantallas (screen reader) es un completo error.

En este artículo no se comenta cuál es la mejor técnica para esconder cierto contenido y que esté disponible para los lectores de pantalla. Pero yo eso sí que lo expliqué en mi artículo Técnicas para ocultar contenido.

Bonus, cómo se debería hacer usando WAI-ARIA Hiding visible content from screen readers with aria-hidden.

Un problema importante con ocultar las listas

La teoría dice que aquello que sea una lista lo debes etiquetar como una lista. Por ejemplo, una lista de enlaces. Por ejemplo, los enlaces que forman un menú.

La teoría también dice que si no te gusta la apariencia de la lista, la puedes cambiar con CSS con la propiedad list-style-type o list-style. Con el valor none se logra que la lista no aparezca marcada, pero sigue siendo una lista.

La teoría también dice que los lectores de pantalla seguirán leyendo las listas como listas, sea cual sea su apariencia visual. Los lectores de pantalla ofrecen facilidades para que el usuario se mueva por una lista, como por ejemplo indicarle cuántos elementos tiene la lista y en qué posición en la lista se encuentra en un momento dado.

Esta es la teoría que podemos leer en muchos sitios. Es una teoría "bonita" que tiene mucho sentido.

Pues no, porque parece que la teoría no siempre se cumple.

En el artículo Screen readers, list items and list-style: none nos explican que esto no siempre funciona así. El autor ha hecho pruebas con los lectores de pantalla NVDA, Orca y VoiceOver y ha descubierto que estos navegadores no anuncian las listas cuando list-style-type o list-style toman el valor none.

¿Y qué pasa con JAWS? En el artículo no aparece.

El contenido generado desde CSS: un nuevo problema

En CSS, se usan los pseudoelementos :before y :after para generar contenido que aparece en la página web, como si fuera HTML, pero que no está en el HTML. Es un poco raro, y parece que rompe un poco la separación entre HTML y CSS que se debe lograr.

Pero ahí está la clave: se debe emplear esta característica para generar contenido que realmente no es contenido, sino contenido que forma parte del estilo o de la presentación de la página. Por ejemplo, un escenario típico de uso de esta característica es cuando se le da estilo a las citas (q) y se quiere que aparezcan unas comillas especiales al principio y al final de la cita, o cuando se quiere separar una lista de enlaces con algún símbolo (como ":").

Sin embargo, este uso presenta un problema: según el artículo CSS generated content and screen readers, este contenido generado es leído por muchos lectores de pantalla. Es decir, lo sacamos del HTML para que no lo lean los lectores de pantalla porque es un elemento de decoración, y luego resulta que también lo leen en el contenido generado por CSS.

¿Qué podemos hacer? Usarlo con mucho cuidado, porque ni todos los lectores de pantalla lo leen, ni todos los lectores de pantalla no lo leen. En conclusión: no usarlo para contenido que sea imprescindible.

Cuando se usa :hover también se tiene que usar :focus

Acabo de leer el artículo Whenever you use :hover, also use :focus, que nos explica que usar la pseudoclase :hover sin configurar la clase :focus causa un grave problema de accesibilidad, ya que los usuarios que utilicen el ordenador con el teclado tendrán problemas para identificar el enlace que ha recibido el foco.

Recuerda, configura las dos propiedades a la vez.

Cómo ordenar las propiedades de CSS con prefijos específicos de vendedor

Hace unos meses escribí la entrada Cada vez que llamas a una característica propietaria "CSS3", un gatito muere, que recibió bastantes visitas, seguramente por lo de "un gatito muere". En esa entrada se hablaba de las propiedades de CSS con prefijos de vendedor, como -moz para Mozilla y -o para Opera, que son propietarias del vendedor, es decir, que no forman parte de la especificación oficial, pero que mucha gente cree que sí que forman parte de la especificación. La entrada terminaba con este consejo:

La regla de oro es fácil: evita por completo las características propietarias. No las uses, no las evangelices, y sin duda alguna, no dependas de ellas.

Sin embargo, hay otras propiedades de CSS que forman parte de la especificación oficial (que quizás todavía no ha alcanzado el nivel de recomendación) y aún así también se utilizan con prefijo porque algunos navegadores las soportan de forma experimental o porque no está clara cuál será la forma correcta de usarla (ya que aún no es recomendación oficial).

Cuando se usan estas propiedades, se aconseja escribirlas también sin prefijo, por compatibilidad con los navegadores futuros que sí que la soportaran. Y aquí es donde surge la duda:

¿En qué orden se deben escribir las propiedades con prefijo y sin prefijo?

Siempre he pensado que la propiedad sin prefijo debe ir la última, para que sea la que al final predomine cuando se aceptada por todos los navegadores. Pero alguna vez he discutido con alguna persona por este tema.

Ahora acabo de encontrar el artículo Ordering CSS3 Properties, del año 2010, que explica de una forma muy clara cuál es el problema de escribirlo de una forma u otra y, por tanto, señala cuál es la forma correcta: la propiedad sin prefijo debe ir siempre la última.

Por ejemplo, la forma correcta de utilizar la propiedad border-radius es:

.not-a-square {

  -webkit-border-radius: 10px;

  -moz-border-radius: 10px;

  border-radius: 10px;

}
Y si un artículo no te convence de que esta es la forma correcta, ahí va otro que dice lo mismo: Remember non-vendor-prefixed CSS 3 properties (and put them last).

Diseñador de layouts con roles de WAI-ARIA

YUI CSS Grid Builder es una herramienta gratuita de Yahoo! que permite diseñar maquetas (layouts) o rejillas (grids) de páginas web. Existen muchas herramientas similares a esta, pero me ha sorprendido que este generador incluye la posibilidad de asignar un rol de WAI-ARIA a las distintas partes de la página.

Además, esta herramienta también permite visualizar el orden de lectura del contenido de la página. Al final, existe un botón para generar el código HTML de la página, que hace referencia al framework de CSS de Yahoo!

Recordemos que WAI-ARIA, Accessible Rich Internet Applications 1.0 (que todavía no es una recomendación), proporciona una serie de mecanismos (roles, estados y propiedades) para que las aplicaciones ricas de Internet (rich internet applications) sean accesibles.

Un elemento clave son los roles, que permite definir la función (la semántica) de cualquier parte de una página. Así, por ejemplo, existen roles de tipo widget para definir lo que es un botón o una barra de desplazamiento, roles de tipo estructura de documento para definir las distintas partes de una página como un encabezado o un artículo, y los roles de punto destacado para definir elementos significativos de una página como un formulario o un cuadro de búsqueda.

En la siguiente imagen podemos ver la taxonomía de roles de WAI-ARIA, que es bastante compleja.

Técnicas para ocultar contenido

Hace unos días leí el artículo Hiding content untangled: Hiding vs. moving out of the visible viewport. En este artículo nos explican un caso real de una página web en la que se oculta o esconde cierto contenido, para que no se pueda ver, pero con la intención de que un usuario que utilice un lector de pantallas sí que tenga tenga acceso al contenido. En la página analizada, no se hace bien y el resultado es desastroso.

El típico uso de esta técnica se aplica con los enlaces "saltar a", pero como expliqué hace tiempo en la entrada Enlace de "saltar navegación", en muchos casos puede ser mucho mejor mostrar el contenido a todos los usuarios, ya que quizás no nos demos cuenta, pero puede haber otros usuarios que también se beneficien del contenido que queremos ocultar.

En el artículo que indico al principio se nos explica que desde hace muchos, muchos años, está extendida la idea de que display: none o visibility: hidden esconde el contenido "de la vista", pero sigue estando disponible para un usuario que utilice un lector de pantallas. Sin embargo, esto es totalmente falso, el contenido no está disponible para ningún usuario. Entonces, ¿qué hay que usar para este objetivo?

Antes que nada, según lo anterior, display: none es la mejor opción para lograr otros efectos, como por ejemplo para crear un menú desplegable (dropdown menu): el menú aparecerá y desaparecerá tanto para el usuario vidente como para el invidente.

Si se quiere ocultar cierto contenido sólo a los usuarios videntes, uno de los métodos más sencillos de entender y de aplicar es el posicionamiento fuera de pantalla, que se puede lograr con reglas como text-indent: -999em o top: -999em.

Si se quiere leer un estudio riguroso sobre todas las posibilidades que existen, recomiendo el artículo Ocultar contenido sin comprometer la accesibilidad ni el posicionamiento de la página de Olga Carreras, que realiza un repaso muy exhaustivo sobre las principales técnicas, con sus ventajas y desventajas.

Y si alguien quiere más información, un par de artículos en inglés:

• "Skip Navigation" Links
• Skip Navigation Links

Las características de CSS que mejoran la accesibilidad

He encontrado de casualidad el documento Accessibility Features of CSS. Es una nota del W3C de agosto de 1999 que sólo tiene en cuenta las características de CSS1 y CSS2.

Está claro que CSS mejora enormemente la accesibilidad al permitir separar la estructura/contenido y la presentación de un documento. Además, CSS permite un control preciso sobre la presentación del contenido. Con CSS se puede controlar el espacio, la alineación o la posición de los elementos que componen una página. Por ejemplo, en Espacio entre las letras de una palabra explico que es un error introducir espacios en blanco entre las letras de una palabra para crear un efecto visual, como por ejemplo en un título, ya que eso se tiene que realizar con CSS. O en Texto/Diseño tipográfico se explica cómo controlar la presentación del texto para que sea accesible.

En Accessibility Features of CSS se explica cómo las siguientes características de CSS pueden ayudar a la accesibilidad:

• Spacing, alignment, and positioning:
• text-indent
• text-align
• word-spacing
• letter-spacing
• font-stretch
• margin
• margin-top
• margin-right
• margin-bottom
• margin-left
• float
• position
• top
• right
• bottom
• left
• empty-cells
• User override of styles:
• !important
• inherit
• system fonts
• system colors
• list types
• dynamic outlines (outline, outline-width, outline-style, outline-color)
• Generated content
• :before/:after pseudo-elements
• content
• cue
• cue-before
• cue-after
• Aural style sheets
• volume
• speak
• pause
• pause-before
• pause-after
• cue
• cue-before
• cue-after
• play-during
• azimuth
• elevation
• speech-rate
• voice-family
• pitch
• pitch-range
• stress
• richness
• speak-punctuation
• speak-numeral
• Access to alternative content
• attribute selectors
• attr() function

Holmes, el detective de CSS

Holmes, The CSS Markup Detective es una herramienta muy simple que ayuda a mejorar la calidad y la accesibilidad de las páginas web. Holmes clasifica los errores que detecta en tres tipos:

• Errores, remarcados en rojo.
• Advertencias, remarcados en amarillo.
• Elementos desaconsejados, remarcados en gris.

Entre otras cosas, Holmes es capaz de detectar:

• Atributos requeridos que faltan en etiquetas, como por ejemplo el atributo name en los controles de un formulario.
• Atributos que no existen.
• Elementos desaconsejados (obsoletos) o que no forman parte del estándar.

Además de recuadrar el elemento que presenta un error, Holmes muestra un mensaje de información sobre el elemento que al pasar el cursor del ratón por encima. En la página de ejemplo Test Suite podemos ver cómo funciona y qué errores detecta:

• Enlaces sin el atributo href.
• Imágenes sin el atributo alt.
• Elementos desaconsejados como acronym o center.
• ...

Lo mejor de todo es que es muy fácil de instalar y usar: simplemente, es un CSS que debemos añadir a las páginas que queremos comprobar. Para activarlo, simplemente hay que añadir una clase especial llamada "holmes-debug" a la etiqueta body.

Gracias a esa simplicidad en su uso, se pueden hacer cosas como integrarlo en un gestor de contenidos. En la página Adding  a CSS Markup Detective to Drupal no explican un ejemplo de uso con el gestor de contenidos Drupal.

Cuando esta herramienta se integra con un gestor de contenidos, los creadores de contenido pueden detectar de forma sencilla y por ellos mismos, sin tener que ser experto en HTML, algunos errores que repercuten en la accesibilidad.

Por último, funciona en todos lo navegadores actuales, excepto... lo has adivinado, Internet Explorer.

De los estándares, normas, recomendaciones y otras "tonterías"

En mi anterior entrada, Cada vez que llamas a una característica propietaria "CSS3", un gatito muere, me han dejado unos comentarios interesantes.

Por un lado tenemos, a Álvaro y Rogelio, que comentan como justificación de por qué emplear características propietarias que, si el cliente te las pide, al final tragas. Bueno, todo depende de las "tragaderas" que uno tenga. Un día vi en un restaurante alicantino como salió el cocinero a hablar con unos clientes extranjeros cuando se enteró de que habían pedido ketchup para la paella que había cocinado con mucho cariño. Les dijo que si iban a hacer eso, prefería que se levantasen y se fuesen del restaurante inmediatamente sin pagar nada.

Claro, no se puede comparar el dinero que va a dejar una mesa en un restaurante normalito con el dinero que puede dejar un desarrollo web. Y claro, el dinero es del cliente, y si el cliente lo quiere usar mal, no vamos a ser nosotros los que le detengamos. Pero hay cosas que no se deben hacer: parte de la labor del desarrollador web (o mucho mejor, del agente comercial que trate con el cliente) es asesorar y convencer al cliente de lo que es bueno o malo. Por ejemplo, ¿es bueno hacer un sitio web para que sea compatible con Internet Explorer 6? He oído muchas veces la misma historia en boca de profesionales y alumnos que hacen sitios web: he hecho el sitio web compatible con Internet Explorer 6 porque así lo quería el cliente o el jefe... por ejemplo, porque es el navegador que él usa. Pues el cliente o el jefe se tiene que enterar de que el sitio web no se hace para él, sino para el resto del mundo, y el resto del mundo (incluido Microsoft) pasa de Internet Explorer 6 desde hace tiempo (The Internet Explorer 6 Countdown). En última instancia, si aún así el cliente o el jefe quiere que sea compatible con Internet Explorer 6, lo que se debe hacer es cobrarle una cantidad adicional por el trabajo extra que supondrá lograrlo. Entonces quizás se lo piense dos veces.

Por otro lado, en otros comentarios, Rogelio pregunta por qué se tarda tanto en crear los estándares y Félix cita el artículo Every Time You Make a Good Business Decision, a Puppy Gets Cloned que ha aparecido como respuesta a la "masacre de los gatitos". En este artículo, aunque se comparten muchas ideas aparecidas en el primer artículo, también se defiende el uso de las características propietarias como impulsor de desarrollo web y defiende que los estándares web no se deben tomar como una religión. Esperar a que exista un estándar puede ser pernicioso, pero el uso de no estándares puede ser mucho más pernicioso.

Por ejemplo, en España hemos tenido que sufrir durante muchos años que no hubiese una comunicación directa de la red española ferroviaria con la red de los países vecinos porque el ancho de vía español es superior al europeo. Afortunadamente, las líneas de alta velocidad (AVE) emplean el ancho de vía europeo y poco a poco se va solucionando la situación, después de más de 150 años de existencia del ferrocarril en España.

En todo el mundo hemos tenido que sufrir durante muchos años la ausencia de un estándar en los cargadores de móvil. El impacto ecológico que ha tenido la ausencia de un estándar (millones y millones de cargadores desechados), el impacto en los bolsillos de millones de usuarios que se han tenido que comprar un cargador nuevo porque ninguno de los que tenían en casa les servía, o el inconveniente de no encontrar un cargador adecuado y no poder recargar la batería del móvil, no se puede valor pero seguro que tiene muchos ceros. Afortunadamente, desde el año pasado los fabricantes de móviles emplean un mismo conector de tipo microUSB.

Desgraciadamente, en todo el mundo tenemos que seguir sufriendo la falta de un estándar en los enchufes eléctricos, en el voltaje y en la frecuencia de la electricidad. Algo tan "sencillo", no se ha podido solucionar después de más de 100 años de uso de la electricidad en lo hogares y tenemos que sufrirlo y pagarlo, tanto los usuarios finales como los fabricantes de productos eléctricos.

En la Web hay millones y millones de usuarios. El uso de tecnologías no estandarizadas es un error de cara a los usuarios finales y, para el desarrollador, lo más normal es que suponga un mayor esfuerzo inicial y mayores problemas de mantenimiento futuros.

Esto no significa un NO rotundo a lo no estándar: se puede emplear, pero con cuidado, teniendo en cuenta, por ejemplo, el concepto de mejora progresiva (progressive enhancement).

Mañana escribiré sobre el W3C y veremos su proceso de estandarización (o normalización).

Cada vez que llamas a una característica propietaria "CSS3", un gatito muere

¿Y quién no sufre cuando un gatito muere?

Hace unos días escribí la entrada El dominio de Google y Apple, peor que con Microsoft, en la que comentaba que se debe evitar utilizar las propiedades de CSS específicas de un vendedor, las que comienzan con un prefijo como -webkit- o -moz-. Acabo de leer el artículo Every Time You Call a Propietary Feature "CSS3", a Kitten Dies (publicado en A List Apart, referencia en el desarrollo web y en defender el uso de los estándares), que incide sobre el mismo tema.

A continuación, la traducción de algunos de los párrafos más interesantes del artículo:

Anuncio de servicio público: Cada vez llamas a una característica propietaria "CSS3", un gatito muere. Cualquier característica -webkit- que no exista en una especificación (ni siquiera en el borrador del editor) no es de CSS3. Sí, normalmente son evangelizadas como tales, pero no son parte de CSS, absolutamente. Esta distinción no es excesivamente puntillosa. Es importante porque anima a ciertos vendedores(*ejem* Apple *ejem*) a eludir el proceso de estandarización, les anima a poner en práctica todo lo que venga con WebKit, y a continuación a evangelizarla a los desarrolladores como la mejor cosa desde el pan en rebanadas. Los juguetes nuevos y relucientes nos deslumbran y empezamos a promocionarlos, contribuiyendo a la cámara de resonancia.

En nuestro afán por utilizar la última novedad, a menudo nos olvidamos de cuánta gente luchó en la última década para que nosotros podamos escribir código sin bifurcaciones y trucos y esperar que sea interoperable. Si has estado en este campo más de unos pocos años, seguramente recordarás que no siempre fue así. La razón por la que ahora tenemos esta comodidad es gracias a los estándares web, duramente ganada en la guerra de los navegadores (Browser Wars). 

[...] 

Las características propietarias que no han pasado a través del proceso de normalización, por lo general sufren de un diseño pobre, aun cuando la idea general sea buena. Por ejemplo, los gradientes en CSS fueron una gran idea, pero -webkit-gradient() era un gran lío susceptible de numerosos errores. Los tipos de letra web son una gran idea, pero requerir el uso de los ficheros .eot no lo fue. El proceso de normalización no sólo ayuda a lograr la interoperabilidad, sino que también ayuda a mejorar el diseño de cada función, debido a la mayor cantidad y diversidad de opiniones. 

Así que, ¿cuáles son esas características infames? En CSS, algunas de las más populares son:

• -webkit-box-reflect

• -webkit-text-stroke

• -webkit-mask

• -webkit-background-clip

• -webkit-text-size-adjust

• -webkit-tap-highlight-color

• -webkit-text-fill-color

No todas las características que lleven el prefijo del vendedor tienen que ser propietarias. Algunas de ellas son sólo las implementaciones experimentales de características incluidas en los borradores de las especificaciones. 

[...] 

La regla de oro es fácil: evita por completo las características propietarias. No las uses, no las evangelices, y sin duda alguna, no dependas de ellas.

Para finalizar, en el artículo The Future of CSS: Experimental CSS Properties, podemos encontrar una lista de características propietarias QUE NO DEBEMOS UTILIZAR (aunque en ese artículo nos inviten a ello). Además, en la mayoría de los casos, su utilidad es bien escasa.

El dominio de Apple y Google, peor que con Microsoft

No lo digo yo, lo dice la noticia W3C co-chair: Apple, Google power causing Open Web crisis, que salió ayer publicada en CNET. El resumen de la noticia dice:

The dominance of Apple and Google mobile browsers is leading to a situation that's even worse for Web programming than the former dominance of Internet Explorer, a standards group leader warned today.

Traducido al castellano:

El dominio de Apple y Google en el mercado de los navegadores para móviles está llevando a una situación que es aún peor para la programación web que con el antiguo dominio de Internet Explorer, un líder del grupo de estandarización advirtió hoy.

El problema que se explica en este artículo es que muchos programadores web se están centrando en los navegadores de Apple y Google, ambos basados en WebKit, y por contra, se están olvidando de los navegadores Firefox, Internet Explorer y Opera. Esto está ocurriendo porque los navegadores de Apple (Safari) y de Google (Chrome) son los mayoritarios entre los dispositivos móviles (teléfonos), que es el segmento de dispositivos con conexión a Internet que más está creciendo en los últimos años.

Muchos programadores web emplean propiedades de CSS específicas para estos dos navegadores. Estas propiedades, que comienzan con el prefijo -webkit, puede ser que ya estén estandarizadas o que estén camino de serlo y, por tanto, que sean compatibles con otros navegadores. Pero al anteponer el prefijo específico del vendedor, sólo funcionan en el navegador especificado.

Esto es un completo error, y se debe evitar utilizar las propiedades de CSS específicas de un vendedor. Pero si por alguna razón es imprescindible su uso, entonces lo más conveniente es emplear la propiedad sin el prefijo (para que el CSS sea compatible con las futuras versiones de los navegadores) y con el prefijo de los navegadores más populares, para que sea compatible con los navegadores actuales.

Por ejemplo, si se quiere emplear la nueva propiedad transform de CSS3, lo correcto es:

div
{
  transform: rotate(7deg);
  -ms-transform: rotate(7deg); /* IE 9 */
  -moz-transform: rotate(7deg); /* Firefox */
  -webkit-transform: rotate(7deg); /* Safari y Chrome */
  -o-transform: rotate(7deg); /* Opera */
}

Si no se hace así, algunos grupos de usuarios podrán sufrir problemas en el uso. Ni más ni menos que un problema de accesibilidad web, en esta ocasión producido por una discriminación tecnológica.

Un par de ejemplos de diseño responsive

"Responsive web design" es un nuevo término que, aunque ya se lleva más de dos años hablando de él en el mundo del desarrollo web, en los últimos meses ha cobrado mucha más fuerza.

Al español se podría traducir como diseño web sensible, pero como con cualquier neologismo, es mejor esperar un poco y ver qué termino emplea el público español. En pocas palabras (próximamente quiero publicar una entrada sobre este tema), el diseño web sensible consiste en ofrecer sitios web con diferentes diseños según el dispositivo que utilice el usuario.

Un par de ejemplos:

• El sitio web Fluid Squares v2. A responsive grid experiment, emplea esta técnica: además de cambiar el número de columnas (esto es algo normal en cualquier diseño líquido y se lleva empleando muchos años), donde se aprecia realmente que es un diseño sensible es en el cambio del tamaño del texto y el cambio en la imagen. Por cierto, son muy interesantes todos los enlaces que contiene esta página.
• En mi página de promoción del curso Introducción a la accesibilidad web, he aplicado un diseño sensible al tamaño de la ventana del navegador y ofrezco tres visualizaciones distintas:

Hasta 1024 píxeles de ancho:

 


Entre 1025 y 1600 píxeles de ancho:



Más de 1600 píxeles de ancho:

[Actualización 17/04/2012]

Un artículo muy interesante en el que se propone el término diseño web adaptable: Diseño web sensible. ¿¿¿Sensible???

Tipografía web, ¿mejorará la accesibilidad?

La tipografía web (web typography) ha sido durante muchos años un punto débil del diseño web.

Los diseñadores de otros medios tradicionales, cuando empezaban en la Web querían emplear alguno de los cientos de tipos de letra que estaban acostumbrados a usar, y los programadores contestaban que no podían.

Los clientes pedían a gritos usar tal o cual tipo de letra que tenían en su ordenador y era muy difícil hacerles entender que no era posible, que había que utilizar y limitarse a Arial, Courier, Times New Roman, Verdana y poco más.

¿Qué problemas había con los tipos de letra?

Primero, no todos los ordenadores disponían (y disponen, ya que sigue igual en la actualidad) de los mismos tipos de letra y no existía un método para que se pudiese descargar y utilizar un tipo de letra que no existiese en el ordenador de forma transparente al usuario. Este problema se resolvió hace tiempo, pero la mayoría de los programadores y diseñadores lo desconocían (y muchos, la mayoría, lo desconocen todavía).

Segundo, no existía (ni existe) un formato de tipo de letra estándar y admitido por todos los dispositivos y sistemas.

Tercero, los tipos de letra tienen copyright, existe un comercio de tipos de letra, y no se pueden utilizar "libremente". Si se quería utilizar un tipo de letra "exótico" era necesario pagar una licencia.

Para solventar este problema, se emplearon todo tipo de técnicas, como poner una imagen con el texto o usar Adobe Flash para mostrar un texto. Pero estas técnicas  penalizaban la indexación del contenido de las páginas (el famoso SEO) y eran muy innaccesibles: para un ciego, el texto en una imagen no existe, a no ser que se proporcione un texto alternativo.

A su vez, para solucionar estos problemas, se desarrollaron unas técnicas llamadas reemplazo de imágenes (image replacement), como por ejemplo Fahrner Image Replacement, que lo que hacían era colocar un texto y encima, tapando el texto, una imagen con el texto mostrado con el tipo de letra que quería el diseñador.

Pero estas técnicas eran complicadas y artificiales, requerían mucho trabajo por parte del programador, en algunos casos eran incompatibles entre navegadores y no existía la técnica "perfecta" (siempre había alguna desventaja importante).

Afortunadamente, este panorama parece que va a cambiar y eso redundará en una mejora de la accesibilidad de las páginas web. Parece que los escollos que existían para poder descargar los tipos de letra se han solucionado con Web Open Font Format, un formato de tipo de letra específico para la Web.

Si, además, le sumamos que ya existe una gran variedad de tipos de letra de mucha calidad y gratuitos, como por ejemplo 10 Great Free Fonts for @font-face embedding o 40+ Excellent Freefonts For Professional Design, parece que ya tenemos la solución completada. ¿O no?

Por último, un par de artículos que nos orientan a la hora de crear (o elegir) una tipografía:

• On Web Typography
• Real Web Type in Real Web Context

Enlaces que no son enlaces

Hace unos días, un amigo me pasó la web que le había hecho una empresa para su negocio. Le eché un vistazo de 5 minutos y encontré un error muy, muy grave de accesibilidad. Además, este error también era importante para el tema de buscadores y posicionamiento.

El error era que el menú o barra de navegación del sitio web se había implementado mediante etiquetas <div> con el atributo onclick y código JavaScript para simular la función de enlace. Para un usuario que utilice un lector de pantallas, para un usuario que utilice un navegador en modo texto o para un buscador, estos "enlaces" no existen y, por tanto, no se puede acceder al contenido del sitio web.

En mi ejemplo Enlaces que no son enlaces explico este error y proporciono dos posibles soluciones.

Hoja de trucos del W3C

Hace unos pocos días se lanzó W3C cheatsheet, la hoja de trucos del W3C para desarrolladores web. Según nos cuentan en el blog del W3C:

This cheatsheet aims at providing in a very compact and mobile-friendly format a compilation of useful knowledge extracted from W3C specifications — at this time, CSS, HTML, SVG and XPath —, completed by summaries of guidelines developed at W3C, in particular the WCAG2 accessibility guidelines, the Mobile Web Best Practices, and a number of internationalization tips.
Its main feature is a lookup search box, where one can start typing a keyword and get a list of matching properties/elements/attributes/functions in the above-mentioned specifications, and further details on those when selecting the one of interest.

Por ahora, ofrece información sobre:

• Las especificaciones HTML, CSS, SVG y XPath.
• Mobile Web Best Practices
• Accessibility: WCAG2 at a Glance
• Internationalization Quicktips
• English Typography