La semana pasada se liberó el primer borrador de las WCAG 3.0 (AKA “Silver”) y ¡prepárate porque se avecinan grandes cambios!
Esta entrada la he reescrito varias veces. Me gustaría ser muy productivo y lanzar los artículos rápido, pero es que soy como soy y me gusta profundizar en cada tema. Así que he pasado por varios estadios, el primero de euforia, ¡versión nueva!, el segundo de incredulidad una vez lees el resumen que compartió la W3C en el que piensas que se va a acabar el mundo y un tercer estado de «¡ahh, vale, en realidad querían decir X y no Z como pone en el resumen!» tras la lectura completa del borrador.
Así que, te voy a hacer mi resumen personal, subjetivo e incompleto, de un primer borrador que va a ir evolucionando con el tiempo. La terminología tal vez no será la más adecuada pero hay tantas novedades que no tengo claro como traducirlas y que mantengan el sentido. ¡Allá voy!
No me llames WCAG 3.0, llámame Silver
Todas las organizaciones y empresas exitosas mantienen ciclos de desarrollo de sus productos que empiezan cuando se termina el desarrollo anterior o incluso antes. En este proceso una de las primeras etapas es analizar qué se puede mejorar del producto actual y de ese análisis pueden surgir dos opciones: una actualización (como por ejemplo hizo Nintendo con las múltiples versiones de la DS) o un producto nuevo (como también hizo Nintendo tras el descalabro de Wii U y el éxito de 3DS dando como resultado a la exitosa Switch).
Proyecto Silver
En este caso nos encontramos que mientras aún no se ha producido la aprobación de la versión final de la WCAG 2.2 ya empezamos a ver el primer borrador de WCAG 3.0. Este borrador es el resultado del proyecto “Silver”, iniciado en 2016. Este proyecto se organizó para plantear una nueva forma de las guías de accesibilidad.
Tras meses de trabajo se concluyó que las WCAG 2.X son complejas de entender, no cubren bien las necesidades de determinados colectivos (especialmente las personas con diversidad a nivel cognitivo) y que el modelo de conformidad no encaja bien con las necesidades de las organizaciones (sea lo que sea esta última frase). Hay una presentación con las conclusiones del proyecto.
Destaco tres retos que identificaron:
- Es necesario mejorar la usabilidad
- No todas las mejoras de accesibilidad se pueden evaluar con un SÍ/NO
- Facilitar el mantenimiento de la norma
Objetivos y desarrollo
De esta forma se establecieron nuevos objetivos específicos para WCAG 3.0
- Ser más inclusivas con las necesidades de las personas con discapacidad (especialmente con la diversidad cognitiva)
- Tener en cuenta el impacto real de los diferentes problemas de accesibilidad que se pueden producir
- Facilitar la comprensión por parte de personas sin conocimientos técnicos
- Flexibilizar el modelo de conformidad para que se adapte a diferentes tipos de contenido.
- Permitir que una web tenga pequeños errores de accesibilidad si no tienen un impacto importante en la usabilidad
- Animar a mejorar la accesibilidad en vez de limitarse a cumplir con WCAG 2.x AA
- No limitarse al contenido web e incluir aplicaciones, herramientas y nuevas tecnologías como la realidad aumentada.
Para aumentar la inclusión se ha vuelto a analizar las necesidades específicas y las barreras que se encuentran al navegar las personas con tipos concretos de discapacidad que generan diversidad a nivel funcional. Estas necesidades funcionales se han clasificado según categorías de funcionalidad, por ejemplo: visión, audición, movilidad, habla, memoria, lenguaje y formación, etc. La taxonomía no es definitiva y puede variar.
Para cada necesidad se ha escrito un resultado satisfactorio para la misma. Este resultado (outcome en el borrador) permite definir tests para comprobar si se obtiene el resultado deseado y también permite la redacción de un método (method) para conseguir el resultado. Los resultados se han agrupado en guías (guidelines) y también se ha desarrollado manuales (how-to) con información adicional.
Los métodos serían similares a las técnicas de la versión 2.X y los how-to serían similares a los actuales understanding.
No me llames Silver, llámame borrador de WCAG 3.0
Todo este proceso, que ha sido muy completo y muy largo ha llevado que el proyecto Silver dé como resultado el primer borrador de WCAG 3.0 que se liberó el 21 de enero de 2021 con el objetivo de recibir feedback público y no solo de los equipos e individuos relacionados con el proyecto.
Cambios que traerá WCAG 3.0
En el nombre
Aunque sea cosmético tenemos un cambio grande en el nombre. WCAG 2.X era Web Content Accessibility Guidelines, y con 3.0 será W3C Accessiblity Guidelines. Este cambio se produce por dos motivos, el primero para ampliar los horizontes de las guías de accesibilidad y no limitarse al contenido web y por otro reconoce que WCAG se ha convertido en sinónimo de accesibilidad.
En la estructura
Pasamos de una estructura organizada en: principio, pauta, criterio de éxito, técnicas y undestanding a una estructura basada en guías, resultados, métodos y how-to. En el borrador no se mencionan los principios POCR (perceptible, operable, comprensible y robusto).
En el modelo de conformidad, adiós a la retrocompatibilidad
Se han generado una serie de cambios para mejorar el modelo de conformidad para dejar atrás las cuestiones con respuesta SÍ/NO ya que se quedan cortas al evaluar algunas necesidades. A la misma vez, se tiene en cuenta que pese a que todas las medidas son deseables no todas las barreras impactan igual a los usuarios con una diversidad específica.
En la rama 2.X teníamos tres niveles: A, AA y AAA. Si se cumple el criterio se considera superado y cada criterio pertenece a uno de los tres niveles. Para obtener el nivel A se deben superar todos los criterios de nivel A y de la misma forma para los otros dos niveles. Si falla un criterio, no se obtiene el nivel de conformidad. Por ejemplo, podemos tener una web perfectamente hecha, que cumpla con todos los criterios del nivel AA, AAA pero que falle en uno de nivel A, el resultado objetivo es que la página web no cumple con las medidas de accesibilidad.
Los niveles A, AA y AAA quedan atrás y ahora tendremos bronce, plata y oro. Y la equivalencia no será directa, así que adiós a la retrocompatibilidad. Pero afortunadamente el nivel AA será muy similar al nuevo bronce. Plata y oro requerirán evaluaciones de usabilidad adicionales.
Tests atómicos y tests holísticos
Ahora tendremos dos tipos de pruebas, las atómicas y las holísticas. Las pruebas atómicas se refieren al contenido web, similar a los criterios de éxito actuales aunque algunas serán más sofisticadas pero en el fondo se parecerán mucho a las auditorías actuales, una parte serán manuales y otras automatizables como lo son ahora. El resultado de estas pruebas determina si se alcanza el nivel bronce o no.
Las pruebas holísticas por el contrario serán más similares a las pruebas de usabilidad, pero con usuarios reales de tecnologías de asistencia. El resultado de estas pruebas es clave para conseguir los niveles plata y oro si previamente se ha alcanzado el nivel bronce.
Se persiguen varios objetivos, el primero es motivar a las organizaciones a no conformarse con el nivel AA y tener en cuenta la usabilidad para mejorar la accesibilidad y por otro evitar falsos negativos.
¿Falsos negativos? Sí, serían aquellas páginas que consiguen el nivel bronce (o el AA, AAA) pero que en realidad no son usables. Aquí entrarían todos los hacks que consiguen que una web pase las auditorías pero cuyo resultado es desastroso y también las webs que implementan mal las medidas de accesibilidad, por ejemplo añadir un texto alternativo que no sea útil o encabezados que no estructuren el contenido. Realmente la web tendría atributos alt y encabezados, pero si no están bien hechos no ayudarán a los usuarios a completar los procesos de interés.
Sistema de puntuación
Esta novedad la he adelantado en la sección anterior. Para el nuevo modelo de conformidad se ha diseñado un sistema de puntuación y vamos a tener que acostumbrarnos a esta nueva forma de evaluar. El objetivo es conseguir una serie de valores numéricos a partir de los resultados de las pruebas atómicas.
En WCAG 2.X teníamos respuestas binarias, para muchos criterios estas preguntas cerradas son adecuadas, pero en otras situaciones no tanto. Tendremos tests binarios, promediables y otro tipo de respuestas (adjetivos, rúbricas, etc.).
Imagina esta situación, un criterio podría ser: “Las imágenes tienen un atributo alt”. Sí o no, así de fácil. Pero podemos hilar más fino, en una web pueden aparecer varias imágenes. ¿Qué es más grave?, ¿que todas las imágenes tengan un alt a excepción de una o que no lo tenga ninguna? Si 9 de las 10 imágenes tienen un atributo alt, podríamos decir que este outcome (la palabra en castellano me parece que no encaja bien) se cumpliría en el 90%, este ejemplo se corresponden con una prueba promediable. Se trataría de aplicar la prueba binaria al número de apariciones del objeto en cuestión.
Una segunda cuestión podría ser este otro criterio que me invento: “El atributo alt proporciona información equivalente a la imagen o describe su contenido”. Aquí entramos en el apasionante mundo del atributo alt, ¿cómo se redacta un buen atributo alt? No hay una guía al respecto, depende de muchísimos factores, entre otro el contexto, de forma que una misma imagen puede tener dos atributos alt diferentes y completamente válidos en dos contextos distintos. En este ejemplo es más evidente que una respuesta SÍ/NO no es adecuada y tal vez sería más apto usar un determinante (en el borrador hablan de adjetivos) como “mucho”, “poco” o “ninguno”.
¿Y cómo se integra esto con la puntuación? Fácil, pregunta binaria: 100% ó 0%. Pregunta promediable sería calcular la frecuencia relativa a partir del número de respuestas binarias. Y los tests que aceptan otras respuestas nos especificarán cómo puntuarlos. En el ejemplo del párrafo anterior “mucho” debería tener una puntuación superior a “poco”.
Como objeción podemos añadir que hay errores que son graves y que no deben aparecer nunca en una web por mucho que el 99% de los casos estén bien resueltos. Lo tienen previsto, estos son los errores críticos y si suceden la puntuación en esa prueba pasa a ser del 0% independientemente del resto.
Así tendremos dos series de valores que tendremos que ir contando: la puntuación de cada prueba y el número de errores críticos. Para alcanzar el nivel bronce se necesitará una puntuación media de 3,5 (sobre 4) global y en todas las categorías funcionales y ningún error crítico en vistas o procesos.
No te lo niego, al principio no me gustó para nada el planteamiento. Es complicar las cosas pero si lo piensas bien tiene sus ventajas, porque se aceptarán pequeños errores si su impacto es bajo así la gente dejará de ver a la accesibilidad web como una molestia. Por otro lado, se consigue el objetivo de ser más inclusivo a través de las categorías funcionales. Si le añadimos las pruebas holísticas tendremos una web (o app o herramienta o lo que sea) que respeta las buenas prácticas (o su mayoría) y que resulta usable a grupos de usuarios con diversidades específicas.
Definición de ámbito
Se tiene en cuenta que la evaluación de la accesibilidad se produce en un contexto y ámbito específico. En algunos casos, como era hasta ahora, teóricamente se refería a todo el contenido de un sitio web. Pero claro, eso no es práctico en algunos casos y por ello surgió la metodología abreviada WCAG-EM para poder auditar un sitio web sin revisar todo el contenido (imagina que la Wikipedia quisiese una auditoría de todo el contenido, ¡tierra trágame!).
Este cambio se adapta a la realidad de la web, sitios con mucho contenido no se pueden evaluar a mano. Si el contenido cambia frecuentemente la validez de la validación caducará rápido. No todo el contenido de un sitio tiene la misma importancia y que la importancia se ha de centrar en los procesos.
Declaración de accesibilidad
Aunque no sean obligatoria, depende de la legislación que se aplique a cada sitio web, es necesario tener una declaración de accesibilidad ya que en ella se recoge información esencial que es de especial valor para los colectivos más beneficiados por cuidar la accesibilidad web y no añadiendo plugins que mal configurados pueden empeorarla.
En la 2.X declarábamos la fecha, las guías utilizadas, el nivel de conformidad alcanzado, una descripción de las páginas analizadas y un listado de tecnologías necesarias para que la web sea accesible. En WCAG 3.0 cambian los dos últimos puntos, ahora se deberá explicar brevemente las vistas (documentos web, contenido estático o lo equivalente en la aplicación o herramienta) y los procesos y un listado del hardware y software (incluyendo tecnologías de asistencia) utilizadas en la revisión.
Conclusión
Se avecinan muchos cambios y la fecha de llegada es indeterminada, igual dos años o más. Solo una lectura detallada y pormenorizada del borrador y los documentos que le acompañan resuelven parte de las dudas y angustias que generan los resúmenes así que no te agobies como me ha pasado a mi. Se trata de un borrador con una declaración de intenciones, intenciones muy importantes y que buscan generar una Web más justa e inclusiva, aunque al resto nos de más trabajo y esfuerzo adaptarnos y acostumbrarnos. Muchas cosas pueden cambiar a lo largo de este proceso pero una cosa está clara la W3C sabe que WCAG 2.X no es suficiente y que se puede mejorar aunque ello implique romper con parte de la retrocompatibilidad. Este borrador plantea algunas incógnitas que se responderán a su debido momento y lo que debemos hacer es estar pendientes y proporcionar feedback cuando nos lo pidan.
Deja una respuesta