Sería genial saber que todos los bloques que replican la funcionalidad del editor clásico son accesibles en Gutenberg.

Lo correcto aquí es obtener una auditoría de accesibilidad independiente. WordPress tiene una política establecida de cumplir con las pautas de accesibilidad en el núcleo, y también tiene la responsabilidad de que sus usuarios cumplan con esas pautas. Solo una auditoría de accesibilidad exhaustiva puede mostrar si este es el caso o no. El equipo de accesibilidad ha señalado numerosos problemas, algunos de los cuales se han solucionado y otros no. Por lo menos, estos deben abordarse.

WordPress es una interfaz entre el editor, una base de datos y el visitante. La forma exacta en que el editor elige ingresar o manipular la interfaz depende de ese usuario. El trabajo de WordPress es hacer que la interfaz sea accesible para cualquier modalidad de entrada elegida por ese usuario. Esto no es nuevo ni controvertido: es la base sobre la que se asienta la web.

Estoy de acuerdo con @ mor10. Teniendo en cuenta lo invertidos que han estado Automattic y el equipo central en el proyecto, y todavía están viendo problemas, el único camino verdadero y válido a seguir es tener una auditoría objetiva e independiente.

WordPress tiene una política declarada de cumplir con las pautas de accesibilidad en el núcleo

Sí exactamente. Quisiera la confianza de los clientes potenciales en el proyecto más grande de w.org, como @afercia y @rianrietveld , en el trabajo aquí.

En resumen, creo que Gutenberg _CAN_ es accesible, pero me preocupa que no se pueda enviar en su estado actual en función de los 117 elementos abiertos en el proyecto .

¡Esperando que esto suceda!

Apoyaría totalmente una auditoría de accesibilidad externa e independiente.

Como mencionaste, hay algunos problemas de percepción que creo que están relacionados con la falta de material e información con respecto a las pruebas de los usuarios, y específicamente, volver a probar a medida que avanzaba el desarrollo. En lugar de perseguir los resultados del usuario, parece que estamos persiguiendo errores y regresiones.

Agradezco su honestidad y estoy de acuerdo en que una auditoría externa / independiente sería valiosa. Pero, me temo que esto está abordando retroactivamente la accesibilidad desde un punto de vista técnico (es decir, marcando las casillas para WCAG 2.x / AA) en lugar de buscar brindar una experiencia _mejor_ para aquellos que podrían no estar usando un mouse y teclado. Solo para la accesibilidad, la investigación cualitativa y cuantitativa de la experiencia de Gutenberg sin datos relativos a la experiencia actual (o, mejor aún, otros productos similares) podría no contar una historia justa.

Creo que la transparencia en torno a esta información duraría mucho con el apoyo de la comunidad y aliviaría muchas fricciones, tanto desde el punto de vista de la accesibilidad como del despliegue más amplio de Gutenberg.

No me sorprende escuchar que otros están a favor de una auditoría externa, lo cual sería genial. 👍 Puedo decirles que también me encantaría, y buscaré formas en las que podamos facilitarlo durante la próxima semana.

¿Existen agencias / empresas especializadas en accesibilidad involucradas con WordPress que puedan priorizar su tiempo para ejecutar una auditoría de accesibilidad del proyecto (probablemente a partir de 4.0, que es un gran lanzamiento)? Creo que sería útil establecer una idea básica de cómo se compara Gutenberg con el editor clásico.

Estoy seguro de que habrá problemas (como se mencionó anteriormente, tenemos más de 100 problemas de accesibilidad) pero estoy tratando de obtener una visión macro de la accesibilidad en Gutenberg. Cabe señalar que también tenemos más de 100 problemas etiquetados como "errores", pero esto se debe a que consideramos que ningún error es demasiado pequeño. Intentamos registrar todo, pero recuerde que esto significa 100 problemas de accesibilidad, no 100 bloques de accesibilidad. Los bloqueadores de accesibilidad (a partir de ahora) están incluidos en el hito de fusión del que forma parte este problema.

Gracias a quienes han sumado sus voces al apoyo de una auditoría. Proporcionaré una lista de los flujos que queremos probar y garantizar que funcione para los usuarios como MVP; cuando lo haga, los publicaré aquí, pero aún no los he formulado completamente.

Una auditoría externa es una gran idea. Me complacería contribuir económicamente a la contratación de una empresa calificada para realizar esta auditoría.

También contribuiría económicamente, especialmente por algo de esta magnitud e importancia.

También estaría dispuesto a liderar el camino para ayudar a recaudar dinero de la comunidad.

Me gusta esta idea. Para las empresas que requieren el cumplimiento de WCAG en su software, una auditoría puede ser de gran ayuda para calmar las preocupaciones. Generar un VPAT a partir de una auditoría también puede ayudar a las organizaciones que lo requieran como parte de su proceso de contratación. Consulte Incorporación de la accesibilidad en los contratos de proveedores de tecnología para obtener información relacionada.

También apoyo una auditoría de accesibilidad externa e independiente. Revisaré los excelentes recursos a11y de mi trabajo diario y veré qué recomiendan. :)

¡Eso es muy amable! Pero no buscamos contribuciones financieras de la comunidad. Me pondré en contacto con algunos auditores de accesibilidad y veré cómo conseguir que realicen algunas auditorías en Gutenberg.

Veré qué tipo de costos y cronogramas están involucrados, pero si podemos obtener algo a un precio razonable con un cronograma que funcione para 5.0, debería poder hacer que Automattic cubra el costo. 😊

No estaba seguro del apoyo financiero que pudiera brindar Automattic cuando publiqué un comentario anterior y no tenía claras las expectativas de la comunidad: ¡lo siento! Actualicé el comentario y aclaré lo que no estaba buscando. En este momento voy a ver cómo organizar auditorías, ¡probablemente me llevará unos días al menos discutir las cotizaciones! Informaré una vez que sepa más 😊

Sé que puede que este no sea el lugar para declarar esto, pero mi empresa realiza auditorías de accesibilidad. Déjame saber si quieres saber más. Aunque no tan activo recientemente, he estado involucrado con WordPress por un tiempo y he contribuido con ideas de accesibilidad a Gutenberg, así como a otras partes de WP. Si no soy lo suficientemente independiente, trabajo con un socio de confianza que nunca ha usado WordPress.

@tofumatt Creo que una solicitud de propuestas sería una buena manera de indicar exactamente lo que está buscando una auditoría y darles a los proveedores de servicios la oportunidad de proporcionar un esquema general de cómo procederían. ¿Existe un precedente para este tipo de procesos en Automattic?

Hola, soy el coordinador de accesibilidad de TI de NC State University. Usamos WordPress para los sitios web de nuestro campus y, como institución estatal, estamos obligados a seguir la Sección 508 de la Ley de Rehabilitación de 1973. Debido a esto, nuestras herramientas de creación como WordPress tienen que ser accesibles para personas con discapacidades.

Tenemos una gran variedad de usuarios de WordPress, incluidos estudiantes, profesores y personal que usan blogs de WordPress y editan sitios de WordPress en nombre de los departamentos de sus organizaciones. Todo eso para decir, WordPress debe ser accesible para estas personas.

Como institución de educación superior, queremos estar al día con los nuevos programas y tecnologías. Sería perjudicial para nosotros no poder progresar y usar Gutenberg o hacer una situación "separados por iguales" en la que las personas con discapacidades se limitan a usar el editor clásico, mientras que las personas sanas pueden hacerlo con Gutenberg.

Eso es tan increíble de escuchar 👍

¡Estoy totalmente de acuerdo! Por supuesto, quiero establecer la expectativa clara de que puede haber problemas de accesibilidad que descubramos (o posiblemente sepamos) que no podemos solucionar antes del lanzamiento de WordPress 5.0.

Hay muchos sitios, por muchas razones, que querrán / necesitarán usar el complemento Classic Editor por un tiempo limitado mientras se mejoran Gutenberg, o complementos externos. Probablemente habrá usuarios que encuentren problemas de accesibilidad, junto con una serie de otros problemas, que necesiten el complemento Classic durante algunas semanas o meses mientras mejoramos nuestro software.

Quiero que el futuro del editor de WordPress sea asombroso y accesible para todos. Mis disculpas de antemano para los usuarios que se quedan atrás al principio, por cualquier motivo. Pero sepa que trabajaremos para hacer que Gutenberg y WordPress sean increíbles para ellos también, incluso si no sucede de inmediato . ❤️

Respecto a la auditoría

¡Oigan todos! Todavía soy un poco nuevo en ser un líder de lanzamiento y vengo de casi una década trabajando en el proyecto @mozilla , donde también trabajamos mucho al aire libre, con errores y todo. Seré lo más transparente posible sobre lo que está sucediendo, incluido el intento de proporcionar actualizaciones oportunas (por lo tanto, no estoy seguro de poder pagar las auditorías de accesibilidad hasta que verifique con algunas personas).

El tipo de auditoría que estoy buscando hacer puede no ser demasiado legal / específico de cumplimiento, ya que primero busco tener una idea macro de la usabilidad de WordPress por parte de usuarios con necesidades de accesibilidad. Sin embargo, si eso incluye cosas de cumplimiento: increíble.

En este momento, he estado en contacto con algunos miembros de la comunidad de accesibilidad de @WordPress y empleados de @automattic conocedores que me han proporcionado algunas personas para contactar sobre una auditoría de accesibilidad. En este momento quiero que sea imparcial (algo fuera de la comunidad de WordPress es genial para evitar prejuicios / conocimiento pasado / etc.), de alto nivel, procesable y algo rápido. Sé que estoy pidiendo mucho 😆

Tengo algunas personas en mente ahora yse acercará a ellos Me he puesto en contacto con varias empresas especializadas en auditorías de accesibilidad. Publicaré actualizaciones aquí, pero no sabré más hasta la semana que viene. Por ahora, hay:

1. no es necesario ofrecer apoyo financiero (pero Dios mío, muchas gracias a los que lo han hecho, es genial ver su compromiso con WordPress)
2. no es necesario que ofrezca sus servicios (creo que queremos a alguien fuera del ecosistema de WordPress, pero si desea ayudar con las pruebas de accesibilidad / errores regulares , ¡hágalo! )
3. mucho ❤️ de mi parte 🙂

Que tengan un gran fin de semana, ¡los mantendré informados! 😄

Si busca más proveedores para la auditoría, le recomiendo WebAIM de la Universidad Estatal de Utah, que generalmente se considera uno de los principales recursos web de todos los Estados Unidos. No estoy afiliado con ellos de ninguna otra manera que no sea la lectura de su increíble documentación web, pero he visto que ofrecen auditorías.

Aunque WordPress en sí es de código abierto y todavía tiene mucho trabajo voluntario, también ha alcanzado el "gran momento", como antes, y ya no puede permitirse el lujo de recurrir a la muleta de "Pero solo somos de código abierto". Creo que una auditoría de accesibilidad completa y el compromiso de mejorar donde se encuentra que falta WP (no solo Gutenberg) sería una gran fuente de avance en lo que respecta a la adopción de WP. Además, por supuesto, democratizar la publicación y todo eso.

Hay muchos sitios, por muchas razones, que querrán / necesitarán usar el complemento Classic Editor por un tiempo limitado mientras se mejoran Gutenberg, o complementos externos. Probablemente habrá usuarios que encuentren problemas de accesibilidad, junto con una serie de otros problemas, que necesiten el complemento Classic durante algunas semanas o meses mientras mejoramos nuestro software.

Este sentimiento es simplemente inaceptable para mí y espero que muchos otros que han interiorizado los valores de WordPress ...

Mis disculpas de antemano para los usuarios que se quedan atrás al principio, por cualquier motivo. Pero sepa que trabajaremos para hacer que Gutenberg y WordPress también sean increíbles para ellos, incluso si no sucede de inmediato. ❤️

¿Cuál es la ventaja de impulsar una experiencia que no cumple con los estándares de todo lo demás en Core? Los plazos no son arbitrarios, pero eso no significa que se reduzcan las esquinas. Al menos no de acuerdo con los valores de WordPress como yo los entiendo. Estos valores probablemente sean distintos de todo lo que tenía Mozilla, como recién llegado a la comunidad, le animo a que los analice.

En general, el sentimiento de que trabajar mayoritariamente será suficiente crea un riesgo innecesario para la comunidad, y uno debe preguntarse quién se beneficia de eso. ¿Cuál es la ventaja del proyecto Gutenberg o WordPress? No es que necesitemos ayuda para identificar problemas.

Dado que Automattic aparentemente patrocinará y concebirá los parámetros para esta auditoría, existe la posibilidad de que aparezcan sesgos y que estén calificando su propio trabajo. Propongo que la comunidad en general proceda con el crowdfunding para contratar a un especialista en accesibilidad para un informe paralelo desde la perspectiva de los usuarios reales. Tal vez Automattic pueda hacer una auditoría técnica o lo que sea, pero la sugerencia de que la accesibilidad de Gutenberg "no es tan mala" ha sido vehementemente en desacuerdo por verdaderos expertos en este campo (a saber, Sina Braham de WordCamp Publishers). Tal vez necesitemos algo más parecido a una prueba de Mikey en la que los usuarios ciegos naveguen por la aplicación y digan si la volverían a usar.

Esto es lo que he estado enviando a las empresas a las que me he estado acercando para este trabajo, por cierto. Puede ayudar a otras personas involucradas en accesibilidad, no estoy seguro. Por lo menos lo estoy publicando aquí por transparencia 🙂

Requisitos

Una serie de pruebas de accesibilidad que se deben realizar con el editor Gutenberg en un sitio web de WordPress usando WP-Admin. Estas pruebas deben incluir, como mínimo, los siguientes flujos de prueba:

Flujo de publicación principal

• Crear una nueva publicación
• Agregue contenido común (párrafo, imagen, lista, HTML y contenido de tabla; consulte "Uso de bloques" a continuación)
• Publica una publicación de inmediato y la publicación se realiza según lo previsto
• Programe una publicación para el futuro con el selector de fechas
• Asignar categorías y etiquetas para publicar
• Asignar una imagen destacada a una publicación
• Experimente con otras configuraciones a nivel de documento, si el tiempo lo permite

Usando bloques

Estos son los veinte bloques más utilizados en WordPress.com y deben probarse para encontrar cualquier problema de accesibilidad que no esté incluido en nuestra lista de problemas de accesibilidad :

1. párrafo
2. imagen
3. Bóveda
4. lista
5. galería
6. citar
7. incrustar / youtube
8. html
9. separador
10. más
11. Imagen de portada
12. Código corto
13. botón
14. mesa
15. espaciador
16. empotrar
17. bloquear
18. insertar / twitter
19. columnas
20. código

Estos bloques deben probarse con tecnologías de asistencia para garantizar que no haya bloqueadores para su uso y que su configuración de nivel de bloque sea accesible.

Editor clásico

Debemos comprobar que, en comparación con el Editor clásico, no existen regresiones notables en cuanto a accesibilidad. La creación de una publicación con el mismo tipo de contenido que uno puede crear en un contexto de Classic Editor básico debería ser factible con Gutenberg. Gutenberg, que tiene cero regresiones en la experiencia de edición en comparación con el Editor clásico, es mi objetivo final al decir que podemos recomendarlo como la experiencia de edición predeterminada para los usuarios de tecnologías de asistencia.

Tecnologías de asistencia a considerar

Debido a la línea de tiempo limitada disponible y la priorización de la capacidad de acción sobre la minuciosidad extrema, preferiría que se utilicen las mejores combinaciones de navegador + lector de pantalla de dos a tres para las pruebas . Usar más si el tiempo lo permite es absolutamente accesible, pero preferiría comenzar con las combinaciones más utilizadas. A mi entender, esto es:

• JAWS con Internet Explorer / Edge (Windows)
• NVDA con Firefox (Windows)
• VoiceOver con Safari (MacOS)
• ZoomText

La tecnología de asistencia móvil no es una prioridad para esta auditoría. Es de esperar que las pruebas de VoiceOver en MacOS incluyan algún cruce con los usuarios de VoiceOver de iOS. El uso de aplicaciones móviles es presumiblemente más importante que el uso de sitios web.

Publicar informe y problemas al aire libre

Nuestra expectativa es que cualquier informe de accesibilidad generado se publique abiertamente a la comunidad de WordPress y no me requiera (ni a ningún otro Automattician) como guardián. Los problemas deben publicarse con un contexto útil en GitHub, con un enfoque en la causa del problema y la reproducibilidad. Las soluciones o enfoques para arreglos se pueden publicar si hay tiempo en el alcance o si el problema es especialmente complejo.

@davisshaver Hola, y estoy totalmente de acuerdo contigo. Una auditoría exhaustiva e imparcial es fundamental para garantizar que se cumpla con el nivel máximo de todos.

No solo es importante asegurarse de que el editor sea accesible, sino que también exista una base para garantizar que las modificaciones al editor también puedan ser fácilmente accesibles. Obviamente, no podemos hacer cumplir lo que las personas hacen por sí mismos, pero al menos podemos proporcionar una base para que las personas implementen que sea accesible.

@tofumatt También feliz de ayudar en todo lo posible. Puede que tenga acceso a algunos recursos bastante buenos para realizar pruebas, específicamente a otros con React y cualquier experiencia. También hay algunas personas en mi equipo que trabajan específicamente con todos en su día a día.

@tofumatt Gracias por la actualización. Tengo algunas preguntas de seguimiento:

1) ¿Se completará el plan de auditoría antes de que se publique 5.0?
2) Si la auditoría arroja problemas, ¿cuál es el plan para abordarlos? ¿Se retrasará la versión 5.0 hasta que se aborden?
3) ¿Se están haciendo planes sobre cómo el proyecto probará la accesibilidad en el futuro?

@tofumatt Si desea que los usuarios con una variedad de discapacidades o deficiencias

@tofumatt También estoy muy preocupado por la accesibilidad de WordPress y estoy ansioso por ayudarlo a tener éxito. Puedo hacer que nuestra organización realice una auditoría de accesibilidad completa que cumpla con las WCAG-EM al nivel estándar que prefiera, incluidas las pruebas técnicas y funcionales, y donar cualquier parte del trabajo que necesite para ajustarse a su presupuesto.

Creo que deberíamos considerar tanto ATAG como WCAG AA, y quizás WCAG 2.1 en lugar de 2.0. También podríamos brindar recomendaciones y asesoramiento para ayudarlo a elegir la mejor y más sostenible forma de cerrar las brechas descubiertas.

Estamos convenientemente lejos de su comunidad de desarrollo, pero conocemos bien WordPress desde hace muchos años. Tengo todas las certificaciones de IAAP y he dirigido docenas de auditorías de este tipo en la plataforma WordPress, durante muchos años, tanto para el sector público como para el privado. Consulte nuestra buena fe en davidberman.com/about para decidir cuál es la mejor forma de ayudarlo.

Usando bloques

No estoy seguro de que el equipo que va a realizar la auditoría deba recibir instrucciones o tener conocimiento de lo que es un "bloqueo", al menos no inicialmente. Deben estar en la misma condición inicial de los usuarios que van a utilizar Gutenberg por primera vez, sin instrucciones especiales. En una segunda fase, cuando se vuelvan técnicos, probablemente ya sepan qué es un bloque 🙂

Flujo de publicación principal

El equipo de accesibilidad está de acuerdo en que el principal problema de accesibilidad en Gutenberg es la experiencia general del usuario. Sugeriría expandir esta parte: no debe limitarse al flujo de _publihsing_, sino que debe incluir más tareas, generalmente las que requieren navegar a través de la interfaz de usuario y saltar a través de las secciones principales (barra superior, área de edición, barra lateral , publicar panel). Esto está más relacionado con el diseño general de Gutenberg, que con los detalles de implementación técnica de los distintos componentes. De hecho, la accesibilidad es diseño.

Me gustaría proponer algunas tareas:

• construir una publicación con una gran cantidad de bloques, digamos 20 como mínimo
• editar uno de los párrafos en el medio de la publicación
• cambie su tamaño y color de fuente, luego edite nuevamente su contenido
• agregar nuevos bloques usando los insertadores
• insertar un enlace
• insertar una mención
• cambiar el tipo de bloque
• cambiar algo en la configuración de la barra superior y luego volver al bloque que se editó
• saltar a la barra lateral, cambiar a la configuración de Documento / Bloque y luego volver al bloque que se editó
• editar la publicación enlace permanente
• hacer un bloque reutilizable
• agregar y editar un bloque reutilizable existente

Tecnologías de asistencia a considerar

@tofumatt Me sorprende un poco que mencione solo tecnologías de asistencia y, específicamente, solo lectores de pantalla. Las evaluaciones de accesibilidad no pueden limitarse solo a las pruebas del lector de pantalla. La accesibilidad es un tema mucho más amplio y no se limita a discapacidades o impedimentos. Se trata de hacer que la web sea accesible para todos.

Incluso si queremos limitar la accesibilidad a las discapacidades y deficiencias, son demasiadas para contarlas. Solo por nombrar algunos: usuarios de software de reconocimiento de voz, discapacidades motoras, baja visión, deterioro cognitivo, trastornos convulsivos, dispositivos de entrada alternativos, trastorno por déficit de atención con hiperactividad, dislexia, pérdida de memoria a corto plazo, etc., etc. ¿Debe clasificarse como "discapacidades" reales, por ejemplo, deficiencias temporales, deficiencias ambientales, envejecimiento?

La condición humana es bastante inestable, y le sugiero que considere _Todos estamos capacitados temporalmente_.

Me gustaría proponer algunas tareas:

Esta lista de tareas ampliada parece buena y realista de lo que los usuarios deben hacer.

Como afirman los estándares de accesibilidad para el núcleo de WordPress :

Todo el código nuevo o actualizado publicado en WordPress debe cumplir con las pautas WCAG 2.0 en el nivel AA.

Por tanto, la auditoría debería tenerlo en cuenta. Cosas específicas:

1) Todas las funciones deberían funcionar como se esperaba cuando el navegador se amplía al 200% (tenga en cuenta que esto puede activar css móvil) 1.4.4
2) Todas las funciones deberían funcionar como se esperaba solo usando un teclado 2.1

Es importante que recordemos que lo que buscamos aquí es que todo sea utilizable por todos los usuarios. Puede que no sea una gran experiencia para algunos usuarios, de eso se trata la versión 1, pero los estándares que tenemos son para asegurarnos de que sea completamente utilizable. Todo el software se envía con errores y lo importante es que sabemos acerca de los errores y hacemos las compensaciones de corregirlos frente a no corregirlos.

Gracias @tofumatt por liderar la

Fue útil, al examinar una auditoría / serie de pruebas de accesibilidad, compilar una lista de funciones "básicas" del editor clásico que no deberían retroceder en el nuevo editor:

1. Creación / edición de texto de párrafo
2. Creación / edición de texto de encabezado
3. Creación / edición de texto preformateado
4. Creación / edición de lista con viñetas
5. Creación / edición de lista numerada
6. Creación / edición de una cotización ("Blockquote")
7. Alineación de texto para párrafos y encabezados
8. Agregar, editar y eliminar enlaces del texto en párrafos, encabezados y elementos de lista
9. Sangría / sangría de listas / elementos de lista
10. Negrita / cursiva / tachado de texto en párrafos, encabezados y elementos de lista
11. Agregar una línea / espaciador horizontal al contenido
12. Deshacer rehacer
13. Inserción del comentario "Leer más" de WordPress (Bloque Leer más en Gutenberg)
14. Conversión de contenido de párrafo a contenido de lista
15. Conversión de contenido de lista a contenido de párrafo

Creo que eso es todo, así que es lo que he estado enviando.

Mi lista de tecnologías accesibles era bastante mínima, estuvo de acuerdo. Parte de eso tiene que ver con el alcance, pero parte de eso se debe a que era una lista un poco incompleta que esperaba agregar con el tiempo. Agregué ZoomText a esa lista y también solicitaré que se use para pruebas.

Acabo de revisar la lista de tareas de @afercia y estoy de acuerdo: es una gran lista. Trabajaré en incluir tanto como sea posible de esa lista en el proyecto. No voy a actualizar mi lista original por ahora, pero publicaré la lista finalizada de tareas una vez que comiencen las auditorías / pruebas. ¡Gracias! 👍

Respondiendo a algunas preguntas

@bamadesigner :

El plan, en este momento, es comenzar la auditoría lo antes posible y tener tanta información antes de la versión 5.0 para abordar cualquier problema que se encuentre y agregar contexto a la versión con respecto a su accesibilidad. En términos de retrasar el lanzamiento: depende del problema, el tiempo para solucionarlo y su impacto. Mi opinión es que es poco probable que se retrase la publicación, pero debemos cruzar ese puente cuando lleguemos a él; No quiero especular.

En términos de planes para las pruebas de accesibilidad en el futuro: esa es una pregunta más importante y no está relacionada con el lanzamiento o este problema, por lo que no entraré en ella aquí. Por ahora soy un líder de lanzamiento para 5.0 y me voy a concentrar allí; de nuevo: no quiero especular. Pero es algo que estoy feliz de analizar después de recuperar el aliento con WordPress 5.0 😄

@LukePettway

Si tiene experiencia haciendo pruebas de accesibilidad, sería genial que probara Gutenberg o clasificara los problemas de accesibilidad existentes para que sepamos qué sigue siendo un problema y qué debe enfocarse. Trabajar en cualquier problema de Merge: Accessibility también sería genial.

@tofumatt Gracias por sus respuestas, pero son decepcionantes.

Gutenberg / 5.0 no debe publicarse hasta que se complete la auditoría y se solucionen los problemas encontrados. Es de esperar que la auditoría regrese y diga que solo hay algunos problemas, pero la decisión debería ser que el lanzamiento de 5.0 dependa de ese hallazgo y del tiempo necesario para resolverlo.

No estoy al tanto de lo que está impulsando esta fecha límite de noviembre, pero la accesibilidad es demasiado importante. Si inicia antes de asegurarse de que estas bases estén cubiertas, está sentando un precedente peligroso para toda la comunidad y la web en general, que la accesibilidad no es la prioridad número 1 y puede esperar más tarde.

WordPress 5.0 no está listo hasta que sea accesible. Ninguna otra fecha límite importa más. Sin mencionar el hecho de que viola los estándares básicos de accesibilidad.

WordPress 5.0 no está listo hasta que sea accesible.

@bamadesigner dice la verdad.

El objetivo declarado de WordPress es "democratizar la publicación". Eso, en un sentido literal, significa hacer que la publicación esté disponible para todos. La accesibilidad es fundamental para esta promesa.

Espero que no sea un equívoco decir que un objetivo y una promesa no son lo mismo y no deben tratarse como tales. 😄

Como se mencionó anteriormente, doy la bienvenida a cualquier contribución externa sobre cuestiones de accesibilidad y especialmente aquellas que se encuentran en el hito Merge: Accessibility (
https://github.com/WordPress/gutenberg/milestone/43).

Si se determina que hay problemas de accesibilidad en el lanzamiento, me siento cómodo revisando la sugerencia de @rianrietveld en Trac para advertir a y sugiriendo que usen el Editor clásico si Gutenberg los presenta. problemas de usabilidad. Me gustaría resaltar problemas específicos conocidos y a quiénes afectarían.

No estoy realmente seguro de que sea mi decisión en cualquier caso, pero incluso si lo fuera:

El editor clásico existe, pero no es parte de WordPress , y ese es un elemento crucial para reconocer. Requerir un complemento para adaptar el sistema de gestión de contenido para que sea utilizable es una solución muy cuestionable. Ciertamente es lo que le he estado sugiriendo a la gente; pero hay muchas situaciones que no están bien cubiertas por esa situación. Lo más importante es que significa que solo las personas que tienen la capacidad de instalar complementos tienen algo que decir sobre si el sitio seguirá siendo tan accesible como lo es ahora. Para el escenario en el que alguien simplemente actualiza el sitio, luego los autores que necesitan usar el inicio de sesión del sitio y ya no pueden publicar contenido, esto es inadecuado. El editor clásico no debería ser una opción de todo o nada que dependa de la generosidad del administrador del sitio para garantizar que las personas con discapacidades puedan seguir publicando. Esta es la razón por la que el hecho de que el editor clásico no sea una opción disponible dentro del núcleo de WordPress es un problema de accesibilidad.

Muy buen punto

Prefiero lanzarlo para los usuarios que lo encuentren utilizable (que debería incluir a muchos, pero no todos, los usuarios de tecnologías de asistencia), y acepto que no todos pueden usar Gutenberg el primer día.

Este es un comentario increíblemente aleccionador, y esta posición tiene un diseño deficiente en el mejor de los casos y una capacidad activa en el peor. Realmente espero que esta no sea la solución.

@tofumatt Aprecio que estés tratando de hacer lo correcto y equilibrar muchas preocupaciones, pero encuentro esto increíblemente preocupante:

No estoy realmente seguro de que sea mi decisión en cualquier caso, pero incluso si lo fuera: no veo como una buena decisión retrasar la versión 5.0 por problemas de accesibilidad cuando el Editor clásico existe como respaldo. El objetivo / característica principal de 5.0 es Gutenberg, la nueva experiencia de edición. Prefiero lanzarlo para los usuarios que lo encuentren utilizable (que debería incluir a muchos, pero no todos, los usuarios de tecnologías de asistencia), y acepto que no todos pueden usar Gutenberg el primer día.

Le está diciendo a una población ya marginada de usuarios que podrá hacer que WordPress sea utilizable para ellos ... eventualmente. Ves cómo eso es alienante, ¿verdad?

Pero quizás el conjunto de preguntas más importante es este:

• ¿De quién es la llamada para decidir si el nuevo editor está oficialmente listo para fusionarse con el núcleo?
• ¿Qué factores están considerando para tomar esa decisión?
• ¿Qué debemos hacer nosotros, como comunidad, para que la accesibilidad sea un elemento central de ese proceso de toma de decisiones?

@tofumatt para aclarar: el equipo de accesibilidad no ha pedido retrasar el lanzamiento. La única solicitud oficial ha sido agregar un aviso para los usuarios con necesidades de accesibilidad, informarles que aún hay problemas por resolver, invitarlos a probar Gutenberg pero recomendar el Editor clásico. La propuesta estaba en https://core.trac.wordpress.org/ticket/44671 que ha sido cerrada 🙁

Prefiero lanzarlo para los usuarios que lo encuentren utilizable (que debería incluir a muchos, pero no todos, los usuarios de tecnologías de asistencia), y acepto que no todos pueden usar Gutenberg el primer día.

Genial, impresionante, gran habilidad aquí. Como dijo @briandeconinck , estás alienando a todo un grupo de usuarios solo porque no pueden usar un teclado y un mouse (o pantalla) correctamente. Nuestra universidad ha puesto mucho trabajo y esfuerzo para hacer que nuestra experiencia con WordPress sea accesible y todavía estamos trabajando en ello hasta el día de hoy. Tener una pieza tan grande e importante del núcleo de WordPress potencialmente lanzar y ser de otra manera es extremadamente decepcionante.

@afercia ¡Oh, lo sé totalmente! Ciertamente, no quise dar a entender que la posición del Equipo de Accesibilidad era retrasar el lanzamiento; Algunas personas en los comentarios aquí preguntaban sobre eso, eso es todo. Lo siento mucho si me equivoqué y lo puse en el equipo. ❤️

Ese problema se ha resuelto (en parte porque se trata de la llamada "intentar" que está desapareciendo, tal vez hubo alguna falta de comunicación sobre su intención), pero como se menciona aquí: estoy de acuerdo con implementar su concepto de advertir a los usuarios de asistencia tecnologías si Gutenberg no les va a funcionar.

Estoy de acuerdo con otros en este hilo que presionan para mejorar la accesibilidad antes de 5.0. También agregaría que el resto del ecosistema de WP interpretará el lanzamiento de 5.0 como una luz verde de que Gutenberg está listo para su uso en el mundo real. En ese punto, veremos una afluencia de complementos y temas que amplían Gutenberg y se basan en los estándares que presenta como modelo para su propio desarrollo.

Como desarrollador en el ecosistema WP durante varios años, busco constantemente el núcleo de WordPress para asegurarme de que la accesibilidad, los estilos y el comportamiento de mis propios complementos se alineen con los del núcleo. Si se lanza 5.0 antes de que se aborden los problemas de accesibilidad, entonces la comunidad de WordPress buscará un modelo inaccesible como modelo para su propio desarrollo. Asegurémonos de que el plan cumpla con los estándares que hemos establecido para todo lo demás que se ha presentado antes.

@tofumatt ¿Está sugiriendo que colocar una advertencia que diga que las tecnologías de asistencia no funcionarán con Gutenberg es una solución razonable, dado que el Core Editor se convertirá en un complemento que debe instalarse junto con el hecho de que el usuario puede o no tener la capacidad / conocimiento para instalar ese complemento? Espero haber entendido mal esto, ¿puede aclararme por favor?

Como siempre, gracias por tu tiempo.

El complemento Classic Editor se creó como una rampa de salida temporal para aquellos que no están listos para cambiar a Gutenberg. En el mejor de los casos, es tenue y rápidamente se convertirá en un problema para los desarrolladores que tendrán que proporcionar soluciones para dos editores diferentes. El complemento Classic Editor no puede ser ni siquiera una vía de salida temporal para personas con necesidades de accesibilidad porque, literalmente, ofrece una experiencia inferior basada en la discapacidad. El requisito mínimo para el administrador de WordPress es WCAG 2.0 AA. Cualquier otra cosa, incluido un complemento para degradar la experiencia, va en contra de nuestras propias políticas. Estoy tomando una línea dura en esto porque tenemos reglas. No enviamos código que no cumpla con nuestros propios estándares de codificación. La accesibilidad no debería ser diferente.

Como muchos otros aquí, aprecio los esfuerzos de la comunidad y las personas que dedican su tiempo y esfuerzo a Gutenberg para que sea accesible y esté listo para 5.0. Simplemente, Gutenberg no está listo porque no es completamente accesible. Fin de la historia.

Hasta que Gutenberg sea accesible, no debe fusionarse en el núcleo. La noción de liberar a Gutenberg en el núcleo para "aquellos que _ pueden_ usarlo" no solo es miope sino terriblemente excluyente; yo iría tan lejos como para decir que esto crea (y normaliza) una experiencia _ separada pero igual_ para los usuarios de WordPress. Es un precedente terrible y tremendamente arrogante.

Tengo la esperanza de que la comunidad prevalezca y convenza al equipo central de no publicar 5.0 hasta que sea completamente accesible. Con ese fin, una auditoría independiente es una buena idea y debe llevarse a cabo.

Este problema se presentó para publicitar mi trabajo en la auditoría de accesibilidad, para comunicar que me gustaría que sucediera y para rastrear el intercambio de esa auditoría en una publicación de blog. No pretende ser un punto de discusión sobre lo que debería considerarse un bloqueador de versiones para WordPress 5.0. He tomado nota de las opiniones de la gente sobre el tema y se las transmitiré a @m , que es el líder de lanzamiento de WordPress 5.0. Mi entendimiento es:

1. No tengo veto sobre el envío 5.0, pero incluso si lo tuviera:
2. Todavía no estoy convencido de que existan suficientes problemas de accesibilidad que impidan un lanzamiento

Si el segundo punto cambia, transmitiré esa información. Planeo ser un defensor, pero no establezco los plazos y tampoco tengo datos sólidos sobre accesibilidad. Ese es el objetivo de la auditoría: para que podamos hablar desde un lugar de datos duros. 🙂

Gracias por todos los aportes, pero como esta discusión se ha vuelto bastante fuera del tema de su alcance previsto, estoy bloqueando la conversación de este tema por ahora. Lo dejaré abierto y publicaré actualizaciones sobre la auditoría.

Hubo un poco de discusión adicional sobre este problema en Slack: https://wordpress.slack.com/archives/C02RP4X03/p1539300688000100

Creo que valió la pena abordarlo aquí para que todos los que han estado siguiendo el tema hasta ahora puedan actualizarse sobre lo que está sucediendo. @ mor10 también señaló que sentía que no había una comunicación clara de los resultados de la auditoría. Parece que ha habido muchos malentendidos en torno a mi comunicación en esta publicación: mis disculpas por eso. Intentaré responder las cosas lo mejor que pueda ahora mismo.

Creo que gran parte de la confusión en el ticket cerrado se debe a la falta de claridad sobre lo que sucede si / cuando una auditoría no se puede completar a tiempo para el cronograma de lanzamiento o una auditoría regresa marcando problemas sustanciales que necesitan ser corregidos. Según sus comentarios, no está claro si piensa:

• a) todos los problemas se solucionarán dentro de la línea de tiempo actual
• b) cualquier problema que no se pueda solucionar dentro de la fecha límite pasará a 5.0.1
• c) si se plantean problemas sustanciales, se cambiará el cronograma.

Lo que ha dicho hasta ahora parece indicar que solo a o b son opciones, pero como dije, no está claro. La idea de que la accesibilidad sea castigada para cumplir con el plazo de publicación es lo que preocupa a la gente durante más de un año, y esas preocupaciones no se han aliviado.

• @ mor10 en Slack (https://wordpress.slack.com/archives/C02RP4X03/p1539303342000100)

Según los problemas actuales en Milestone, mi objetivo es solucionar todos los problemas, pero no creo que todos constituyan bloqueadores de versiones. Sabré mejor cómo clasificarlos más cerca del etiquetado final, por lo que no puedo agregar mucho a eso ahora. Por ahora, creo que son una lista realista de problemas que son los más importantes antes de 5.0

Los problemas que no se pueden solucionar deben trasladarse a la próxima versión de WordPress / Gutenberg, sí.

No creo que haya nada allí actualmente que justifique retrasar el lanzamiento.

Este problema se bloqueó porque mi objetivo al crear este problema era:

1. compartir mi trabajo encargando una auditoria
2. para compartir mi trabajo creando una publicación de blog sobre Marca / Accesibilidad en torno a esa publicación

Agradezco los comentarios sobre cómo se podría realizar la auditoría y también escuchar acerca de los problemas relacionados con mi recomendación de "respaldo" del Editor clásico si la accesibilidad termina siendo un problema grave en Gutenberg. Vale la pena señalar que en este momento no hay ningún informe que señalar que evalúe a Gutenberg y lo desaconseje por motivos de accesibilidad. No lo he visto y nadie está vinculado a uno aquí. El sentimiento aquí gira en torno a los fracasos especulativos. Ese tipo de lenguaje desmotiva a los desarrolladores de Gutenberg que trabajan duro y ven una falta de buenas intenciones asumidas.

La función de Responsable de lanzamiento de accesibilidad es nueva y quería que me la entregaran la semana pasada . Al mismo tiempo , se finalizó una

No soy la última palabra en un comunicado. He enviado un mensaje de texto a

Sí, existe un problema mayor de diseño accesible en general, pero los equipos de desarrollo y diseño consideran estos problemas. Estoy más preocupado por las cosas que reconocemos y probamos menos porque somos en gran parte un equipo de usuarios bastante capacitados.

Algunas personas en Slack me han expresado su observación de que el tema parecía estar solicitando comentarios y una discusión más amplia. Esa no era mi intención al presentar este problema, sino simplemente mantener todo al descubierto; dado que GitHub es principalmente donde trabajamos en este proyecto, pensé que sería el mejor lugar para hacerlo. Cerré el problema porque la discusión, aunque posiblemente válida para el proyecto en su conjunto, distraía a:

1. el problema en cuestión (y una auditoría y una publicación de blog con resultados)
2. el equipo en su conjunto al que se le notifica mediante comentarios de emisión

Los comentarios sobre problemas deben ser procesables, discretos y, con suerte, proporcionar nueva información. Sentí que los comentarios aquí no cumplieron con esos criterios, por lo que quería restringir la discusión al tema en cuestión.

Presenté este problema en el hito porque me gustaría que sucediera para WordPress 5.0. Si eso no es posible, el triste resultado es que habrá que moverlo. Estoy haciendo todo lo posible para trabajar en un plazo limitado con recursos limitados. No es para "dar la bienvenida a todos los parches", pero si la accesibilidad es importante para usted, le agradecería mucho que dirigiera su atención hacia nuestra lista de problemas de accesibilidad abierta , especialmente aquellos en la lista Milestone: Accesibilidad .

Me gustaría mantener este problema abierto porque quiero hacer un seguimiento de mi progreso con la auditoría. Si hay otras discusiones que le gustaría tener relacionadas con la accesibilidad, el botón "Nuevo problema" siempre está ahí. Noto que mientras escribía este comentario ya se presentó un nuevo problema (# 10537): eso es genial 😄

Gracias a todos y que tengan un gran viernes. ❤️

@tofumatt ¿Puede actualizar la información sobre la auditoría?

Lo primero es lo primero: he estado hablando con varias empresas durante la semana pasada sobre la realización de una auditoría y recibí propuestas de ellas.

Diré que recibí propuestas bastante detalladas de:

• Nivel de acceso
• Sistemas Deque

Y respuestas menos detalladas pero aún excelentes de:

• El Grupo Paciello
• Heydon Pickering

Todos parecían saber lo suyo. No voy a compartir los detalles de las propuestas porque no creo que sea apropiado, pero tengo noticias desafortunadas en el frente de la auditoría. 😢

Por lo menos por el momento, Automattic ha decidido no realizar una auditoría de accesibilidad en Gutenberg. Las principales razones son:

1. una auditoría no será procesable dado nuestro cronograma de publicación, porque ...
2. la auditoría no afectará el tiempo de publicación, así que ...
3. sería más prudente explorar una auditoría en un cronograma menos apresurado en el futuro

Espero que exploremos una auditoría en el futuro, pero desafortunadamente no sucederá antes de la propuesta de fusión y, por lo tanto, cierro este problema como una solución que no se solucionará. Todavía me gustaría escribir en un blog sobre el estado de la accesibilidad de Gutenberg, tanto para lo bueno como para lo malo. Esta semana vamos a realizar algunas mejoras en la navegación del teclado, el contraste de color, el comportamiento del enfoque y los selectores de fecha / color.

Lo siento por hacernos ilusiones y luego fallarle a la comunidad en este caso. 😞

Solo una nota rápida para decir que me encantaría que esto continúe, incluso si sucede después de 5.0.
¿Hay alguna razón para no dejarlo abierto y asignarlo a un hito diferente o futuro?

Seguro que últimamente hemos estado en una montaña rusa emocional, ¿no es así? 🎢

En primer lugar, gracias a todos por el trabajo que hacen. 💖 Sé que a veces no es fácil ser un defensor de la accesibilidad, puede parecer una batalla cuesta arriba constante. Tenga en cuenta que está teniendo un impacto: desde lo personal (he aprendido mucho sobre accesibilidad de las personas que componen el equipo de accesibilidad de WordPress), hasta lo fundamental (el diseño centrado en las personas es una faceta esencial de las prácticas de diseño modernas ).

Me gusta mucho la idea de una auditoría profesional, aunque no recuerdo que alguna vez hiciéramos una de estas en WordPress, ciertamente no es una condición para un lanzamiento. Me encantaría ver que algo así sucediera en algún momento. WordPress siempre ha intentado aprovechar la mayor parte del camino hacia la accesibilidad al ceñirse a patrones y semánticas comunes, con la diferencia cubierta por los esfuerzos clave de los voluntarios, todos en el equipo de Accesibilidad que realizan pruebas y presentan informes de errores procesables. El paso de Gutenberg a ser una aplicación completamente basada en JavaScript ha dificultado la aplicación de esos patrones, pero podemos trabajar juntos para establecer nuevos patrones, una nueva línea de base.

Sabemos que Gutenberg aún necesita más pulido, ¡lo que estamos haciendo! Y, como todo, tendrá problemas en los que continuaremos repitiendo en los meses y años venideros. En base a muchas conversaciones, parece que los problemas más críticos ya están archivados, muchos de ellos están solucionados y seguiremos solucionándolos a medida que surjan.

Hay un montón de problemas que aún no se han marcado (¡gracias especialmente a todos los que enviaron problemas durante la última semana!). Sería bueno ver una revisión de errores para analizar estos problemas y priorizarlos. Podemos asegurarnos de que se solucionen los problemas que impiden activamente que las personas usen Gutenberg y luego centrarnos en los problemas relacionados con facilitar el uso de Gutenberg.

He mencionado esto antes, pero vale la pena repetirlo: WordPress 5.0 no es la línea de meta, es la pistola de arranque. Muchos de los que estamos en este hilo hemos estado trabajando juntos en WordPress durante años antes de que comenzara Gutenberg, y espero que trabajemos juntos en WordPress durante los próximos años. Hemos visto muchas características nuevas llegar a WordPress a lo largo de los años, y ninguna de ellas se ha mantenido igual que cuando se lanzaron por primera vez. Nos hemos enfrentado a desafíos que la mayoría de los otros proyectos descartarían como insuperables, pero los hemos hecho funcionar.

La misión de WordPress sigue siendo democratizar la publicación. La accesibilidad consiste en hacer que las cosas funcionen para las personas que históricamente han estado increíblemente marginadas. Estos no son solo complementarios, la misión de WordPress requiere inherentemente que sea accesible.

Lo que lanzamos en WordPress 5.0 no está escrito en piedra, continuaremos arreglándolo, reelaborando, aprendiendo de él y haciéndolo mejor. Gutenberg es la base sobre la que podemos construir la próxima generación de la web, y también existe el potencial para mejorar la accesibilidad de toda la web. Cada componente, cada bloque, cada interfaz debe ser completamente accesible, y cada complemento y tema, en última instancia, debería poder aprovechar eso. La generación Gutenberg debería proporcionar una experiencia accesible _por defecto_. No solo eso, el verificador de contraste de color y las advertencias de jerarquía de encabezados son buenos ejemplos de cómo Gutenberg puede hacer que la creación de contenido accesible también sea el comportamiento predeterminado.

He desbloqueado y vuelto a abrir este problema y lo he marcado para el futuro, pero podemos moverlo fácilmente a un hito más cercano en un momento posterior. Tengo una solicitud especial de que todos tratemos de mantenernos en el tema y centrarnos en una conversación productiva. Me encantaría vernos tomar lo que se comenzó aquí y descubrir un marco para una auditoría de accesibilidad de calidad, algo que pueda expandirse para cubrir el alcance de la fase 2 de Gutenberg y más allá. Puede que no estemos allí todavía, pero lo estaremos. ❤️

Relacionado # 10537.

WordPress 5.0 no es la línea de meta, es la pistola de arranque.

Sin embargo, en última instancia, esa pistola de arranque parece funcionar solo para aquellos sin habilidades diferentes. Una pistola de arranque funciona en la práctica, porque el sonido es lo suficientemente fuerte como para crear una estela en el aire que las personas sordas pueden sentir, y porque produce un destello / humo que pueden ver; hace un sonido para que lo escuchen los ciegos. Una pistola de arranque es accesible para todos; Gutenberg no parece serlo.

Al negarse a considerar siquiera la posibilidad de pausar el lanzamiento de Gutenberg hasta después de que se haya realizado una auditoría, le está diciendo a cualquiera que _físicamente_ no puede usar Gutenberg que no son importantes para la comunidad de WordPress. Eso va en contra de los estándares de la comunidad de WordPress, es irresponsable y, francamente, es vergonzoso y peligroso para un producto tan ubicuo que adopte ese tipo de actitud hacia tantas otras comunidades.

Creé la etiqueta "Necesita comentarios sobre accesibilidad" para los problemas que requieren que alguien con conocimientos de accesibilidad intervenga, pero como no hay nada procesable en este tema, eliminaré la etiqueta 😄

Nadie dice nada por el estilo, @cgrymala. Como mencioné, una auditoría de accesibilidad profesional _nunca_ ha sido un requisito para que cualquier característica se fusione en el historial de WordPress. Ciertamente me gustaría ver una auditoría, pero escribir que la falta de auditoría es "irresponsable ... vergonzoso y peligroso" es el tipo de hipérbole que se interpone en el camino del diálogo constructivo.

Reiteraré mi solicitud de mi comentario anterior, manténgase en el tema y concéntrese en una conversación productiva .

Más concretamente, la falta de auditoría no nos impide solucionar problemas. Si la accesibilidad es importante para usted, si usted (o alguien que conoce) usa tecnología de asistencia, ahora es un excelente momento para probar y reportar errores.

@pento , ¿no noté que nadie argumentó que una auditoría era un precedente? Eso parece un argumento de hombre de paja, y basado en este hilo, el precedente simplemente no fue la génesis de la idea de auditoría.

La auditoría fue sugerida por @tofumatt porque hay buenas razones para creer que Gutenberg no es tan accesible como debería ser de acuerdo con los propios estándares de WordPress. Sin una auditoría independiente, o incluso solo una _A_ auditoría, ¿por qué espera que la comunidad crea de repente que Gutenberg es accesible? La falta de una auditoría no es irresponsable y peligrosa, pero este estilo de toma de decisiones y gestión dictatorial sí lo es.

Dados los obstáculos de la autenticación, no creo que llevar esto al núcleo proporcione beneficios para WP más allá de lo que la comunidad obtiene del complemento. No creo que en su estado actual el beneficio supere el costo, y deberíamos pecar de simplicidad.

Eso es lo que dijo @m durante el debate de WP API. Es otro ejemplo más de las hipocresías evidentes en este ciclo de reciclaje, comenzando con el hecho de que los "plazos no son arbitrarios" la compañía se negó a establecer una fecha de lanzamiento para 5.0, hasta que encontraron una que les gustaba, momento en el que no había lugar para el debate . Amo a Gutenberg y lo uso todos los días. Proporciona un gran valor como complemento y, según la propia heurística de Matt, deberíamos pecar de simplicidad hasta que esté realmente listo.

La accesibilidad es importante para muchas personas en este hilo, que han ofrecido tiempo, apoyo y dinero para ayudarnos a superar este estancamiento. No es sincero que sugieras que si realmente nos importara, estaríamos solucionando los problemas.

Respecto a las razones aducidas para cancelar la auditoría:

una auditoría no será procesable dado nuestro cronograma de publicación, porque ...
la auditoría no afectará el tiempo de publicación, así que ...
sería más prudente explorar una auditoría en un cronograma menos apresurado en el futuro

Incluso si la idea de una auditoría de terceros está muerta, implícita en la idea de https://github.com/WordPress/gutenberg/issues/10537 estaría la auditoría de Gutenberg por medios de accesibilidad. El hecho de que Automattic esté dispuesto a lanzar Gutenberg a Core sin estándares de accesibilidad autoimpuestos es extremadamente problemático . En última instancia, me desanima que me recuerden que, al final del día, los intereses de Automattic parecen promoverse por encima de los de la comunidad cuando se trata del desarrollo y lanzamiento de Gutenberg.

Este hilo trata sobre:

1. realizando una auditoria
2. presentación de problemas basados ​​en la auditoría
3. publicar sus resultados como un informe en el blog Make / Accessibility

Reconocemos la utilidad de una auditoría y que a la gente le gustaría que se realizara. Guarde los comentarios relacionados con el proceso de:

1. la realización de la auditoría
2. alcance de la auditoría
3. resultados de la auditoria

Estoy ocultando comentarios fuera del tema que están modificando lo que se ha dicho y destacando la importancia de una auditoría. Me gustaría ver uno realizado. Allí estamos todos de acuerdo. Por favor, mantenga los comentarios sobre el tema, sean productivos y asegúrese de que brinden nueva información / agreguen al problema en cuestión.

@davisshaver Recuerde la etiqueta de WordPress , especialmente:

Las contribuciones al proyecto de código abierto de WordPress son para el beneficio de la comunidad de WordPress en su conjunto, no para empresas o individuos específicos. Todas las acciones que se tomen como colaborador deben realizarse teniendo en cuenta los mejores intereses de la comunidad.

El proyecto de código abierto de WordPress es una comunidad dirigida por voluntarios. Incluso en los casos en los que los contribuyentes son patrocinados por empresas, ese tiempo se dona en beneficio de toda la comunidad de código abierto.

Aunque @pento , @tofumatt , @m y otros son donados por Automattic, están trabajando para mejorar el proyecto. Automattic no es quien decide cuándo se lanzará Gutenberg.

La auditoría puede continuar y continuará como lo señaló @pento :

ahora es un excelente momento para probar e informar errores.

Todo lo que se pueda hacer para contribuir a ese proceso de pruebas e informes es beneficioso. Hay una serie de problemas anteriores que podrían usar pruebas para ver si todavía son un problema que no requiere ninguna tecnología de asistencia especializada para probar. Hacerlo sería de gran ayuda y es, en parte, lo que habría proporcionado una auditoría independiente.

No sabía que ser líder de lanzamiento de WordPress.org implicaba que Matt dejara su responsabilidad fiduciaria en Automattic. Si bien podría argumentar que el conflicto es mínimo, o que Matt trabaja activamente para mitigar el conflicto, la etiqueta de WordPress que citó es una recomendación y no una descripción del mundo ... En última instancia, el conflicto existe.

Estoy seguro de que mucha gente está acechando este tema en este momento y diré que si está interesado y quiere ayudar, pero no ha utilizado tecnología de asistencia antes (lectores de pantalla), únase a la discusión en https: // make .wordpress.org / chat / en el canal de accesibilidad. Siéntase libre de contactarme incluso con un DM. Puede que se sorprenda de lo fácil que es configurar NVDA / Voice Over / JAWS para que pueda comenzar a probar cosas.

Más allá de eso, hay muchas herramientas disponibles para probar los requisitos de WCAG:
Hacha cromada:
https://chrome.google.com/webstore/detail/axe/lhdoppojpmngadmnindnejefpokejbdd

Comprobador de contraste para WCAG: https://chrome.google.com/webstore/detail/wcag-contrast-checker/plnahcmalebffmaghcpcmpaciebdhgdf?hl=en

Herramientas de Chrome A11y: https://chrome.google.com/webstore/detail/accessibility-developer-t/fpkknkljclfencbdbgkenhalefipecmb?hl=en

Hay 113 problemas abiertos con la etiqueta de accesibilidad que están abiertos actualmente:
https://github.com/WordPress/gutenberg/labels/Accessibility

Ya sea que estemos de acuerdo con las decisiones actuales que se están tomando o no, creo que todos podemos estar de acuerdo en que todavía hay mucho trabajo en el que todos podemos participar para ayudar a resolver. Incluso en ausencia de una auditoría oficial, la comunidad todavía tiene el poder de ayudar a brindar una experiencia más accesible.

Este problema se presentó para publicitar mi trabajo en la auditoría de accesibilidad, para comunicar que me gustaría que sucediera y para rastrear el intercambio de esa auditoría en una publicación de blog. No pretende ser un punto de discusión sobre lo que debería considerarse un bloqueador de versiones para WordPress 5.0. He tomado nota de las opiniones de la gente sobre el tema y se las transmitiré a @m , que es el líder de lanzamiento de WordPress 5.0. Mi entendimiento es:

1. I don't have have veto over 5.0 shipping, but even if I did:

2. I'm still not convinced there are sufficient Accessibility issues that prevent a release

Si el segundo punto cambia, transmitiré esa información. Planeo ser un defensor, pero no establezco los plazos y tampoco tengo datos sólidos sobre accesibilidad. Ese es el objetivo de la auditoría: para que podamos hablar desde un lugar de datos duros. 🙂

Gracias por todos los aportes, pero como esta discusión se ha vuelto bastante fuera del tema de su alcance previsto, estoy bloqueando la conversación de este tema por ahora. Lo dejaré abierto y publicaré actualizaciones sobre la auditoría.

Literalmente, todas las personas con discapacidades que han probado Gutenberg, tanto recientemente como al principio, han señalado problemas de bloqueo de por qué no es accesible. Y las pruebas de usuario son tan importantes para la accesibilidad como lo es el cumplimiento del nivel AA de WCAG 2.0. Probablemente debería decir WCAG 2.1 AA en este punto, pero WCAG 2.0 aún te acerca mucho más a donde debes estar. Decir que no tiene datos es, en el mejor de los casos, inexacto.

La falta de una auditoría en este caso es irresponsable porque, para empezar, a diferencia de WordPress en el pasado, se ha elegido un marco que no viene con componentes accesibles listos para usar y, a diferencia de WordPress anterior, está modificando mucho el documento. modelo de objetos con Gutenberg, además de eliminar elementos del árbol de accesibilidad, y en el caso de los navegadores, el DOM y el árbol de accesibilidad son literalmente cómo la tecnología de asistencia recupera información para interpretar. Incluso si deja la tecnología de asistencia fuera de esto, como se encuentra actualmente Gutenberg, la carga cognitiva es enorme. El complemento del editor clásico es un sustituto completamente inaceptable. Para empezar, es para todo el sitio. Entonces, si un sitio usa Gutenberg y necesito ingresar y hacer algo con el contenido, no puedo hacerlo por usuario y no puedo instalar el complemento del editor clásico, hacer mi trabajo y luego desinstalar y esperar que todo se comporte como debería una vez que se lleve a cabo la reversión a Gutenberg. Y sí, he probado esto. El hecho de que la accesibilidad se deje como una ocurrencia tardía, de nuevo, es literalmente cómo WordPress se metió en el lío en el que estaba en 2011/2012 cuando el equipo de accesibilidad despegó por primera vez. Y el proyecto, literalmente, está cometiendo exactamente el mismo error nuevamente, y nos pide que confiemos en que eventualmente lo hará bien, nuevamente. Lo siento, pero ¿cuántas veces hay que enviar a las personas con discapacidades a la parte trasera del autobús por el bien común? Cuántas veces tenemos que estar satisfechos con un montón de palabras bonitas sobre accesibilidad, sobre cómo prometemos que lo haremos mejor la próxima vez, solo para descubrir cuando se trata de tachuelas de bronce que la accesibilidad realmente no es un ¿prioridad?

Por lo menos por el momento, Automattic ha decidido no realizar una auditoría de accesibilidad en Gutenberg. Las principales razones son:

1. una auditoría no será procesable dado nuestro cronograma de publicación, porque ...
2. la auditoría no afectará el tiempo de publicación, así que ...
3. sería más prudente explorar una auditoría en un cronograma menos apresurado en el futuro

@tofumatt @pento ¿Puede aclarar si la línea de tiempo mencionada aquí se refiere a una fecha de lanzamiento del 19 de noviembre de 2018 o del 22 de enero de 2019 como se menciona en el Alcance y Programación Propuestos de WordPress 5.0 ?

La fecha del 22 de enero de 2019 permitiría más de tres meses entre hoy y el lanzamiento de 5.0 para completar una auditoría y tomar medidas. Las razones anteriores sugieren que no podemos completar una auditoría y mejorar significativamente la accesibilidad en tres meses. Si es cierto, esa es una razón más para comenzar el proceso ahora y responder a la auditoría solucionando tantos problemas como podamos antes de las versiones 5.0.

La idea de que la línea de tiempo se volverá menos apresurada después de 5.0 (cuando está en manos de los usuarios del mundo real que más lo necesitan) no tiene ningún sentido.

Los sitios que cumplieron con el nivel AA de WCAG 2.0, pero el nuevo contenido editado con Gutenberg no cumplirán con la normativa cuando la versión 5.0 desate una pesadilla legal.

Gracias a todos los que comentaron aquí hasta ahora y mantuvieron la discusión sobre el tema. Realmente lo aprecio: con tantas cosas en torno a WordPress 5.0, realmente me ayuda a poder dedicar el tiempo que se merece este problema. 🙂

@amandarush : Mencionaste varias inquietudes, intentaré responderlas todas, pero avísame si me pierdo algo.

Literalmente, todas las personas con discapacidades que han probado Gutenberg, tanto recientemente como al principio, han señalado problemas de bloqueo de por qué no es accesible.

Estoy realmente agradecido con todos los que han señalado estos problemas. Pensé que habíamos hecho un trabajo razonable al abordar estos problemas a medida que surgían, pero claramente hay más trabajo por hacer. Cuando @tofumatt se ha referido a "no tener datos", creo que lo está viendo desde la perspectiva de que hemos solucionado muchos problemas de accesibilidad, no tenemos una idea completa del estado actual de las cosas, por lo que queremos Obtenga una imagen más clara de la gravedad de los problemas restantes.

La falta de una auditoría en este caso es irresponsable porque, para empezar, a diferencia de WordPress en el pasado, se ha elegido un marco que no viene con componentes accesibles listos para usar.

¿Te refieres a React aquí? Tengo entendido que las aplicaciones creadas con React son igualmente accesibles para cualquier otra biblioteca que actualice dinámicamente el DOM. Siempre que hagamos un uso adecuado de los atributos aria-* (además de garantizar un enfoque predecible del teclado), debería poder utilizarse con tecnología de asistencia. ¿No es esto correcto?

El complemento del editor clásico es un sustituto completamente inaceptable. Para empezar, es para todo el sitio. Entonces, si un sitio usa Gutenberg y necesito ingresar y hacer algo con el contenido, no puedo hacerlo por usuario y no puedo instalar el complemento del editor clásico, hacer mi trabajo y luego desinstalar y esperar que todo se comporte como debería una vez que se lleve a cabo la reversión a Gutenberg.

Gracias por mencionar este caso de uso, es un buen ejemplo de dónde falla actualmente el complemento Classic Editor. Ciertamente podemos agregar una opción por usuario.

Y el proyecto, literalmente, está cometiendo exactamente el mismo error nuevamente, y nos pide que confiemos en que eventualmente lo hará bien, nuevamente. Lo siento, pero ¿cuántas veces hay que enviar a las personas con discapacidades a la parte trasera del autobús por el bien común? Cuántas veces tenemos que estar satisfechos con un montón de palabras bonitas sobre accesibilidad, sobre cómo prometemos que lo haremos mejor la próxima vez, solo para descubrir cuando se trata de tachuelas de bronce que la accesibilidad realmente no es un ¿prioridad?

Lo siento. A pesar de las mejores intenciones de todos en el equipo de Gutenberg, no hemos hecho lo suficiente. Honestamente puedo decir que la accesibilidad siempre ha sido una prioridad, pero no ha sido una prioridad lo suficientemente alta y hemos hecho un mal trabajo comunicando dónde se ha mejorado la accesibilidad. Mencioné algunas de esas mejoras en mi comentario anterior, pero esas mejoras no tienen ningún beneficio si no hemos alcanzado la experiencia accesible de referencia.

Por supuesto, una disculpa no sirve sin acciones para corregirlo, así que esto es lo que propongo. En este momento, la intención es priorizar y solucionar tantos problemas de accesibilidad como sea posible. Ya hemos solucionado cientos y ya hay correcciones en curso para algunos de los problemas abiertos. Estaremos probando, por supuesto, pero necesitamos la experiencia de las personas que utilizan tecnología de asistencia para descubrir errores. Cualquier prueba e informe de errores para los que pueda dedicar tiempo es muy apreciado.

Si bien creo que podemos llevar el editor de bloques a un estado en el que tenga una experiencia de usuario aceptable para los usuarios de tecnología de asistencia para cuando se publique la versión 5.0, reconozco que existe la posibilidad de que no podamos. Además de la configuración por usuario que sugirió, ¿de qué otra manera podemos asegurarnos de que el complemento Classic Editor sea una opción razonable para que la gente la use hasta que esté satisfecha con el estado del editor de bloques?

Todavía me gustaría ver una auditoría de accesibilidad independiente, pero sin la línea de tiempo apresurada de la versión 5.0. Ahí es donde este problema se puede utilizar para crear el marco para una auditoría integral. A medida que se descubren los problemas, se pueden solucionar en las versiones 5.0.x, ciertamente no hay necesidad de esperar a la 5.1.

@kevinwhoffman : la línea de tiempo se refiere a la fecha de lanzamiento del 19 de noviembre (o el 27 de noviembre a más tardar). Aplazar la fecha de lanzamiento hasta el 22 de enero no nos daría mucho tiempo adicional: entre WCUS (y la preparación requerida antes), necesitando organizar un lanzamiento de WordPress 4.9.9, luego la gente está de vacaciones en Navidad y Año Nuevo, podríamos ganar dos semanas laborales completas adicionales si adelantamos dos meses la fecha de lanzamiento. Tres meses adicionales suena como una cantidad generosa, pero nos daría muy pocos resultados reales, y aún necesitaríamos una auditoría rápida, por lo que podríamos estar trabajando para abordarlo en noviembre.

@rcemory : Si bien su comentario está un poco fuera de tema, vale la pena señalar que esta discusión está relacionada con la interfaz del editor de bloques en sí, no con el contenido que produce para mostrar en la parte frontal de su sitio. Al igual que con WordPress ahora, el contenido producido en el editor de bloques es accesible. En muchos casos, es más accesible que antes, ya que el editor de bloques hace un mejor trabajo agregando etiquetas aria-* apropiadas, advierte cuando está usando combinaciones de colores que no cumplen con WCAG, o cuando está poner los elementos de título en el orden incorrecto.

El complemento del editor clásico es un sustituto completamente inaceptable. Para empezar, es para todo el sitio. Entonces, si un sitio usa Gutenberg y necesito ingresar y hacer algo con el contenido, no puedo hacerlo por usuario y no puedo instalar el complemento del editor clásico, hacer mi trabajo y luego desinstalar y esperar que todo se comporte como debería una vez que se lleve a cabo la reversión a Gutenberg.

Gracias por mencionar este caso de uso, es un buen ejemplo de dónde falla actualmente el complemento Classic Editor. Ciertamente podemos agregar una opción por usuario.

Esto sería fantástico, pero es una preocupación que se planteó hace más de un año y que no se ha abordado hasta ahora. Dado que en el estado actual de las cosas, una vez que una publicación pasa a GB, no se puede revertir a "normal" y luego volver a GB de nuevo mientras se conserva toda la información relevante.
Por lo tanto, el plan para tener una opción basada en el usuario simplemente no es realista, ya que significa que los editores que opten por no participar en GB tendrán dificultades para editar el contenido creado por autores que usan GB.

Los comentarios de @amandarush son poderosos y del corazón. Y, lo sé, basándome en la experiencia pasada de intentar avanzar en la accesibilidad dentro de WordPress.

Desde que participé en el equipo de accesibilidad, ha habido 4 (creo) mejoras de funcionalidad importantes en el área de administración: creador de menús personalizados, administrador de medios, personalizador y ahora Gutenberg.

Tal como se concibieron y construyeron originalmente, todos estos componentes eran prácticamente (o totalmente) inaccesibles para los usuarios de lectores de pantalla y los usuarios de teclados videntes. En mi opinión, esto se debe a que la accesibilidad no se pensó en absoluto en las etapas de diseño gráfico y UX. Después de que el equipo de accesibilidad se quejó, se realizaron mejoras de accesibilidad en los 4, pero el diseño subyacente y la experiencia de usuario siguen siendo en gran medida los mismos.

Así que comparto su opinión de que WordPress sigue cometiendo el mismo error una y otra vez. Y, tristemente, comparto su escepticismo cuando escuchamos "La accesibilidad es realmente importante para nosotros". Es muy frustrante y una de las razones por las que ya casi nunca contribuyo a WP.

Parece poco probable ahora que las preocupaciones por la accesibilidad detengan el impulso para lanzar WP5.0 en noviembre, lo que por supuesto es una gran decepción después de que la lista de 'bloqueadores' de accesibilidad se redactó por primera vez en la primavera de este año. Y el deseo frecuentemente citado de WP de democratizar la web, y la promesa de no lanzar ninguna funcionalidad que no sea compatible con WCAG2.0.

Pero creo que una revisión de accesibilidad independiente, que implique no solo pruebas para WCAG2.1, sino también pruebas de usuario adecuadas, sería algo sensato de hacer ahora. Al menos de esa manera, todos sabríamos dónde estamos, y se puede dar el enfoque apropiado para priorizar y corregir los defectos / problemas de accesibilidad en versiones futuras.

En respuesta a esto de @pento

¿Te refieres a React aquí? Tengo entendido que las aplicaciones creadas con React son igualmente accesibles para cualquier otra biblioteca que actualice dinámicamente el DOM. Siempre que hagamos un uso adecuado de los atributos aria- * (además de garantizar un enfoque predecible del teclado), debería poder utilizarse con tecnología de asistencia. ¿No es esto correcto?

Sí, eso es cierto, pero los desarrolladores deben comprender cómo hacer que sus componentes sean accesibles en diseño, semántica, operación, administración de enfoque y con el uso correcto de ARIA. Lamentablemente, esto rara vez sucede en mi experiencia.

Si / a medida que Automattic sigue el camino de una auditoría, puede valer la pena no solo identificar los flujos críticos / recorridos del usuario, sino también los widgets comunes para revisar. Si estos widgets se pueden identificar y auditar solos, también pueden formar la base de una biblioteca de patrones accesible. Esto puede ayudar a mitigar los riesgos de accesibilidad a medida que se crean más funciones utilizando esos patrones.

Puede que valga la pena no solo identificar los flujos críticos / viajes del usuario, sino también los widgets comunes para revisar. Si estos widgets se pueden identificar y auditar solos, también pueden formar la base de una biblioteca de patrones accesible. Esto puede ayudar a mitigar los riesgos de accesibilidad a medida que se crean más funciones utilizando esos patrones.

@aardrian Ese es un punto de partida interesante que ya puede existir y que será necesario para la auditoría que podemos usar ahora para actuar: no he visto viajes de usuario para Gutenberg, y ese es probablemente el punto de partida más obvio para comenzando a alcance dicha auditoría.

@karmatosed @jwold - ¿Sabes si ya existen dichos flujos / viajes para usar Gutenberg? ¿Quizás una lista de "widgets" o "patrones" como se describe aquí?

Creo que si bien este hilo general tiene mucha emoción (y estoy de acuerdo en que Gutenberg debe ser utilizable por todos y enviarlo cuando esté listo), me encantaría encontrar un terreno común y los próximos pasos. Me encantaría cambiar los lugares de conversación para identificar dónde estamos listos para la acción.

Dicho flujo de usuarios también nos daría una lista de tareas de lugares para auditar para que los desarrolladores, probadores y cazadores de errores comiencen a dividirse y buscar cosas para informar.

@postphotos , creo que @afercia describió un buen conjunto de flujos arriba en https://github.com/WordPress/gutenberg/issues/10318#issuecomment -428957684.

@aardrian De acuerdo, ¡es un gran lugar para comenzar! 👍 Gracias por recordar eso.

Mi pregunta sigue en pie: me encantaría saber, más allá de ese flujo crítico inicial, si hay trabajo adicional que ya se ha puesto en los viajes de los usuarios en lo que respecta a las funciones, ya que ayudará a validar el trabajo que estamos haciendo aquí. Puede haber otros elementos que nosotros (este grupo) podríamos querer agregar a la lista inicial de @afercia , o secuenciar más allá de una auditoría inicial. 😄

Por ejemplo, no hemos mencionado la función Estructura de contenido, deshacer / rehacer, etc. o ver una publicación, y esas tareas que podríamos acordar son importantes y útiles para que los usuarios puedan usarlas, las cosas que acordamos hacen que Gutenberg increíblemente útil y debería ser accesible. Sería fantástico encontrar un consenso de forma activa si podemos.

Un beneficio adicional de hacer una auditoría es la contribución al proyecto React más grande. React tiene sus propios problemas de accesibilidad, y una auditoría de Gutenberg bien puede identificar tanto los problemas como las soluciones que se relacionan y pueden ayudar al núcleo de React.

Bueno, estas son buenas noticias: https://make.wordpress.org/core/2018/10/18/regarding-accessibility-in-gutenberg/

Atajos de teclado para navegación de regiones y bloques, comandos de barra, barra de herramientas enfocable y mejoras en la barra lateral de puntos de referencia y roles mejorados de ARIA, pruebas automatizadas de un extremo a otro, y más.

ICYMI: La organización WPCampus está organizando una auditoría de accesibilidad de Gutenberg.

Hemos terminado nuestra RFP y ahora estamos seleccionando un proveedor.

Sin embargo, como la mayoría de ustedes probablemente saben, una auditoría de accesibilidad profesional es un gran gasto para una pequeña organización sin fines de lucro como WPCampus.

Solicitamos su ayuda para financiar la auditoría y garantizar que se complete esta investigación vital.

Puede leer más sobre la iniciativa y hacer donaciones en nuestro sitio web: https://wpcampus.org/2018/11/fundraising-for-wpcampus-gutenberg-accessibility-audit/

Hola Rachel,

Veo que nos está pidiendo que donemos para la auditoría.
Me pregunto si has pensado en mi publicación en este hilo que escribí.
hace un par de meses, ofreciendo donar auditorías de accesibilidad, ya que
¿Resolvería por completo cualquier brecha restante en la financiación?
Algunos de los principales gobiernos y empresas Fortune 500 del mundo confían en nosotros
con tales proyectos!

Esto es lo que publiqué el 11 de octubre de 2018:

==========================

@tofumatt https://github.com/tofumatt También me preocupa mucho
Accesibilidad de WordPress y ansioso por ayudarlo a tener éxito. Puedo tener nuestro
La organización realiza una auditoría de accesibilidad completa que cumple con WCAG-EM para
cualquier nivel estándar que prefiera, tanto técnico como funcional
pruebas, * y done cualquier parte del trabajo que necesite * para adaptarse a su
presupuesto.

Creo que deberíamos considerar tanto ATAG como WCAG AA, y tal vez
WCAG 2.1 en lugar de 2.0. También podríamos ofrecer recomendaciones y
coaching para ayudarlo a elegir la mejor y más sostenible forma de cerrar cualquier
lagunas descubiertas.

Estamos convenientemente separados de su comunidad de desarrollo, pero sabemos
WordPress bien durante muchos años. Poseo todas las certificaciones IAAP y he liderado
docenas de auditorías de este tipo en la plataforma de WordPress, durante muchos años, tanto para
sector público y privado. Consulte nuestra buena fe en

davidberman.com/about para decidir cuál es la mejor forma de ayudarlo.

Pensamientos

• David

El miércoles 28 de noviembre de 2018 a las 10:10, Rachel Cherry [email protected]
escribió:

ICYMI: La organización WPCampus está organizando una auditoría de accesibilidad de
Gutenberg.

Hemos terminado nuestra RFP
https://wpcampus.org/2018/10/gutenberg-a11y-audit-rfp/ y ahora
seleccionar un proveedor.

Sin embargo, como la mayoría de ustedes probablemente saben, un profesional
La auditoría de accesibilidad es un gran gasto para una pequeña organización sin fines de lucro como WPCampus.

Le pedimos su ayuda para financiar la auditoría y garantizar que esta
se completa la investigación.

Puede leer más sobre la iniciativa y hacer donaciones en nuestro sitio web:
https://wpcampus.org/2018/11/fundraising-for-wpcampus-gutenberg-accessibility-audit/

-
Estás recibiendo esto porque comentaste.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/WordPress/gutenberg/issues/10318#issuecomment-442480511 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/ABz4pIgVSgZmWJRL2n3Uy-i8Ov7NXnj1ks5uzqdcgaJpZM4XG_WQ
.

-
David Berman, RGD, FGDC, CPWA
Comunicaciones de David Berman | [email protected] | @davidberman
+ 1-613-728-6777 https://dialpad.com/launch?phone=%2B1-613-728-6777 | 340
Selby Avenue, Ottawa K2A 3X6

Asesor de alto nivel, Naciones Unidas | Experto invitado, W3C | Ico-D
Cátedra de Sostenibilidad | Silla Carleton U. Access Network

Próximamente: Toronto | Nueva Orleans | Montreal | Buenos Aires | Tampa | Tel Aviv
Curso de accesibilidad: únase a nosotros en línea www.davidberman.com/next

Este mensaje puede contener información de propiedad. No autorizado
Prohibida la divulgación / copia / distribución de contenidos.

@tofumatt , vi esto en el blog personal de Matt Mullenweg el 29 de noviembre:

Finalmente, Automattic financiará un estudio de accesibilidad de WordPress, Gutenberg y una evaluación de las mejores prácticas en la web, para garantizar que WordPress sea completamente accesible y establezca nuevos estándares para la web en general.

Como usted es un representante de Automattic, ahora que la auditoría de Automattic está nuevamente activada, ¿puede decirnos si esto será independiente de la auditoría de WPCampus o Automattic financiará la auditoría de WPCampus en su lugar?

Por un lado, odio ver que WPCampus tenga que financiarlo colectivamente. Por otro lado, me gusta la idea de dos auditorías de dos empresas para comparar y contrastar.

Matt respondió a mi pregunta en su blog:

Creo que está bien tener dos también, hablaré con Rachel sobre cómo va la financiación.

Para aquellos que sigan adelante, se han comprometido a financiar completamente cualquier proyecto de Rachel que necesite en el lado de WP Campus y en la fase de selección de proveedores para el patrocinado por Automattic. El objetivo de este último es también ver cuáles son los enfoques de accesibilidad de mejores prácticas para otras interfaces de estilo de editor de bloques en la web moderna.

@m Gracias por la actualización. Es muy alentador ver que esto avanza y realmente estoy ansioso por ver a dónde conduce. Me encantaría que WordPress fuera algún día el ejemplo de cómo se debe tratar la accesibilidad.

@metro

Para aquellos que sigan adelante, se han comprometido a financiar por completo cualquier proyecto de Rachel que necesite en el lado de WP Campus.

Esto es grandioso y valioso. ¿Hay alguna razón por la que no lo financie en su totalidad hoy? Parece extraño pedirle a las personas que sigan donando cuando saben que será financiado por completo independientemente.

@aardrian Eso no está en el espíritu de lo que estamos haciendo. Queremos que este sea un proyecto comunitario y que permita a las personas y organizaciones la oportunidad de participar y mostrar su apoyo, si pueden.

A fines de 2018, WPCampus lanzó una solicitud de propuestas para realizar una auditoría de accesibilidad del editor de bloques de WordPress, también conocido como Gutenberg. A principios de 2019, anunciamos nuestra selección de Tenon, LLC para realizar la auditoría, a un costo de $ 31,200.

Hoy nos complace publicar el informe de Tenon sobre la accesibilidad del nuevo editor.

Ver más en https://wpcampus.org/2019/05/gutenberg-audit-results/

Creo que concluye este tema 🎉🎉🎉🎉🎉

Todos los problemas informados se rastrean en este proyecto:
https://github.com/WordPress/gutenberg/projects/25

Todos los problemas notificados se registran en este proyecto.

No del todo correcto. El informe WPCampus / Tenon incluye consideraciones importantes adicionales que no se tratan en la lista de problemas en GitHub. Más específicamente, el Resumen ejecutivo y el Informe de usabilidad muestran (con datos) que hay problemas de accesibilidad estructural más amplios en Gutenberg que no se pueden abordar en problemas pequeños y procesables de GitHub y que requieren soluciones a un nivel superior.

Esto es para dejar en claro que incluso si se resolvieron todos los problemas informados, todavía habrá importantes problemas de accesibilidad por resolver. Estos suelen estar relacionados con el diseño general del editor.

Como referencia, adjunto aquí dos de los documentos publicados en https://wpcampus.org/2019/05/gutenberg-audit-results/

Documento resumido que describe las pruebas de usabilidad de Tenon
Gutenberg_UX_Report.pdf

Resumen Ejecutivo
Gutenberg_Executive_Summary.pdf

Sugiero abrir un nuevo número, o incluso un proyecto, para manejar los problemas de usabilidad descubiertos en el informe.