El viernes 25 saltaba la noticia en WordPressTavern: WordPress caía de la lista de los posibles CMS para renovar la web de la W3C y el principal motivo era Gutenberg, en concreto sus problemas con la accesibilidad.
La renovación de la web de W3C
Pero para entender los motivos para descartar a WordPress, que te adelanto ya que no es solo por problemas de Gutenberg.
Hace casi un año, el 9 de noviembre de 2019, el coronavirus quizá ya estaba empezando a pasearse libremente, la W3C publica una llamada para buscar una agencia que se encargue de la renovación de su página web.
En esta llamada explican que son conscientes de que es difícil navegar por su web y que el aspecto está desfasado entre otras cuestiones, la página actual tiene aproximadamente 10 años.
Publican una lista de requisitos, en el primero como no podía ser menos se indica que la nueva web debe estar construida con HTML 5 y respetar WCAG 2.1 AA, a ser posible AAA, y cumplir con los estándares. Entre otros requisitos la agencia deberá aconsejarles qué CMS se ajusta mejor a sus necesidades. Además indica, necesitamos un CMS con trayectoria y de fácil mantenimiento porque pretenden mantenerlo durante bastantes años. Cabe destacar que en la lista de requisitos no mencionan nada de la licencia del CMS.
Para facilitar el proyecto a la agencia la W3C les proporcionará ayuda a través de sus equipos, en especial les proporcionarán expertos en accesibilidad.
Al final del documento hay una FAQ en la que aparecen datos y explicaciones interesantes. El primero es que el presupuesto del encargo es unos 200.000 dólares y que la W3C no se encarga de la renovación porque sus empleados trabajan en otras áreas y no quieren cargarlos con más trabajo. Actualmente la web funciona con una solución que programaron ellos en 2008 que recopila todos los fragmentos de HTML que provienen de diferentes fuentes (Wordpress [sic], Symfony, etc.). Y otro dato importante, no tienen preferencia por el CMS pero sí que les gustaría que fuese open source y que si tiene control de versiones ilimitado sería ideal.
Como último comentario destaco que en la FAQ piden a las agencias que indiquen en sus propuestas como van a testear la accesibilidad web.
La propuesta de Studio24
Aquí tienes la propuesta de Studio 24, entrada publicada el 13 de diciembres de 2019
Studio24, una agencia británica con 20 años de experiencia en desarrollo web respetando los estándares les remite su propuesta en formato PDF. Quiero destacar un par de puntos del documento:
- Se presentan como especialistas en desarrollo open source HTML, CSS, JS y PHP
- Pueden hacer pruebas de usuarios en colaboración con una empresa dedicada a la accesibilidad digital
- Sus desarrollos se centran en la accesibilidad y el buen etiquetado
- Dejan caer que tienen un framework que sirve de starter kit
- Recalcan que como equipo se toman la accesibilidad muy seriamente
- Para la selección del CMS recalcan:
- Elegirán el CMS que genere HTML accesible y respetando los estándares
- No se puede garantizar que ningún CMS de hoy se mantenga durante los próximos 10 años, incluso WordPress
- Respecto a WordPress dicen que lo han usado mucho estos últimos 10 años y que su combinación de usabilidad en el editor, la comunidad, la licencia open source y estar basado en PHP le convierten en una plataforma bien soportada.
- Control de versiones: el sistema es “nice” pero no es eficiente
- Edición colaborativa: Gutenberg ahora mismo no la soporta
- Accesibilidad:
- “La accesibilidad y el diseño inclusivo está en el corazón de todo lo que hacemos”
- Usan un conjunto de herramientas: evaluadores automáticos, Lighthouse (que extrañamente dicen que está en versión experimental), un simulador de defectos de visión (que realmente sirve para poco en el testeo) y el lector de pantalla de Apple.
- Regularmente consulta la lista de herramientas de accesibilidad de la W3C, sí, la misma lista que se actualizó por última vez en 2016
- Que su proceso de trabajo incluye formación en accesibilidad al cliente. Es decir, que le darán clase a la W3C sobre accesibilidad. Esto a mi me suena copy paste de otras propuestas, sinceramente.
Enfoque del proyecto
Entrada explicando el enfoque del proyecto, publicada el 7 de mayo de 2020
En el enfoque del proyecto establecen una lista de resultados exitosos, entre ellos cumplir con la WCAG 2.1 a nivel AA y AAA donde sea posible. En ningún momento se menciona que el CMS sea open source.
Estrategia CMS y requisitos
Entrada explicando la estrategia CMS y los requisitos, publicada el 15 de junio de 2020
Recalcan que ningún CMS del mercado puede garantizar estar activo dentro de 10 años (aunque podrían destacar que los CMS open source basado en estándares garantizan una mayor longevidad o un mantenimiento después del fin de su desarrollo por parte de cualquier tipo de desarrollador). También destacan que la W3C tiene un sesgo a favor de los CMS con grandes comunidades como lo es WordPress.
Así que interpretan de los requisitos que el CMS debe ser un proyecto:
- Maduro, con más de 2-3 versiones mayores
- Idealmente open source
- Tener una comunidad grande
- Soportar una API basada en estándares
- Soportar internacionalización
Respecto a la accesibilidad dicen que el front end debe respetar WCAG 2.1 AA, AAA idealmente y ya indican “muchos CMS no respetan el nivel AA de accesibilidad. Por ejemplo, WordPress tiene 189 problemas de accesibilidad abiertos en su nuevo [sic] editor Gutenberg (a fecha 15 de junio de 2020)”. Empiezan las críticas a WordPress, por otro lado razonables dada su familiaridad con el proyecto.
Al final, los tres factores que determinarán la elección del CMS son:
- Lo bien que cumpla el CMS con los requisitos de la W3C
- Lo bien que encaje el CMS con la forma de trabajar de Studio 24
- La facilidad de mantenimiento del CMS
Estándares front end
Entrada explicándo los estándares front end, publicada el 12 de junio de 2020
En esta entrada se deja claro que durante el desarrollo las comprobaciones de accesibilidad las hará Studio 24, literalmente (según mi traducción) dicen: “… con referencia a la WCAG Guía de Referencia Rápida, para asegurar que la accesibilidad está en primera fila del proceso desde el comienzo y no sea un ejercicio de marcar casilla posterior”
Buf, esto me genera muchas dudas, la guía de referencia rápida sirve única y exclusivamente para hacer una comprobación inicial orientativa, nada más. Se trata de una serie de comprobaciones muy básicas pero que no cubren todos los puntos de la WCAG, así que esto dista mucho de poner la accesibilidad en primera línea.
Tampoco se trata de hacer una auditoría extensa en cada paso que se da en el desarrollo. Lo correcto sería primero formar a todas las personas implicadas en el proyecto para que conozcan los puntos mencionados en la guía rápida y además que cada perfil profesional conozca las barreras que puede introducir en el proyecto y la forma de evitarlas. Por ejemplo, en diseño que se entienda bien qué es el contraste de color, en desarrollo que se conozca el buen uso de HTML5 y ARIA, etc.
Me llama mucho la atención que determinan los sistemas operativos y los navegadores sobre los que se testeará la web, para ello se basan en una guía del gobierno británico que determina estos navegadores y sistemas operativos. Personalmente me parece una lista claramente insuficiente: ¿dónde está GNU/Linux?, ¿no sería necesario que incluyan navegadores populares en otros territorios?, ¿algún navegador en formato texto?. Realmente no es una lista extensiva ni inclusiva y que no refleja la realidad sobre cómo las personas navegan por la web, por ejemplo los dispositivos de Xiaomi, que son muy populares, incorporan su propio navegador.
Actualización sobre la selección del CMS
Entrada actualizando el estado de la elección del CMS, publicada el 24 de julio
Problema: Los tres CMS estudiados Statamic, Craft y WordPress no cumplen bien con los requisitos de accesibilidad.
Señala, muy acertadamente, que pocos CMS parecen cumplir con las ATAG, y aún así aunque las cumplan no se ajustan adecuadamente al resto de requisitos del proyecto.
A mi personalmente me llama la atención que en este momento se cite a las ATAG (Authoring Tools Accessibility Guidelines), hermanas de las WCAG que sí se citan en los requisitos.
Debido a su familiaridad con WordPress y su desconocimiento de los otros CMS los ponen a prueba y los evalúan. Y ya nos indican una serie de preocupaciones que tienen Respecto a WordPress, principalmente respecto a la longevidad que puede tener el proyecto según su forma de trabajar con WordPress. Gutenberg no les gusta y lo dejan claro, en vez de evaluar una versión actual desde que se lanzó Gutenberg se han mantenido fieles a Classic Editor. Y ahí es donde viene el problema de la longevidad, Classic Editor tiene una fecha de finalización de soporte, el 31 de diciembre de 2021. También lanzan una reflexión, consideran que Gutenberg es síntoma de que WordPress se está enfocando en un usuario no técnico en lugar de un usuario desarrollador que quiera usar WordPress en sus proyectos para clientes.
Apuntan a una gran verdad, WordPress depende demasiado en plugins para añadir funciones que integran CMS más modernos. Una de las funcionalidades necesarias para este proyecto es la internacionalización y es totalmente cierto que WordPress no sirve. Me puedes decir, hay plugins, cierto, pero son plugins de terceros, pese a que estén licenciados bajo GPL nadie sabe qué sucederá en el futuro. Sabemos que la i18n (abreviatura de internacionalización) llegará en próximas versiones. Cuando llegue, ¿qué pasará con los plugins?, ¿se abandonarán?, ¿seguirán?, ¿habrá que hacer cambios para que las webs sigan funcionando?, etc.
Por último también destacan que el sistema de revisiones no es óptimo para un gran número de versiones.
Entrada de WordPressTavern
Entrada de WPTavern mostrando su opinión sobre el descarte de WordPress, publicada el 24 de septiembre de 2020
Entonces llega el artículo de WordPressTavern. En este artículo se centran en dos puntos:
- Se rechaza el uso de WordPress por los problemas de accesibilidad de Gutenberg, el problema de i18n lo dejan como otra cosa más
- Se debería usar WordPress por ser de licencia abierta
Como has llegado hasta aquí sabrás que esto no es así y que son más motivos los que hacen descartar el uso de WordPress. Pero especialmente me sorprende negativamente la frase: “La W3C prioriza la accesibilidad sobre su preferencia por las licencias open source”. Esto llevó a que empezase el hilo de Twitter que dio lugar a una buena e interesante discusión entre varios miembros de la comunidad.
Mi opinión es sencilla, a la W3C le gusta el open source, pero menos que la accesibilidad. ¿Qué sentido tiene que la organización que define las normas de accesibilidad use herramientas no accesibles? Por mucho que estas herramientas sean open source la accesibilidad es irrenunciable. La W3C tiene equipos muy diversos, algunos de ellos han trabajado muy duro, ¿en serio creemos que estas personas van a estar de acuerdo en que se usen herramientas no accesibles, que probablemente les van a discriminar en su trabajo, simplemente porque son open source?. Además, recuerdo que la accesibilidad es requisito y la licencia open source es deseable pero no imprescindible.
No entro en el debate a favor del open source, tengo mi propia opinión al respecto y creo que es fácil saber cuál es, para algo intento colaborar en la comunidad WordPress 😉
La respuesta de Studio 24
Entrada respondiendo al artículo de WPTavern, publicada el 25 de septiembre de 2020
La respuesta oficial no se dejó esperar demasiado. Basándose en la accesibilidad justifican que se descarta el uso de Gutenberg.
En particular, dicen que este año lanzaron un proyecto para la universidad de Cambridge con WordPress y Gutenberg. En junio revisaron el feedback sobre accesibilidad por parte de los usuarios y que ello fue determinante en su decisión.
Por cierto, momento spam de valor, nos doran la píldora hablando positivamente de WordPress Accessibility Day.
También habla sobre la elección de React. En Studio 24 tienen front ends pero no especialistas en React e insisten en que el front end debería basarse en estándares, razón no le falta. Pero, React se usa en el backoffice y no en la página que se entrega al visitante, así que esta crítica es correcta pero no decisiva.
Respecto al open source deja claro que la mayor parte del proyecto se basa en estándares y proyectos open source, a excepción de Craft. Y que no sea open source les ha dado una ventaja muy provechosa: poder hablar directamente con el equipo de desarrollo y conseguir que se comprometan a solucionar los problemas de accesibilidad que tiene actualmente Craft. ¿Cómo deberían haberlo hecho con WordPress?, el proceso actual no es efectivo para este tipo de proyectos, tener un teléfono al que llamar sí.
Por último dejan claro que las páginas con informes técnicos seguirán funcionando como hasta ahora, sobre Symfony y que las especificaciones se seguirán publicando en GitHub.
Mi opinión
Es muy loable que Studio 24 haya practicado este ejercicio de transparencia, aunque la W3C haya intervenido en este punto. No obstante al analizar toda la documentación que publican a mi me surgen dudas respecto a sus argumentos sobre accesibilidad. Cuando presentan su propuesta regalan los oídos de la W3C hablando de accesibilidad, más tarde anuncian su forma de actuar en el estudio, que no garantiza una verdadera evaluación de la accesibilidad, en otra entrada dejan caer que no tienen a un especialista pero en otra posterior sí que lo tienen. Me parece que hay una falta de consistencia, aunque también puede ser una falta de información o precisión en la misma. Por último la forma de proceder, evaluando la accesibilidad de Statamic y Craft pero no la de Gutenberg porque ya la conocen y usando como argumento el número de tickets de accesibilidad abierto en GitHub… ¿qué queréis que os diga? Entiendo su decisión pero a mi no me convence el motivo ni es un proceso justo yo puedo creer que conozco una herramienta pero si la quiero comparar detenidamente con otra tendré que auditarlas a las dos. Deberían haber dedicado más tiempo y haber hecho una revisión en profundidad a los tres CMS y presentar incluso tablas comparativas dejando claras las versiones de cada herramienta. Han criticado mucho a Gutenberg pero no sé a cuál de todas sus versiones.
Obviamente que se descarte a WordPress, el CMS open source más usado del mundo, es una mala noticia. Pero hay que entender las razones. La primera y más importante es que WordPress “out of the box” no cubre las necesidades de la mayoría de proyectos, hay que recurrir a plugins para conseguir funciones que podrían considerarse básicas, como la i18n. Al mismo tiempo, ¿es necesario que WordPress incorpore todas esas funcionalidades que necesita un proyecto como el de la W3C?, creo que no., WordPress se usa en muchísimos proyectos más pequeños y con unas necesidades a nivel de longevidad menores. Es razonable pensar que WordPress debe de ser “ligero” pero ampliable para poder adaptarse a diferentes tipos de proyecto.
Se puede razonar que un CMS open source garantiza una longevidad superior que uno propietario puesto que el código está disponible para modificar. Pero para ello hace falta saber modificarlo. La W3C en su encargo ya deja claro que no hacen internamente la renovación de la web porque no quieren que sus trabajadores hagan esta tarea y que prefieren delegar. Y si la empresa sobre la que delegan decide que prefiere no arriesgarse y la W3C está de acuerdo no cabe más discusión.
Por otro lado me llama la atención la defensa a ultranza del open source, está muy bien pero no siempre ha de ser así. La mayor parte de herramientas que utilizamos no lo son y no pasa nada. En cambio, la accesibilidad no es algo que podamos obviar, porque si lo hacemos estaremos discriminando a algún conjunto de personas y eso es simple y llanamente inaceptable. Además, la propia fundación WordPress utiliza herramientas privativas como son Slack. Tenían licencia de CrowdCast y cuando se informó de que no era una herramienta accesible inmediatamente se buscó alternativas. La solución no se encontró en el open source y no pasa nada, hemos podido disfrutar de múltiples WordCamp Online que permitían a personas con diversidad funcional ser ponentes porque la herramienta era accesible para sus ayudas técnicas y también integrar la estenotipia en directo para tener subtítulos en directo. Todo eso es más beneficioso con las personas con diversidad funcional que usar herramientas open source.
¿Significa esto que el open source no es bueno?, en absoluto, todo lo contrario, el open source brinda libertades que son interesantes pero que no están por encima del derecho a la no discriminación de las personas con algún tipo de discapacidad como reconoce la ONU. Los lectores de pantalla más populares son VoiceOver y JAWS, ninguno de código libre y con coste. NVDA es una alternativa estupenda, libre y gratuita y eso es bueno porque hay personas que no pueden costearse una licencia, se aumenta la competitividad y la evolución de las herramientas, etc.
Entonces, ¿es esto un guantazo a WordPress?. Creo que sí, un guantazo fuerte que lo que hace es evidenciar que tenemos algunos problemas importantes en el desarrollo de WordPress. El primero es la presión que se ha metido para lanzar Gutenberg cuando es obvio que no está en el punto de maduración adecuado. El segundo es que como se trata principalmente de trabajo voluntario cada persona colabora en lo que quiere. ¿Qué le puede gustar a un desarrollador? Desarrollar, añadir funcionalidades, conseguir conectar cosas, ¿y qué le gusta menos a un desarrollador? Pues parece que resolver los tickets sobre problemas de accesibilidad. Esto ha llevado a un problema y es que si entendemos WordPress como un taburete sobre el que sentarse resulta que la pata de Gutenberg ha crecido más que la de accesibilidad desestabilizando el taburete. El tercer problema es que a WordPress le hacía falta haber incorporado antes funcionalidades como el i18n o mejorar el sistema de revisiones y dejar de confiar en que terceros desarrollen plugins.
La comunidad WordPress y en especial aquellos que la lideren deben tomar esta noticia como una oportunidad de reflexión y mejora. Tal vez es hora de centrarse en lanzar una versión de WordPress centrada en solucionar todos los problemas y carencias en lugar de seguir avanzando tan rápidamente en el editor, que también es necesario.
Gutenberg ha mejorado mucho, especialmente en esta última versión, pero todavía queda mucho trabajo por hacer. Tras casi dos años muchos usuarios se quejan de problemas, ya no solo de accesibilidad, sino de la más simple usabilidad y esto es algo incomprensible para un proyecto tan grande e importante como es WordPress.
Deja una respuesta