Usable y accesible

Ocultar contenido sin comprometer la accesibilidad ni el posicionamiento de la página

2011-11-13T03:01:00.003+01:00

Artículos relacionados:

El objetivo del artículo es explicar cuál es la mejor manera de ocultar visualmente contenido de una página web de tal manera que:

no comprometa el posicionamiento de la página con prácticas sancionables por Google
asegure la accesibilidad de las páginas para aquellas personas que utilicen lectores de pantalla

La idea de este artículo ha surgido a raíz de la conversación que ha suscitado mi último consejo de accesibilidad en Twitter: “Si quieres ocultar contenido pero que sea accesible para los lectores de pantalla NO uses display:none, usa text-indent:-999px”

Por tanto no lo hubiera escrito si no lo hubieran comentado: @cssbarcelona, @cottonfieldsbcn, @davidhidalgo, @martuishere, @ericalarcon, @htmlboy, @josegemar y @noekidotcom

¿Qué texto podemos desear ocultar? ¿deberíamos ocultarlo?

En un desarrollo accesible hay dos ejemplos típicos y habituales en los que se plantea ocultar texto:

el enlace “Saltar al contenido” que suele incluirse al comienzo de las páginas. Según la encuesta “Survey of Preferences of Screen Readers Users” de WebAim de 2009, el 38% de los usuarios de lectores de pantalla lo utiliza siempre que puede o a menudo y el 24% algunas veces (otros prefieren saltar de encabezado en encabezado). Recordemos que incluir este tipo de enlace es de prioridad AAA en las WCAG 1.0 (punto de verificación 13.6) y de prioridad A en las WCAG 2.0 (criterio de verificación 2.4.1)
el texto complementario a los enlaces del tipo “Leer más”, puesto que deben evitarse enlaces con el mismo texto pero con vínculos a páginas diferentes. Por tanto, cada uno de los enlaces “Leer más” (por ejemplo asociados a los titulares de varias noticias) es en realidad “Leer más sobre la Noticias 1”, “Leer más sobre la Noticia 2”, pero el texto que sigue a “Leer más” se oculta a la vista. Recordemos que evitar este tipo de enlaces con texto igual pero vínculo diferente es un requisito AA en las WCAG 1.0 (punto de verificación 13.1) y A o AAA en las WCAG 2.0 en función de si es comprensible el enlace en el contexto (criterio de verificación 2.4.4 y 2.4.9)

Por tanto se dan casos en los que para cumplir con las pautas de accesibilidad puede que pensemos que hay que ocultar algún texto. Digo que “puede que pensemos” puesto que antes de tomar esta decisión habría que meditar si es realmente necesario o conveniente ocultarlo.

Por ejemplo, en el primer caso, si bien es cierto que el enlace “Saltar al contenido” beneficia a los usuarios que utilizan lectores de pantalla porque les permite alcanzar el contenido principal de una forma sencilla y rápida (evitándoles escuchar la cabecera y el sistema de navegación en todas las páginas antes de llegar al contenido) también beneficia a las personas que acceden con el teclado, a aquellos que utilizan magnificadores de pantalla o a los que acceden desde un dispositivo móvil.

Sería por tanto recomendable incluirlo siempre visible, pero a veces se imponen otros criterios estéticos. Solo quería dejar ahí la reflexión. Pasemos ahora a ver, si los ocultamos, cómo deberíamos hacerlo.

Display:none

Aplicar el estilo display:none a un elemento de una página lo hace totalmente invisible: no genera una caja, no ocupa lugar, no afecta a la disposición. Oculta el elemento y sus descendientes no sólo visualmente sino también a los lectores de pantalla.

Para saber exactamente cómo interpretan diferentes lectores de pantalla display:none (pues no es cierto que todos los lectores de pantalla en todos los casos y con todos los navegadores no lean un elemento oculto con display:none) recomiendo el artículo de agosto de 2011 “JAWS, Window-Eyes and display:none: Return to 2007” de Jason Kiss.

Sobre el uso de display:none recomiendo el artículo “Do not use display:none to visually hide content intended for screen readers” de Roger Johansson.

Visibility:hidden

Con visibility:hidden ocurre algo similar, el contenido así oculto no siempre será leído por los lectores de pantalla, pero estos tampoco lo interpretan como un display:none. Por eso, cuando lo que se quiere es que algo esté oculto visualmente y oculto para todos los lectores de pantalla (lo contrario que estamos tratando aquí, que queremos ocultarlo visualmente pero que sea leído por los lectores de pantalla) lo que se recomienda es que se oculte con ambos:

.hide { display: none; visibility: hidden; }

Recomiendo leer el artículo “Screen readers sometimes ignore display:none” de Roger Johansson y el estudio “Empty Links and Screen Readers” de yuiblog.com donde se muestran esquemáticamente los resultados de utilizar display:none y visibility:hidden con diferentes navegadores y lectores de pantalla.

En cualquier caso, ni display:none ni visibility:hidden cumplirían el requisito que necesitamos de que el texto oculto sea leído por todos los lectores de pantalla.

Height:0

.element-invisible { height: 0; overflow: hidden; position: absolute;}

Hubiera estado bien, pero Jeff Burnz indica en “Using CSS clip as an Accessible Method of Hiding Content”, que desgraciadamente, aunque NVDA y Jaws leían el contenido, Apples Voice Over no lo lee.

Posicionar el texto fuera de pantalla

Por ejemplo con text-indent:-999em (no aplicable a los lenguajes que se leen de derecha a izquierda) o top: -999em;

Esta técnica es accesible para los lectores de pantalla. Pero debe tenerse en cuenta también a los usuarios que no usan un lector de pantalla y asegurarse de que el foco se haga visible. No puede ser que una persona que accede con el tabulador pierda el foco porque este se ha ido a una serie de elementos ocultos situados fuera de pantalla, de tal manera que debe tabular varias veces, sin saber dónde está el foco, hasta que este vuelve a ser visible.

Fijaros cómo lo resuelve la página Department of Homeland Security

a#skip, a#skip:hover, a#skip:visited {position:absolute; top:-100px; width:1px; height:1px; overflow:hidden; font-size:x-small;} a#skip:active, a#skip:focus {position:static;width:auto;height:auto;text-align:center;margin:0 auto} <a href="#content" id="skip" accesskey="2">Skip Navigation</a>

El enlace está fuera de pantalla, pero cuando el enlace coge el foco este se hace visible.

Os recomiendo también el artículo “Skip Navigation Links” de James W. Thatcher, donde recuerda también el tema del tabindex=”-1” y las anclas en Explorer.

Puede parecer entonces que esta opción, bien implementada, sería la solución ideal. Sin embargo surge la duda de si podemos tener un problema con el posicionamiento de la página.

Google dice que penaliza el contenido que se oculta, y contenido con text-indent negativo parece fácil de rastrear. Da igual que lo incluyas en la CSS porque también analiza las CSS. Si las restringimos en el fichero “robots.txt” no quiere decir que Google no pueda acceder a ellas y entonces puede que sí seamos realmente sospechosos.

¿Se debe por tanto dejar de utilizar text-indent negativo por miedo a ser penalizado? He estado leyendo experiencias de mucha gente y todos parecen coincidir al final en lo mismo: lo utilizan sin sufrir penalización cuando se hace sin intención maliciosa, es decir, cuando el texto oculto no incluye un relleno de palabras clave, así lo dicen incluso desde Google, cuya página, al fin y al cabo también utiliza el posicionamiento fuera de pantalla.

Resultan muy ilustrativos los comentarios del artículo ”Google, SEO and using CSS to hide text” o el artículo “Demystifying Google's text-indent mystery”

En fin, que después de horas leyendo no he encontrado a nadie que diga que utilizando text-indent de forma legítima, como los ejemplos que he expuesto, le hayan penalizado.

Aun así nos queda una última técnica.

Clip

.element-invisible { position: absolute !important; clip: rect(1px 1px 1px 1px); /* IE6, IE7 */ clip: rect(1px, 1px, 1px, 1px); }

Está técnica es explicada en “Using CSS clip as an Accessible Method of Hiding Content”. Según se indica, el texto así oculto trabaja en todos los navegadores y es leído por Jaws, NVDA y Apple Voice Over. En realidad hay que retocarlo para que esto sea realmente así según se explica en “Clip your hidden content for better accessibility”, de Thierry Koblentz.

Esta técnica la podemos mejorar para el tema del foco (cuando lo que ocultamos son elementos que cogen el foco, por ejemplo un enlace), tal y como veíamos en el ejemplo anterior, de tal manera que cuando coja el foco ponemos "clip" a "auto" y "position" a "static"

Por otra parte, Google no penaliza esta práctica. Así que parece la solución ideal: accesible y no compromete el posicionamiento. Pero siempre hay una pega, en este caso que clip: rect(1px 1px 1px 1px); no pasa el validador de sintaxis CSS. Resulta que IE6 y IE7 no siguen la especificación y para que funcione en estos navegadores los parámetros deben separarse sin comas.

Mi opinión es que, si las definiciones específicas para determinados navegadores:

no provocan conflictos con otros navegadores
no suponen un problema de accesibilidad
se agrupan en una CSS independiente

no deben coartar que se utilicen en aras precisamente de mejorar la accesibilidad de las páginas.

Conclusión

No usar display:none, visibility:hidden, ni height:0, puesto que no aseguran la accesibilidad de los textos ocultos en todos lectores de pantalla.
Se puede usar el posicionamiento fuera de pantalla porque es accesible, siempre y cuando lo utilices de forma lícita y no para incluir palabras clave, de lo contrario puedes ser penalizado.
Se puede usar la técnica del clip porque es accesible y no provoca problemas con el posicionamiento de la página, pero tienes que ser consciente de que la CSS no pasará el validador de sintaxis del W3C.

Artículos relacionados:

SEO y Accesibilidad. Accesible también para buscadores

2011-02-20T20:56:00.009+01:00

Recursos "Usable y accesible" relacionados:

Tu usuario más importante es ciego. La mitad de las visitas a tu sitio vienen de Google, y Google sólo ve lo que un ciego puede ver. Si tu sitio no es accesible, tendrás menos visitas. Fin de la historia.
- Steven Pemberton -

Todas aquellas acciones que llevamos a cabo para hacer nuestra web más accesible repercuten directa y positivamente en su posicionamiento en los buscadores. No debemos olvidar que uno de los visitantes importantes de nuestra web no es humano y, que los problemas que suele tener para acceder al contenido, no difiere mucho de los que puede tener un usuario con una discapacidad visual.

Si los buscadores encuentran barreras que les impiden o les dificultan recorrer nuestras páginas e indexar su contenido, localizar sus temas principales y sus palabras clave, la consecuencia será que no estaremos en las páginas de resultado de los buscadores, o en posiciones poco relevantes, o indexados por palabras irrelevantes.

Hay muchas razones para hacer una web accesible, una de ellas es que mejora el posicionamiento en buscadores. Evidentemente, el principal motivo por el que hacemos páginas accesibles no es posicionar bien nuestras páginas, pero seguro que es un argumento que convence a muchos, así que bienvenido sea.

Este artículo explica cómo usabilidad, accesibilidad y SEO están estrechamente relacionados, de modo que las acciones que llevamos a cabo para que nuestras páginas sean más usables y accesibles repercuten directamente en su indexación y posicionamiento.

Índice

Texto equivalente para todo elemento no textual (punto de verificación 1.1 y 8.1)
Javascript (punto de verificación 6.2, 6.3, 10.1)
Código (XHTML) válido y separación de contenido y la presentación (punto de verificación 3.2, 3.3, 6.1, pauta 5, 11.2)
Marcado correcto y uso adecuado de encabezados (punto de verificación 3.1, 3.5, 3.6 y 3.7)
Escribir para la web (punto de verificación 12.3, 13.8, 14.1)
Enlaces (punto de verificación 1.2, 13.1)
Frames (punto de verificación 6.5 y 12.1)
Metainformación e idioma (punto de verificación 13.2, 13.9, y pauta 4)
Mapa web (punto de verificación 13.3)
Redireccionamiento automático (punto de verificación 7.5)

Texto equivalente para todo elemento no textual

Es sin duda, el punto de verificación más conocido de las WCAG 1.0:

1.1 Proporcione un texto equivalente para todo elemento no textual (Por ejemplo, a través de "alt", "longdesc" o en el contenido del elemento). Esto incluye: imágenes, representaciones gráficas del texto, mapas de imagen, animaciones (Por ejemplo, GIFs animados), "applets" y objetos programados, "ascii art", marcos, scripts, imágenes usadas como viñetas en las listas, espaciadores, botones gráficos, sonidos (ejecutados con o sin interacción del usuario), archivos exclusivamente auditivos, banda sonora del vídeo y vídeos [Prioridad 1].

SEO y aplicación del punto de verificación 1.1 de las WCAG 1.0

El robot del motor de búsqueda que recorre nuestras páginas es “ciego”. Puedes comprobar cómo “ve” tu página con la aplicación gratuita online Seo-browser. Por tanto, incluir equivalentes textuales en las imágenes ayuda a que Google comprenda la información que transmiten las imágenes y las pueda indexar correctamente. Si además estas imágenes son relevantes en relación con el contenido de la página, las alternativas textuales que incluyas tendrán palabras claves que ayudarán también al posicionamiento. Lo mismo se aplica a los vídeos o a los audios, para los cuales siempre se debe proporcionar una transcripción.

También influye que las imágenes tengan un nombre significativo, el tamaño de las mismas (las imágenes con un tamaño excesivo no indexan tan bien como las de un tamaño normal) y su contexto (el texto cercano que las acompaña), aspectos todos ellos que se tienen en cuenta al evaluar la usabilidad de una página.

Hay que tener también en cuenta que no ejecuta applets ni objetos, por ello también es importante para indexar su contenido incluir un texto alternativo en los elementos OBJECT y APPLET, tal y como indica el punto de verificación 1.1.

Por último tenemos el tema de Flash. Google ya indexa contenido en Flash (probad por ejemplo a incluir: accesibilidad filetype:swf en la caja de búsqueda) El problema con Flash es que si este es inacesible de forma nativa (todo el texto con imágenes, sin enlaces de texto, sin alternativas al contenido no textual, etc.) será inacesible para muchos usuarios pero también para el robot de Google.

Según las WCAG 2.0 las películas Flash deben ser accesibles de forma nativa ("Flash Techniques for WCAG 2.0"), y en caso contrario, como indican también las WCAG 1.0 en la pauta 8, tener una alternativa accesible. Asegurar la accesibilidad de las películas Flash, por tanto, permitirá que su contenido sea accesible para los usuarios y para los buscadores.

Javascript

El punto de verificación 6.3 dice: Asegúrese de que las páginas sigan siendo utilizables cuando se desconecten o no se soporten los scripts, applets u otros objetos programados. Si esto no es posible, proporcione información equivalente en una página alternativa accesible. [Prioridad 1]

Uno de los requisitos para que una web sea accesible es que el javascript no suponga una barrera de acceso para los contenidos de la página.

SEO y aplicación del punto de verificación 6.3 de las WCAG 1.0

El robot del motor de búsqueda es uno de nuestros visitantes que accede sin javascript activo: no ejecuta los scripts.

Es fundamental que el robot pueda seguir tus enlaces, pero no podrá si generas tu menú por javascript o creas enlaces o abres pop-ups mediante javascript sin dar una alternativa accesible.

El típico enlace <a href=”javascript:mifuncion(‘parámetro’)”>Texto del enlace</a> no podrá ser seguido por Google.

El punto de verificación 10.1 de las WCAG 1.0 desaconseja el uso de ventanas emergente. En la técnica SCR24 de las WCAG 2.0 (SCR24: Using progressive enhancement to open new windows on user request) se indica cómo hacer un window.open accesible, que pasa por incluir un "href" con la ruta de la página: accesible para los usuarios y para los buscadores.

De la misma manera, si generas contenido mediante javascript y este no está disponible sin javascript activo, dicho contenido no podrá ser indexado por Google. En este caso es también fundamental, como indica el punto de verificación 6.2 de prioridad 1, que las alternativas se correspondan realmente con el contenido dinámico.

Es importante también intentar métodos alternativos al “noscript”, que Google mira con recelo por el abuso que se ha hecho de él por parte de los spammers. En especial si contiene enlaces.

En resumen, hacer tu web accesible sin javascript beneficia no sólo a los usuarios que no pueden ejecutarlo sino también a los robots que podrán seguir tus enlaces y acceder a todo el contenido, lo cual repercutirá en tu posicionamiento.

Es muy interesante el artículo de Google “Rastreo con AJAX: guía para webmasters y desarrolladores”

Código (X)HTML válido y separación de contenido y la presentación

El punto de verificación 3.2 indica Cree documentos que estén validados por las gramáticas formales publicadas [Prioridad 2], siendo además necesario evitar características desaconsejadas como por ejemplo el elemento "font" (pauta 11.2 de prioridad 2).

Por su parte, el punto de verificación 3.3 indica que es necesario separar el contenido de la presentación: Utilice hojas de estilo para controlar la maquetación y la presentación. [Prioridad 2], de modo que la página pueda ser leída correctamente sin CSS accediendo de forma lógica a todo su contenido (pauta 6.1 de prioridad 1).

En este sentido, las WCAG 1.0 (y también las WCAG 2.0) desaconsejan explícitamente maquetar mediante tablas en la pauta 5.

SEO y aplicación de los puntos de verificación 3.2 y 3.3 (y otros asociados) de las WCAG 1.0

Tener un código (X)HTML válido (se puede validar con el servicio online del W3C) repercute indirectamente en el posicionamiento desde el punto de vista de que permite al robot un acceso más sencillo a la información, que es más fácil de analizar y procesar.

Google lee código X(HTML) pero sólo indexará el contenido textual de la página, si los estilos están en las CSS y el código javascript en archivos externos, le estás facilitando su labor. Maquetar sin tablas y separar el contenido de la presentación mediante CSS genera un HTML más limpio y con menos líneas de código, de manera que nuestro contenido no se haya después de líneas y más líneas de código. Además de ser más fácil de entender por los buscadores, influye en el tamaño de la página (se suele aconsejar que no sea mayor de 150kb) Desde marzo de 2010 Google incluyó en su algoritmo la velocidad de carga de la página.

También hay que tener en cuenta que si la página tiene más de dos tablas anidadas se indexará peor (hay quien incluso dice que los robots obvian todo lo que se encuentre en las tablas anidadas a partir del tercer nivel de anidación), y que muchos expertos SEO indican que se tiene en cuenta la relación entre el número de líneas de código y el texto de la página.

Marcado correcto y uso adecuado de encabezados

El punto de verificación 3.1 indica Cuando exista un marcador apropiado, y se soporta, use marcadores en vez de imágenes de mapa de bits para transmitir la información [Prioridad 2]

Por su parte, el punto de verificación 3.5 señala Utilice elementos de encabezado para transmitir la estructura lógica y utilícelos de acuerdo con la especificación. [Prioridad 2] Por su parte los puntos de verificación 3.6 y 3.7 (ambas de prioridad 2) hacen referencia a marcar correctamente las listas y las citas.

SEO y aplicación de los puntos de verificación 3.1 y 3.5 (y otros asociados) de las WCAG 1.0

Ya hemos dicho que el robot es ciego y lee código (X)HTML. Si marcamos correctamente el código le estamos ayudando a interpretarlo, por ello es fundamental estructurar el contenido adecuadamente con encabezados, párrafos, etc.

No sólo tiene en cuenta la frecuencia de las palabras sino también su relevancia, y está es mayor en función de dónde se encuentran: si están en un encabezado, el nivel de encabezado que las contienen, si están marcadas como relevantes (con “strong” o “em”), etc.

Por tanto, usar correctamente los encabezados y el marcado de la página ayuda no sólo a los usuarios sino también a los buscadores: la estructura del contenido y la relevancia de cada uno de sus elementos es más evidente, lo cual ayuda a interpretar la página e indexarla correctamente.

Escribir para la web

El punto de verificación 14.1 dice Utilice el lenguaje apropiado más claro y simple para el contenido de un sitio. [Prioridad 1]

La forma de redactar adecuadamente para la web, tal y como por ejemplo se explica en las técnicas asociadas a este punto de verificación, aborda aspectos tales como colocar el contenido más importante al comienzo, facilitar el escaneo de la información utilizando encabezados, listas o textos destacados, usar párrafos cortos y centrados en una idea o utilizar un lenguaje común (ampliar información en Reseña: "Cómo escribir para la Web" de Guillermo Franco)

Otros puntos de verificación relacionados son el 12.3 de prioridad 2 que insta a dividir los bloques largos de información en grupos más manejables o la 13.8 de prioridad 3 que indica que se debe localizar al principio la información diferencial.

SEO y aplicación del punto de verificación 14.1 (y otros asociados) de las WCAG 1.0

Es más sencillo inferir la temática de un contenido textual claro y conciso, sin paja y sin faltas de ortografía o gramaticales, siendo sin duda más fácil de rastrear e indexar correctamente.

Enlaces

La pauta 13.1 dice Identifique claramente el objetivo de cada vínculo. [Prioridad 2] para lo cual hay que prestar especial atención a la redacción del texto de los enlaces para que sean significativos y tengan sentido fuera de contexto, incluyendo el atributo “title” para clarificar su destino cuando no sea evidente.

SEO y aplicación del punto de verificación 13.1 de las WCAG 1.0

Ya he comentado que es imprescindible que el robot pueda rastrear nuestros enlaces, y que por ello se deben evitar prácticas como la generación de enlaces o menús por javascript, o también otras prácticas como los menús mediante combos de formulario que los robots no pueden seguir, o los enlaces dentro de mapas de imágenes sin alternativa accesible (como previene por ejemplo el punto de verificación 1.2 de prioridad 1), etc.

Si es importante que el robot pueda seguir nuestros enlaces para poder indexar las páginas, también lo será cómo realizas esos enlaces para que las páginas se indexen adecuadamente y se posicionen por las palabras claves que las definen. Tener enlaces con un texto significativo (y no por ejemplo “pulsa aquí”) como indica el punto de verificación 13.1 no sólo beneficia a tus usuarios sino que influirá positivamente en el posicionamiento de las páginas internas que enlazas.

Frames

Las WCAG no prohíben la utilización de frames pero sí que los desaconsejan por los problemas que pueden suponer para las personas que utilizan ayudas técnicas, siendo preferibles otras alternativas como los includes de servidor (más información en ¿Mi sitio es accesible si utiliza frames?)

Si a pesar de todo se usan frames, las WCAG indican que cada frame debe tener un atributo “title” y utilizar la etiqueta “noframes” para ofrecer una alterativa (puntos de verificación 12.1 y 6.5, de prioridad 1 y 2 respectivamente)

Por otro lado, desde un punto de vista de usabilidad, también se desaconseja el uso de frames por sus problemas asociados en cuanto a la impresión de la página, problemas con el botón “atrás” del navegador, etc.

¿Cómo repercute en SEO que tengamos en cuenta los problemas de accesibilidad y usabilidad de los frames?

Google no recomienda tampoco el uso de frames, como ellos mismo dicen Google intenta asociar el contenido enmarcado con la página que incluye los marcos, pero no puede garantizar resultados.

La "Guía de recomendaciones 'SEO' de posicionamiento en Internet" de Inteco resumen muy bien los problemas que suponen los frames para los robots de los motores de búsqueda:

complica la progresión lineal de los robots por los enlaces
aparecen dificultades como problemas de recursividad en la progresión
ambigüedad en la titulación de las paginas
descargas extras por residir el código de los marcos fuera de la pagina descargada

Por tanto, seguir la recomendación de no usar frames ayudará a que tu página sea más accesible también para los buscadores. Y si a pesar de todo usas frames, cumplir con las pautas de accesibilidad asegurará que por lo menos, gracias a la titulación de los frames y a la correcta redacción del “noframes” (sin mensajes del tipo “Su navegador no admite frames”), sean lo más accesibles posibles también para los buscadores.

Al igual que con la etiqueta “noscript” hay que tener cuidado con la etiqueta “noframes”, pues debido a su abuso por los spammers está en el punto de mira y puedes ser penalizado si no la usas correctamente.

Metainformación e idioma

La pauta 13.2 indica Proporcione metadatos para añadir información semántica a las páginas y sitios. [Prioridad 2] En relación con la cual, la 13.9 de prioridad 3 indica que se proporcione información sobre la colección de documentos con el elemento LINK y los atributos "rel" y "rev".

Por su parte, en la pauta 4 se especifica que se ha de identificar el idioma del documento así como los cambios de idioma en el contenido.

SEO y aplicación del punto de verificación 13.2 y la pauta 4 de las WCAG 1.0

La inclusión de metainformación en la página es quizás la norma de accesibilidad cuya repercusión en el posicionamiento de la página resulta más evidente. La información que proporcionemos a través de las etiquetas “meta” o el atributo “rel” es vital, pues estamos ofreciendo al buscador información sobre el título de la página, su descripción, sus palabras clave, su relación con otras páginas o e tipo de contenido que incluimos.

Por otra parte, identificar el idioma usado no sólo beneficia a los usuarios que utilizan ayudas técnicas, sino también permite a los motores de búsqueda localizar las palabras clave e identificar los documentos en el idioma deseado (pauta 4).

Relacionado con el idioma hay que tener en cuenta que a la hora de posicionar por aspectos geográficos también se tienen muy en cuenta otros factores como el país donde se aloja la web o la orientación geográfica que definas en “Herramientas para webmasters” de Google.

Mapa web

La pauta 13.3 indica Proporcione información sobre la maquetación general de un sitio (por ejemplo, mapa del sitio o tabla de contenidos). [Prioridad 2]

SEO y aplicación del punto de verificación 13.3 de las WCAG 1.0

El robot del motor de búsqueda debe ser capaz de llegar a todas las páginas de nuestra web. Incluir un mapa del sitio ayuda a mostrar su estructura y nos asegura que se pueda acceder a todas sus páginas. No hay que confundirlo con un “sitemap.xml” que es un mapa del sitio específico para los motores de búsqueda y que también es recomendable definirlo.

Redireccionamiento automático

La pauta 7.5 dice Hasta que las aplicaciones de usuario proporcionen la posibilidad de detener el redireccionamiento automático, no utilice marcadores para redirigir las páginas automáticamente. En su lugar, configure el servidor para que ejecute esta posibilidad. [Prioridad 2].

SEO y aplicación del punto de verificación 7.5 de las WCAG 1.0

Según este punto de verificación, una página que cumple con las WCAG utilizará un redireccionamiento de servidor 301 para una página movida permanentemente y no el meta "redirect". Podremos así acceder tanto a la vieja como a la nueva URL, manteniendo los backlinks y el PageRank.

Recursos "Usable y accesible" relacionados:

Artículos "Usable y accesible" relacionados:

Documentos que recomiendo conocer(7)

2009-10-22T15:00:00.004+02:00

Serie "Documentos que recomiendo conocer"

Usabilidad

Libros

"The Principles of Readability", William H. DuBay, 2004 (PDF)

"Introduction to Good Usability", Peter Conradie, 2008 (PDF)

"Search User Interfaces", Marti A. Hearst, 2009

"Research-Based Web Design & Usability Guidelines", Michael O. Leavitt y Ben Shneiderman , 2006 (PDF, 157 MB)

Accesibilidad

Libros

"Guía de estilo sobre discapacidad para profesionales de los medios de comunicación", José Luis Fernández Iglesias, 2006. Permite la descarga gratuita en PDF.

"Diseño de Páginas Web Accesibles", Sección de Documentación Consejería de Trabajo, Consumo y Política Social de la Región de Murcia. Permite la descarga gratuita en PDF.

"Delivering inclusive websites", COI, 2009 (PDF)

Recursos

"IMS Guidelines for Developing Accessible Learning Applications", 2002

"IBM Web accessibility checklist", IBM

"Evaluación de la accesibilidad de sitios web con la barra de herramientas de Firefox Web Developer Toolbar" de Sergio Luján

"Google accessibility"

Accesibilidad en documentos de Office

"Pautas de accesibilidad en presentaciones PowerPoint", CEAPAT. [Visto en accesibilidadweb.com]

"Accessible Web Publishing Wizard", Virtual508.com. Accesibilidad de documentos Word y PPT.

Navegadores

"When can I use... Compatibility tables for features in HTML5, CSS3, SVG and other upcoming web technologies", Alexis Deveria.

SEO y marca

"Audiciencia de Internet", AICM (Asociación para la Investigación de Medios de Comunicación)

"Personal Branding", Colin Wright [Visto en sortega]

"How to convert clicks into profit", Google [Visto en Daniel Ulczyk]

Vínculos de sitios en las búsquedas de Google

2009-04-30T21:00:00.007+02:00

Me han hecho varias veces la misma pregunta, y aunque la respuesta está en la propia documentación de Google, me ha parecido buena idea dedicarle un pequeño post.

A veces, cuando realizamos una búsqueda en Google, aparecen bajo la descripción de los enlaces del resultado de una búsqueda una lista de enlaces adicionales, es lo que Google denomina "enlaces o vínculos de sitio" (sitelinks).

La duda que surge es, ¿tenemos algún control sobre dichos enlaces?

Estos vínculos adicionales que aparecen asociados a algunos sitios son generados por Google a partir de sus contenidos, y su objetivo es ayudar a los usuarios a navegar por ellos.

Se generan de manera dinámica, de modo que la lista puede cambiar periódicamente.

¿En qué se basan para seleccionarlos?

Nuestros sistemas analizan la estructura de enlaces de su sitio para buscar los atajos que ahorrarán tiempo a los usuarios y les permitirán encontrar con rapidez la información que están buscando.

Únicamente mostramos enlaces de sitios en los resultados cuando consideramos que serán útiles para el usuario. Si la estructura de su sitio no permite que nuestros algoritmos encuentren enlaces de sitios de calidad o si no consideramos que su sitio tenga enlaces relevantes para la consulta del usuario, no los mostraremos.

Actualmente, los enlaces de sitios aparecen de forma totalmente automática. Trabajamos continuamente para mejorar nuestros algoritmos de enlaces de sitios y podríamos incorporar la colaboración del webmaster en un futuro.

"¿Cómo compila Google la lista de enlaces que aparecen debajo de algunos resultados de la búsqueda?", Ayuda de Webmasters de Google.

Dependen por tanto de cómo estén estructuradas nuestras páginas. Es recomendable subir un mapa del sitio a Google, puesto que Google Sitemaps utiliza el mapa del sitio para conocer su estructura, cuándo se actualizan sus páginas y cuál es su importancia relativa (la prioridad sólo indica la importancia de una URL concreta en relación a otras URL del mismo sitio ).

También es conveniente cumplir con las Directrices para webmasters.

A pesar de todo sí que tenemos algún control sobre estos enlaces, puesto que podemos bloquearlos, es decir, indicarle a Google que no queremos que algunos de ellos aparezcan. El bloqueo se realiza desde las Herramientas de webmasters:

Tras bloquear o desbloquear un enlace de sitio, las modificaciones pueden tardar un poco en aparecer.

Tenga en cuenta que sólo mostramos enlaces de sitio de los sitios que contienen un mínimo de cuatro. Si su sitio tiene tres o menos enlaces de sitio desbloqueados, no aparecerá ninguno en los resultados de búsqueda de Google.

Si bloquea un enlace de sitio, este no aparecerá en los resultados de búsqueda de Google durante 90 días. Este período de tiempo se ampliará cada vez que visite la página "Enlaces de sitio" en la cuenta de Herramientas para webmasters.

Hay que tener por tanto en cuenta que el bloqueo no es permanente sino temporal, y que hay que tener un mínimo de tres para que aparezcan.

Después de lo dicho, me seguía quedando la incógnita de cómo realmente Google selecciona los enlaces a mostrar. He encontrado el artículo de Mani Karthik, "Cómo hacer que sus páginas aparezcan en Google bajo fragmentos SERPS", en el cual defiende como hipótesis que Google incluye como sitelinks las páginas/enlaces del menú de navegación con el máximo de visitas o clics.

A esta conclusión llega después de observar que:

Sólo los sitios web con gran tráfico parecen mostrar sitelinks.
Los enlaces publicados son en su mayoría los más vistos en las páginas de un sitio.
Los enlaces son en su mayor parte una copia de los eslabones de la estructura de navegación del sitio.
En sitios que tienen sitelinks, la categoría de páginas o la estructura de navegación es universal o repetida muchas veces; esto puede ser un criterio de Google para considerar que estos vínculos ayudan a reducir el tiempo de navegación del usuario.

Está hipótesis tiene sentido, pero no me cuadra con los vínculos de sitio que aparecen asociados a mi blog.

Es cierto que algunos de los que se muestran sí que son de los más visitados o forman parte de algún menú y por tanto están enlazados desde todas las páginas.

Sin embargo, no encuentro sentido a otros sitelinks que muestra Google, puesto que son artículos con muy poca relevancia, poco visitados y no están en los menús de navegación. Curiosamente, estos artículos (algunos los he bloqueado) contienen en el título las palabras Chrome o Blogger.

Así que me pregunto, sin ningún fundamento científico, ¿es pura casualidad o en el algoritmo de Google se les habrá colado alguna línea de código como la siguiente?


/* Se abre ironía*/

if (page.title.contains(Google.product.name))
page.sitelinks.show() && page.relevance *= 1000

/* Se cierra ironía*/

No sé si Google tendrá sentido del humor y me penalizará por el chiste o por el contrario añadirá este post a los sitelinks de mi blog...

Imprescindibles (15)

2009-04-28T13:49:00.001+02:00

Estos son los artículos que han llamado mi atención últimamente (no tienen porque ser recientes):

Usabilidad

"Cómo ha de ser el diseño: una visión del análisis heurístico" de Torres Burriel.

"¿Cómo diseñar para móviles?" de Daniel Ulczyk.

"Para Nielsen las webs móviles deben ser simples y minimalistas", de Úsalo.

"Breadcrumb Navigation Increasingly Useful" de Jakob Nielsen.

"CRAP Design (traducción)" de MinaLab

"3 Pasos para crear una web profesional: Paso 1 Fijar objetivos" de Galería CSS.

"OPTGROUP y la usabilidad en SELECT" de Javier Fernández Rivera.

SEO

"Cómo asegurarnos de que Google visite a fondo nuestras páginas web en 10 pasos" de acceso.com

"Un buen plan SEO" de Daniel Ulczyk.

SEO CheatSheet

Navegadores

"Safari 4.0 es el navegador mas rápido" de Geekets.

"Rendimiento de los navegadores dependiendo del código HTML" de anieto2k.

Imprescindibles anteriores (recopilación de artículos de interés)

Imprescindibles... (9)

2008-07-21T09:00:00.001+02:00

Los artículos que más han llamado mi atención durante estos últimos meses han sido:

1
Revisión automática de páginas con la norma UNE 139803 mediante PISTA

En diciembre comentaba en Mis validadores que una de mis herramientas preferidas para la revisión automática de la accesibilidad de un sitio Web era PISTA, herramienta del Ministerio de Industria, Turismo y Comercio.

Una de sus muchas ventajas es que permite realizar análisis de accesibilidad con normativas distintas a la WAI WCAG1.0 (normativa por defecto). El único requisito que deben cumplir las normativas que se añadan a la herramienta es que estén especificadas en un fichero XML que siga el DTD "normativas.dtd".

En el manual de la herramienta se explica como realizarlo.

Tenía pensado desde hace tiempo incluir un nuevo fichero para poder validar automáticamente con la Norma UNE 139803, que como ya he comentado otras veces, es la norma que han de cumplir muchos sitios Web españoles desde finales de año, y que sólo se diferencia en cuatro puntos de las WCAG 1.0, como ya expliqué en Diferencias de prioridad entre los requisitos UNE 139803:2004 y los puntos de control de las WCAG 1.0

Pues bien, Olga Revilla nos ha ahorrado el trabajo y nos facilita la vida desde su blog Itákora. En Cómo validar las normas UNE 139803 con la herramienta PISTA te explica como descargarte e importar en PISTA el XML para validar automáticamente con la Norma UNE 139803.

Otro artículo de Itákora relacionado es: Comparativa de accesibilidad de las WCAG 1.0 y la norma UNE 139803/2004.

2
Cómo definir un menú de navegación

En "Sugerencias para definir un menú de navegación" Jorge Garrido ofrece unas interesantes pautas para planificar nuestro menú de navegación.

3
Word accesible

En "Cómo crear un documento Word accesible" Fran Tarifa remata una discusión dentro de la lista AccesoWeb.

Emmanuelle comentaba:

Si por accesible entendemos que pueda ser usado por cualquier persona en cualquier situación y mediante cualquier dispositivo, evidentemente la respuesta es no. Puesto que se trata de un formato propietario, debe siempre ofrecerse la información que se tenga en ese formato en otro formato que sea abierto y accesible o en varios formatos para cubrir las necesidades de todos los usuarios potenciales.

Ahora, lo que sí se puede y se debe hacer, es ofrecer los contenidos en word de manera que puedan acceder a ellos los usuarios de lectores de pantalla, y seguir unas pautas en su elaboración.

Entonces, aparte de que ofrezcas los contenidos en otros formatos, además de en Word, deberás estructurar el contenido de los documentos, usar correctamente los estilos, simplificar el lenguaje, etc.

Se daban dos referencias interesantes sobre cómo hacer documentos Word accesibles:

"Microsoft Word" de WebAIM

Guidelines: Accessible Word Documents

En este contexto, es interesante la herramienta aDesigner que permite evaluar la accesibilidad de documentos ODF.

4
La crueldad de los internautas según Nielsen

En "La crueldad de los internautas" la BBC comenta el informe anual sobre los hábitos en el uso de Internet de Jakob Nielsen. Me llama especialmente la atención que el 75% de los usuarios no navega por un sitio, sino que utiliza directamente el buscador del mismo.

"Los usuarios de internet siempre han sido despiadados y ahora lo son más que nunca", dijo Nielsen. "La gente quiere sitios que los lleve, sin rodeos, al punto. Tienen muy poca paciencia", señaló. "Creo que los sitios todavía no han apreciado eso", agregó. "Aún sienten que su sitio es interesante y especial y que la gente estará feliz con todo lo que se le arroje".

[...]

Los internautas también se están frustrando mucho con todas las adiciones, como los "widgets" (artilugios) y las aplicaciones que se vienen agregando a los sitios para hacerlos más amigables. Tales adiciones sólo están sirviendo para que las páginas se tarden más en cargar, afirma Nielsen.

[...]

En 2004, un 40% de los internautas visitaba una página principal y luego navegaban hacia donde querían ir, y un 60% usaba un vínculo que los llevaba directamente al destino buscado dentro de un sitio.

En 2008, dijo Nielsen, sólo un 25% de las personas navega a través del "homepage" o página principal. El resto usa el buscador o "search engine" y se va directo a donde quiere.

5-6
No justifiques el texto en la web

Estoy totalmente de acuerdo con el artículo "La justificación de texto en la web" de Duopixel. La próxima vez que me pidan que justifique un texto les pasaré directamente su post.

Se puede seguir la lucha dialéctica sobre este tema en AccesoWeb.

Leyendo este artículo me llama la atención el título de otro, "¿Cómo llamar a la persona que usa un objeto de diseño?", en el cual reflexiona sobre las alternativas al odiado "usuario" de Donald Norman, que aboga por el término "persona".

7
URLs y usabilidad

En "La usabilidad también tiene en cuenta las URLs" Gabriel Porrás introduce el artículo "URL semántica / Clean URL / Friendly URL" de Viv Dehaes.

8
Google y accesibilidad

En "Google y Accesibilidad" Nelson concluye que la accesibilidad no sólo beneficia los usuarios que por ejemplo navegan en condiciones no tradicionales (conexiones de baja velocidad, uso de dispositivos móviles, etc.) sino que "facilita la labor de los robots indexadores como Googlebot, lo que te beneficia porque genera mejores puntajes y posicionamiento en los resultados de búsqueda, por lo tanto, más visitas".

Y como bien dice él: "esta relación, independientemente de cualquier argumento humanista que se pueda hacer al respecto, es desde ya un muy buen argumento de ventas de la accesibilidad".

9
Frases que asesinan a la accesibilidad

Didáctica de la accesibilidad y "frases asesinas" recopila las frases que funcionan como excusas o impedimentos para justificar la accesibilidad de un sitio. Lo triste es que son ciertas, yo al menos he oído cinco de las diez que citan.

10
Bug de Internet Explorer 7

Andrés Nieto comenta un Curioso bug en Internet Explorer 7 . Aunque parezca increíble, una lista OL pierde la numeración cuando se le aplica un HEIGHT en la CSS.

11
Cosas que no debes hacer al construir un sitio web

En microsiervos encontramos un resumen en español de 19 Things NOT To Do When Building a Website, de Josiah Cole

Noticias... (11)

2008-07-08T11:46:00.001+02:00

Las noticias que más han llamado mi atención durante estos meses de ausencia han sido estas cuatro:

1

La AGPD (Agencia Española de Protección de Datos) sanciona a una web que tiene la opción "Recomendar a un amigo"

Según la Agencia Española de Protección de Datos esta práctica vulnera la Ley de Servicios de la Sociedad de la Información y Comercio Electrónico (LSSI), que no prevé que se pueda enviar ningún mail con contenido publicitario o promocional

La única excepción a este hecho sancionable es que exista un consentimiento previo e informado o que, con antelación, haya habido una relación contractual entre el remitente del correo y el destinatario.

¡Ojo al enviar datos "a un amigo! Protección de Datos considera que es sancionable

Al hilo de esta noticia hay que recordar que la AGPD también sancionó en enero a un usuario que mandó un correo felicitando la Navidad a sus conocidos sin CCO.

La AGPD multa con 601,01 euros por felicitar las fiestas por e-mail sin CCO

2

El W3C invita a los desarrolladores a implementar las Pautas de Accesibilidad al Contenido en la Web (WCAG) 2.0 (Candidata a Recomendación)

En febrero explicaba todo acerca de las WCAG 2.0, que entonces eran sólo un borrador. El 30 de abril se publicaba la recomendación candidata que el w3C animaba a los desarrolladores a implentar.

Habrá que estar atentos a la fecha fijada: 31 de agosto.

Working closely with Web developers, we expect to receive initial implementations by 30 June 2008 and to show evidence of meeting the exit criteria by 31 August 2008.

El W3C invita a los desarrolladores a implementar las Pautas de Accesibilidad al Contenido en la Web (WCAG) 2.0 (Candidata a Recomendación)

WCAG 2.0 Se Mueve: Lista para Prueba de Conducción

Presentación sobre WCAG 2.0 Working Draft (2007)

3

Google incorpora mejoras en su algoritmo para indexar los contenidos textuales dentro de archivos Flash

Flash se vuelve más indexable

4

Nuevas versiones de navegadores: Firefox 3, Opera 9.5, Explorer 8 beta, Opera Mini 4.1

Enlaces relacionados:

Browser History Timeline

Opera 9.5 y el movimiento hacia los nuevos estándares web

Poniendo el radar a los navegadores web más modernos

Navegadores web y el consumo de memoria

Identifican agujero crítico de seguridad en Firefox 3

Opera Mini 4.1 ya se encuentra disponible

La II Guerra de los Navegadores

Opera publica la versión 9.51

Usable y accesible

Ocultar contenido sin comprometer la accesibilidad ni el posicionamiento de la página

¿Qué texto podemos desear ocultar? ¿deberíamos ocultarlo?

Display:none

Visibility:hidden

Height:0

Posicionar el texto fuera de pantalla

Clip

Conclusión

SEO y Accesibilidad. Accesible también para buscadores

Índice

Texto equivalente para todo elemento no textual

SEO y aplicación del punto de verificación 1.1 de las WCAG 1.0

Javascript

SEO y aplicación del punto de verificación 6.3 de las WCAG 1.0

Código (X)HTML válido y separación de contenido y la presentación

SEO y aplicación de los puntos de verificación 3.2 y 3.3 (y otros asociados) de las WCAG 1.0

Marcado correcto y uso adecuado de encabezados

SEO y aplicación de los puntos de verificación 3.1 y 3.5 (y otros asociados) de las WCAG 1.0

Escribir para la web

SEO y aplicación del punto de verificación 14.1 (y otros asociados) de las WCAG 1.0

Enlaces

SEO y aplicación del punto de verificación 13.1 de las WCAG 1.0

Frames

¿Cómo repercute en SEO que tengamos en cuenta los problemas de accesibilidad y usabilidad de los frames?

Metainformación e idioma

SEO y aplicación del punto de verificación 13.2 y la pauta 4 de las WCAG 1.0

Mapa web

SEO y aplicación del punto de verificación 13.3 de las WCAG 1.0

Redireccionamiento automático

SEO y aplicación del punto de verificación 7.5 de las WCAG 1.0

Documentos que recomiendo conocer(7)

Usabilidad

Libros

Recursos

Móvil

Estudios

Accesibilidad

Libros

Recursos

Accesibilidad en documentos de Office

Navegadores

SEO y marca

Vínculos de sitios en las búsquedas de Google

Imprescindibles (15)

Imprescindibles... (9)

Noticias... (11)