Siteimprove, herramienta para el análisis programado de nuestro portal

Resumen:

En este artículo os voy a hablar del producto Siteimprove, una herramienta online para el análisis programado o manual de sitios completos o secciones concretas.

Las evaluaciones detectan problemas de accesibilidad en las páginas y PDF de acuerdo a las WCAG 2.0 (en los tres niveles: A, AA, AAA); pero también, y entre otros, los enlaces rotos, las faltas de ortografía en diferentes idiomas o los problemas relacionados con SEO.

Me ha gustado mucho por la utilidad y potencia de sus funcionalidades; la calidad de su validador de accesibilidad; las posibilidades de personalización y configuración; y su diseño, limpio y muy intuitivo. Por el contrario, apenas le he encontrado pegas.

Índice:

• Características generales
  • Gestión de usuarios
  • Gestión de portales y grupos de páginas
  • Análisis periódicos automáticos del sitio completo pero también manuales
  • Resumen y listado de la información
  • Priorización de errores y agrupación por el rol del corrector
  • Histórico y anulación de decisiones
  • Facilidades para comprender y corregir los errores
• Resumen de las funcionalidades de la aplicación
  • Quality Assurance (calidad)
  • Accessibility
  • SEO
  • Policy (análisis personalizados)
  • Informes
  • Configuración
  • Analytics
  • Response
• Funcionalidades que describo con más detalle:
  • Quality Assurance: enlaces, ortografía e inventarios
  • Accessibility: evaluación de páginas y PDF de acuerdo a las WCAG 2.0
  • Policy: análisis personalizados
  • Informes
• Conclusiones

Características generales

La aplicación es online, está disponible en español y es de pago. El precio depende de diferentes factores, como los módulos contratados o el tamaño del sitio, y por ello no está publicado en la web sino que se informa de manera personalizada.

No hay una demo pública pero se puede solicitar una demostración gratuita en su web.

A continuación repaso las características y funcionalidades generales que me han llamado al atención o que creo que merece la pena destacar.

Gestión de usuarios

Tiene gestión de usuarios, de manera que diferentes roles puedan tener diferentes permisos y niveles de acceso.

Gestión de portales y grupos de páginas

Puedes tener diferentes portales incluidos y, dentro de estos, si lo deseas, diferentes grupos de páginas. Esto te permite analizar de forma independiente, por ejemplo, diferentes secciones del sitio.

Para cambiar de uno a otro de tus sitios o grupos de páginas, hay dos desplegables siempre disponibles en la cabecera de la aplicación, al estilo de Google Analytics:

Imagen 1. Desplegable de tus sitios y desplegable de sus grupos de páginas en la cabecera de la aplicación. Ver más grande

Análisis periódicos automáticos del sitio completo pero también manuales

El análisis completo de tus portales se programa para que se realice de forma periódica pero también se puede lanzar manualmente.

Además, en cualquier momento se puede analizar una página concreta de forma muy sencilla desde los listados de páginas, el detalle de una de ellas o las utilidades de comprobación de una sola página.

Resumen y listado de la información

Cada sección tiene un resumen inicial con gráficas y listados de la información más relevante a modo de visión general.

La mayor parte de la información se muestra en listados que acaban remitiendo a una página de detalle. Estos listados tienen muchas funcionalidades pero a la vez son rápidos y fáciles de usar: permiten ordenación por columnas, filtros, búsqueda, detalle en línea, acciones asociadas a cada celda o fila, y exportación de los datos o su inclusión en un informe personalizado.

Imagen 2. Ejemplo de listado de la aplicación. Ver más grande

Priorización de errores y agrupación por el rol del corrector

Los problemas detectados se clasifican por diferentes parámetros que permiten después agrupar y filtrar los errores. Por ejemplo, como veremos, los errores de accesibilidad se clasifican por:

• Tipo: errores en el texto, en las imágenes, en los formularios, etc.
• Gravedad: error, advertencia, necesita revisión.
• Nivel de adecuación: A, AA, AAA.
• Rol de la persona que ha de corregir los errores: editor, desarrollador, administrador web. Algo muy práctico y de lo que hablé en el artículo Responsabilidad de accesibilidad de cada uno de los roles profesionales implicados en el ciclo de vida de un proyecto web.

Las páginas tienen además una puntuación en base a los problemas encontrados en las mismas. Esto también ayuda a priorizar páginas de cara a las correcciones.

Histórico y anulación de decisiones

Todas las decisiones que se toman en el portal (por ejemplo ignorar determinados errores, añadir palabras al diccionario, etc.) quedan registradas en un histórico. De esta manera se puede consultar la fecha de un cambio o el usuario que tomó la decisión, y deshacerla si es necesario.

Facilidades para comprender y corregir los errores

El informe de una página tiene una pestaña para cada análisis (Accesibilidad, SEO, etc.) en el cual, como veremos, se detallan los errores con mucho detalle. Además incluye la vista de la página (se resaltan los errores que seleccionas) y se muestra el código del elemento implicado.

Destacan varias herramientas útiles en el informe de una página:

• CMS: enlaza con la página en el CMS para poder hacer los cambios.
• Inspeccionar: te muestra el listado de las rutas para llegar a esta página y todas las páginas remitentes con enlace a la misma.
• Volver a comprobar: permite lanzar en el momento un nuevo análisis de la página.
• Mostrar página/ Mostrar HTML: para tener una vista de la página o de su código HTML.
• Activar/desactivar CSS

Imagen 3. Herramientas del informe de una página. Ver más grande.

Resumen de las funcionalidades de la aplicación

Las opciones de menú de la aplicación, los grandes apartados, son los siguientes:

Quality Assurance

Analiza los enlaces rotos (internos, externos, en PDF, a dominios no seguros) y la ortografía del sitio en los diferentes idiomas del mismo. Además hace inventario de los distintos tipos de contenidos del portal.

Lo analizo en detalle: Quality Assurance: enlaces, ortografía e inventarios

Accessibility

Realiza una evaluación automática conforme a las WCAG 2.0 en los tres niveles de conformidad (A, AA, AAA), tanto de las páginas como de los PDF del portal. Se informa de los errores, las advertencias y los aspectos que necesitan una revisión manual.

Es bastante práctico porque, tal y como veremos, la manera de mostrar y organizar la información la hace comprensible tanto para las personas que no tienen demasiados conocimientos de accesibilidad, como para las que sí los tienen. Se indican por ejemplo los criterios y técnicas asociadas a cada error, con su enlace a las WCAG 2.0.

Lo analizo en detalle: Accessibility: evaluación de páginas y PDF de acuerdo a las WCAG 2.0

SEO

Incluye el análisis de los problemas asociados con el posicionamiento de la página: aspectos relacionados con el título, los metas, su exclusión con noindex/nofollow, redirecciones 302, páginas no incluidas en el mapa XML, etc.

Policy

Permite crear y configurar tus propios análisis personalizados en relación con el texto, el código, el contenido multimedia o los documentos del sitio. Los defines mediante reglas (incluyentes o excluyentes). Como veremos luego, la potencia de esta funcionalidad es muy grande, y las posibilidades y aplicaciones muchas.

Lo analizo en detalle: Policy: análisis personalizados

Informes

Es donde se ejecutan, programan y consultan los informes, en HTML o PDF. La facilidad para personalizar dichos informes con los análisis y tipos de datos que desees es otra ventaja de la aplicación que comentaré más adelante.

Lo analizo en detalle: Informes

Configuración

Permite administrar el perfil de usuario y la gestión de roles y permisos, además de otros aspectos como el idioma, la zona horaria, los formatos de fechas, etc.

Analytics

Es el análisis del portal al estilo de Google Analytics.

Response

Incluye información sobre caídas del sitio, tiempos de respuesta o comportamiento irregular.

Voy a detenerme a continuación en describir con más detalle cuatro de las grandes funcionalidades de la herramienta que más me interesan personalmente: Quality Assurance, Accessibility, Policy e Informes.

Quality Assurance: enlaces, ortografía e inventarios

La manera de consultar los resultados es muy amplia: resumen general, por sitios, por grupos, por páginas, por errores, etc.

Imagen 4. Resumen inicial Quality Assurance. A la izquierda todas sus opciones de menú desplegadas. Ver más grande

Enlaces rotos

Se analizan los enlaces rotos internos y externos, incluidos los presentes en documentos PDF, y los enlaces a dominios no seguros.

Ortografía

Encuentra errores y posibles errores de ortografía en diferentes idiomas.

Se ofrecen sugerencias por cada error, la posibilidad de ignorarlo en una página o en todo el sitio (decisiones que quedan guardadas y pueden anularse), o la posibilidad de agregar la palabra al diccionario y así mantener un vocabulario propio.

Además de poder consultar los resultados por listado de páginas con errores, listado de palabras erróneas o listado de posibles palabras erróneas, me encanta la opción de consultar todas las palabras de tu portal.

Dicha vista, “Lista de palabras”, tiene las opciones habituales (agregar, ignorar, sugerencias, etc.) y permite filtro por idioma, estado (agregada al diccionario, ignorada en todo el sitio etc.) y búsqueda. Puedes de esta manera saber qué palabras estás usando en el portal y con qué frecuencia.

Imagen 5. Listado de las palabras de tu sitio. Ver más grande

Otra funcionalidad es consultar los idiomas utilizados en el portal y su porcentaje de uso.

Inventario

Este apartado me parece también muy útil pues te proporciona un inventario de multitud de elementos. La página inicial es una visión general de todos ellos, con gráfica incluida.

La gran cantidad de inventarios disponibles, unido a sus funcionalidades de ordenación, búsqueda y filtrado, hacen de ella una herramienta muy útil.

Los diferentes inventarios que puedes consultar son:

Contenido

• Páginas. Listado de páginas del portal, y por cada una: tamaño, número de páginas que remiten a la misma (y acceso a ese listado), fecha en que se detectó la página, puntuación en base a los errores que presenta y nivel en el mapa web.
• Enlaces. Listado de todos los enlaces del sitio, y por cada uno: estado HTTP, número de páginas y PDF en los que aparece (y acceso a ese listado).
• Documentos. Listado de documentos por tipo (Excel, PDF, PPT, Word, XML, etc.) con el número que hay (internos y externos), y ya en cada uno: su tamaño, número y acceso a las páginas y PDF en los que aparece, hora de la última modificación y estado.
• Archivos multimedia. Igual que en el caso anterior pero para archivos multimedia (audio, imágenes, vídeo, Flash, applets, etc.)
• Javascript. Listado de los JS del sitio, y por cada uno: número de páginas que los incluyen y que no los incluyen (y acceso a ese listado).
• CSS. Igual que en el caso anterior pero con las hojas de estilo.
• Texto de enlace. Listado de todos los textos de enlace del portal, y por cada uno: número de páginas que los tienen (y acceso a ese listado). Es una buena manera de ver si son comprensibles fuera de contexto.
• Marcas comerciales. Busca los nombres seguidos de ® o TM. Pero también se muestran los duplicados posibles si al nombre le sigue un símbolo de marca comercial diferente, un símbolo de copyright o sin símbolo de marca comercial.

Personal

• Direcciones de correo electrónico, este listado es muy útil para ver si hay direcciones obsoletas, equivocadas, etc.
• Números de teléfono
• Números de identificación (DNI, Seguridad Social, etc.)

Técnico

• Etiquetas META. Listado de todos los metas encontrados en las páginas, y por cada uno: número de páginas que los contienen (y acceso a ese listado) y detalle de su contenido.
• Mapa del sitio. Es un mapa físico de la estructura de directorios en el servidor, y por cada uno: número de páginas (y acceso a ese listado). Es una manera de acceder directamente al detalle de una página en base a su ubicación física.

Accessibility: evaluación de páginas y PDF de acuerdo a las WCAG 2.0

Uno de los apartados que más me interesaba analizar era el de la evaluación de accesibilidad, para valorar la calidad y el detalle del análisis y los resultados.

La evaluación se realiza de acuerdo a las WCAG 2.0 y admite los tres niveles: A, AA, AAA. Los problemas se dividen en errores, advertencias y necesitan revisión manual.

Como ya he comentado antes, una gran ventaja es que los errores se clasifican por diferentes parámetros: nivel de conformidad (A, AA, AAA), gravedad (errores, advertencias, necesitan revisión), tipo (encabezados, imágenes, enlaces, formularios y otros problemas) y rol del corrector (administrador web, desarrollador y editor).

Imagen 6. Parte del resumen donde se observa la agrupación de los errores por diferentes criterios. Ver más grande

Esta clasificación facetada se explota luego en los filtros de las tablas:

Imagen 7. Filtro de las tablas por tipo de problema. Ver más grande

Imagen 8. Filtro de las tablas por el rol del corrector. Ver más grande

Los problemas de accesibilidad detectados en el sitio se pueden consultar de diversas maneras:

Mis sitios

El listado de todos mis sitios permite ver un resumen general: número de páginas y PDF que tienen problemas de accesibilidad, y número de páginas que tienen problemas en cada nivel de conformidad. Desde este listado se puede acceder al listado concreto de páginas.

Grupos

Igual que en el caso anterior pero para los grupos de páginas del sitio que tenemos definidos. Puedes tener, por ejemplo, un grupo para cada sección del portal, y así analizarlas y consultarlas de manera independiente.

Políticas de accesibilidad

Listado de los análisis personalizados que he creado y que he relacionado con la accesibilidad, así como el acceso a sus resultados.

Hablo de esta funcionalidad más adelante (Policy: análisis personalizados) pero podrían ser por ejemplo páginas con determinado texto o código y/o con contenido de más de determinada longitud de caracteres y/o con contenido multimedia o documentos de más de determinado tamaño, etc. Son muchas las reglas que se puede definir, de manera excluyente o no excluyente.

Comprobación de una sola página

Puedo evaluar en el acto una sola página, por ejemplo una que se acabe de incluir en el portal. En cualquier caso, en los listados y detalles también puedo en cualquier momento volver a analizar una página.

Problemas

Me parece un listado amigable para las personas que no tienen muchos conocimientos de accesibilidad, pues no se les asusta de primeras con los números de criterio o las técnicas. Por el contrario, es un listado de los problemas con un nombre comprensible, organizados por nivel de conformidad, pero con posibilidad de filtro.

Además es muy visual, pues incluye tanto una barra de progreso general muy destacada como una por cada página. Se genera en positivo, en base al porcentaje de problemas resueltos. Creo que este planteamiento es acertado, siempre anima más ver el vaso medio lleno que ver el porcentaje en rojo, en negativo, en base a los problemas que faltan por resolver.

Tanto en el icono de ayuda, como después en los detalles, sí se informa ya del principio, pauta, criterio de conformidad, técnicas asociadas, etc.

Imagen 9. Listado de problemas con la ayuda asociada a uno de ellos abierta. Ver más grande

Veremos luego la página de detalle, es decir, el informe de una página concreta.

Directrices

Este es ya un listado más técnico. Se incluyen todos los principios, pautas y criterios de conformidad, indicando el número de páginas que presentan errores, advertencias y necesidad de revisión.

Por cada uno de los criterios de conformidad podemos abrir el listado de todos los aspectos que se están evaluando y el número de páginas en los que se detectan problemas.

Imagen 10. Listado de pautas y criterios de conformidad de las WCAG 2.0. Está abierto el listado de problemas evaluados en uno de ellos. Ver más grande

También se señalan aquellos criterios de conformidad para los cuales no se puede hacer ninguna revisión automática:

Imagen 11. Listado de pautas y criterios de conformidad de las WCAG 2.0. Está abierta la información asociada a uno de los que no admite evaluación automática. Ver más grande

Hubiera estado bien que se pudiera hacer un seguimiento manual de estos criterios no evaluables para que los revisores avanzados de accesibilidad pudieran registrar si se están cumpliendo. Así se podría tener una visión completa de si las páginas son realmente AA en base a todos los criterios de conformidad.

El listado de aspectos evaluados dentro de cada criterio de conformidad remite a la página de detalle del problema, con el listado de páginas que presentan errores.

Páginas

Listado de todas las páginas, y por cada una, el número de errores que presentan de cada nivel.

Este listado es un arma de doble filo porque el número de errores que indica en cada página es el sumatorio de todas las instancias de cada error, advertencia y "necesita revisión". Lo que voy a comentar a continuación sirve también para tenerlo en cuenta cuando hacemos una consultoría de accesibilidad: hay que ser prudentes con la manera de dar la información y explicarla muy bien para no distorsionar los datos.

Por una parte, está bien contabilizar el sumatorio de todas las instancias de los errores. Esto nos ayuda a priorizar las páginas a corregir, ya que no es igual de prioritaria una página que tienen 5 tipos de errores 1 vez cada uno, que una página que tiene 3 tipos de errores 50 veces cada uno:la primera tiene 5 errores y la segunda 150 errores. Si solo contáramos los tipos de errores parecería que la primera con 5 es más prioritaria que la que tiene 3. Combinado con la ordenación por nivel de conformidad (A, AA, AAA), me ayuda a priorizar las páginas.

Pero por otra parte, contabilizar el sumatorio de todas las instancias de los errores, sin distinguir si son errores, advertencias o "necesita revisión" (esta tabla no permite filtro por gravedad), nos puede dar una idea equivocada de la problemática de una página.

Si, por ejemplo, tienes 30 imágenes en tu página, saldrán ya fijos 30 errores relativos al “necesita revisión” del criterio 1.4.5 que indica que debes revisar manualmente que no son imágenes de texto. Si esto lo multiplicamos por todos los "necesita revisión", el número de errores que presenta la página es tan elevado que nos puede hacer pensar que es muy problemática. Quizás una página sin imágenes (y por tanto sin estos errores iniciales) pueden ser más problemática pero tener menos errores. Se mitigaría con un filtro por gravedad, o con la posibilidad de consultar el número de errores y/o el sumatorio de todas las instancias del error.

Al final es cierto que los vas puliendo a medida que confirmas o ignoras errores en las páginas, y en este sentido el sumatorio que hace te dará una idea del número de elementos por página que te quedan por mirar. Pero hay que tener cuidado a la hora de utilizar esta información en un informe para no distorsionar los datos.

PDF

Listado de todos los PDF que presentan problemas de accesibilidad.

En cada PDF se indica:

• su título
• si es legible por máquina, es decir, si es un PDF resultante de un escaneo y por tanto inaccesible.
• si está etiquetado, requisito imprescindible para ser accesible.
• el número de errores que presenta. Los errores que se detectan son evidentemente solo los que se pueden detectar con una evaluación automática (si se ha definido el idioma, si la estructura de encabezados es correcta, etc.) pero ayuda a asegurar un mínimo de accesibilidad en los PDF, que no es poco.

Igual que en el informe detalle de una página, en el informe detalle del PDF se visualiza también el fichero.

Hubiera estado bien que los revisores avanzados de accesibilidad pudieran hacer el seguimiento de los aspectos que deben revisarse manualmente (el orden de lectura, el etiqueta correcto, etc.) para poder indicar si el PDF es accesible más allá los aspectos que se pueden evaluar automáticamente.

Validaciones HTML/CSS

Por otra parte hay dos apartados para los resultados de la validación HTML y CSS de las páginas:

• Validación HTML. Listado de todas páginas con el número de errores detectados por el validador automático de código del W3C (y enlace al detalle en el mismo).
• Validación CSS. Listado de las CSS del sitio con el número de errores detectados por el validador automático de CSS del W3C (y enlace al detalle en el mismo).

Decisiones e Historial

En el apartado “Decisiones” se puede hacer el seguimiento de todos los problemas y elementos que has marcado que se ignoren. Esto nos permite tener un histórico, poder supervisar las decisiones y deshacerlas si es necesario.

En “Historial” podemos ver de manera gráfica la evolución de los problemas (número de páginas con problemas de nivel A, AA, AAA) en el tiempo.

Detalle de una página

Al final, en todos los listados, puedes llegar al detalle o informe de una página. Donde, como hemos visto, tienes una pestaña específica para los problemas de accesibilidad de la página:

Imagen 12. Detalle de una página. A la izquierda listado de criterios de conformidad con errores. Está abierto el listado de errores del criterio 1.3.1. Ver más grande

Al seleccionar un error concreto asociado a un criterio, accedes al detalle de dicho error:

Imagen 13. Detalle de un error. A la izquierda la información detallada del error: instancias del mismo en la página, técnicas asociadas, etc. Ver más grande

En la zona derecha se visualiza la página con el error resaltado y el código HTML del elemento implicado.

En la zona izquierda está toda la información detallada del error. Esta incluye un listado de todas las instancias del error en la página así como todas las técnicas que se pueden usar para resolverlo.

Tenemos botones para volver a analizar la página o para abrir la página en el CMS para corregir los errores.

Las validaciones que hace son muchas, incluyendo ARIA. El validador me ha parecido bueno, completo y fiable.

No se da, por ejemplo, un tipo de falso error habitual en otros validadores

Un mismo criterio de conformidad se puede cumplir aplicando diferentes técnicas: no puedes dar como error, por ejemplo, que falta un enlace “Saltar al contenido” al comienzo de la página porque puedes cumplir con el criterio de conformidad 2.4.1 aplicando otras técnicas.

Como digo, este validador NO da este tipo de falsos errores. Si por ejemplo no encuentra el enlace “Saltar contenido”, te advierte que puedes cumplir con el criterio de esa forma pero también con otras técnicas.

Ver: Falsos errores de validadores automáticos de accesibilidad basados en las WCAG 2.0

Policy: análisis personalizados

Una política, en el argot de la aplicación, es la creación de un análisis personalizado que defines mediante la combinación de reglas predefinidas.

Cuando creas la política le das un nombre y una descripción para que los editores sepan por ejemplo qué hacer con el listado de páginas que lo cumplan. Puedes indicar los sitios en los que quieres incluirla, darle una prioridad (alta, media, baja) y asociarla con Quality, Accessibility y SEO, de manera no excluyente, para que sus resultados aparezcan en estos apartados y sus informes si lo así lo decides.

La política se define en base a una serie de reglas predefinidas. Se pueden añadir varias reglas de manera excluyente o no excluyente. Las reglas se clasifican según estén relacionadas con el contenido, los documentos o los archivos multimedia.

Por ejemplo, podría buscar páginas con determinado texto, con determinado código HTML, o con un tipo concreto de contenido multimedia o documento, y hacerlo en base a su URL, tamaño, tipo, fecha, nivel de página, o incluso en función de las visitas que tiene la página o los clics en un enlace, y todo ello de manera no excluyente.

Ejemplo 1: todas las imágenes de más de 300KB con texto alternativo que comience por “undefined” en páginas con más de 1000 páginas vistas en los últimos 30 días.

Ejemplo 2: páginas HTTPS con contenido HTTP:

Imagen 14. Ejemplo de política con varias reglas no excluyentes. Ver más grande

La potencia de esta herramienta es tremenda. También, como alternativa a la creación manual de una política, puedes añadir políticas de la biblioteca existente.

Podrás consultar las políticas por sitios, páginas, documentos o archivos multimedia que presenten coincidencias con las reglas definidas.

También hay un registro de eventos para cualquier acción asociada a la creación y modificación de políticas, de manera que quedan registradas con la fecha y el usuario que las realizó.

Informes

El apartado “Informes” es donde se ejecutan, programan y consultan los informes Quality Assurance, Accessibility, SEO, Analytics y Policy.

En Policy tienes tus análisis personalizados, pero si un análisis lo asocias a cualquiera de las otras categorías como hemos visto, también lo tendrás disponible en los informes de dichas categorías.

Al programar un informe se puede indicar el intervalo de tiempo, programar para determinados sitios y grupos de páginas, seleccionar destinatarios, el formato (HTML o PDF) y la plantilla del correo electrónico de la notificación. Mi experiencia es que la generación del informe es bastante rápida.

Puedes tener tantos tipos de informes como desees. Cada tipo de informe diferente que te creas es una plantilla.

Imagen 15. Dos plantillas de informes de accesibilidad. La general de la aplicación y la mía personalizada “WCAG 2.0 AA Detallado”. Ver más grande

Una de las cosas que me han gustado es la forma de personalizar un informe. En cualquier listado o gráfica de la aplicación hay un botón “exportar” que, además de permitir exportarlo a Excel, permite incluir ese tipo de contenido en una plantilla de informe.

Imagen 16. Listado de pautas de accesibilidad y páginas que presentan errores en las mismas. La opción exportar permite indicar en qué plantilla de informe se quiere incluir esta información. Ver más grande

La información se insertará en el informe en base a los filtros aplicados. Si yo aplico un filtro a la tabla y añado la tabla al informe, la tabla se incluirá con dicho filtro.

Sin embargo es una pena que no funcione de la misma manera con el ordenamiento de las columnas. En algunos casos sería muy útil poder incluir en el informe la tabla ordenada por una columna determinada, pero al incluir un tipo de tabla al informe recuerda el filtro pero no la ordenación.

Además de la funcionalidad anterior, puedes crear una plantilla desde cero o basada en una existente, y podrás seleccionar todos los componentes que desees añadir:

Imagen 17. Creación de una plantilla. Selección de los componentes que se quieren añadir. Ver más grande

Al editar una plantilla puedo modificar el título de cada sección, cambiar el orden en que aparece la información, seleccionar el número de filas a mostrar (en aquellas que tienen un formato de listado), etc.

He colgado un informe personalizado de accesibilidad creado por la herramienta: ver informe de ejemplo creado con Siteimprove (PDF, 453KB).

El informe es tal cual lo genera la herramienta, no lo he modificado. El PDF no es accesible, pues ya de base no se genera etiquetado. El informe también puede generarse en HTML, aunque tampoco es accesible en este formato.

Conclusiones

Me parece una herramienta recomendable para monitorizar nuestros portales mediante análisis periódicos automáticos que impidan que la accesibilidad y la calidad del portal se degrade con el tiempo, algo habitual en los portales que se actualizan con frecuencia. Entre sus clientes hay universidades (Berkeley o Stanford), bancos, aseguradoras o empresas como Microsoft, Vodafone, Audi o Adecco.

Me parece potente, útil y fácil de usar. Los aspectos que he ido comentando que podrían mejorarse son poca cosa si se comparan con todas funcionalidades y ventajas que ofrece la aplicación. Sí que sería relevante cuidar la accesibilidad de los informes generados. La he probado en diferentes navegadores y, salvo un problema muy concreto en una página y zona específica con Explorer y Firefox, me ha funcionado bien con todos ellos.

Me interesaba especialmente el validador de accesibilidad, y me ha sorprendido que sea uno de los puntos fuertes de la herramienta, al contrario de lo que suele ocurrir en estos casos. Es fiable, ofrece información detallada desde diferentes puntos de vista y comprensible para expertos y no expertos en accesibilidad, así como muchas funcionalidades relevantes, algunas poco habituales.

Por mi parte he revisado mi web en base a los errores que indicaban los informes para corregir aquellos que efectivamente lo eran.

Enlace: Siteimprove

Artículos relacionados

• Nueva versión de la herramienta de ayuda para realizar una consultoría de accesibilidad web de acuerdo a las WCAG 2.0
• Validadores y herramientas para consultorías de accesibilidad y usabilidad
• Responsabilidad de accesibilidad de cada uno de los roles profesionales implicados en el ciclo de vida de un proyecto web
• Falsos errores de validadores automáticos de accesibilidad basados en las WCAG 2.0 en otros
• aXe Rules, Google ADT Rules y el Mobile Web Accessibility Checker
• Accessibility Scanner, evaluar la accesibilidad de una app de Android
• Tenon: herramienta online, extensión y API para validar de acuerdo a las WCAG 2.0

Reseña del libro "Pioneros y Hacedores. Fundamentos y Casos de Diseño de Interacción con estándares de Accesibilidad y Usabilidad"

Autor: varios. Compilación Lorena Paz.

Nº páginas: 294

Idioma: español

Formato: ebook y libro impreso

Fecha de publicación: diciembre 2013

Enlaces:

• Descarga gratuita del libro en formato ePub y solicitud de libro impreso
• Descarga gratuita de mi capítulo ampliado "Accesibilidad y SEO" en formato PDF (248 KB)

Podéis consultar más reseñas de libros en: "Libros y reseñas"

Sobre el libro

El libro está compuesto por 19 capítulos de distintos autores, pioneros y hacedores en Arquitectura de Información, Diseño Centrado en el Usuario, Usabilidad y Accesibilidad, Ergonomía, Psicología, Diseño participativo y Co-desarrollo, oriundos de Centroamérica, Sudamérica, Norteamérica, Australia y Europa.

El origen de esta selección de textos nace de la necesidad académica de contar con material bibliográfico en español para formar en diseño de interacción con estándares de accesibilidad y usabilidad. El trabajo editorial se justifica por la ausencia, o falta de sistematización, de fundamentos y casos de experiencias de investigación, diseño y desarrollo de Diseño de Interacción en nuestro idioma. La compiladora, Lorena Paz, dirige la Especialización en Diseño de Interacción con Estándares de Accesibilidad y Usabilidad (DIEAU) en la Universidad Tecnológica Nacional de Buenos Aires (Argentina)

Los capítulos, mediante casos o fundamentos, tratan temas que van desde ergonomía física y cognitiva, al desarrollo de un videojuego y de un recurso educativo accesible; de métodos y dispositivos para evaluar la interacción con la nueva televisión interactiva a las técnicas de inspección e indagación heurística; de la internacionalización de la web a las normativas gubernamentales para hacer páginas web accesibles y usables.

Estos son los capítulos y sus autores:

Capítulo 1: El botón de los $300, por Jared M.Spool

Jared M. Spool nos cuenta el caso real de un e-commerce donde estudió la interacción de sus usuarios con los formularios de registro e ingreso. Finalmente, la modificación de un botón supuso un 45% más de usuarios que terminaban las compras y una ganancia adicional de 15 millones de dólares el primer mes tras el cambio, y 300 millones de dólares después del primer año.

Capítulo 2: Cómo usamos la web realmente, por Steve Krug

Steve Krug nos habla sobre las diferencias entre cómo creemos que la gente usa los sitios web y lo que sucede en realidad: las páginas no se leen, se hojean; no tomamos óptimas decisiones, nos conformamos con lo suficiente; y no nos interesa averiguar el funcionamiento de las cosas, nos las arreglamos.

Os recomiendo la reseña de sus libros "No me hagas pensar" y "Haz fácil lo imposible".

Capítulo 3: Mobile Sites vs. Full Site, por Jakob Nielsen

Defiende la necesidad de que los sitios web dispongan de una versión móvil. Nos habla de las buenas pautas a seguir en dicha versión y los desafíos que supone.

Este punto de vista es contrario al de los que defiende una web única implementada mediante Responsive Design, hablé de ello en Responsive Design y accesibilidad. Buenas y malas prácticas. Errores comunes.

Capítulo 4: ¿Qué se mueve?, por Don Norman

Parte de una anécdota personal con un mando a distancia, que tenía solo dos botones y sin embargo los usuarios interpretaban de diferente manera, para reflexionar sobre la elección de las metáforas en un diseño adecuado de la interacción.

Capítulo 5: Diseño de interacción, prácticas de investigación y diseño en materiales digitales, por Jonas Löwgren

Presenta qué es el Diseño de Interacción y la naturaleza de la investigación actual en este campo, para desarrollar lo que podría (y quizás debería ser) el Diseño de Interacción.

Capítulo 6: Diseño participativo para la inclusión digital, por Stephen Grant, Laurel Evelyn Dyson y Toni Robertson

Ofrecen un panorama general del desarrollo histórico del proyecto llevado a cabo en la Universidad Tecnológica de Sydney (UTS) para aumentar la participación de los estudiantes aborígenes australianos en los cursos IT, y el modo en el que, gracias a su éxito, fue evolucionando hasta llegar a ser un programa permanente en la Facultad de Ingeniería y Tecnología Informática: el Programa de Participación Indígena en IT (IPIT)

Capítulo 7: Introducción a la Interacción Persona-Computadora, por Yusef Hassan Montero y Sergio Ortega Santamaría

Introducen y describen los conceptos y aspectos más relevantes de la disciplina Interacción Persona-Computadora, que estudia cómo las personas diseñan, implementan y usan sistemas informáticos interactivos, y cómo las computadoras influyen en las personas, las organizaciones y la sociedad. Aportan también una bibliografía para ampliar y profundizar en el conocimiento de la disciplina.

Capítulo 8: Entre la Arquitectura y la Información, por Jorge Arango

Nos ofrece una introducción a la disciplina Arquitectura de Información, el área de práctica profesional que busca traer orden y coherencia a los medios digitales para lograr que la información sea más fácil de encontrar, navegar y entender a través de múltiples canales y dispositivos.

Capítulo 9: Accesibilidad y SEO, por Olga Carreras

Este capítulo es mi contribución al libro. En un principio era más extenso de lo que aparece en el libro, ya que tuve que reducirlo para ajustarme a las directrices editoriales. Podéis descargar el capítulo ampliado en "Accesibilidad y SEO. Capítulo ampliado" (PDF, 248 KB)

La accesibilidad web y el SEO parecen dos disciplinas muy diferentes, sin embargo tienen muchos puntos de encuentro. Ambas deberían caminar de la mano porque a menudo las técnicas de accesibilidad web y las buenas prácticas SEO se solapan y coinciden.

Comienzo el capítulo con una introducción de ambas disciplinas para pasar a dar un enfoque conciliador y explicar los puntos de encuentro entre ellas.

En la segunda parte del capítulo repaso los requisitos de accesibilidad web (haciendo referencia a las WCAG 2.0) que coinciden con buenas prácticas SEO y que por tanto repercuten directamente en la indexación y posicionamiento de nuestra páginas.

Capítulo 10: Desarrollo de un videojuego accesible, análisis del proceso de trabajo: El Caso Slalom, por Javier Mairena y Daniel Márquez

Nos habla de las claves y las dificultades para desarrollar un videojuego accesible, para lo cual será muy importante tener presente la accesibilidad desde el inicio del diseño hasta su publicación e implicar a todas las personas que forman parten del proyecto.

Los autores nos presentan un caso práctico, el desarrollo del videojuego Slalom (que se puede descargar gratis para Windows) Es un simulador del deporte “Slalom en Silla de Ruedas” practicado por personas con parálisis cerebral.

También nos ofrecen una bibliogafía muy interesante sobre recomendaciones publicadas por distintas entidades que pueden servir como guías para crear videojuegos más accesibles.

Gracias al artículo he conocido la iniciativa de SpecialEffect de utilizar un icono que identifique que el juego ha sido diseñado para ser accesible, icono que debería ir acompañado de una información más detallada sobre su accesibilidad. Y también que hay tiendas, como IndieCity, que clasifican sus juegos por sus características de accesibilidad.

Capítulo 11: Lo que desconocemos que conocemos sobre accesibilidad y usabilidad, por Emmanuelle Gutiérrez y Restrepo

Me gusta mucho el enfoque de Emmanuelle para este artículo, pues trata de acercar la accesibilidad a todo el mundo, mostrándola como algo más cercano al sentido común que a complicadas directrices que haya que seguir.

Mediante la comparación con las técnicas y prácticas habituales en la creación de documentos de texto, y siguiendo los tipos de contenido que suelen encontrarse en la mayoría de los sitios web hoy en día, especialmente aquellos que han sido creados mediante un gestor de contenidos, se analizan los criterios de conformidad que tienen su equivalente en dichas prácticas habituales y que, por tanto, todo desarrollador y diseñador conoce de antemano. Todos ellos tienen en realidad un conocimiento de accesibilidad y usabilidad que no sabían que tenían.

La autora nos muestra que con los conocimientos básicos para crear un documento de texto, bien formateado, legible y comprensible para nuestros destinatarios, conseguimos cumplir con 32 de los 61 criterios de conformidad de las WCAG 2.0. Es decir, cumplimos con el 52% de las pautas de accesibilidad para el contenido web. De los 25 criterios de conformidad de nivel A, cumplimos con 15, lo que significa cumplir con el 60% de ellos. De los 13 criterios de conformidad con nivel Doble A, cumplimos con 8, lo que significa cumplir con el 61,5% de ellos. De los 23 criterios de conformidad de nivel Triple A, cumplimos con 9, lo que significa cumplir con 39% de ellos.

Capítulo 12: Ergonomía física y cognitiva: los sistemas sensoriales humanos y la evaluación ergonómica de interfaces, por Sebastian Betti

Nos ofrece y explica una serie de criterios de conformidad para la evaluación ergonómica de las interfaces humano-computadora, que permiten reducir la carga del esfuerzo mental, visual y físico, y de este modo adaptarse mejor a las capacidades humanas.

Capítulo 13: Evaluación de la usabilidad con tecnología eye tracking. El caso de la TV conectada, por Mari Carmen Marcos y Verónica Mansilla

La tecnología Eye Tracking (ET) es una herramienta que complementa al test con usuarios para estudiar la usabilidad y la experiencia de usuario. La utilizaremos cuando nos interese conocer cómo miran los usuarios una interfaz cuando realizan determinada tarea.

Nos hablan de los modelos que existen, de los requisitos de los participantes y de la sala, de las métricas que obtendremos, de la calibración del ET o de los contratiempos que podemos encontrarnos. Otra parte importante del capítulo está dedicada al análisis de los datos obtenidos, que dependerá de si se ha hecho un análisis cuantitativo o cualitativo.

Nos presentan un caso de estudio concreto, aplicando la ET a la televisión conectada, que usa dos canales para recibir información, uno para los contenidos televisivos, y otro para los datos de Internet. Se estudió la interfaz de los menús, puesto que cada fabricante y cadena tienen su propia propuesta. Primero se hizo un test con usuarios en el que se detectaron muchos problemas de usabilidad. Uno de ellos era que los usuarios no lograban acceder con facilidad a un servicio concreto. Para profundizar en el motivo se llevó a cabo un test con ET. Nos cuentan los resultados y las dificultades del mismo.

La Universitat Pompeu Fabra ha llevado a cabo diversos estudios de ET:

• Investigación sobre la interacción en los procesos de búsqueda en Google (Marcos, Nettleton y Sáez 2012)
• Diferencias culturales en la interacción con el buscador (Marcos, García-Gavilanes, Bataineh y Pasarín 2013)
• Personalización de texto en pantalla para mejorar el rendimiento en la lectura (Rello, Pielot; Marcos; Carlini 2013)

Capítulo 14: Accesibilidad de un recurso educativo: El caso de la Mapoteca, por Manuel Razzari

Presenta como caso práctico la experiencia con el proyecto "Mapoteca" de educ.ar, una aplicación web para que estudiantes de nivel medio interactúen con mapas escolares. La aplicación sería distribuida en los 3.5 millones de netbooks de los alumnos de escuelas secundarias públicas.

Nos habla de los desafíos del proyecto, del marco de trabajo y de la importancia de elegir los componentes adecuados tanto en el back-end como en front-end, así como del testeo de la aplicación, tanto con usuarios reales como con herramientas de evaluación.

También nos describe los problemas detectados: los que habría sido necesario prever con suficiente antelación (como el uso del color); los que se podrían haber evitado formando adecuadamente a las personas que harán la carga de contenidos; los que son difíciles de imaginar hasta que se hace un test con usuarios; o los que simplemente no tienen una solución al alcance de todos, por ejemplo la solución de la aplicación de mapas de Apple 6, que no usa mosaicos de imágenes sino datos vectoriales, así VoiceOver te leerá las calles mientras desplazas el dedo, leyendo por tanto el contenido de cada zona del mapa.

La verdad es que me gusta mucho este capítulo, cómo describe con sinceridad la realidad de su proyecto, que es la de muchos otros, las limitaciones y los problemas que solemos encontrarnos, y los consejos son realistas y acertados. Además le tengo que agradecer la mención de este blog.

Capítulo 15: Elaboración de una Normativa de Usabilidad y Accesibilidad Web: El caso de la web de la Ciudad de Buenos Aires, Verónica Traynor

La autora nos introduce en el Diseño Centrado en el Usuario, en una forma de trabajo evolutiva y en espiral que permite a los integrantes del equipo avanzar y aumentar la calidad de sus bocetos de un modo más certero; según los modelos mentales ya no de ellos mismos, sino de los usuarios finales. El eje pasa a ser el ser humano con sus necesidades de percepción, comprensión, operabilidad y aprendizaje. Todo gira en torno a la observación empírica y metodológica de personas aprendiendo e interactuando.

Nos habla de la observación como metodología: "existe una diferencia significativa entre lo que les sucede a los usuarios, lo que interpretan sobre lo ocurrido y lo que opinan que les sucedió" y de los colores como parte del diálogo: "dejamos de hablar de pintar un cuadro y pasamos a construir un semáforo. Bello, pero fundamentalmente claro". Dos frases que me encantan.

Por último incluye la normativa de Usabilidad y Accesibilidad Web, publicada en 2010, que deben cumplir los sitios web pertenecientes al Gobierno de la Ciudad Autónoma de Buenos Aires.

Capítulo 16: Internacionalización Web, por Claudio Segovia

Nos introduce en la internacionalización de un sitio web (que no se refiere simplemente a crear sitios multilingües) y por qué deberíamos tenerla en cuenta. Detalla diferentes aspectos a los que deberemos prestar atención.

Si os interesa el tema, tengo un artículo relacionado con el mismo: Usabilidad e internacionalización.

Capítulo 17: Prácticas participativas en el Diseño de Interacción: El caso del Design Museum, por Mariana Salgado

Nos cuenta el proyecto "La vida secreta de los objetos" llevado a cabo en el Design Museum de Helsinki. El eje de este proyecto fue que el contenido generado por los visitantes (in situ, online o en los talleres organizados) como comentarios, relatos, opiniones, poemas, recuerdos o sentimientos basados en los objetos expuestos (y que podían estar en forma de texto, sonidos, música, imágenes, vídeos, etc.) estuvieran también en la galería, a disposición de los visitantes y promoviendo su participación. Un nuevo concepto de museo abierto y participativo, donde el diálogo continúe después de la visita.

De esta manera se enriquecería la experiencia de la visita al museo por medio de la inclusión. Esta información subjetiva permitiría disfrutar de las obras expuestas de muchas maneras, dando lugar a un museo abierto, y por tanto más accesible e inclusivo de las diferentes voces de nuestra sociedad.

En las conclusiones me llamó la atención dos párrafos porque se aplican también a la realidad de los proyectos web:

En muchos casos de diseño de interacción en el museo, el equipo de diseñadores no trabaja durante el proceso de incorporación de la pieza al espacio del museo, sino que su rol termina cuando la pieza interactiva está instalada. Eso imposibilita entender el contexto y encontrar ideas innovadoras para diseños futuros.

[...]

El público contribuye en mayor medida cuando ve que los comentarios de otros han sido respetados y exhibidos como parte del mensaje de la exposición.

Capítulo 18: Diseño y desarrollo de un editor de texto accesible bajo modalidad open-source, por Nahuel González

El objetivo del proyecto fue desarrollar un editor de texto accesible open-source. Partiendo de una lista de necesidades que debería atender el software, el artículo describe todas las características de la aplicación final, que a la publicación del libro estaba en la versión 2.0 y que es utilizado por usuarios con diferentes tipos de discapacidad.

Le agradezco al autor su referencia a mi artículo La usabilidad como metodología para el desarrollo de una aplicación (octubre, 2007)

Capítulo 19: Las métricas de accesibilidad desde una perspectiva práctica: eXaminator, por Carlos Benavidez

Carlos Benavidez, el creador de la conocida herramienta de evaluación automática de accesibilidad eXaminator explica por qué eXaminator se planteó como una herramienta que ofreciera una puntación numérica de la accesibilidad de la página. Explica además cómo se calcula la puntuación que otorga así como las ventajas y las limitaciones de la herramienta.

Una página que cumple con el nivel A, pero con ningún criterio de conformidad de nivel AA, obtiene según las WCAG el mismo valor de accesibilidad que una página que cumple con el nivel A pero también con muchos requisitos de nivel AA. La falta de precisión de esta escala tampoco permite conocer cuánto le falta a un sitio para alcanzar el nivel AA. Además, no todos los criterios de determinado nivel de conformidad afectan por igual a todos los usuarios. Estas son las razones para plantearse una puntuación numérica.

A pesar de ello, advierte que la accesibilidad no es una cualidad que se pueda medir con valores absolutos. La nota de eXaminator solo se puede considerar un indicador aproximado para contar con una escala sensible y precisa que nos permita hacer comparaciones (entre distintos sitios o el mismo sitio en el tiempo) o nos permita resumir en un resultado final, un resultado fácil de comprender y con una interpretación clara.

También habla de las limitaciones de cualquier herramienta de validación automática, que solo pueden comprobar un pequeño subconjunto de criterios de conformidad, y que por tanto toda revisión de accesibilidad deberá contar con un experto y una revisión manual.

Advierte que la calificación que otorga la herramienta no mide la accesibilidad general de la página sino el desempeño de la misma con respecto a las pruebas que realiza: no se puede asegurar que un 8 represente el mismo grado de accesibilidad que la misma nota en otro sitio.

Otra limitación de la herramienta es que la estructura de la página determina el número de pruebas que se pueden hacer en ella, habrá página con más de 20 pruebas y páginas que solo recibirán 4 o 5 pruebas, por tanto un mismo error tendrá mayor influencia en el promedio general a medida que disminuya el número total de pruebas posibles.

En el 2012 publiqué un artículo sobre otra limitación que hay que tener en cuenta en los validadores automáticos de accesibilidad: Falsos errores de validadores automáticos de accesibilidad basados en las WCAG 2.0

---

Artículos relacionados:

• Reseña: "Pioneros y Hacedores II. Fundamentos y Casos de Diseño de Interacción con estándares de Accesibilidad y Usabilidad", 2016

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

Nota 2020: consultar tabla resumen en el artículo Ocultar contenido visualmente y/o para el lector de pantalla (tabla resumen).

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

¿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, Voice Over (en dispositivos Apple) 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.

Descarga mi capítulo ampliado "Accesibilidad y SEO" (PDF, 248) del libro "Pioneros y Hacedores. Fundamentos y Casos de Diseño de Interacción con estándares de Accesibilidad y Usabilidad" , 2013, Lorena Paz (comp.)

Artículos relacionados:

• SEO y Accesibilidad. Accesible también para buscadores
• Sobre el uso de lectores de pantalla

SEO y Accesibilidad. Accesible también para buscadores

Descarga mi capítulo ampliado "Accesibilidad y SEO" (PDF, 248) del libro "Pioneros y Hacedores. Fundamentos y Casos de Diseño de Interacción con estándares de Accesibilidad y Usabilidad" , 2013, Lorena Paz (comp.)

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

1. Texto equivalente para todo elemento no textual (punto de verificación 1.1 y 8.1)
2. Javascript (punto de verificación 6.2, 6.3, 10.1)
3. 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)
4. Marcado correcto y uso adecuado de encabezados (punto de verificación 3.1, 3.5, 3.6 y 3.7)
5. Escribir para la web (punto de verificación 12.3, 13.8, 14.1)
6. Enlaces (punto de verificación 1.2, 13.1)
7. Frames (punto de verificación 6.5 y 12.1)
8. Metainformación e idioma (punto de verificación 13.2, 13.9,  y pauta 4)
9. Mapa web (punto de verificación 13.3)
10. 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:

• Ocultar contenido sin comprometer la accesibilidad ni el posicionamiento de la página
• Glosario SEO y analítica web
• Herramientas de SEO y analítica web

Artículos "Usable y accesible" relacionados:

• 10 razones para pasarse a las WCAG 2.0
• Respuesta a 25 dudas habituales sobre accesibilidad web