Ce serait vraiment cool de savoir que tous les blocs qui répliquent les fonctionnalités de l'éditeur classique sont accessibles dans Gutenberg.

La bonne chose à faire ici est d'obtenir une vérification indépendante de l'accessibilité. WordPress a une politique déclarée de respecter les directives d'accessibilité dans le noyau, et a également la responsabilité envers ses utilisateurs de respecter ces directives. Seul un audit d'accessibilité approfondi peut montrer si c'est le cas ou non. L'équipe d'accessibilité a signalé de nombreux problèmes, dont certains ont été traités, d'autres non. À tout le moins, ces problèmes doivent être résolus.

WordPress est une interface entre l'éditeur, une base de données et le visiteur. La manière exacte dont l'éditeur choisit de saisir ou de manipuler l'interface dépend de cet utilisateur. Le travail de WordPress est de rendre l'interface accessible quelle que soit la modalité d'entrée choisie par cet utilisateur. Ce n'est ni nouveau ni controversé: c'est le fondement sur lequel repose le Web.

Je suis d'accord avec @ mor10. Compte tenu de la façon dont Automattic et l'équipe principale ont été investis dans le projet et rencontrent toujours des problèmes, la seule voie vraie et valable à suivre est d'avoir un audit objectif indépendant.

WordPress a une politique déclarée de respecter les directives d'accessibilité dans le noyau

Oui, exactement. Je voudrais que les responsables du projet w.org plus large - tels que @afercia et @rianrietveld -

En bref, je pense que Gutenberg _CAN_ sera accessible, mais je crains qu'il ne soit pas livrable dans son état actuel sur la base des 117 éléments ouverts dans le projet .

En espérant que cela puisse arriver!

Je soutiendrais pleinement un audit d'accessibilité externe et indépendant.

Comme vous l'avez mentionné, il y a des problèmes de perception qui, je pense, sont liés au manque de matériel et d'information concernant les tests par les utilisateurs, et plus particulièrement, les re-tests à mesure que le développement progressait. Au lieu de rechercher les résultats des utilisateurs, nous avons l'impression de rechercher des bogues et des régressions.

J'apprécie votre honnêteté et je conviens qu'un audit externe / indépendant serait précieux. Mais je crains que cela aborde rétroactivement l'accessibilité d'un point de vue technique (c'est-à-dire en cochant les cases pour WCAG 2.x / AA) au lieu de chercher à fournir une meilleure expérience à ceux qui n'utilisent peut-être pas de souris et de clavier. Pour la seule accessibilité, une recherche qualitative et quantitative de l'expérience de Gutenberg sans données relatives à l'expérience actuelle (ou, mieux encore, d'autres produits similaires) pourrait ne pas raconter une histoire juste.

Je pense que la transparence autour de ces informations serait longue avec le soutien de la communauté et soulagerait beaucoup de frictions, à la fois du point de vue de l'accessibilité et du déploiement plus large de Gutenberg.

Je ne suis pas surpris d'entendre que d'autres sont en faveur d'une vérification externe, ce qui serait formidable à faire. 👍 Je peux vous dire que j'adorerais cela aussi et que je chercherai des moyens de faciliter cela la semaine prochaine.

Y a-t-il des agences / entreprises spécialisées dans l'accessibilité impliquées dans WordPress qui seraient en mesure de prioriser leur temps pour exécuter un audit d'accessibilité du projet (probablement à partir de la version 4.0, qui est une grande version)? Je pense qu'il serait utile d'établir une idée de base de la façon dont Gutenberg se compare à l'éditeur classique.

Je suis sûr qu'il y aura des problèmes (comme mentionné ci-dessus, nous avons plus de 100 problèmes d'accessibilité) mais j'essaie d'avoir une vue macro de l'accessibilité à Gutenberg. Il convient de souligner que nous avons également plus de 100 problèmes étiquetés «bogues», mais c'est grâce à nous de ne considérer aucun bogue trop petit. Nous essayons de tout consigner, mais rappelez-vous que cela signifie 100 problèmes d'accessibilité, pas 100 blocs d'accessibilité. Les bloqueurs d'accessibilité (pour le moment) sont contenus dans le jalon de fusion auquel ce problème fait partie.

Merci à ceux qui ont ajouté leur voix pour soutenir un audit. Je vais fournir une liste des flux que nous voulons tester et assurer le travail des utilisateurs en tant que MVP - lorsque je le ferai, je les publierai ici mais je ne les ai pas encore entièrement formulés.

Un audit externe est une excellente idée. Je serais heureux de contribuer financièrement à l'embauche d'un cabinet qualifié pour effectuer cet audit.

Je contribuerais également financièrement, en particulier pour quelque chose de cette ampleur et de cette importance.

Je serais également disposé à montrer la voie pour aider à recueillir des fonds auprès de la communauté.

J'aime cette idée. Pour les entreprises qui exigent la conformité WCAG dans leurs logiciels, un audit peut contribuer grandement à dissiper les inquiétudes. La génération d'un VPAT à partir d'un audit peut également contribuer à l'adoption par les organisations qui en ont besoin dans le cadre de leur processus contractuel. Voir Intégration de l'accessibilité dans les contrats des fournisseurs de technologie pour plus d'informations.

Je soutiens également un audit d'accessibilité externe et indépendant. Je vais vérifier les excellentes ressources de mon travail quotidien et voir ce qu'elles recommandent. :)

C'est très gentil! Mais nous ne cherchons pas de contributions financières de la communauté. Je vais contacter des auditeurs d'accessibilité et voir comment les amener à exécuter des audits sur Gutenberg.

Je vais voir quels types de coûts et de délais sont impliqués, mais si nous pouvons obtenir quelque chose à un prix raisonnable avec un calendrier qui fonctionnera pour 5,0, je devrais être en mesure d'obtenir Automattic pour couvrir le coût. 😊

J'étais un peu incertain du soutien financier que je pourrais fournir d'Automattic lorsque j'ai posté un commentaire précédent et je n'étais pas un peu clair sur les attentes de la communauté: désolé! J'ai mis à jour le commentaire et clarifié ce que je ne cherchais pas. En ce moment, je vais voir comment organiser des audits, il me faudra probablement quelques jours au moins pour débattre les devis! Je ferai un rapport une fois que j'en saurai plus 😊

Je sais que ce n'est peut-être pas le lieu de le dire, mais mon entreprise effectue des audits d'accessibilité. Alors faites-moi savoir si vous voulez en savoir plus. Bien que je ne sois pas si actif récemment, je suis impliqué dans WordPress depuis un certain temps et j'ai contribué des idées d'accessibilité à Gutenberg ainsi qu'à d'autres parties de WP. Si je ne suis pas assez indépendant, je travaille avec un partenaire de confiance qui n'a jamais utilisé WordPress.

@tofumatt Je pense qu'une demande de propositions serait un bon moyen d'indiquer exactement ce que recherche un audit et de donner aux prestataires de services l'occasion de donner un aperçu général de la façon dont ils procéderaient. Existe-t-il un précédent pour ce type de processus chez Automattic?

Bonjour, je suis le coordinateur de l'accessibilité informatique pour la NC State University. Nous utilisons WordPress pour nos sites Web de campus et en tant qu'institution publique, nous sommes tenus de suivre la section 508 de la loi sur la réadaptation de 1973. Pour cette raison, nos outils de création comme WordPress doivent être accessibles aux personnes handicapées.

Nous avons une grande variété d'utilisateurs de WordPress, y compris des étudiants, des professeurs et du personnel qui utilisent des blogs WordPress et éditent des sites WordPress au nom de leurs départements de leurs organisations. Tout cela pour dire, WordPress doit être accessible à ces personnes.

En tant qu'institution d'enseignement supérieur, nous voulons rester à jour avec les nouveaux programmes et technologies. Il serait préjudiciable pour nous de ne pas pouvoir progresser et utiliser Gutenberg ou de faire une situation "séparée par égal" où les personnes handicapées sont limitées à utiliser l'éditeur classique alors que les personnes valides peuvent Gutenberg.

C'est tellement génial à entendre 👍

Je suis entièrement d'accord! Bien sûr, je souhaite définir clairement qu'il peut y avoir des problèmes d'accessibilité que nous découvrons (ou dont nous avons peut-être connaissance) que nous ne sommes pas en mesure de résoudre avant la sortie de WordPress 5.0.

Il existe de nombreux sites, pour de nombreuses raisons, qui voudront / devront utiliser le plugin Classic Editor pendant une durée limitée tandis que Gutenberg - ou les plugins extérieurs - sont améliorés. Il y aura probablement des utilisateurs qui rencontreront des problèmes d'accessibilité - ainsi qu'une foule d'autres problèmes - qui nécessitent le plugin Classic pendant quelques semaines / mois pendant que nous améliorons notre logiciel.

Je veux que l'avenir de l'éditeur WordPress soit génial et accessible à tous. Mes excuses à l'avance pour les utilisateurs qui sont tombés entre les mailles du filet au début, pour une raison quelconque. Mais sachez que nous travaillerons pour rendre Gutenberg et WordPress géniaux pour eux aussi, même si cela ne se produit pas tout de suite . ❤️

Concernant l'audit

Salut à tous! Je suis encore un peu nouveau en tant que responsable de publication et je viens de près d'une décennie à travailler sur le projet @mozilla où nous avons aussi beaucoup travaillé à l'air libre, les faux pas et tout. Je serai aussi transparent que possible sur ce qui se passe, y compris en essayant de fournir des mises à jour en temps opportun (d'où mon incertitude quant à la possibilité de payer pour des audits d'accessibilité jusqu'à ce que je vérifie avec certaines personnes).

Le type d'audit que je cherche à faire n'est peut- être rien de trop légal / spécifique à la conformité, car je cherche d'abord à avoir une idée générale de l'utilisabilité de WordPress par les utilisateurs ayant des besoins d'accessibilité. Si cela inclut des éléments de conformité: génial.

En ce moment, j'ai été en contact avec des membres de la communauté @WordPress Accessibility et des employés @automattic bien

J'ai quelques personnes en tête maintenant etva leur tendre la main J'ai contacté plusieurs entreprises spécialisées dans les audits d'accessibilité. Je publierai des mises à jour ici, mais je n'en saurai plus avant la semaine prochaine. Pour l'instant, il y a:

1. pas besoin d'offrir un soutien financier (mais OMG merci beaucoup à ceux qui l'ont fait, c'est super cool de voir votre engagement envers WordPress)
2. pas besoin d'offrir vos services (je pense que nous voulons quelqu'un en dehors de l'écosystème WordPress, mais si vous voulez aider avec des tests de bogues / d'accessibilité réguliers , faites-le! )
3. beaucoup ❤️ de ma part 🙂

Passez un bon week-end, je vous tiendrai tous au courant! 😄

Si vous recherchez d'autres fournisseurs pour l'audit, je recommande WebAIM à l'Utah State University, qui est généralement considérée comme l'une des meilleures ressources Web aux États-Unis. Je ne suis pas affilié à eux d'autre que la lecture de leur incroyable documentation Web, mais j'ai vu qu'ils proposent des audits.

Bien que WordPress lui-même soit open source et ait encore beaucoup de travail bénévole, il a également frappé le «grand moment», et ne peut plus se permettre de se rabattre sur la béquille «Mais nous sommes juste open source». Je pense qu'un audit d'accessibilité complet et l'engagement d'améliorer là où WP fait défaut (pas seulement Gutenberg) seraient une excellente source de progrès en ce qui concerne l'adoption de WP. Et bien sûr, démocratiser l'édition, et tout ça.

Il existe de nombreux sites, pour de nombreuses raisons, qui voudront / devront utiliser le plugin Classic Editor pendant une durée limitée tandis que Gutenberg - ou les plugins extérieurs - sont améliorés. Il y aura probablement des utilisateurs qui rencontreront des problèmes d'accessibilité - ainsi qu'une foule d'autres problèmes - qui nécessitent le plugin Classic pendant quelques semaines / mois pendant que nous améliorons notre logiciel.

Ce sentiment est tout simplement inacceptable pour moi et j'espère que beaucoup d'autres ont intériorisé les valeurs de WordPress ...

Mes excuses à l'avance pour les utilisateurs qui sont tombés entre les mailles du filet au début, pour une raison quelconque. Mais sachez que nous travaillerons pour rendre Gutenberg et WordPress géniaux pour eux aussi, même si cela ne se produit pas tout de suite. ❤️

Quel est l'avantage de faire vivre une expérience qui n'est pas à la hauteur de tout le reste de Core? Les délais ne sont pas arbitraires, mais cela ne signifie pas que vous coupez les coins ronds. Du moins pas selon les valeurs de WordPress telles que je les comprends. Ces valeurs sont probablement distinctes de tout ce que Mozilla avait, en tant que nouveau venu dans la communauté, je vous encourage à les examiner.

En général, le sentiment que travailler principalement sera suffisant crée des risques inutiles pour la communauté, et il faut se demander à qui en profite. Quel est l'avantage du projet Gutenberg ou de WordPress? Ce n'est pas comme si nous avions besoin d'aide pour identifier les problèmes.

Étant donné qu'Automattic sponsorisera et concevra apparemment les paramètres de cet audit, il y a une apparence potentielle de biais et qu'ils notent leur propre travail. Je propose que la plus grande communauté procède au financement participatif pour embaucher un spécialiste de l'accessibilité pour un rapport parallèle du point de vue des utilisateurs réels. Peut-être qu'Automattic peut faire un audit technique ou autre, mais la suggestion que l'accessibilité de Gutenberg n'est «pas si mauvaise» a été vivement désapprouvée par de vrais experts dans ce domaine (à savoir, Sina Braham chez WordCamp Publishers). Nous avons peut-être besoin de quelque chose de plus proche d'un test Mikey où nous permettons aux utilisateurs aveugles de naviguer dans l'application et de dire s'ils l'utiliseront à nouveau.

C'est ce que j'ai envoyé aux entreprises que j'ai approchées pour ce travail, d'ailleurs. Cela peut aider d'autres personnes impliquées dans l'accessibilité, je ne suis pas sûr. Au moins, je le poste ici pour plus de transparence 🙂

Exigences

Une série de tests d'accessibilité à effectuer à l'aide de l'éditeur Gutenberg sur un site Web WordPress à l'aide de WP-Admin. Ces tests doivent inclure, au minimum, les flux de test suivants:

Flux de publication de base

• Créer un nouveau message
• Ajouter du contenu commun (paragraphe, image, liste, HTML et contenu de tableau; voir «Utiliser des blocs» ci-dessous)
• Publiez un message immédiatement et le message est fait comme prévu
• Planifiez une publication pour l'avenir à l'aide du sélecteur de dates
• Attribuer des catégories et des balises à publier
• Attribuer une image sélectionnée à un message
• Expérimentez avec d'autres paramètres au niveau du document, si le temps le permet

Utiliser des blocs

Ce sont les vingt blocs les plus utilisés sur WordPress.com et doivent être testés pour trouver tous les problèmes d'accessibilité qui ne sont pas déjà répertoriés dans notre liste de problèmes d'accessibilité :

1. paragraphe
2. image
3. titre
4. liste
5. Galerie
6. citation
7. intégrer / youtube
8. html
9. séparateur
10. plus
11. Image de couverture
12. petit code
13. bouton
14. table
15. espaceur
16. intégrer
17. bloquer
18. intégrer / twitter
19. Colonnes
20. code

Ces blocs doivent être testés avec des technologies d'assistance pour s'assurer qu'il n'y a pas de bloqueurs à leur utilisation et que leurs paramètres au niveau des blocs sont accessibles.

Éditeur classique

Nous devons vérifier que, par rapport à l'éditeur classique, il n'y a pas de régressions notables en matière d'accessibilité. Créer une publication avec le même type de contenu que l'on peut créer dans un contexte de l'éditeur classique barebones devrait être faisable avec Gutenberg. Gutenberg n'ayant aucune régression dans l'expérience d'édition par rapport à l'éditeur classique est mon objectif ultime pour dire que nous pouvons le recommander comme expérience d'édition par défaut pour les utilisateurs de technologies d'assistance.

Technologies d'assistance à considérer

En raison de la chronologie limitée disponible et de la priorisation de la capacité d'action par rapport à une extrême minutie, je préférerais que les combinaisons de deux à trois principaux navigateurs + lecteur d'écran soient utilisées pour les tests . En utiliser plus si le temps le permet est absolument accessible, mais je préférerais commencer par les combinaisons les plus utilisées. D'après ma compréhension, c'est:

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

La technologie d'assistance mobile n'est pas une priorité pour cet audit. Les tests VoiceOver sur MacOS devraient, espérons-le, inclure des croisements avec les utilisateurs iOS VoiceOver. L'utilisation des applications mobiles est vraisemblablement plus une priorité que l'utilisation du site Web.

Publier le rapport et les problèmes à l'air libre

Nous nous attendons à ce que tout rapport d'accessibilité généré soit publié ouvertement sur la communauté WordPress et ne devrait pas exiger de moi (ou de tout autre Automattician) en tant que gardien. Les problèmes doivent être publiés avec un contexte utile sur GitHub, en mettant l'accent sur la cause du problème et la reproductibilité. Des solutions ou des approches de correctifs peuvent être publiées s'il y a du temps dans la portée ou si le problème est particulièrement complexe.

@davisshaver Bonjour, et je suis totalement d'accord avec vous. Un audit approfondi et impartial est essentiel pour garantir que le niveau maximum de tout est respecté.

Non seulement il est important de s'assurer que l'éditeur est accessible, mais qu'il existe également une base en place pour garantir que les modifications apportées à l'éditeur peuvent également être facilement rendues accessibles. De toute évidence, nous ne pouvons pas imposer ce que les gens font seuls, mais nous pouvons au moins fournir aux gens une base à mettre en œuvre qui soit accessible.

@tofumatt Aussi heureux de vous aider de toutes les manières possibles. J'ai peut-être accès à de très bonnes ressources pour les tests, en particulier à d'autres avec l'expérience React et a11y. Il y a aussi des personnes dans mon équipe qui travaillent spécifiquement avec tout le monde au quotidien.

@tofumatt Merci pour la mise à jour. J'ai quelques questions complémentaires:

1) Le plan de vérification doit-il être terminé avant la publication de la version 5.0?
2) Si l'audit renvoie des problèmes, quel est le plan pour les résoudre? La version 5.0 sera-t-elle retardée jusqu'à ce qu'ils soient traités?
3) Des plans sont-ils en cours d'élaboration pour la manière dont le projet testera l'accessibilité à l'avenir?

@tofumatt Si vous voulez des tests par des utilisateurs ayant une variété de handicaps / déficiences, j'ai travaillé avec une société appelée Hassell Inclusion, et ils peuvent organiser ce genre de tests. Ils sont complètement supprimés de la communauté WordPress. La société est dirigée par Jonathan Hassell qui était auparavant en charge de l'accessibilité à la BBC.

@tofumatt Je suis également très préoccupé par l'accessibilité de WordPress et désireux de vous aider à réussir. Je peux demander à notre organisation de réaliser un audit d'accessibilité complet conforme aux WCAG-EM au niveau standard que vous préférez, y compris des tests techniques et fonctionnels, et de faire don de la partie du travail dont vous avez besoin pour s'adapter à votre budget.

Je pense que nous devrions examiner à la fois ATAG et WCAG AA, et peut-être WCAG 2.1 plutôt que 2.0. Nous pourrions également vous fournir des recommandations et un encadrement pour vous aider à choisir le moyen le meilleur et le plus durable pour combler les lacunes découvertes.

Nous sommes commodément indépendants de votre communauté de développement, mais connaissons bien WordPress depuis de nombreuses années. Je suis titulaire de toutes les certifications IAAP et j'ai mené des dizaines d'audits de ce type sur la plateforme WordPress, pendant de nombreuses années, pour le secteur privé et public. Veuillez consulter notre bonne foi sur davidberman.com/about pour décider de la meilleure façon de vous aider.

Utiliser des blocs

Je ne suis pas sûr que l'équipe qui effectuera la vérification devrait recevoir des instructions ou savoir ce qu'est un «blocage», du moins pas au départ. Ils doivent être dans le même état initial que les utilisateurs qui utiliseront Gutenberg pour la première fois, sans instructions spéciales. Dans un second temps, en passant à la technique, ils sauront probablement déjà ce qu'est un bloc 🙂

Flux de publication de base

L'équipe d'accessibilité convient que le principal problème d'accessibilité à Gutenberg est l'expérience utilisateur globale. Je suggérerais d'élargir cette partie: elle ne devrait pas être limitée au flux _publihsing_, mais plutôt inclure plus de tâches, généralement celles qui nécessitent de naviguer dans l'interface utilisateur et de parcourir les sections principales (barre supérieure, zone d'édition, barre latérale , publier le panneau). Ceci est plus lié à la conception générale de Gutenberg, plutôt qu'aux détails techniques de mise en œuvre sur les différents composants. En fait, l'accessibilité est une conception.

Je voudrais proposer quelques tâches:

• construire un poteau avec un grand nombre de blocs, disons 20 au minimum
• modifier l'un des paragraphes au milieu du message
• changer sa taille et sa couleur de police, puis modifier à nouveau son contenu
• ajouter de nouveaux blocs à l'aide des inserteurs
• insérer un lien
• insérer une mention
• changer le type de bloc
• modifier quelque chose dans les paramètres de la barre supérieure, puis revenir au bloc qui a été modifié
• passez à la barre latérale, passez aux paramètres du document / bloc, puis revenez au bloc qui a été modifié
• modifier le permalien de l'article
• faire un bloc réutilisable
• ajouter et modifier un bloc réutilisable existant

Technologies d'assistance à considérer

@tofumatt Je suis un peu surpris que vous mentionniez uniquement les technologies d'assistance et, en particulier, uniquement les lecteurs d'écran. Les évaluations d'accessibilité ne peuvent pas être limitées aux seuls tests de lecteurs d'écran. L'accessibilité est un sujet bien plus large et ne se limite pas aux handicaps ou aux déficiences. Il s'agit de rendre le Web accessible à tous.

Même si nous voulons limiter l'accessibilité aux handicaps et aux déficiences, ils sont trop nombreux pour être comptés. Pour n'en nommer que quelques-uns: utilisateurs de logiciels de reconnaissance vocale, handicaps moteurs, basse vision, déficiences cognitives, troubles épileptiques, dispositifs d'entrée alternatifs, trouble d'hyperactivité avec déficit de l'attention, dyslexie, perte de mémoire à court terme, etc., etc. ne peuvent pas être classés comme de véritables «handicaps», par exemple des déficiences temporaires, des atteintes à l'environnement, le vieillissement?

La condition humaine est assez instable, et je vous suggère de considérer que nous sommes tous temporairement capables.

Je voudrais proposer quelques tâches:

Cette liste de tâches étendue semble bonne et réaliste ce que les utilisateurs doivent faire.

Comme l'état des normes d'accessibilité pour le noyau de WordPress :

Tout code nouveau ou mis à jour publié dans WordPress doit être conforme aux directives WCAG 2.0 au niveau AA.

Par conséquent, l'audit devrait en tenir compte. Des choses spécifiques:

1) Toutes les fonctionnalités devraient fonctionner comme prévu lorsque le navigateur est zoomé à 200% (notez que cela peut déclencher le CSS mobile) 1.4.4
2) Toutes les fonctionnalités doivent fonctionner comme prévu uniquement en utilisant un clavier 2.1

Il est important pour nous de nous rappeler que ce que nous recherchons ici, c'est que tout est utilisable par tous les utilisateurs. Ce n'est peut-être pas une expérience formidable pour certains utilisateurs, c'est le sujet de la version 1, mais les normes que nous avons visent à nous assurer qu'elle est complètement utilisable. Tous les logiciels sont livrés avec des bogues et l'important est que nous connaissions les bogues et que nous faisions le compromis entre les corriger et ne pas les corriger.

Merci @tofumatt d' avoir mené la charge dans la réalisation de cet audit. J'ai hâte de voir cela se produire et que Gutenberg soit utilisable par tous.

Il a été utile, lors de l'examen d'un audit / d'une série de tests d'accessibilité, de compiler une liste des fonctionnalités "principales" de l'éditeur classique qui ne devraient pas régresser dans le nouvel éditeur:

1. Création / édition de texte de paragraphe
2. Création / édition de texte de titre
3. Création / édition de texte pré-formaté
4. Création / édition de liste à puces
5. Création / édition de liste numérotée
6. Création / édition d'un devis ("Blockquote")
7. Alignement du texte pour les paragraphes et les en-têtes
8. Ajout, modification et suppression de liens du texte dans les paragraphes, les en-têtes et les éléments de liste
9. Mise en retrait / déduction des listes / éléments de liste
10. Gras / italique / barré du texte dans les paragraphes, les en-têtes et les éléments de liste
11. Ajout d'une ligne horizontale / d'un espaceur au contenu
12. Défaire refaire
13. Insertion du commentaire WordPress "Lire la suite" (Lire la suite Bloc dans Gutenberg)
14. Conversion de contenu de paragraphe en contenu de liste
15. Conversion du contenu de la liste en contenu de paragraphe

Je pense que c'est ça, donc c'est ce que j'ai envoyé.

Ma liste de technologies accessibles était assez minime, d'accord. Une partie de cela concerne la portée, mais une partie était due au fait que c'était un peu une liste incomplète que j'espérais ajouter avec le temps. J'ai ajouté ZoomText à cette liste et je demanderai également qu'il soit utilisé pour les tests.

Je viens de liste des tâches de

Répondre à quelques questions

@bamadesigner :

Le plan, pour le moment, est de démarrer l'audit dès que possible et d'avoir autant d'informations avant la version 5.0 pour résoudre tous les problèmes détectés et ajouter du contexte à la version concernant son accessibilité. Pour ce qui est de retarder la sortie: cela dépend du problème, du temps pour le résoudre et de son impact. À mon avis, il est peu probable de retarder la publication, mais nous devrions franchir ce pont lorsque nous y arriverons; Je ne veux pas spéculer.

En termes de plans pour les tests d'accessibilité à venir: c'est une question plus importante et non liée à la version ou à ce problème, donc je ne vais pas y entrer ici. Pour l'instant, je suis responsable de la version 5.0 et je vais me concentrer là-dessus; encore une fois: je ne veux pas spéculer. Mais c'est quelque chose que je suis heureux d'examiner après avoir repris notre souffle de WordPress 5.0 😄

@LukePettway

Si vous avez de l'expérience dans les tests d'accessibilité, il serait bon que vous testiez Gutenberg ou que vous triiez les problèmes d'accessibilité existants afin que nous sachions ce qui reste un problème et ce qui doit être ciblé. Travailler sur tous les problèmes du jalon Merge: Accessibility serait également formidable.

@tofumatt Merci pour vos réponses mais elles sont décevantes.

Gutenberg / 5.0 ne doit pas être publié tant que l'audit n'est pas terminé et que les problèmes détectés ne sont pas résolus. Espérons que l'audit revienne et indique qu'il n'y a que quelques problèmes, mais la décision devrait être que la publication de 5.0 dépend de cette constatation et du temps nécessaire pour résoudre.

Je ne suis pas au courant de ce qui motive cette date limite de novembre, mais l'accessibilité est trop importante. Si vous lancez avant de vous assurer que ces bases sont couvertes, vous créez un dangereux précédent pour toute la communauté, et le Web en général, que l'accessibilité n'est pas la priorité n ° 1 et que vous pouvez attendre plus tard.

WordPress 5.0 n'est pas prêt tant qu'il n'est pas accessible. Aucune autre date limite n'a plus d'importance. Sans parler du fait qu'il viole les normes fondamentales d'accessibilité.

WordPress 5.0 n'est pas prêt tant qu'il n'est pas accessible.

@bamadesigner dit la vérité.

L'objectif déclaré de WordPress est de «démocratiser l'édition». Cela signifie, au sens littéral, rendre la publication accessible à tous. L'accessibilité est au cœur de cette promesse.

J'espère que ce n'est pas une équivoque de dire qu'un objectif et une promesse ne sont pas les mêmes et ne devraient pas être traités comme tels. 😄

Comme mentionné précédemment, je salue vivement toutes les contributions extérieures sur les problèmes d'accessibilité et en particulier celles trouvées dans le jalon Merge: Accessibility (
https://github.com/WordPress/gutenberg/milestone/43).

S'il est déterminé qu'il y a des problèmes d'accessibilité lors de la sortie, je suis à l'aise de revoir la suggestion de @rianrietveld dans Trac pour avertir les utilisateurs de la technologie d'assistance des problèmes spécifiques avec Gutenberg et leur suggérer d'utiliser l'éditeur classique si Gutenberg les présentera avec problèmes d'utilisabilité. Je voudrais mettre en évidence des problèmes spécifiques et connus et qui ils affectent.

Je ne suis pas vraiment sûr que ce soit mon appel dans tous les cas, mais même si c'était le cas: je ne considère pas cela comme une bonne décision de retarder la version 5.0 pour des problèmes d'accessibilité lorsque l'éditeur classique existe comme solution de secours . Le but / caractéristique principale de 5.0 est Gutenberg, la nouvelle expérience d'édition. Je préfère le publier pour les utilisateurs qui le trouveront utilisable (ce qui devrait inclure de nombreux utilisateurs de technologies d'assistance, mais pas tous), et accepter que tout le monde ne puisse pas utiliser Gutenberg le premier jour. C'est déjà la réalité pour beaucoup utilisant des plugins incompatibles. Personne n'oblige quiconque à utiliser Gutenberg lors du lancement de la version 5.0 🙂

L'éditeur classique existe, mais il ne fait

Super-bon point @joedolson , un que je n'avais pas envisagé - et la messagerie d'appel ne l'avait probablement pas non plus. Merci pour ça.

Je préfère le publier pour les utilisateurs qui le trouveront utilisable (ce qui devrait inclure de nombreux utilisateurs de technologies d'assistance, mais pas tous), et accepter que tout le monde ne puisse pas utiliser Gutenberg le premier jour.

C'est un commentaire incroyablement décevant, et cette position est au mieux mauvaise conception et au pire activement capable. J'espère vraiment que ce n'est pas la solution.

@tofumatt J'apprécie que vous

Je ne suis pas vraiment sûr que ce soit mon appel dans tous les cas, mais même si c'était le cas: je ne considère pas cela comme une bonne décision de retarder la version 5.0 pour des problèmes d'accessibilité lorsque l'éditeur classique existe en tant que solution de secours. Le but / caractéristique principale de 5.0 est Gutenberg, la nouvelle expérience d'édition. Je préfère le publier pour les utilisateurs qui le trouveront utilisable (ce qui devrait inclure de nombreux utilisateurs de technologies d'assistance, mais pas tous), et accepter que tout le monde ne puisse pas utiliser Gutenberg le premier jour.

Vous dites à une population d'utilisateurs déjà marginalisée que vous vous efforcerez de rendre WordPress utilisable pour eux ... éventuellement. Vous voyez à quel point c'est aliénant, non?

Mais peut-être que l'ensemble de questions le plus important est celui-ci:

• À qui appartient-il de décider si le nouvel éditeur est officiellement prêt à être fusionné dans le noyau?
• Quels facteurs envisagent-ils pour prendre cette décision?
• Que devons-nous, en tant que communauté, faire pour placer l'accessibilité au cœur de ce processus décisionnel?

@tofumatt pour clarifier: l'équipe d'accessibilité n'a pas demandé de retarder la sortie. La seule demande officielle a été d'ajouter un avis pour les utilisateurs ayant des besoins d'accessibilité, de les informer des problèmes à résoudre, de les inviter à essayer Gutenberg mais de recommander l'éditeur classique. La proposition était dans https://core.trac.wordpress.org/ticket/44671 qui a été fermée 🙁

Je préfère le publier pour les utilisateurs qui le trouveront utilisable (ce qui devrait inclure de nombreux utilisateurs de technologies d'assistance, mais pas tous), et accepter que tout le monde ne puisse pas utiliser Gutenberg le premier jour.

Cool, génial, grand capacitisme ici. Comme l'a dit @briandeconinck , vous

@afercia Oh, je le sais totalement! Je ne voulais certainement pas laisser entendre que la position de l'équipe d'accessibilité était de retarder la publication; certaines personnes dans les commentaires ici posaient des questions à ce sujet, c'est tout. Je suis vraiment désolé si je me suis mal exprimé et que je mets cela sur l'équipe. ❤️

Ce problème a été résolu (en partie parce qu'il s'agit de l'appel "try" qui disparaît, il y a peut-être eu une mauvaise communication au sujet de son intention), mais comme mentionné ici: je suis d'accord avec la mise en œuvre de son concept d'avertissement aux utilisateurs d'assistance technologies si Gutenberg ne fonctionne pas pour eux.

Je suis d'accord avec les autres dans ce fil de discussion pour une meilleure accessibilité avant la version 5.0. J'ajouterais également que la sortie de 5.0 sera interprétée comme un feu vert par le reste de l'écosystème WP que Gutenberg est prêt pour une utilisation dans le monde réel. À ce stade, nous verrons un afflux de plugins et de thèmes qui étendent Gutenberg et s'appuient sur les normes qu'il propose comme modèle pour leur propre développement.

En tant que développeur dans l'écosystème WP depuis plusieurs années, je me tourne constamment vers le cœur de WordPress pour m'assurer que l'accessibilité, les styles et le comportement de mes propres plugins s'alignent sur ceux du cœur. Si la version 5.0 est publiée avant que les problèmes d'accessibilité ne soient résolus, la communauté WordPress recherchera un plan inaccessible comme modèle pour son propre développement. Assurons-nous que le plan répond aux normes que nous avons fixées pour tout ce qui est arrivé auparavant.

@tofumatt Suggérez -vous que mettre en place un avertissement disant que les technologies d'assistance ne fonctionneront pas avec Gutenberg est une solution raisonnable, étant donné que l'éditeur principal deviendra un plugin qui doit être installé couplé au fait que l'utilisateur peut la capacité / la connaissance d'installer ce plugin? J'espère que je comprends mal cela, pouvez-vous clarifier s'il vous plaît?

Comme toujours, merci pour votre temps!

Le plugin Classic Editor a été conçu comme une sortie temporaire pour ceux qui ne sont pas prêts à passer à Gutenberg. Il est au mieux dix et va rapidement devenir un problème pour les développeurs qui devront apporter des solutions à deux éditeurs différents. Le plugin Classic Editor ne peut même pas être une sortie temporaire pour les personnes ayant des besoins d'accessibilité, car il sert littéralement une expérience inférieure basée sur le handicap. La configuration minimale requise pour l'administrateur WordPress est WCAG 2.0 AA. Tout le reste, y compris un plugin pour dégrader l'expérience, va à l'encontre de nos propres politiques. Je prends une ligne dure à ce sujet parce que nous avons des règles. Nous n'expédions pas de code qui ne respecte pas nos propres normes de conding. L'accessibilité ne devrait pas être différente.

Comme beaucoup d'autres ici, j'apprécie les efforts de la communauté et des gens qui consacrent leur temps et leurs efforts à Gutenberg pour le rendre accessible et prêt pour la version 5.0. Simplement, Gutenberg n'est pas prêt car il n'est pas entièrement accessible. Fin de l'histoire.

Tant que Gutenberg n'est pas accessible, il ne doit

J'espère que la communauté l'emportera et convaincra l'équipe principale de ne pas publier la version 5.0 jusqu'à ce qu'elle soit pleinement accessible. À cette fin, un audit indépendant est une bonne idée et doit être poursuivi.

Ce numéro a été déposé pour faire connaître mon travail sur l'audit d'accessibilité, pour communiquer que j'aimerais que cela se produise et pour suivre le partage de cet audit dans un article de blog. Il ne s'agit pas d'un point de discussion sur ce qui devrait être considéré comme un bloqueur de publication pour WordPress 5.0. J'ai noté les opinions des gens à ce sujet et je les transmettrai à @m , qui est le responsable de la publication de WordPress 5.0. Ma compréhension est:

1. Je n'ai pas de veto sur la livraison 5.0, mais même si je l'ai fait:
2. Je ne suis toujours pas convaincu qu'il existe suffisamment de problèmes d'accessibilité qui empêchent une publication

Si le deuxième point change, je relayerai cette information. Je prévois d'être un défenseur, mais je ne fixe pas les délais et je n'ai pas non plus de données solides sur l'accessibilité. C'est le but de l'audit: afin que nous puissions parler d'un lieu de données concrètes. 🙂

Merci pour toutes vos contributions, mais comme cette discussion est devenue assez hors sujet par rapport à sa portée prévue, je verrouille la conversation de ce problème pour le moment. Je vais le laisser ouvert et publier des mises à jour concernant l'audit.

Il y a eu quelques discussions supplémentaires sur ce problème sur Slack: https://wordpress.slack.com/archives/C02RP4X03/p1539300688000100

Je pense que cela valait la peine d'être abordé ici afin que tous ceux qui ont suivi le problème jusqu'à présent puissent être informés de ce qui se passe. @ mor10 a également souligné qu'il estimait que les résultats de l'audit n'étaient pas clairement communiqués. Il semble qu'il y ait eu beaucoup de malentendus autour de ma communication dans cet article: je m'en excuse. Je vais essayer de répondre aux choses du mieux que je peux pour le moment.

Je pense qu'une grande partie de la confusion dans le ticket fermé provient d'un manque de clarté sur ce qui se passe si / quand un audit ne peut pas être terminé à temps pour le calendrier de publication ou qu'un audit revient signalant des problèmes substantiels à résoudre. D'après vos commentaires, il n'est pas clair si vous pensez:

• a) tous les problèmes seront résolus dans le délai actuel
• b) tout problème qui ne peut pas être résolu dans le délai sera repoussé à 5.0.1
• c) si des problèmes importants sont soulevés, le calendrier sera modifié.

Ce que vous avez dit jusqu'à présent _semble_ indiquer seulement a ou b sont des options, mais comme je l'ai dit, ce n'est pas clair. L'idée que l'accessibilité soit forcée de respecter une date limite de publication est ce qui inquiète les gens depuis plus d'un an, et ces préoccupations n'ont pas été atténuées.

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

Sur la base des problèmes actuels du Milestone, mon objectif est de résoudre tous les problèmes, mais je ne pense pas qu'ils constituent tous des bloqueurs de publication. Je saurai mieux comment les trier plus près du marquage final, je ne peux donc pas ajouter grand-chose à cela maintenant. Pour l'instant, je pense qu'il s'agit d'une liste réaliste de problèmes qui sont les plus importants avant la version 5.0

Les problèmes qui ne peuvent pas être résolus doivent être déplacés vers la prochaine version de WordPress / Gutenberg, oui.

Je ne pense pas qu'il y ait quoi que ce soit là-dedans actuellement qui justifie de retarder la sortie.

Ce problème a été verrouillé car mon objectif en créant ce problème était:

1. pour partager mon travail en commandite un audit
2. pour partager mon travail en créant un article de blog sur Make / Accessibility autour de cet article

J'apprécie les commentaires sur la façon dont l'audit pourrait être mené et aussi pour entendre les problèmes entourant ma recommandation de «sauvegarde» de l'éditeur classique si l'accessibilité finit par être un problème sérieux dans Gutenberg. Il convient de noter à l'heure actuelle qu'il n'y a aucun rapport à signaler qui évalue Gutenberg et le déconseille pour des raisons d'accessibilité. Je ne l'ai pas vu, et personne n'est lié à un ici. Le sentiment ici est autour des échecs spéculatifs. Ce genre de langage est démotivant pour les développeurs de Gutenberg qui travaillent dur et voient un manque de bonne intention supposée.

Le rôle de responsable de la publication de l'accessibilité est nouveau et il m'a été demandé la semaine dernière . Dans le même temps, une date de sortie du 19 novembre 2018 a été finalisée . Mon premier instinct après avoir été assigné au rôle de responsable de la publication a été d'essayer de dépenser l'argent d'Automattic pour créer un audit comme un signe de notre engagement en matière d'accessibilité, et de créer une idée concrète des problèmes réels auxquels Gutenberg est confronté en termes de travail avec la technologie d'assistance. Je travaille sur un calendrier limité et partage des informations comme je le peux et le cas échéant, avec la mise en garde que je ne veux pas évaluer publiquement les entreprises avec lesquelles je suis en discussion (je considère que ce n'est pas professionnel) et je dois trier les le côté achats des choses avec Automattic (cet aspect de cet audit ne peut pas être public, pour autant que je sache).

Je ne suis pas le dernier mot dans un communiqué. J'ai cc'd @m sur ce problème; il est le responsable de la publication et il appelle à retarder la publication en raison de problèmes d'accessibilité. Ce ne serait personnellement pas ma recommandation de retarder la publication en fonction des problèmes connus actuels, même dans les limites du jalon.

Oui, il y a un plus gros problème de conception accessible dans l'ensemble, mais les équipes de développement et de conception prennent en compte ces problèmes. Je suis davantage préoccupé par les choses que nous reconnaissons et testons moins parce que nous sommes en grande partie une équipe d'utilisateurs assez compétents.

Certaines personnes de Slack m'ont fait part de leur observation selon laquelle la question semblait solliciter des commentaires et une discussion plus large. Ce n'était pas mon intention en déposant ce numéro, mais simplement de garder tout au grand jour; puisque GitHub est principalement l'endroit où nous travaillons sur ce projet, j'ai pensé que ce serait le meilleur endroit pour le faire. J'ai verrouillé le problème car la discussion, bien que peut-être valable pour le projet dans son ensemble, était distrayante pour:

1. le problème en question (et un audit et un article de blog avec les résultats)
2. l'équipe dans son ensemble qui est notifiée par les commentaires sur les problèmes

Les commentaires sur les problèmes doivent être exploitables, discrets et, espérons-le, fournir de nouvelles informations. J'ai eu le sentiment que les commentaires ici ne répondaient pas à ces critères, je voulais donc limiter la discussion à la question à l'étude.

J'ai déposé ce problème dans le jalon car j'aimerais que cela se produise pour WordPress 5.0. Si ce n'est pas possible, le triste résultat est qu'il devra être déplacé. Je fais de mon mieux pour travailler dans un délai limité avec des ressources limitées. Je ne souhaite pas que les "correctifs accueillent" tout le monde, mais si l'accessibilité est importante pour vous, je vous serais reconnaissant de bien vouloir attirer votre attention sur notre liste de problèmes d'accessibilité ouverts , en particulier ceux de la liste Milestone: Accessibility .

Je voudrais garder ce problème ouvert parce que je veux suivre mes progrès avec l'audit. Si vous souhaitez avoir d'autres discussions liées à l'accessibilité, le bouton "Nouveau problème" est toujours présent. Je remarque en écrivant ce commentaire qu'un nouveau numéro a déjà été déposé (# 10537): c'est cool 😄

Merci à tous et bon vendredi. ❤️

@tofumatt Pouvez-vous mettre à jour les informations sur l'audit?

La première chose à faire: j'ai parlé à plusieurs entreprises au cours de la semaine dernière au sujet de la réalisation d'un audit et j'ai reçu des propositions de leur part.

Je dirai que j'ai reçu des propositions assez détaillées de:

• Accès au niveau
• Systèmes Deque

Et des réponses moins détaillées mais toujours excellentes de:

• Le groupe Paciello
• Heydon Pickering

Ils semblaient tous connaître leurs affaires. Je ne vais pas partager les détails des propositions parce que je ne pense pas que ce soit approprié, mais j'ai de mauvaises nouvelles sur le front de la vérification. 😢

Au moins pour le moment, Automattic a décidé de renoncer à effectuer un audit d'accessibilité sur Gutenberg. Les principales raisons étant:

1. un audit ne pourra pas donner lieu à une action compte tenu de notre calendrier de publication, car…
2. l'audit n'affectera pas le moment de la publication, donc ...
3. il serait plus prudent d'explorer un audit selon un calendrier moins rapide à l'avenir

J'espère que nous explorerons un audit à l'avenir, mais malheureusement, cela ne se produira pas avant la proposition de fusion et je clôture donc ce problème car cela ne résoudra pas. Je voudrais toujours bloguer sur l'état de l'accessibilité de Gutenberg, à la fois le bon et le mauvais. Cette semaine, nous apportons quelques améliorations à la navigation au clavier, au contraste des couleurs, au comportement de mise au point et aux sélecteurs de date / couleur.

Désolé à tous d'avoir suscité des espoirs et d'avoir échoué à la communauté sur celui-ci. 😞

Juste un petit mot pour dire que j'aimerais voir cela continuer, même si cela se produit après 5.0.
Y a-t-il une raison de ne pas le laisser ouvert et de l'attribuer à un autre jalon ou à un autre futur?

Nous avons certainement été sur une montagne russe émotionnelle ces derniers temps, n'est-ce pas? 🎢

Tout d'abord, merci à tous pour le travail que vous faites. 💖 Je sais qu'il n'est parfois pas facile d'être un défenseur de l'accessibilité, cela peut ressembler à une bataille constante. Sachez que vous avez un impact: du personnel (j'ai beaucoup appris sur l'accessibilité des personnes qui composent l'équipe d'accessibilité de WordPress), au fondamental (la conception centrée sur l'humain est une facette essentielle des pratiques de conception modernes ).

J'aime beaucoup l'idée d'un audit professionnel, même si je ne me souviens pas que nous en ayons déjà fait un dans WordPress, certainement pas une condition pour une sortie. J'adorerais voir quelque chose comme ça arriver à un moment donné. WordPress a toujours essayé de tirer le meilleur parti de l'accessibilité en s'en tenant aux modèles et à la sémantique communs, la différence étant couverte par les efforts clés des bénévoles, tous les membres de l'équipe d'accessibilité effectuant des tests et déposant des rapports de bogues exploitables. Le passage de Gutenberg à une application entièrement basée sur JavaScript a rendu plus difficile l'application de ces modèles, mais nous pouvons travailler ensemble pour établir de nouveaux modèles, une nouvelle base de référence.

Nous savons que Gutenberg a encore besoin d'être peaufiné - ce que nous faisons! - et, comme tout, il aura des problèmes sur lesquels nous continuerons de réitérer dans les mois et les années à venir. Sur la base de nombreuses conversations, il semble que les problèmes les plus critiques sont déjà classés, beaucoup d'entre eux sont résolus et nous continuerons à les résoudre au fur et à mesure qu'ils se présenteront.

Il y a un tas de problèmes qui n'ont pas encore été traités (merci en particulier à tous ceux qui ont soumis des problèmes au cours de la semaine dernière environ!). Ce serait bien de voir un nettoyage des bogues pour résoudre ces problèmes et les hiérarchiser. Nous pouvons nous assurer que les problèmes qui empêchent activement les gens d'utiliser Gutenberg sont résolus, puis nous concentrer sur les problèmes qui visent à faciliter l'utilisation par les gens.

Je l'ai déjà mentionné, mais il convient de le répéter: WordPress 5.0 n'est pas la ligne d'arrivée, c'est le pistolet de démarrage. Beaucoup d'entre nous dans ce fil travaillons ensemble sur WordPress depuis des années avant que Gutenberg ne commence, et j'espère que nous travaillerons ensemble sur WordPress pour les années à venir. Nous avons vu de nombreuses nouvelles fonctionnalités arriver sur WordPress au fil des ans, et aucune d'entre elles n'est restée la même que lors de leur première sortie. Nous avons rencontré des défis que la plupart des autres projets qualifieraient d'insurmontables, mais nous les avons fait fonctionner.

La mission de WordPress continue d'être de démocratiser l'édition. L'accessibilité consiste à faire fonctionner les choses pour des personnes qui, historiquement, ont été extrêmement marginalisées. Ce ne sont pas seulement des compléments, la mission de WordPress exige intrinsèquement qu'il soit accessible.

Ce que nous publions dans WordPress 5.0 n'est pas gravé dans le marbre, nous continuerons à le réparer, à le retravailler, à en tirer des leçons et à l'améliorer. Gutenberg est la base sur laquelle nous pouvons construire la prochaine génération du Web, et le potentiel d'amélioration de l'accessibilité de l'ensemble du Web existe également. Chaque composant, chaque bloc, chaque interface doit être entièrement accessible, et chaque plugin et thème doit finalement pouvoir en profiter. La génération Gutenberg devrait fournir une expérience accessible _par défaut_. Non seulement cela, le vérificateur de contraste de couleur et les avertissements de hiérarchie des en-têtes sont de bons exemples de la façon dont Gutenberg peut également faire de la création de contenu accessible le comportement par défaut.

J'ai déverrouillé et rouvert ce numéro, et je l'ai jalonné pour l'avenir, mais nous pouvons facilement le déplacer vers une étape plus proche ultérieurement. J'ai une demande spéciale pour que nous essayions tous de rester sur le sujet et de nous concentrer sur une conversation productive. J'aimerais nous voir prendre ce qui a été commencé ici et trouver un cadre pour un audit d'accessibilité de la qualité, quelque chose qui peut s'étendre pour couvrir la portée de la phase 2 de Gutenberg et au-delà. Nous n'en sommes peut-être pas encore là, mais nous le serons. ❤️

Lié # 10537.

WordPress 5.0 n'est pas la ligne d'arrivée, c'est le pistolet de départ.

En fin de compte, cependant, ce pistolet de démarrage semble ne fonctionner que pour ceux qui n'ont pas de capacités différentes. Un pistolet de démarrage fonctionne dans la pratique, parce que le son est assez fort pour créer un sillage dans l'air que les personnes sourdes peuvent ressentir, et parce qu'il produit un flash / fumée qu'ils peuvent voir; il émet un son que les aveugles peuvent entendre. Un pistolet de démarrage est accessible à tous; Gutenberg ne semble pas l'être.

En refusant même d'envisager de suspendre la publication de Gutenberg jusqu'à ce qu'un audit complet ait été effectué, vous dites en fait à quiconque que _physiquement_ ne peut pas utiliser Gutenberg qu'il n'a pas d'importance pour la communauté WordPress. Cela va à l'encontre des normes de la communauté WordPress, est irresponsable et, très franchement, c'est embarrassant et dangereux pour un produit si omniprésent d'adopter ce genre d'attitude envers tant d'autres communautés.

J'ai créé le libellé "Besoin de commentaires sur l'accessibilité" pour les problèmes qui nécessitent qu'une personne possédant des connaissances en accessibilité intervienne, mais comme il n'y a rien de concret sur ce problème, je supprime le libellé

Personne ne dit quoi que ce soit de la sorte, @cgrymala. Comme je l'ai mentionné, un audit d'accessibilité professionnel n'a jamais été une exigence pour qu'une fonctionnalité soit fusionnée dans l'historique de WordPress. J'aimerais certainement voir un audit se produire, mais écrire qu'un manque d'audit est "irresponsable ... embarrassant et dangereux" est le genre d'hyperbole qui empêche un dialogue constructif.

Je vais réitérer ma demande à partir de mon commentaire précédent, veuillez rester sur le sujet et me concentrer sur une conversation productive .

Plus précisément, un manque d'audit ne nous empêche pas de résoudre les problèmes. Si l'accessibilité est importante pour vous, si vous (ou quelqu'un que vous connaissez) utilisez une technologie d'assistance, c'est le moment idéal pour tester et signaler les bogues.

@pento , je n'ai remarqué que personne

L'audit a été suggéré par @tofumatt car il y a de bonnes raisons de croire que Gutenberg n'est pas aussi accessible qu'il devrait l'être selon les propres normes de WordPress. Sans un audit indépendant, ou même juste un audit _A_, pourquoi vous attendez-vous à ce que la communauté croie soudainement que Gutenberg est accessible? L'absence d'audit n'est ni irresponsable ni dangereuse, mais ce style de prise de décision et de gestion dictatoriale l'est.

Compte tenu des obstacles liés à l'authentification, je ne pense pas que l'intégration de cela dans le noyau offre des avantages pour WP au-delà de ce que la communauté tire du plugin. Je ne crois pas que dans son état actuel, les avantages l'emportent sur le coût, et nous devrions pencher du côté de la simplicité.

C'est ce que @m a dit lors du débat sur l'API WP. C'est encore un autre exemple des hypocrisies évidentes de ce cycle de recyclage, à commencer par le fait que la société "les délais ne sont pas arbitraires" a refusé de fixer une date de sortie pour la version 5.0, jusqu'à ce qu'elle en trouve une qui lui plaisait, à quel point il n'y avait pas de place pour le débat . J'adore Gutenberg et je l'utilise tous les jours. Il offre une grande valeur en tant que plugin, et selon l'heuristique de Matt, nous devrions pécher du côté de la simplicité jusqu'à ce qu'il soit vraiment prêt.

L'accessibilité est importante pour de nombreuses personnes sur ce fil, qui ont offert du temps, du soutien et de l'argent pour nous aider à sortir de cette impasse. Il est malhonnête de votre part de suggérer que si nous nous en soucions vraiment, nous réglerons les problèmes.

Concernant les raisons avancées pour annuler l'audit:

un audit ne pourra pas donner lieu à une action compte tenu de notre calendrier de publication, car…
l'audit n'affectera pas le moment de la publication, donc ...
il serait plus prudent d'explorer un audit selon un calendrier moins rapide à l'avenir

Même si l'idée d'un audit tiers est morte, implicitement dans l'idée de https://github.com/WordPress/gutenberg/issues/10537 serait l'audit de Gutenberg pour des moyens d'accessibilité. Le fait qu'Automattic soit prêt à libérer Gutenberg en Core sans aucune norme d'accessibilité auto-imposée est extrêmement problématique . En fin de compte, je suis découragé qu'on me rappelle qu'en fin de compte, les intérêts d'Automattic semblent être promus au-dessus de ceux de la communauté en ce qui concerne le développement et la sortie de Gutenberg.

Ce fil porte sur:

1. réalisation d'un audit
2. les problèmes de classement basés sur l'audit
3. publier ses résultats sous forme de rapport sur le blog Make / Accessibility

Nous reconnaissons l'utilité d'une vérification et le fait que les gens aimeraient qu'une vérification soit effectuée. Veuillez conserver les commentaires relatifs au processus de:

1. réalisation de l'audit
2. cadrage de l'audit
3. résultats de l'audit

Je cache les commentaires hors sujet qui remodèlent ce qui a été dit et soulignent l'importance d'un audit. J'aimerais en voir une menée. Nous sommes tous d'accord là-bas. Veuillez garder les commentaires sur le sujet, productifs et assurez-vous qu'ils fournissent de nouvelles informations / ajoutent au problème en question.

@davisshaver Veuillez vous souvenir de l' étiquette WordPress , en particulier:

Les contributions au projet open source WordPress sont au profit de la communauté WordPress dans son ensemble, pas d'entreprises ou d'individus spécifiques. Toutes les actions entreprises en tant que contributeur doivent être prises en gardant à l'esprit les meilleurs intérêts de la communauté.

Le projet open source WordPress est une communauté gérée par des bénévoles. Même dans les cas où les contributeurs sont parrainés par des entreprises, ce temps est reversé au profit de l'ensemble de la communauté open source.

Tandis que @pento , @tofumatt , @m et d'autres sont donnés par Automattic, ils travaillent pour l'amélioration du projet. Automattic n'est pas celui qui décide de la sortie de Gutenberg.

L'audit peut et continuera comme indiqué par @pento :

C'est maintenant le moment idéal pour tester et signaler les bogues.

Tout ce qui peut être fait pour contribuer à ce processus de test et de rapport est bénéfique. Il existe un certain nombre de problèmes plus anciens qui pourraient utiliser le test pour voir s'il s'agit toujours d'un problème qui ne nécessite aucune technologie d'assistance spécialisée pour le test. Cela serait d'une grande aide et est en partie ce qu'une vérification indépendante aurait fourni.

Je ne savais pas qu'être responsable de la publication de WordPress.org impliquait que Matt abandonne sa responsabilité fiduciaire envers Automattic. Bien que vous puissiez affirmer que le conflit est minime ou que Matt travaille activement pour atténuer le conflit, l'étiquette WordPress que vous avez citée est une recommandation et non une description du monde ... En fin de compte, le conflit existe.

Je suis sûr que beaucoup de gens se cachent sur ce sujet pour le moment et je dirai si vous êtes intéressé et que vous souhaitez aider mais que vous n'avez jamais utilisé de technologie d'assistance auparavant (lecteurs d'écran) rejoignez la discussion sur https: // make .wordpress.org / chat / dans le canal d'accessibilité. N'hésitez pas à me contacter avec un DM. Vous serez peut-être surpris de voir à quel point il est facile de configurer NVDA / Voice Over / JAWS afin de pouvoir commencer à tester les choses.

Au-delà de cela, de nombreux outils sont disponibles pour tester les exigences WCAG:
Hache chromée:
https://chrome.google.com/webstore/detail/axe/lhdoppojpmngadmnindnejefpokejbdd

Vérificateur de contraste pour WCAG: https://chrome.google.com/webstore/detail/wcag-contrast-checker/plnahcmalebffmaghcpcmpaciebdhgdf?hl=en

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

Il y a 113 problèmes ouverts avec l'étiquette d'accessibilité qui sont actuellement ouverts:
https://github.com/WordPress/gutenberg/labels/Accessibility

Que nous soyons d'accord ou non avec les décisions actuelles, je pense que nous pouvons tous convenir qu'il y a encore beaucoup de travail que nous pouvons tous participer pour donner un coup de main pour aider à résoudre. Même en l'absence d'audit officiel, la communauté a toujours le pouvoir de contribuer à offrir une expérience plus accessible.

Ce numéro a été déposé pour faire connaître mon travail sur l'audit d'accessibilité, pour communiquer que j'aimerais que cela se produise et pour suivre le partage de cet audit dans un article de blog. Il ne s'agit pas d'un point de discussion sur ce qui devrait être considéré comme un bloqueur de publication pour WordPress 5.0. J'ai noté les opinions des gens à ce sujet et je les transmettrai à @m , qui est le responsable de la publication de WordPress 5.0. Ma compréhension est:

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 le deuxième point change, je relayerai cette information. Je prévois d'être un défenseur, mais je ne fixe pas les délais et je n'ai pas non plus de données solides sur l'accessibilité. C'est le but de l'audit: afin que nous puissions parler d'un lieu de données concrètes. 🙂

Merci pour toutes vos contributions, mais comme cette discussion est devenue assez hors sujet par rapport à sa portée prévue, je verrouille la conversation de ce problème pour le moment. Je vais le laisser ouvert et publier des mises à jour concernant l'audit.

Littéralement, toutes les personnes handicapées qui ont testé Gutenberg, à la fois récemment et au début, ont signalé des problèmes de blocage pour expliquer pourquoi il n'est pas accessible. Et les tests utilisateur sont tout aussi importants pour l'accessibilité que la conformité WCAG 2.0 niveau AA. Je devrais probablement dire WCAG 2.1 AA à ce stade, mais WCAG 2.0 vous rapproche encore beaucoup de l'endroit où vous devez être. Dire que vous n'avez pas de données est au mieux inexact.

L'absence d'audit dans ce cas est irresponsable car, pour commencer, contrairement à WordPress dans le passé, un framework a été choisi qui ne vient pas avec des composants accessibles prêts à l'emploi, et contrairement à WordPress passé, vous modifiez fortement le document modèle d'objet avec Gutenberg, ainsi que la suppression d'éléments de l'arborescence d'accessibilité, et dans le cas des navigateurs, le DOM et l'arbre d'accessibilité sont littéralement la manière dont la technologie d'assistance récupère les informations à interpréter. Même si vous laissez la technologie d'assistance en dehors de cela, comme le dit Gutenberg, la charge cognitive est énorme. Le plugin de l'éditeur classique est un substitut totalement inacceptable. Pour commencer, c'est à l'échelle du site. Donc, si un site utilise Gutenberg et que j'ai besoin d'entrer et de faire quelque chose avec du contenu, je ne peux pas le faire par utilisateur, et je ne peux pas installer le plugin de l'éditeur classique, faire mon travail, puis désinstaller et attendez-vous à ce que tout se comporte comme il se doit une fois que le retour à Gutenberg aura lieu. Et oui, j'ai testé ça. Le fait que l'accessibilité soit laissée après coup, encore une fois, est littéralement la façon dont WordPress s'est retrouvé dans le désordre dans lequel il se trouvait en 2011/2012 lorsque l'équipe d'accessibilité a démarré pour la première fois. Et le projet fait à nouveau exactement la même erreur, et nous demande de croire qu'il finira par réussir à nouveau. Je suis désolé, mais combien de fois faut-il envoyer des personnes handicapées à l'arrière du bus pour le plus grand bien? Combien de fois devons-nous être satisfaits de tout un tas de jolis mots sur l'accessibilité, sur la façon dont nous promettons que nous ferons mieux la prochaine fois, seulement pour découvrir quand il s'agit de punaises priorité?

Au moins pour le moment, Automattic a décidé de renoncer à effectuer un audit d'accessibilité sur Gutenberg. Les principales raisons étant:

1. un audit ne pourra pas donner lieu à une action compte tenu de notre calendrier de publication, car…
2. l'audit n'affectera pas le moment de la publication, donc ...
3. il serait plus prudent d'explorer un audit selon un calendrier moins rapide à l'avenir

@tofumatt @pento Pouvez-vous préciser si la chronologie mentionnée ici fait référence à une date de sortie du 19 novembre 2018 ou du 22 janvier 2019, comme indiqué dans la portée et le calendrier proposés de WordPress 5.0 ?

La date du 22 janvier 2019 laisserait plus de trois mois entre aujourd'hui et la publication de la version 5.0 pour terminer un audit et prendre des mesures. Les raisons ci-dessus suggèrent que nous ne pouvons pas terminer un audit et améliorer considérablement l'accessibilité en trois mois. Si cela est vrai, c'est une raison de plus pour démarrer le processus maintenant et répondre à l'audit en résolvant autant de problèmes que possible avant les versions 5.0.

L'idée que la chronologie deviendra moins précipitée après 5.0 (lorsqu'elle est entre les mains des utilisateurs du monde réel qui en ont le plus besoin) n'a aucun sens.

Les sites qui étaient conformes au niveau AA des WCAG 2.0, mais dont le nouveau contenu édité avec Gutenberg ne sera pas conforme lorsque la version 5.0 est publiée, déclenche un cauchemar juridique.

Merci à tous ceux qui ont commenté ici jusqu'à présent et qui ont gardé la discussion sur le sujet. Je l'apprécie vraiment: avec tant de choses autour de WordPress 5.0, cela m'aide vraiment à mettre de côté le temps que ce problème mérite. 🙂

@amandarush : Vous avez évoqué plusieurs préoccupations, je vais essayer d'y répondre, mais faites-moi savoir si quelque chose me manque.

Littéralement, toutes les personnes handicapées qui ont testé Gutenberg, à la fois récemment et au début, ont signalé des problèmes de blocage pour expliquer pourquoi il n'est pas accessible.

Je suis vraiment reconnaissant à tous ceux qui ont signalé ces problèmes. J'avais pensé que nous avions fait un travail raisonnable pour régler ces problèmes au fur et à mesure qu'ils se présentaient, mais il y a manifestement encore du travail à faire. Quand @tofumatt a fait référence à "ne pas avoir de données", je pense qu'il considère que nous avons résolu de nombreux problèmes d'accessibilité, nous n'avons pas une idée complète de l'état actuel des choses, nous voulons donc obtenez une image plus claire de la gravité des problèmes restants.

L'absence d'audit dans ce cas est irresponsable car, pour commencer, contrairement à WordPress dans le passé, un framework a été choisi qui ne vient pas avec des composants accessibles prêts à l'emploi

Faites-vous référence à React ici? Je crois comprendre que les applications construites avec React sont également accessibles à toute autre bibliothèque qui met à jour dynamiquement le DOM. À condition que nous utilisions de manière appropriée les attributs aria-* (tout en garantissant une focalisation prévisible du clavier), il devrait être utilisable avec la technologie d'assistance. N'est-ce pas correct?

Le plugin de l'éditeur classique est un substitut totalement inacceptable. Pour commencer, c'est à l'échelle du site. Donc, si un site utilise Gutenberg et que j'ai besoin d'entrer et de faire quelque chose avec du contenu, je ne peux pas le faire par utilisateur, et je ne peux pas installer le plugin de l'éditeur classique, faire mon travail, puis désinstaller et attendez-vous à ce que tout se comporte comme il se doit une fois que le retour à Gutenberg aura lieu.

Merci d'avoir évoqué ce cas d'utilisation, c'est un bon exemple de l'échec actuel du plugin Classic Editor. Nous pouvons certainement ajouter une option par utilisateur.

Et le projet fait à nouveau exactement la même erreur, et nous demande de croire qu'il finira par réussir à nouveau. Je suis désolé, mais combien de fois faut-il envoyer des personnes handicapées à l'arrière du bus pour le plus grand bien? Combien de fois devons-nous être satisfaits de tout un tas de jolis mots sur l'accessibilité, sur la façon dont nous promettons que nous ferons mieux la prochaine fois, seulement pour découvrir quand il s'agit de punaises priorité?

Je suis désolé. Malgré les meilleures intentions de tous les membres de l'équipe de Gutenberg, nous n'avons pas fait assez. Je peux honnêtement dire que l'accessibilité a toujours été une priorité, mais cela n'a pas été une priorité suffisamment élevée, et nous avons fait un mauvais travail de communication là où l'accessibilité a été améliorée. J'ai mentionné certaines de ces améliorations dans mon commentaire précédent, mais ces améliorations ne sont d'aucune utilité si nous n'avons pas atteint l'expérience de base accessible.

Bien sûr, des excuses ne servent à rien sans mesures pour corriger les choses, alors voici ce que je propose. À l'heure actuelle, l'intention est de hiérarchiser et de résoudre autant de problèmes d'accessibilité que possible. Nous en avons déjà corrigé des centaines et des correctifs sont déjà en cours pour certains des problèmes en suspens. Nous allons tester, bien sûr, mais nous avons besoin de l'expérience des personnes qui utilisent la technologie d'assistance pour découvrir les bogues. Tout test et rapport de bogue pour lequel vous êtes en mesure de prendre du temps est grandement apprécié.

Bien que je pense que nous pouvons amener l'éditeur de blocs à un état où il a une UX acceptable pour les utilisateurs de technologies d'assistance avant la sortie de la version 5.0, je reconnais qu'il est possible que nous ne puissions pas. Outre le paramètre par utilisateur que vous avez suggéré, comment pouvons-nous nous assurer que le plugin Classic Editor est une option raisonnable que les gens peuvent utiliser jusqu'à ce qu'ils soient satisfaits de l'état de l'éditeur de blocs?

J'aimerais toujours voir un audit d'accessibilité indépendant se produire, mais sans le calendrier précipité de la version 5.0. C'est là que ce problème peut être utilisé pour créer le cadre d'un audit complet. Comme les problèmes sont découverts, ils peuvent être corrigés dans les versions 5.0.x, il n'est certainement pas nécessaire d'attendre 5.1.

@kevinwhoffman : La chronologie fait référence à la date de sortie du 19 novembre (ou du 27 novembre au plus tard). Repousser la date de sortie au 22 janvier ne nous donnerait pas beaucoup de temps supplémentaire: entre WCUS (et la préparation nécessaire pour y parvenir), avoir besoin d'organiser une version WordPress 4.9.9, puis les gens sont en vacances à Noël et au Nouvel An, nous pourrions gagner deux semaines de travail complètes supplémentaires en repoussant la date de sortie de deux mois. Trois mois supplémentaires semblent être une somme généreuse, mais cela nous donnerait très peu de résultats réels, et nous aurions encore besoin d'une vérification rapide, de sorte que nous pourrions travailler à y remédier en novembre.

@rcemory : Bien que votre commentaire soit un peu hors sujet, il convient de noter que cette discussion est liée à l'interface de l'éditeur de blocs elle-même, pas au contenu qu'il produit pour afficher sur le front-end de votre site. Comme avec WordPress maintenant, le contenu produit dans l'éditeur de blocs est accessible. Dans de nombreux cas, il est plus accessible qu'avant, car l'éditeur de blocs fait un meilleur travail pour ajouter des étiquettes aria-* appropriées, il avertit lorsque vous utilisez des combinaisons de couleurs qui ne sont pas conformes aux WCAG, ou lorsque vous êtes mettre les éléments de titre dans le mauvais ordre.

Le plugin de l'éditeur classique est un substitut totalement inacceptable. Pour commencer, c'est à l'échelle du site. Donc, si un site utilise Gutenberg et que j'ai besoin d'entrer et de faire quelque chose avec du contenu, je ne peux pas le faire par utilisateur, et je ne peux pas installer le plugin de l'éditeur classique, faire mon travail, puis désinstaller et attendez-vous à ce que tout se comporte comme il se doit une fois que le retour à Gutenberg aura lieu.

Merci d'avoir évoqué ce cas d'utilisation, c'est un bon exemple de l'échec actuel du plugin Classic Editor. Nous pouvons certainement ajouter une option par utilisateur.

Ce serait formidable, mais c'est une préoccupation qui a été soulevée il y a plus d'un an et qui n'a pas été abordée jusqu'à présent. Étant donné que dans l'état actuel des choses, une fois qu'un message passe en GB, il ne peut pas être rétabli en "clair", puis de nouveau en GB tout en conservant toutes les informations pertinentes.
Par conséquent, le projet d'avoir une option basée sur l'utilisateur n'est tout simplement pas réaliste car cela signifie que les éditeurs qui se désengagent de GB auront du mal à éditer le contenu créé par des auteurs utilisant GB.

Les commentaires de @amandarush sont puissants et viennent du cœur. Et, je sais, basé sur l'expérience passée d'essayer de faire progresser l'accessibilité dans WordPress.

Depuis que je suis impliqué dans l'équipe d'accessibilité, il y a eu 4 (je pense) mises à niveau de fonctionnalités majeures dans la zone d'administration: le générateur de menu personnalisé, le gestionnaire de médias, le personnalisateur et maintenant Gutenberg.

Tels qu'ils avaient été conçus et construits à l'origine, tous ces composants étaient pratiquement (ou totalement) inaccessibles aux utilisateurs de lecteurs d'écran et aux utilisateurs de clavier voyants. À mon avis, cela est dû au fait que l'accessibilité n'est pas du tout prise en compte au stade de la conception graphique et de l'UX. Après que l'équipe d'accessibilité ait crié au scandale, des améliorations d'accessibilité ont été apportées aux 4, mais la conception sous-jacente et l'UX restent largement les mêmes.

Je partage donc son point de vue selon lequel WordPress continue de faire la même erreur encore et encore. Et malheureusement, je partage son scepticisme lorsque nous entendons "L'accessibilité est vraiment importante pour nous". C'est très frustrant, et c'est l'une des raisons pour lesquelles je contribue rarement plus à WP.

Il semble peu probable maintenant que les problèmes d'accessibilité arrêteront la poussée de sortie de WP5.0 en novembre, ce qui est bien sûr une énorme déception après la première ébauche de la liste des `` bloqueurs '' d'accessibilité au printemps de cette année. Et le désir souvent cité de WP de démocratiser le Web, et la promesse de ne publier aucune fonctionnalité non conforme aux WCAG2.0.

Mais je pense qu'un examen indépendant de l'accessibilité - impliquant non seulement des tests pour WCAG2.1, mais également des tests utilisateur appropriés - serait une chose sensée à faire maintenant. Au moins de cette façon, nous saurions tous où nous en sommes, et une attention appropriée peut être accordée à la hiérarchisation et à la résolution des défauts / problèmes d'accessibilité dans les versions futures.

En réponse à cela de @pento

Faites-vous référence à React ici? Je crois comprendre que les applications construites avec React sont également accessibles à toute autre bibliothèque qui met à jour dynamiquement le DOM. À condition que nous utilisions correctement les attributs aria- * (tout en garantissant une mise au point prévisible du clavier), il devrait être utilisable avec la technologie d'assistance. N'est-ce pas correct?

Oui, c'est vrai, mais les développeurs doivent comprendre comment rendre leurs composants accessibles dans la conception, la sémantique, l'exploitation, la gestion de la mise au point et avec l'utilisation correcte d'ARIA. Malheureusement, cela se produit rarement dans mon expérience.

Si / au fur et à mesure qu'Automattic suit la voie d'un audit, cela peut valoir non seulement l'identification des flux critiques / parcours des utilisateurs, mais également des widgets courants à examiner. Si ces widgets peuvent être identifiés et audités seuls, ils peuvent également former la base d'une bibliothèque de modèles accessible. Cela peut aider à atténuer les risques d'accessibilité à mesure que davantage de fonctionnalités sont créées à l'aide de ces modèles.

cela peut valoir non seulement l'identification des flux critiques / parcours des utilisateurs, mais également des widgets courants à examiner. Si ces widgets peuvent être identifiés et audités seuls, ils peuvent également former la base d'une bibliothèque de modèles accessible. Cela peut aider à atténuer les risques d'accessibilité à mesure que davantage de fonctionnalités sont créées à l'aide de ces modèles.

@aardrian C'est un point de départ intéressant qui existe peut-être déjà et qui sera nécessaire pour l'audit que nous pourrons peut-être utiliser maintenant pour agir: je n'ai pas vu de parcours utilisateur pour Gutenberg, et c'est probablement le point de départ le plus évident pour commencer à couvrir ledit audit.

@karmatosed @jwold - Savez-vous si lesdits flux / voyages pour utiliser Gutenberg existent déjà? Peut-être une liste de "widgets" ou de "modèles" comme décrit ici?

Je pense que même si ce fil général a beaucoup d'émotion (et je suis d'accord que Gutenberg doit être utilisable par tous et expédié lorsqu'il est prêt) - j'aimerais trouver un terrain d'entente et les prochaines étapes. J'adorerais déplacer les lieux de conversation pour identifier où nous sommes prêts à agir.

Ledit flux d'utilisateurs nous donnerait également une liste de tâches à vérifier pour que les développeurs, les testeurs et les chasseurs de bogues commencent à se diviser et à rechercher des éléments à signaler.

@postphotos , je pense que @afercia a décrit un bon ensemble de flux ci-dessus dans https://github.com/WordPress/gutenberg/issues/10318#issuecomment -428957684.

@aardrian D'accord, c'est un bon point de départ! 👍 Merci de l'avoir rappelé.

Ma demande tient toujours - j'aimerais savoir, au-delà de ce flux critique initial, s'il y a du travail supplémentaire qui a déjà été mis dans les parcours des utilisateurs en ce qui concerne les fonctionnalités, car cela aidera à valider le travail que nous faisons ici. Il peut y avoir d 'autres éléments que nous (ce groupe) souhaitons peut - être ajouter à la liste initiale de @afercia , ou passer après un audit initial. 😄

Par exemple, nous n'avons pas appelé la fonctionnalité de structure de contenu, annuler / rétablir, etc. incroyablement utile et devrait être accessible. Ce serait formidable de trouver activement un consensus si nous le pouvons.

Un autre avantage à faire un audit est la contribution au projet React plus large. React a ses propres problèmes d'accessibilité, et un audit de Gutenberg pourrait bien identifier à la fois les problèmes et les solutions qui concernent et peuvent aider React core.

Eh bien, c'est une nouvelle passionnante: https://make.wordpress.org/core/2018/10/18/regarding-accessibility-in-gutenberg/

Raccourcis clavier pour la navigation dans les régions et les blocs, commandes de barre oblique, barres d'outils focalisables et améliorations de la barre latérale à partir des repères et des rôles ARIA améliorés, des tests automatisés de bout en bout, etc.

ICYMI: L'organisation WPCampus organise un audit d'accessibilité de Gutenberg.

Nous avons terminé notre appel d'offres et sélectionnons maintenant un fournisseur.

Cependant, comme la plupart d'entre vous le savent probablement bien, un audit d'accessibilité professionnel est une dépense importante pour une petite organisation à but non lucratif comme WPCampus.

Nous vous demandons votre aide pour financer la vérification afin de garantir que cette recherche vitale est terminée.

Vous pouvez en savoir plus sur l'initiative et faire des dons sur notre site Web: https://wpcampus.org/2018/11/fundraising-for-wpcampus-gutenberg-accessibility-audit/

Salut Rachel,

Je vois que vous nous demandez de faire un don pour la vérification.
Je me demande si vous avez réfléchi à mon message sur ce fil que j'ai écrit
il y a quelques mois, en offrant de faire un don d'audit d'accessibilité,
résoudrait entièrement tout déficit de financement?
Nous avons la confiance de certains des plus grands gouvernements et des Fortune 500 du monde
avec de tels projets!

Voici ce que j'ai publié le 11 octobre 2018:

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

@tofumatt https://github.com/tofumatt Je suis également très préoccupé par
Accessibilité WordPress et désireux de vous aider à réussir. Je peux avoir notre
l'organisation effectue un audit d'accessibilité conforme aux WCAG-EM pour
quel que soit le niveau standard que vous préférez, à la fois technique et fonctionnel
tester, * et donner la partie du travail dont vous avez besoin * pour s'adapter à votre
budget.

Je pense que nous devrions examiner à la fois ATAG et WCAG AA, et peut-être
WCAG 2.1 plutôt que 2.0. Nous pourrions également fournir des recommandations et
coaching pour vous aider à choisir la manière la meilleure et la plus durable de fermer tout
lacunes découvertes.

Nous sommes facilement indépendants de votre communauté de développement, mais savons
WordPress bien depuis de nombreuses années. Je possède toutes les certifications IAAP et j'ai dirigé
des dizaines d'audits de ce type sur la plateforme WordPress, sur de nombreuses années, pour les deux
secteur privé et public. Veuillez consulter notre bonne foi à

davidberman.com/about pour décider de la meilleure façon de vous aider.

Pensées?

• David

Le mercredi 28 novembre 2018 à 10 h 10, Rachel Cherry [email protected]
a écrit:

ICYMI: L'organisation WPCampus organise un audit d'accessibilité de
Gutenberg.

Nous avons terminé notre appel d'offres
https://wpcampus.org/2018/10/gutenberg-a11y-audit-rfp/ et le sont maintenant
sélectionner un fournisseur.

Cependant, comme la plupart d'entre vous le savent probablement bien, un professionnel
l'audit d'accessibilité est une dépense importante pour une petite organisation à but non lucratif comme WPCampus.

Nous vous demandons votre aide pour financer l'audit et assurer cette vitale
la recherche est terminée.

Vous pouvez en savoir plus sur l'initiative et faire des dons sur notre site Web:
https://wpcampus.org/2018/11/fundraising-for-wpcampus-gutenberg-accessibility-audit/

-
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail, affichez-le sur GitHub
https://github.com/WordPress/gutenberg/issues/10318#issuecomment-442480511 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/ABz4pIgVSgZmWJRL2n3Uy-i8Ov7NXnj1ks5uzqdcgaJpZM4XG_WQ
.

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

Conseiller de haut niveau, Nations Unies | Expert invité, W3C | Ico-D
Chaire de développement durable | Chaise Carleton U. Access Network

À venir: Toronto | La Nouvelle-Orléans | Montréal | Buenos Aires | Tampa | Tel Aviv
Cours d'accessibilité: rejoignez-nous en ligne www.davidberman.com/next

Ce message peut contenir des informations exclusives. Non autorisé
divulgation / copie / distribution de contenu interdite.

@tofumatt , j'ai vu ceci sur le blog personnel de Matt Mullenweg le 29 novembre:

Enfin, Automattic financera une étude d'accessibilité de WordPress, Gutenberg et une évaluation des meilleures pratiques sur le Web, afin de garantir que WordPress est entièrement accessible et d'établir de nouvelles normes pour le Web dans son ensemble.

Comme vous êtes un représentant d'Automattic, maintenant que l'audit Automattic est de nouveau activé, pouvez-vous nous dire si cela sera séparé de l'audit WPCampus ou Automattic financera-t-il l'audit WPCampus à la place?

D'une part, je déteste voir WPCampus devoir le financement participatif. De l'autre, j'aime l'idée de deux audits de deux cabinets pour comparer et contraster.

Matt a répondu à ma question sur son blog:

Je pense que c'est bien d'en avoir deux aussi, je vais parler à Rachel de la façon dont le financement va.

Pour ceux qui suivent, se sont engagés à financer entièrement tous les besoins du projet de Rachel du côté WP Campus et dans la phase de sélection des fournisseurs pour celui parrainé par Automattic. L'objectif de ce dernier est également de voir quelles sont les meilleures approches d'accessibilité pour d'autres interfaces de style éditeur de blocs sur le Web moderne.

@m Merci pour la mise à jour. C'est très encourageant de voir cela évoluer et j'ai vraiment hâte de voir où cela mène. J'aimerais que WordPress soit un jour l'exemple de la façon dont l'accessibilité devrait être traitée.

@m

Pour ceux qui suivent, se sont engagés à financer entièrement tout ce dont le projet de Rachel a besoin du côté WP Campus

C'est formidable et précieux. Y a-t-il une raison pour laquelle vous ne le financez pas au total aujourd'hui? Il semble étrange de demander aux gens de continuer à faire un don alors qu'ils savent qu'il sera complètement financé.

@aardrian Ce n'est pas dans l'esprit de ce que nous faisons. Nous voulons que ce soit un projet communautaire et que les gens et les organisations aient la possibilité de participer et de montrer leur soutien, s'ils le peuvent.

Fin 2018, WPCampus a publié un appel à propositions pour mener un audit d'accessibilité de l'éditeur de blocs WordPress, également connu sous le nom de Gutenberg. Début 2019, nous avons annoncé notre sélection de Tenon, LLC pour réaliser l'audit, au coût de 31200 $.

Aujourd'hui, nous sommes ravis de publier le rapport de Tenon sur l'accessibilité du nouvel éditeur.

En savoir plus sur https://wpcampus.org/2019/05/gutenberg-audit-results/

Je pense que cela conclut ce numéro 🎉🎉🎉🎉🎉

Tous les problèmes signalés sont suivis dans le cadre de ce projet:
https://github.com/WordPress/gutenberg/projects/25

Tous les problèmes signalés sont suivis dans le cadre de ce projet

Pas tout à fait correct. Le rapport WPCampus / Tenon inclut des considérations supplémentaires importantes qui ne sont pas couvertes dans la liste des problèmes sur GitHub. Plus spécifiquement, le résumé et le rapport sur l'utilisabilité montrent (avec des données) qu'il existe des problèmes d'accessibilité structurelle plus larges dans Gutenberg qui ne peuvent pas être résolus dans de petits problèmes GitHub et qui nécessitent des solutions à un niveau supérieur.

Il s'agit de préciser que même si tous les problèmes signalés ont été résolus, il restera d'importants problèmes d'accessibilité à résoudre. Ceux-ci sont généralement liés à la conception générale de l'éditeur.

Pour référence, je joins ici deux des documents publiés sur https://wpcampus.org/2019/05/gutenberg-audit-results/

Document de synthèse décrivant les tests d'utilisabilité de Tenon
Gutenberg_UX_Report.pdf

Résumé
Gutenberg_Executive_Summary.pdf

Je suggère d'ouvrir un nouveau numéro, ou même un projet, pour gérer les problèmes d'utilisabilité découverts dans le rapport.