Tenon: herramienta online, extensión y API para validar de acuerdo a las WCAG 2.0
Resumen:
Sigo repasando diferentes herramientas de evaluación de accesibilidad. En este artículo os voy a hablar de Tenon, una herramienta de validación automática de acuerdo a las WCAG 2.0. Puedes consultar mi recopilación de todos los validadores en: Validadores y herramientas para consultorías de accesibilidad y usabilidad
Puedes usar Tenon de cuatro formas diferentes que voy a ir repasando a lo largo del artículo:
- 1. Evaluación online de una URL o código
- 2. Extensión de navegador "Tenon- Check"
- 3. Tenon API
- 4. Herramienta online avanzada para usuarios registrados
- Conclusiones: ventajas e inconvenientes
Evaluación online de una URL o código
Solo tienes que acceder a la página principal de Tenon.
La evaluación es gratuita, no es necesario registrarse y no hay límite de evaluaciones.
En el campo de texto puedes incluir tanto la URL de la página a evaluar como el código de la misma, útil si es una página cuyo acceso requiere autenticación.
Opciones de validación
Las opciones de validación son bastantes interesantes y las explico a continuación.
- Opciones de validación de Tenon -
Minimum Certainty
La documentación dice:
A veces las herramientas de accesibilidad devuelven resultados sobre los que la herramienta no está completamente segura de si son o no problemas reales.
Este parámetro permite filtrar los resultados “inciertos” eligiendo una puntuación mínimamente aceptable de certeza.
Se puede elegir 0%, 20%, 40%, 60%, 80% y 100%. Por defecto el valor es 0%, es decir, devuelve todos los resultados.
100% devuelve solo los errores de los que está 100% seguro de que son errores, algo que no recomiendan salvo en casos muy concretos. En la documentación dicen que intentan hacer pruebas que devuelvan resultados reales y que las puntuaciones con baja certeza debería ser pocos.
Yo pensé que la configuración de la certeza estaba pensada para filtrar los falsos positivos, tema que ya comenté en la recopilación que tengo sobre falsos positivos en validadores automáticos (Falsos positivos de validadores automáticos de accesibilidad basados en las WCAG 2.0)
Pero no es así. A continuación incluyo un ejemplo de un falso positivo que se muestra con "minimum certainty" tanto a 0% como a 100%. Se reporta siempre como error, no como advertencia, y ya informé a los autores para que lo revisen. En mi artículo sobre falsos errores puedes leer la razón por la cuál es un falso positivo, así como consultar otros falsos positivos de la herramienta.
- Falso positivo de Tenon -
Minimum Priority
Según la documentación, cada aspecto evaluado tiene una serie de factores que determinan su prioridad relativa. Por tanto, podremos filtrar los errores por prioridad. Se puede elegir 0%, 20%, 40%, 60% y 80%, siendo 0% el valor por defecto que nos devolverá todos los errores.
No se informa exactamente de cómo se calcula, pero indican que no es relativo al nivel de adecuación (A, AA, AAA). Efectivamente, en el listado de errores pueden aparecer errores de nivel AA antes que errores de nivel A. En la página de explicación de cada test, como luego veremos, se da alguna información relacionada con la prioridad, como el impacto en el usuario o en la interfaz, cuánto cuesta repararlo, etc.
Page Importance
Básicamente se calcula en relación con la prioridad de los errores encontrados en la página. Se recomienda dejar el valor más bajo por defecto y podría utilizarse para ordenar y filtrar los resultados.
Minimum WCAG Level
Permite evaluar por el nivel de adecuación A, AA, y AAA. Recordemos que si se indica AAA está evaluando todos los requisitos de nivel A, AA, y AAA.
En la documentación se indica que muy pocos criterios AAA son comprobables automáticamente. Por ello se recomienda que para evaluar el nivel AAA se sea estricto en la configuración del parámetro Minimum Certainty para controlar los falsos positivos.
User - Agent String / ViewPort Size
Si te emocionas pensando que te dan la opción de que evalúen la página con diferentes navegadores, lo siento, el user-agent no tiene impacto en el test. Como se indica en la documentación, es meramente informativo y la página no se renderiza con otra máquina aunque selecciones otro user-agent.
La buena noticia es que sí analiza en base al viewport indicado. Esto la convierte en una herramienta muy útil y poco común para analizar con facilidad la accesibilidad en diseños responsivos. Traté este tema en el artículo Responsive Design y accesibilidad. Buenas y malas prácticas. Errores comunes..
Esta opción te permitirá después, como veremos, en la versión como usuario registrado, tener diferentes proyectos para cada configuración del viewport.
Project ID / Document ID
Si tienes una cuenta, cada uno de tus proyectos tiene un ID. Si indicas el ID, este test quedará asociado a dicho proyecto, lo cual es luego útil porque podemos filtrar los test por proyecto.
El campo "Document ID" no parece estar documentado, de hecho si lo rellenas da error. Actualmente, como veremos, puedes filtrar los resultados por proyecto pero no por página. Estaría muy bien poder ver todos los test que has hecho de una misma página, imagino que este campo está pensado para poderlo explotar en el futuro.
Do you want Tenon to store the results?
Puedes elegir si quieres o no que almacene los datos (si tienes cuenta y estás logueado, sino es indiferente lo que indiques), y que de esta manera te aparezca en el historial de evaluaciones, como luego veremos.
Página de resultados
El número de test que realiza la herramienta por cada cada criterio de conformidad de las WGAC 2.0 se puede consultar en What Tenon Tests.
Según la documentación se realizan 132 comprobaciones:
- 104 test asociados a criterios de nivel A,
- 5 test asociados a criterios de nivel AA,
- 23 test asociados a criterios de nivel AAA.
En la documentación no se listan los test concretos que se realizan por cada criterio, pero se pueden deducir de los resultados de una evaluación y de las páginas concretas de documentación de cada test.
Datos generales
La página de resultados de una validación tiene una primera zona de datos generales:
- Datos generales del resultado de una evaluación con Tenon (ver imagen más grande) -
Los datos que se ofrecen son:
- Enlace "Show sample code": es un ancla al final de la página donde se muestra el request y el response de la API de Tenon para cURL, PHP, Python, Node y Ruby.
- "Share Link": es el enlace permanente a la página de resultados de la validación, por si deseas compartirlo.
- Número de errores y advertencias encontrados en la página analizada.
- Tiempo en el que se ha procesado el test. Veremos que en las opciones de validación como usuario registrado puedes poner un retardo para que el validador comience a hacer la validación. Esto puede ser útil se estás generando contenido dinámicamente.
- Viewport analizado, por ejemplo 800*600.
- Tamaño de la página, por ejemplo 125 KB.
- Descarga de los resultados en CSV.
- Gráficas de tarta:
- número de test que se han realizado en la página, con el porcentaje de los que han dado error y los que no;
- porcentaje por tipo de error. Es poco útil, indica el id del error y eso no nos da mucha información, tampoco es un enlace al listado de un determinado tipo de error en la página.
Hecho en falta que se incluya la información sobre los parámetros que has seleccionado para la evaluación, como por ejemplo el nivel evaluado (A, AA, AAA). Tampoco se indica en qué fecha se realizó el test. Puesto que esta página es la misma a la que enlaza luego el historial de las evaluaciones, sería muy relevante incluir estos datos.
Invocando directamente a la API, podrías pintarte el resultado de forma personalizada incluyendo por ejemplo estos datos.
El tratamiento personalizado de los datos devueltos por la API podría también utilizarse para mejorar mucho la información de las gráficas. Por ejemplo, algunas propuestas podrían ser:
- Gráfica por errores de nivel A, AA, AAA.
- Gráfica por tipo de error pero que permita reconocer cuál es el nombre de dicho error y un enlace a las instancias del mismo.
- Gráfica por tipo de error pero asociado al criterio de conformidad y al principio al que pertenece.
Datos por cada error
Después de la zona de datos generales tenemos un listado de todos los errores y advertencias.
- Resultado de un error encontrado por el validador en la página de resultados de Tenon -
Cada uno de los errores y advertencias tiene los siguientes elementos:
- Código del fragmento en el que se ha detectado el error.
- ID del test (cada test tiene su ID).
- Si es error o advertencia.
- Su prioridad expresada en % como hemos explicado anteriormente.
- La línea de código en la que se encuentra el error en la página generada.
- El criterio de conformidad de las WCAG 2.0 con el que está asociado y su nivel (A, AA, AAA)
- Descripción del error.
- Enlace "Recommended Fix" donde se documenta qué se está evaluando en este test. En esta página se indica:
- ID, título, breve descripción del error y de la solución.
- Datos sobre la priorización: impacto en el usuario, cuánto cuesta repararlo, impacto en la interfaz, etc.
- Código de ejemplo de error y solución.
- Personas a las que beneficia.
- Criterio o criterios de las WCAG 2.0 con los que está asociado
Aunque cada error tiene su página explicativa, como hemos visto, no se puede consultar esta documentación salvo pulsando en el enlace de cada error.
La herramienta no permite filtrar, agrupar u ordenar los resultados, que podría ser por tipo de error, nivel de adecuación, criterio de conformidad o principio al que está asociado, prioridad, ect. Sin embargo, de nuevo, el tratamiento personalizado de los resultados de la API nos permitiría poder implementar estas funcionalidades.
Extensión de navegador "Tenon- Check"
La extensión está disponible para los siguientes navegadores:
Al instalarla se incluye un icono en la barra de herramientas del navegador. Al pulsarlo evalúa la página en la que te encuentras y te envía a la página de resultados de Tenon, como si hubieras utilizado el validador online descrito en el apartado anterior.
Si estás logueado en la aplicación (la cuarta forma de usar Tenon que veremos) esta evaluación te aparecerá en el historial del evaluaciones.
Tenon API
Otra manera se usar Tenon es invocando directamente a su API, para ello deberás usar la key que te dan al registrarte (como veremos en la cuarta forma de usar Tenon). Según el plan que contrates tendrás la posibilidad de hacer más o menos llamadas a la API. Por ejemplo, la versión gratuita de 30 días incluye 500 llamadas a la API.
Este uso es muy útil para utilizar la API de forma personalizada, tanto en la revisión de tus desarrollos, como en la elaboración de tus informes en base a sus respuestas.
Request
En la llamada a la API deben incluirse dos parámetros obligatorios: la key (tu código personal que te dan al registrarte) y la URL de la página a evaluar.
El resto de parámetros son opcionales y son los que hemos visto en las opciones de validación, y otras opciones disponibles para usuarios registrados, como veremos: el ID del proyecto, el retardo para ejecutar el test, etc.
Enlaces de interés:
Response
La respuesta de la API te devuelve un JSON con todos los resultados de las pruebas realizadas.
Enlaces de interés:
- Documentación de los parámetros del response
- Ejemplos de requests (datos generales)
- Ejemplos de requests (datos de la evaluación)
Integraciones de la API de Tenon
Las tienes disponibles para WordPress (Access Monitor), Drupal (módulo Tenon), Selenium, etc.
Puedes ver el listado completo en Get Code de Tenon.io
Herramienta online avanzada para usuarios registrados
La última manera de utilizar Tenon es registrándose en su web para acceder a la herramienta que nos permite tener varios proyectos y acceder al historial de nuestras revisiones.
Solo está en inglés, es de pago y hay diferentes planes de precios. Hay un plan trial de 30 días que incluye 500 llamadas a la API.
A continuación repaso las funcionalidades de sus diferentes opciones de menú.
Dashboard
- "Dashboard" de Tenon -
La página principal incluye la siguiente información y funcionalidades:
- Filtro por proyecto (o todos los proyectos) y periodo de fechas (por defecto el último mes).
- Datos generales: número de páginas evaluadas, número de test realizados (pueden ser más que las páginas porque se ha podido evaluar repetidamente una página), promedio de errores o advertencias por página, promedio de certainty o priority de los errores y advertencias, etc.
- Gráfica de porcentaje de errores y advertencias por KB de código por día, puesto que no es lo mismo que una página de 10 KB tenga 15 errores a que los tenga una página de 400 KB, en el primero tienes más densidad de errores.
- Gráfica de densidad de errores por páginas, por ejemplo, hay 19 página con 11%-20% errores (por KB)
- Listado "Worst Performing Pages": es el listado de páginas que tienen mayor densidad de errores y advertencias.
- Listado "Duplicate Issues": lista los errores repetidos más frecuentes, es decir, el mismo código exacto que causa el mismo problema exacto, posiblemente asociados a la plantilla y que deberían corregirse urgentemente.
- Listado "Issues by Test ID": es la suma de problemas por test y el porcentaje que suponen. Por ejemplo, puede indicar que el 40% de los problemas es que las imágenes no tengan texto alternativo.
- Listado "Issues by WCAG Success Criteria": listado que, por cada criterio de las WCAG 2.0, indica el número de problemas encontrados y el % que suponen.
Estos datos te dan una visión general del número de errores y de los errores más habituales. Sin embargo en la práctica es poco operativo, porque esta información no me enlaza con el listado de páginas que tienen dichos errores. En este sentido era mucho más útil el planteamiento que hacia por ejemplo Siteimprove.
History
En este apartado tenemos el listado de las páginas que se han evaluado.
- "History" de Tenon (ver imagen más grande) -
El listado está ordenado a partir del test más reciente y solo puede filtrarse por proyecto. Esto no da mucha versatilidad: no podemos filtrar para mostrar solo los test de determinada página, no podemos ordenarlos en base al número de errores encontrados o la prioridad de los mismos, no podemos buscar los test realizados entre determinadas fechas, etc.
Por cada test del listado tenemos los siguientes elementos:
- Id del test.
- Minutos, horas o días que hace que se ha realizado el test.
- Código 200 (se pudo evaluar la página) o 400 (no se pudo evaluar la página).
- URL de la página evaluada.
- Número de errores y advertencias.
- Enlace a la página de resultados, tal y como la he descrito
API Settings
Puedes fijar cuáles serán las opciones de validación por defecto.
Además de las opciones ya vistas en las opciones de validación del validador público, aquí podemos además indicar:
- "Fragment": si estás evaluando código en vez de URL.
- "Reference info": si quieres que en la página de resultados se muestre en cada error el enlace "Recommended Fix", que como vimos, documenta qué se está evaluando en cada test.
- "Delay": indicas en milisegundos el retardo para que empiece el testeo de la página, que puede ser importante si tienes contenido que se pinta dinámicamente y sabes que tarda.
Projects
- "Project" de Tenon (ver más grande) -
Hay un proyecto por defecto pero puedes crearte tantos como desees. Pulsando en el nombre del proyecto puedes ir al dashboard con los datos filtrados por dicho proyecto.
Los campos que definen a un proyecto son:
- Nombre y descripción. Además a cada proyecto se le asigna un ID que permite después asociar evaluaciones a un proyecto concreto.
- URLs a testear.
- "Test these URLs now?": que lanzará el análisis cuando crees el proyecto.
- Opciones de evaluación por defecto de ese proyecto, que son las que ya hemos comentado en apartados anteriores. Por ejemplo puedes tener un proyecto para evaluar cada viewport de tu portal.
- Si deseas que este proyecto sea tu proyecto por defecto y por tanto el asociado al campo de validación siempre presente en la cabecera de la herramienta.
Profile
Tienes los datos de tu cuenta y perfil: nombre, email y tu avatar.
Hace unos meses se añadió una funcionalidad nueva, ahora puedes añadir los sitios que quieres monitorizar y el proyecto con el que quieres asociarlos.
Se analizarán automáticamente tus páginas cada vez que se modifiquen.
En función del plan de pago que tengas te puede interesar o no.
Por cada sitio que incluyas, se genera un siteKey. En la página se informa del código que debes incluir antes del </body>
de las páginas (que incluye tu siteKey) al estilo de lo que se hace para incluir la monitorización de tu sitio por ejemplo con Google Analytics.
Password
Permite cambiar tu contraseña para acceder a la aplicación.
Address
Puedes indicar tu dirección y teléfono.
API key
Tu key para invocar a la API directamente, como explique en Tenon API. Tienes la posibilidad de generar una nueva.
Settings
Puedes configurar aspectos como: el formato de las fechas y horas, la franja horaria, cuándo caduca la sesión, el formato de los numerales o tu suscripción a la mailing list.
Documentation
Acceso a la documentación y ayuda.
Conclusiones: ventajas e inconvenientes
A lo largo del artículo he ido repasando los puntos fuertes y débiles de la herramienta que resumo a continuación.
Puntos fuertes:
- La evaluación de un URL o código y el uso de la extensión del navegador es gratuita sin límite de evaluaciones.
- Evalúa de acuerdo a las WCAG 2.0 en sus tres niveles de adecuación A, AA, AAA.
- La opción de poder seleccionar el viewport que quieres evaluar es de gran ayuda para revisar la accesibilidad en portales Responsive Design (Responsive Design y accesibilidad. Buenas y malas prácticas. Errores comunes.)
- Desde 9 dólares al mes tienes acceso a la herramienta para usuarios registrados, que puedes probar con la versión trial (30 días y 500 llamadas a la API).
- En la versión para usuarios registrados puedes tener un proyecto por cada viewport y un historial de tus evaluaciones. Además tiene otras opciones de validación, como el retardo en comenzar la evaluación hasta que estés seguro de que se ha cargado y generado todo el contenido dinámico.
- La versión de pago ya admite la monitorización automática de tus sitios. Es decir, las páginas se evalúan automáticamente cada vez que cambian.
- Puedes invocar directamente a la API, lo cual te permite controlar directamente tus análisis, los resultados y la manera de mostrarlos.
Puntos débiles:
- Los test son menos fiables que los que hemos visto en otras herramientas de evaluación, puesto que pueden presentar falsos positivos.
- La página de resultados no permite ordenar, filtrar o agrupar los resultados, que podría ser por tipo de error, nivel de adecuación, criterio de conformidad o principio al que está asociado, prioridad, etc. Podría además incluir gráficas más útiles.
- La página de resultados no incluye la información sobre los parámetros que has seleccionado para la evaluación o la fecha en que se realizó el test, algo muy relevante cuando accedes desde el historial o compartes la página de resultados.
- Las principales páginas de la versión de pago, historial y dashboard, en la práctica son poco útiles: no puedes agrupar los test de una misma página, apenas tienes opciones de filtrado y búsqueda, los listados de errores más frecuentes no te enlazan con las instancias de los errores o las páginas que los tienen, etc.
- No hay una documentación centralizada donde consultar cómo se calcula exactamente la prioridad, o qué se está evaluando exactamente por cada criterio, aunque puedes ir test a test investigando para hacerte una idea.
- Habrá personas para las cuales sea una limitación que solo esté disponible en inglés.
Artículos relacionados:
- Validadores y herramientas para consultorías de accesibilidad y usabilidad
- Siteimprove, herramienta para el análisis programado de nuestro portal
- aXe Rules, Google ADT Rules y el Mobile Web Accessibility Checker
- Accessibility Scanner, evaluar la accesibilidad de una app de Android
- Tanaguru
- Falsos positivos de validadores automáticos de accesibilidad basados en las WCAG 2.0
- Nueva versión de la herramienta de ayuda para realizar una consultoría de accesibilidad web de acuerdo a las WCAG 2.0