Vicent Sanchis

Accesibilidad, Ciencias de la Visión y WordPress

La nueva web de la W3C, descartan WordPress y no solo por culpa de Gutenberg

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.


Comentarios

9 respuestas a «La nueva web de la W3C, descartan WordPress y no solo por culpa de Gutenberg»

  1. Muy buen artículo Vicent, me gusta sobre todo tu opinión al respecto. Yo también creo que el gran problema ha sido el estado en el que ha entrado Gutenberg al Core en lugar de mantenerlo como plugin durante estos dos años y aún algún tiempo más… y el problema del multidioma en el Core del sistema(recordemos que WordPress si soporta internacionalización i18n en el núcleo), es algo que para mi entender debería ser prioritario.

    Un abrazo y enhorabuena por el artículo.

    1. Avatar de Vicent Sanchis
      Vicent Sanchis

      Muchísimas gracias por leer el artículo y comentar Carlos.

      Gutenberg tiene sus cosas buenas y malas, va por buen camino pero aún le falta un poco para poder ser el editor predeterminado que necesita WP. Toda la gente de este mundillo, use WP o no, sabe que la apuesta por Gutenberg causó que la líder del equipo de accesibilidad dimitiera y hacen rápidamente la asociación “dimisión de la líder => Gutenberg no es accesible” sin tener en cuenta que hubo más factores que participaron en esa decisión.

      Es momento de ver todas las asignaturas pendientes que tiene WP y solucionarlas en vez de dejar pasar al siguiente curso.

      Un abrazo enorme!

  2. ¿Y por qué utilizar Gutenberg y no el editor clásico de WordPress? Otros constructores como Elementor, Divi, etc. los descartaría directamente por el futuro soporte.

    1. Avatar de Vicent Sanchis
      Vicent Sanchis

      Pues porque el editor clásico tiene prevista una fecha de caducidad: 31 de diciembre de 2021. Aunque es cierto que esta fecha se podría extender. Pero ten en cuenta que la apuesta tan fuerte que se está haciendo por el editor de bloques es porque se trata del presente en WP y del futuro, así que para este tipo de proyectos se debe analizar la viabilidad de usar Gutenberg.
      Además, Gutenberg a diferencia de Elementor o Divi no es solo un maquetador visual, es el editor de entradas y ese matiz es lo que lo hace tan diferente y limita tanto su evolución.
      Muchas gracias por dejar tu comentario!

  3. Avatar de Patri

    Enhorabuena por el superartículo. Gracias por explicárnoslo taaaaan bien. Un abrazo!

  4. Hola
    Supongo que el problema en wordpress es que es gratuito y con una gran proyección internacional y cuando algo tiene un alto % de uso, siempre genera conflictos en especial con los creadores de plugin para maquetar o constructores web.
    Aunque estoy de acuerdo que Gutenberg no está en su punto óptimo para ser usado, parece aún un poco verde.

    1. Avatar de admin

      Hola Pascual, gracias por comentar. El problema de WP es que es open source, que esa es su principal ventaja también. Pese a que la W3C prefiere basarse en software open source, que para este tipo de webs es lo mejor, también tienen otro tipo de requisitos que WP a día de hoy no puede satisfacer, como es un buen soporte multiidioma. Por otro lado, la crítica a Gutenberg que se usó para descartar a WP frente a una opción de software privativo no se correspondía con la realidad, el editor de bloques ha mejorado muchísimo y sigue mejorando.
      Tal vez lo que faltó fue un intento de comunicación directo con la comunidad WP. Entiendo que considerasen más sencillo descolgar el teléfono y llamar a una empresa para solicitar su compromiso en mejorar su software que ponerse en contacto con la comunidad WP y hacer exactamente lo mismo. Aunque tal vez habría funcionado, ¿quién sabe?

  5. Hola Vicent!

    Leo la fecha del post pero veo que es de hace 2 años…

    ¿Esto ha cambiado en algo a día de hoy?

    Es Wordpress ya válido y cumple con la accesibilidad de una web?

    1. Avatar de Vicent Sanchis
      Vicent Sanchis

      Hola Antonio. Gracias por escribir.

      Intuyo que estás mezclando conceptos. WordPress tienen que entenderse como dos cosas diferentes: un software que entrega páginas web al usuario y una herramienta para crear esas páginas web.

      Las páginas hechas con WP pueden ser accesibles y eso depende poco de la propia herramienta, depende más de los temas (usa los #accessibility-ready), los plugins que uses y el contenido que añadas. Si usas mal los encabezados ya no respetas las normas de accesibilidad, y eso es un fallo del usuario no de la herramienta.

      Si te preocupa como herramienta, WP aún no es perfecto. El editor de bloques ha sido muy criticado y con razón, requiere mucha más interacción (y más compleja) que el editor clásico a cambio de dar mayores posibilidades intentando ser más amigable para los usuarios menos expertos.

      Como software WP está en una evolución constante y por desgracia hay novedades que se van incorporando o modificando continuamente, cosa que puede ser confusa para cualquier tipo de usuario.

      No obstante el proyecto está comprometido con ceñirse a las normas WCAG y ATAG https://wordpress.org/about/accessibility/

      Saludos!

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *