Es wäre wirklich cool zu wissen, dass in Gutenberg auf alle Blöcke zugegriffen werden kann, die die klassischen Editorfunktionen replizieren.

Hier ist es richtig, ein unabhängiges Barrierefreiheits-Audit durchzuführen. WordPress hat eine festgelegte Richtlinie zur Einhaltung der Richtlinien zur Barrierefreiheit im Kern und ist auch gegenüber seinen Benutzern dafür verantwortlich, diese Richtlinien einzuhalten. Nur eine gründliche Prüfung der Barrierefreiheit kann zeigen, ob dies der Fall ist oder nicht. Das Barrierefreiheitsteam hat zahlreiche Probleme gemeldet, von denen einige behandelt wurden, andere nicht. Zumindest müssen diese angegangen werden.

WordPress ist eine Schnittstelle zwischen dem Herausgeber, einer Datenbank und dem Besucher. Wie genau der Herausgeber die Benutzeroberfläche eingibt oder bearbeitet, hängt von diesem Benutzer ab. Die Aufgabe von WordPress ist es, die Benutzeroberfläche für jede von diesem Benutzer gewählte Eingabemodalität zugänglich zu machen. Dies ist weder neu noch umstritten: Es ist das Fundament, auf dem das Web steht.

Ich stimme @ mor10 zu. In Anbetracht der Investition von Automattic und des Kernteams in das Projekt und der anhaltenden Probleme besteht der einzig wahre und gültige Weg in der Zukunft in einer unabhängigen, objektiven Prüfung.

WordPress hat eine festgelegte Richtlinie zur Einhaltung der Richtlinien für Barrierefreiheit im Kern

Ja genau. Ich möchte Vertrauen von den Leads in das größere w.org-Projekt - wie @afercia und @rianrietveld - in die Arbeit hier.

Kurz gesagt, ich glaube, Gutenberg _CAN_ ist zugänglich, aber ich befürchte, dass es in seinem aktuellen Zustand aufgrund der 117 im Projekt geöffneten Elemente möglicherweise nicht versandfähig ist.

Ich hoffe, das kann passieren!

Ich würde eine externe, unabhängige Prüfung der Barrierefreiheit uneingeschränkt unterstützen.

Wie Sie bereits erwähnt haben, gibt es einige Wahrnehmungsprobleme, die meines Erachtens mit dem Mangel an Material und Informationen zu Benutzertests und insbesondere zu erneuten Tests im Verlauf der Entwicklung zusammenhängen. Anstatt den Ergebnissen der Benutzer nachzujagen, scheint es, als würden wir Bugs und Regressionen nachjagen.

Ich schätze Ihre Ehrlichkeit hier und stimme zu, dass eine externe / unabhängige Prüfung wertvoll wäre. Ich befürchte jedoch, dass dies die Barrierefreiheit aus technischer Sicht rückwirkend betrifft (dh die Kontrollkästchen für WCAG 2.x / AA aktiviert), anstatt eine bessere Erfahrung für diejenigen zu bieten, die möglicherweise keine Maus und Tastatur verwenden. Allein aus Gründen der Zugänglichkeit kann eine qualitative und quantitative Untersuchung der Gutenberg-Erfahrung ohne Daten in Bezug auf die aktuelle Erfahrung (oder, noch besser, andere ähnliche Produkte) keine faire Geschichte erzählen.

Ich denke, Transparenz in Bezug auf diese Informationen würde mit der Unterstützung der Community viel Zeit in Anspruch nehmen und viel Reibung verringern, sowohl unter dem Gesichtspunkt der Barrierefreiheit als auch beim größeren Gutenberg-Rollout.

Ich bin nicht überrascht zu hören, dass andere für ein externes Audit sind, was großartig wäre. 👍 Ich kann Ihnen sagen, dass ich das auch lieben würde, und werde prüfen, wie wir dies in der nächsten Woche ermöglichen können.

Gibt es auf WordPress spezialisierte Agenturen / Unternehmen, die sich auf Barrierefreiheit spezialisiert haben und in der Lage sind, ihre Zeit für die Durchführung eines Barrierefreiheits-Audits des Projekts zu priorisieren (wahrscheinlich ab 4.0, was eine große Version ist)? Ich denke, es wäre praktisch, ein grundlegendes Gefühl dafür zu entwickeln, wie sich Gutenberg gegen den Classic Editor schlägt.

Ich bin mir sicher, dass es Probleme geben wird (wie oben erwähnt, wir haben über 100 Probleme mit der Barrierefreiheit), aber ich versuche, eine Makroansicht der Barrierefreiheit in Gutenberg zu erhalten. Es sollte darauf hingewiesen werden, dass wir weit über 100 Probleme mit der Bezeichnung "Bugs" haben, aber dies ist uns zu verdanken, dass wir keinen Fehler als zu klein betrachten. Wir versuchen, alles zu protokollieren, aber denken Sie daran, dass dies 100 Barrierefreiheitsprobleme bedeutet, nicht 100 Barrierefreiheitsblöcke. Die Barrierefreiheitsblocker (ab sofort) sind im Merge Milestone enthalten, zu dem dieses Problem gehört.

Vielen Dank an diejenigen, die ihre Stimmen zur Unterstützung eines Audits hinzugefügt haben. Ich werde eine Liste der Flows bereitstellen, die wir testen und sicherstellen möchten, dass Benutzer als MVP arbeiten. Wenn ich dies tue, werde ich sie hier veröffentlichen, aber ich habe sie noch nicht vollständig formuliert.

Ein externes Audit ist eine gute Idee. Ich würde gerne einen finanziellen Beitrag zur Einstellung eines qualifizierten Unternehmens für diese Prüfung leisten.

Ich würde auch einen finanziellen Beitrag leisten, insbesondere für etwas in dieser Größenordnung und Bedeutung.

Ich wäre auch bereit, den Weg zu weisen, um Geld von der Gemeinde zu sammeln.

Ich mag diese Idee. Für Unternehmen, die die Einhaltung der WCAG in ihrer Software benötigen, kann ein Audit einen großen Beitrag zur Beseitigung von Bedenken leisten. Das Generieren eines VPAT aus einem Audit kann auch dazu beitragen, Organisationen zu unterstützen, die es als Teil ihres Vertragsprozesses benötigen. Weitere Informationen finden Sie unter Einbinden der Barrierefreiheit in Verträge mit

Ich unterstütze auch ein externes, unabhängiges Audit für Barrierefreiheit. Ich werde in den hervorragenden a11y-Ressourcen meines Tagesjobs nachsehen, was sie empfehlen. :) :)

Das ist sehr nett! Aber wir suchen nicht nach finanziellen Beiträgen der Community. Ich werde mich an einige Auditoren für Barrierefreiheit wenden und herausfinden, ob sie einige Audits auf Gutenberg durchführen können.

Ich werde sehen, welche Art von Kosten und Zeitplänen damit verbunden sind, aber wenn wir mit einem Zeitplan, der für 5.0 funktioniert, einen angemessenen Preis erzielen können, sollte ich in der Lage sein, Automattic zur Deckung der Kosten zu bewegen. 😊

Ich war mir nicht sicher, welche finanzielle Unterstützung ich von Automattic erhalten konnte, als ich einen früheren Kommentar veröffentlichte, und ich war mir über die Erwartungen der Community etwas unklar: Entschuldigung! Ich habe den Kommentar aktualisiert und klargestellt, wonach ich nicht gesucht habe. Im Moment werde ich mich um die Organisation von Audits kümmern. Ich werde wahrscheinlich ein paar Tage brauchen, um die Zitate zu streiten! Ich melde mich zurück, sobald ich mehr weiß 😊

Ich weiß, dass dies möglicherweise nicht der Ort ist, an dem dies angegeben wird, aber mein Unternehmen führt Zugänglichkeitsprüfungen durch. Lassen Sie mich wissen, wenn Sie mehr wissen möchten. Obwohl ich in letzter Zeit nicht so aktiv war, habe ich mich eine Weile mit WordPress beschäftigt und Ideen für Barrierefreiheit zu Gutenberg und anderen Teilen von WP beigetragen. Wenn ich nicht unabhängig genug bin, arbeite ich mit einem vertrauenswürdigen Partner zusammen, der WordPress noch nie verwendet hat.

@tofumatt Ich denke, eine Aufforderung zur anzugeben , wonach ein Audit sucht, und den Dienstleistern die Möglichkeit zu geben, einen allgemeinen Überblick über ihre Vorgehensweise zu geben. Gibt es bei Automattic einen Präzedenzfall für diese Art von Prozess?

Hallo, ich bin der IT Accessibility Coordinator der NC State University. Wir verwenden WordPress für unsere Campus-Websites und müssen als staatliche Einrichtung Abschnitt 508 des Rehabilitationsgesetzes von 1973 befolgen. Aus diesem Grund müssen unsere Authoring-Tools wie WordPress für Menschen mit Behinderungen zugänglich sein.

Wir haben eine Vielzahl von Benutzern von WordPress, einschließlich Studenten, Lehrkräfte und Mitarbeiter, die WordPress-Blogs verwenden und WordPress-Websites im Auftrag ihrer Abteilungen ihrer Organisation bearbeiten. Alles in allem muss WordPress für diese Personen zugänglich sein.

Als Hochschule wollen wir mit neuen Programmen und Technologien auf dem Laufenden bleiben. Es wäre nachteilig für uns, nicht in der Lage zu sein, Gutenberg weiterzuentwickeln und zu nutzen, oder eine Situation zu schaffen, in der Menschen mit Behinderungen nur den klassischen Editor verwenden können, während Menschen mit Behinderung Gutenberg können.

Das ist so toll zu hören 👍

Ich bin vollkommen einverstanden! Natürlich möchte ich die klare Erwartung setzen, dass es möglicherweise Probleme mit der Barrierefreiheit gibt, die wir entdecken (oder möglicherweise kennen), die wir nicht beheben können, bevor WordPress 5.0 veröffentlicht wird.

Es gibt viele Websites aus vielen Gründen, die das Classic Editor-Plugin für eine begrenzte Zeit verwenden möchten / müssen, während Gutenberg - oder externe Plugins - verbessert werden. Es wird wahrscheinlich Benutzer geben, bei denen - neben einer Reihe anderer Probleme - Probleme mit der Barrierefreiheit auftreten, für die das Classic-Plugin einige Wochen / Monate erforderlich ist, während wir unsere Software verbessern.

Ich möchte, dass die Zukunft des WordPress-Editors fantastisch und für alle zugänglich ist. Ich entschuldige mich im Voraus für Benutzer, die aus irgendeinem Grund zuerst durch die Ritzen fallen. Aber wissen Sie, wir werden daran arbeiten, Gutenberg und WordPress auch für sie großartig zu machen, auch wenn dies nicht sofort geschieht. ❤️

In Bezug auf Audit

Hallo zusammen! Ich bin noch ein bisschen neu darin, ein Release-Lead zu sein, und ich komme aus fast einem Jahrzehnt, als ich am @ mozilla- Projekt gearbeitet habe, bei dem auch wir sehr offen gearbeitet haben, Fehltritte und so weiter. Ich werde so transparent wie möglich darüber sein, was passiert, einschließlich des Versuchs, zeitnahe Updates zu geben (daher bin ich mir nicht sicher, ob ich für Zugänglichkeitsprüfungen bezahlen kann, bis ich mich bei einigen Leuten erkundige).

Die Art der Prüfung, die ich durchführen möchte, ist möglicherweise nicht allzu legal / Compliance-spezifisch, da ich zunächst ein makroökonomisches Gefühl für die Benutzerfreundlichkeit von WordPress durch Benutzer mit Barrierefreiheitsanforderungen erhalten möchte. Wenn das Compliance-Zeug beinhaltet: großartig.

Im Moment habe ich Kontakt zu einigen Mitgliedern der @WordPress Accessibility-Community und sachkundigen @ automattic- Mitarbeitern aufgenommen, die mir einige Ansprechpartner für ein Accessibility-Audit zur Verfügung gestellt haben. Im Moment möchte ich, dass es unparteiisch ist (etwas außerhalb der WordPress-Community ist großartig, um Voreingenommenheit / Wissen aus der Vergangenheit / etc. Zu vermeiden), auf hohem Niveau, umsetzbar und etwas schnell erledigt. Ich weiß, ich frage viel 😆

Ich habe jetzt und im Kopf einige Leutewird sie erreichen Ich habe mehrere Unternehmen kontaktiert, die sich auf Barrierefreiheitsprüfungen spezialisiert haben. Ich werde hier Updates veröffentlichen, aber ich werde erst nächste Woche mehr wissen. Im Moment gibt es:

1. Sie müssen keine finanzielle Unterstützung anbieten (aber OMG bedankt sich bei allen, die dies getan haben. Es ist super cool, Ihr Engagement für WordPress zu sehen.)
2. Sie müssen Ihre Dienste nicht anbieten (ich denke, wir möchten jemanden außerhalb des WordPress-Ökosystems, aber wenn Sie bei regelmäßigen Fehlern / Zugänglichkeitstests helfen möchten, tun Sie dies bitte! )
3. viel me von mir 🙂

Ich wünsche Ihnen ein schönes Wochenende und halte Sie alle auf dem Laufenden! 😄

Wenn Sie nach weiteren Anbietern für das Audit suchen, empfehle ich WebAIM an der Utah State University, die allgemein als eine der besten Web-Ressourcen in den USA gilt. Sie sind in keiner anderen Weise mit ihnen verbunden, als ihre erstaunliche Web-Dokumentation zu lesen, aber ich habe gesehen, dass sie Audits anbieten.

Obwohl WordPress selbst Open Source ist und immer noch viele freiwillige Mitarbeiter hat, hat es auch die "große Zeit" erreicht und kann es sich nicht länger leisten, auf die Krücke "Aber wir sind nur Open Source" zurückzugreifen. Ich denke, eine vollständige Prüfung der Barrierefreiheit und die Verpflichtung zur Verbesserung, wenn festgestellt wird, dass WP fehlt (nicht nur Gutenberg), wären eine großartige Quelle für Vorwärtsbewegungen, wenn es um die Annahme von WP geht. Und natürlich die Demokratisierung des Publizierens und all das.

Es gibt viele Websites aus vielen Gründen, die das Classic Editor-Plugin für eine begrenzte Zeit verwenden möchten / müssen, während Gutenberg - oder externe Plugins - verbessert werden. Es wird wahrscheinlich Benutzer geben, bei denen - neben einer Reihe anderer Probleme - Probleme mit der Barrierefreiheit auftreten, für die das Classic-Plugin einige Wochen / Monate erforderlich ist, während wir unsere Software verbessern.

Dieses Gefühl ist für mich einfach inakzeptabel und ich hoffe, dass viele andere die WordPress-Werte verinnerlicht haben ...

Ich entschuldige mich im Voraus für Benutzer, die aus irgendeinem Grund zuerst durch die Ritzen fallen. Aber wissen Sie, wir werden daran arbeiten, Gutenberg und WordPress auch für sie großartig zu machen, auch wenn dies nicht sofort geschieht. ❤️

Was bringt es, eine Erfahrung durchzusetzen, die nicht den Standards von allem anderen in Core entspricht? Fristen sind nicht willkürlich, aber das bedeutet nicht, dass Sie Ecken abschneiden. Zumindest nicht nach den WordPress-Werten, wie ich sie verstehe. Diese Werte unterscheiden sich wahrscheinlich von allem, was Mozilla hatte. Als Neuling in der Community ermutige ich Sie, sie zu untersuchen.

Im Allgemeinen schafft das Gefühl, dass meistens Arbeit ausreicht, ein unnötiges Risiko für die Gemeinschaft, und man muss sich fragen, wer davon profitiert. Was ist der Vorteil des Gutenberg-Projekts oder von WordPress? Es ist nicht so, dass wir die Hilfe brauchen, um Probleme zu identifizieren.

Da Automattic anscheinend Parameter für dieses Audit sponsern und konzipieren wird, besteht das potenzielle Auftreten von Voreingenommenheit und dass sie ihre eigene Arbeit bewerten. Ich schlage vor, dass die größere Community mit Crowdfunding fortfährt, um einen Spezialisten für Barrierefreiheit für einen parallelen Bericht aus Sicht der tatsächlichen Benutzer einzustellen. Vielleicht kann Automattic ein technisches Audit durchführen oder was auch immer, aber der Vorschlag, dass die Gutenberg-Zugänglichkeit „nicht so schlecht“ ist, wurde von echten Experten auf diesem Gebiet vehement abgelehnt (Sina Braham von WordCamp Publishers). Vielleicht brauchen wir etwas näher an einem Mikey-Test, bei dem blinde Benutzer durch die App navigieren und sagen, ob sie sie wieder verwenden würden.

Das habe ich übrigens an Unternehmen geschickt, die ich für diese Arbeit angesprochen habe. Es kann anderen Leuten helfen, die mit Barrierefreiheit zu tun haben. Ich bin mir nicht sicher. Zumindest poste ich es hier aus Gründen der Transparenz 🙂

Bedarf

Eine Reihe von Zugänglichkeitstests, die mit dem Gutenberg-Editor auf einer WordPress-Website mit WP-Admin durchgeführt werden sollen. Diese Tests sollten mindestens die folgenden Testabläufe umfassen:

Core Publishing Flow

• Erstelle einen neuen Beitrag
• Fügen Sie allgemeinen Inhalt hinzu (Absatz-, Bild-, Listen-, HTML- und Tabelleninhalt; siehe „Verwenden von Blöcken“ weiter unten).
• Veröffentlichen Sie einen Beitrag sofort und der Beitrag wird wie beabsichtigt erstellt
• Planen Sie mit der Datumsauswahl einen Beitrag für die Zukunft
• Weisen Sie dem Beitrag Kategorien und Tags zu
• Weisen Sie einem Beitrag ein ausgewähltes Bild zu
• Experimentieren Sie mit anderen Einstellungen auf Dokumentebene, sofern es die Zeit erlaubt

Blöcke verwenden

Dies sind die zwanzig am häufigsten verwendeten Blöcke auf WordPress.com und sollten getestet werden, um Barrierefreiheitsprobleme zu finden, die nicht bereits in unserer Liste der Barrierefreiheitsprobleme aufgeführt sind :

1. Absatz
2. Bild
3. Überschrift
4. Liste
5. Galerie
6. Zitat
7. einbetten / youtube
8. html
9. Separator
10. Mehr
11. Titelbild
12. Shortcode
13. Taste
14. Tabelle
15. Abstandshalter
16. einbetten
17. Block
18. einbetten / twittern
19. Säulen
20. Code

Diese Blöcke sollten mit unterstützenden Technologien getestet werden, um sicherzustellen, dass keine Blocker für ihre Verwendung vorhanden sind und dass auf ihre Einstellungen auf Blockebene zugegriffen werden kann.

Klassischer Editor

Wir sollten überprüfen, ob es im Vergleich zum Classic Editor keine nennenswerten Rückschritte hinsichtlich der Barrierefreiheit gibt. Das Erstellen eines Posts mit demselben Inhalt, den Sie in einem Barebone-Classic-Editor-Kontext erstellen können, sollte mit Gutenberg möglich sein. Gutenberg, das im Vergleich zum klassischen Editor keine Regressionen in der Bearbeitungserfahrung aufweist, ist mein oberstes Ziel, um zu sagen, dass wir es als Standardbearbeitungserfahrung für Benutzer unterstützender Technologien empfehlen können.

Zu berücksichtigende unterstützende Technologien

Aufgrund der begrenzten verfügbaren Zeitachse und der Priorisierung der Handlungsfähigkeit gegenüber extremer Gründlichkeit würde ich es vorziehen, die besten Kombinationen aus zwei bis drei Browsern und Bildschirmlesern zum Testen zu verwenden . Wenn es die Zeit erlaubt, ist es absolut zugänglich, mehr zu verwenden, aber ich würde es vorziehen, mit den am häufigsten verwendeten Kombinationen zu beginnen. Nach meinem Verständnis ist dies:

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

Mobile assistive Technologie hat für dieses Audit keine Priorität. VoiceOver-Tests unter MacOS sollten hoffentlich einige Überkreuzungen mit iOS VoiceOver-Benutzern beinhalten. Die Nutzung mobiler Apps ist vermutlich eher ein Schwerpunkt als die Nutzung von Websites.

Veröffentlichen Sie Berichte und Probleme im Freien

Wir gehen davon aus, dass generierte Eingabehilfen in der WordPress-Community veröffentlicht werden und mich (oder einen anderen Automattician) nicht als Gatekeeper benötigen. Probleme sollten mit nützlichem Kontext in GitHub veröffentlicht werden, wobei der Schwerpunkt auf der Ursache und der Reproduzierbarkeit von Problemen liegt. Lösungen oder Lösungsansätze können veröffentlicht werden, wenn Zeit im Umfang liegt oder wenn das Problem besonders komplex ist.

@davisshaver Hallo, und ich stimme dir vollkommen zu. Eine gründliche und unvoreingenommene Prüfung ist entscheidend, um sicherzustellen, dass das maximale Niveau von a11y eingehalten wird.

Es ist nicht nur wichtig sicherzustellen, dass der Editor zugänglich ist, sondern dass auch eine Grundlage vorhanden ist, um sicherzustellen, dass Änderungen am Editor auch leicht zugänglich gemacht werden können. Natürlich können wir nicht durchsetzen, was die Leute selbst tun, aber wir können zumindest eine Grundlage für die Implementierung schaffen, die zugänglich ist.

@tofumatt Gerne auch gerne weiter. Ich habe möglicherweise Zugriff auf einige ziemlich gute Ressourcen zum Testen, insbesondere auf andere mit React- und a11y-Erfahrung. Es gibt auch einige Leute in meinem Team, die in ihrem Alltag speziell mit a11y arbeiten.

@tofumatt Danke für das Update. Ich habe einige Anschlussfragen:

1) Soll der Plan für das Audit abgeschlossen sein, bevor 5.0 veröffentlicht wird?
2) Wenn das Audit Probleme zurückgibt, wie sieht der Plan aus, um diese zu beheben? Wird die Veröffentlichung von 5.0 verzögert, bis sie behoben sind?
3) Gibt es Pläne, wie das Projekt künftig die Zugänglichkeit testen soll?

@tofumatt Wenn Sie Tests von Benutzern mit einer Vielzahl von Behinderungen / Beeinträchtigungen wünschen, habe ich einige Arbeiten mit einer Firma namens Hassell Inclusion durchgeführt, die diese Art von Tests organisieren kann. Sie sind vollständig aus der WordPress-Community entfernt. Das Unternehmen wird von Jonathan Hassell geführt, der früher bei der BBC für die Barrierefreiheit verantwortlich war.

@tofumatt Ich bin auch sehr besorgt über die Barrierefreiheit von WordPress und bin bestrebt, Ihnen zum Erfolg zu

Ich würde denken, wir sollten uns sowohl ATAG als auch WCAG AA und vielleicht WCAG 2.1 statt 2.0 ansehen. Wir können Ihnen auch Empfehlungen und Coaching geben, damit Sie den besten und nachhaltigsten Weg finden, um entdeckte Lücken zu schließen.

Wir sind bequem von Ihrer Entwickler-Community entfernt und kennen WordPress seit vielen Jahren. Ich bin Inhaber aller IAAP-Zertifizierungen und habe über viele Jahre Dutzende solcher Audits auf der WordPress-Plattform sowohl für den privaten als auch für den öffentlichen Sektor durchgeführt. Bitte überprüfen Sie unsere Vertrauenswürdigkeit unter davidberman.com/about, um zu entscheiden, wie wir Ihnen am besten helfen können.

Blöcke verwenden

Ich bin mir nicht sicher, ob das Team, das das Audit durchführen wird, angewiesen werden sollte oder wissen sollte, was ein "Block" ist, zumindest nicht anfangs. Sie sollten sich im gleichen Ausgangszustand wie Benutzer befinden, die Gutenberg zum ersten Mal ohne spezielle Anweisungen verwenden werden. In einer zweiten Phase, wenn sie technisch werden, werden sie wahrscheinlich bereits wissen, was ein Block ist 🙂

Core Publishing Flow

Das Barrierefreiheitsteam ist sich einig, dass das Hauptproblem der Barrierefreiheit in Gutenberg die allgemeine Benutzererfahrung ist. Ich würde vorschlagen, diesen Teil zu erweitern: Er sollte nicht auf den _publihsing_-Fluss beschränkt sein, sondern mehr Aufgaben enthalten, normalerweise diejenigen, bei denen Sie durch die Benutzeroberfläche navigieren und durch die Hauptabschnitte (obere Leiste, Bearbeitungsbereich, Seitenleiste) springen müssen , Panel veröffentlichen). Dies hängt eher mit dem allgemeinen Gutenberg-Design zusammen als mit technischen Implementierungsdetails für die verschiedenen Komponenten. In der Tat ist Zugänglichkeit Design.

Ich möchte einige Aufgaben vorschlagen:

• Baue einen Pfosten mit einer großen Anzahl von Blöcken, sagen wir mindestens 20
• Bearbeiten Sie einen der Absätze in der Mitte des Beitrags
• Ändern Sie die Schriftgröße und die Schriftfarbe und bearbeiten Sie den Inhalt erneut
• Fügen Sie mit den Insertern neue Blöcke hinzu
• Fügen Sie einen Link ein
• eine Erwähnung einfügen
• Blocktyp ändern
• Ändern Sie etwas in den Einstellungen der oberen Leiste und kehren Sie dann zu dem Block zurück, der bearbeitet wurde
• Springen Sie zur Seitenleiste, wechseln Sie zu Dokument- / Blockeinstellungen und kehren Sie dann zu dem Block zurück, der bearbeitet wurde
• Bearbeiten Sie den Post-Permalink
• Machen Sie einen wiederverwendbaren Block
• Hinzufügen und Bearbeiten eines vorhandenen wiederverwendbaren Blocks

Zu berücksichtigende unterstützende Technologien

@tofumatt Ich bin ein bisschen überrascht, dass Sie nur unterstützende Technologien und insbesondere nur Bildschirmleser erwähnen. Zugänglichkeitsbewertungen können nicht nur auf Screenreader-Tests beschränkt werden. Barrierefreiheit ist ein viel umfassenderes Thema und nicht nur auf Behinderungen oder Beeinträchtigungen beschränkt. Es geht darum, das Web für alle zugänglich zu machen.

Selbst wenn wir den Zugang zu Behinderungen und Beeinträchtigungen einschränken wollen, sind sie einfach zu viele, um sie zu zählen. Um nur einige zu nennen: Benutzer von Spracherkennungssoftware, motorische Behinderungen, Sehbehinderung, kognitive Beeinträchtigungen, Anfallsleiden, alternative Eingabegeräte, Aufmerksamkeitsdefizit-Hyperaktivitätsstörung, Legasthenie, Verlust des Kurzzeitgedächtnisses usw. usw. Was ist mit Dingen, die dies können? Nicht als echte "Behinderungen" eingestuft werden, zum Beispiel vorübergehende Beeinträchtigungen, Umweltbeeinträchtigungen, Alterung?

Der menschliche Zustand ist ziemlich instabil, und ich schlage vor, dass Sie überlegen, ob wir alle nur vorübergehend in der Lage sind.

Ich möchte einige Aufgaben vorschlagen:

Diese erweiterte Aufgabenliste scheint gut und realistisch zu sein, was Benutzer tun müssen.

Als Barrierefreiheitsstandards für WordPress-Kernstatus :

Alle neuen oder aktualisierten Codes, die in WordPress veröffentlicht werden, müssen den WCAG 2.0-Richtlinien auf Stufe AA entsprechen.

Daher sollte das Audit dies berücksichtigen. Spezifische Dinge:

1) Alle Funktionen sollten wie erwartet funktionieren, wenn der Browser um 200% gezoomt wird (beachten Sie, dass dies mobile CSS auslösen kann). 1.4.4
2) Alle Funktionen sollten wie erwartet nur mit einer Tastatur 2.1 funktionieren

Es ist wichtig, dass wir uns daran erinnern, dass wir hier suchen, dass alles von allen Benutzern verwendet werden kann. Für einige Benutzer mag es keine großartige Erfahrung sein, darum geht es in Version 1, aber bei unseren Standards geht es darum, sicherzustellen, dass es vollständig verwendbar ist. Alle Software wird mit Fehlern ausgeliefert, und das Wichtigste ist, dass wir über die Fehler Bescheid wissen und die Kompromisse zwischen der Behebung und der Nichtbehebung eingehen.

Vielen Dank an @tofumatt, dass Sie die Durchführung dieses Audits übernommen haben. Ich freue mich darauf, dass es passiert und Gutenberg für alle nutzbar ist.

Bei der Prüfung eines Audits / einer Reihe von Eingabehilfen-Tests war es hilfreich, eine Liste der "Kern" -Funktionen des klassischen Editors zu erstellen, die im neuen Editor nicht zurückgehen sollten:

1. Erstellung / Bearbeitung von Absatztext
2. Erstellung / Bearbeitung von Überschriftentext
3. Erstellung / Bearbeitung von vorformatiertem Text
4. Erstellung / Bearbeitung der Liste mit Aufzählungszeichen
5. Erstellung / Bearbeitung einer nummerierten Liste
6. Erstellung / Bearbeitung eines Zitats ("Blockquote")
7. Textausrichtung für Paragraghen und Überschriften
8. Hinzufügen, Bearbeiten und Entfernen von Links zu Text in Absätzen, Überschriften und Listenelementen
9. Einrücken / Einrücken von Listen / Listenelementen
10. Fett / kursiv / durchgestrichener Text in Absätzen, Überschriften und Listenelementen
11. Hinzufügen einer horizontalen Linie / eines Abstandshalters zum Inhalt
12. Rückgängig wiederholen
13. Einfügen von WordPress "Read More" -Kommentar (Read More Block in Gutenberg)
14. Konvertierung von Absatzinhalten in Listeninhalte
15. Konvertierung von Listeninhalten in Absatzinhalte

Ich denke, das ist es, also habe ich es gesendet.

Meine Liste der zugänglichen Technologien war ziemlich minimal, stimmte zu. Ein Teil davon dreht sich um das Scoping, aber ein Teil davon war, weil es eine unvollständige Liste war, die ich mit der Zeit ergänzen wollte. Ich habe ZoomText zu dieser Liste hinzugefügt und werde anfordern, dass es auch zum Testen verwendet wird.

Ich habe gerade die Aufgabenliste von

Beantwortung einiger Fragen

@bamadesigner :

Derzeit ist geplant, das Audit so schnell wie möglich zu starten und möglichst viele Informationen vor der Version 5.0 zu veröffentlichen, um alle gefundenen Probleme zu beheben und der Version einen Kontext hinsichtlich ihrer Zugänglichkeit hinzuzufügen. In Bezug auf die Verzögerung der Veröffentlichung: Dies hängt vom Problem, der Zeit zur Behebung und den Auswirkungen ab. Meiner Ansicht nach ist es unwahrscheinlich, dass die Veröffentlichung verzögert wird, aber wir sollten diese Brücke überqueren, wenn wir dazu kommen. Ich möchte nicht spekulieren.

In Bezug auf Pläne für zukünftige Barrierefreiheitstests: Das ist eine größere Frage, die nicht mit der Veröffentlichung oder diesem Problem zusammenhängt, daher werde ich hier nicht darauf eingehen. Im Moment bin ich ein Release Lead für 5.0 und ich werde mich dort konzentrieren. nochmal: ich will nicht spekulieren. Aber es ist etwas, worauf ich mich gerne einlasse,

@ LukePettway

Wenn Sie Erfahrung mit Barrierefreiheitstests haben, können Sie Gutenberg entweder testen oder vorhandene Barrierefreiheitsprobleme untersuchen, damit wir wissen, was noch ein Problem ist und worauf Sie sich konzentrieren müssen. Es wäre auch großartig, an Problemen im Meilenstein von Merge: Accessibility zu arbeiten.

@tofumatt Vielen Dank für Ihre Antworten, aber sie sind enttäuschend.

Gutenberg / 5.0 sollte erst veröffentlicht werden, wenn das Audit abgeschlossen ist und festgestellte Probleme behoben sind. Hoffentlich kommt das Audit zurück und sagt, dass es nur wenige Probleme gibt, aber die Entscheidung sollte sein, dass die Veröffentlichung von 5.0 von dieser Feststellung und der zur Lösung erforderlichen Zeit abhängt.

Ich bin nicht mit dem vertraut, was diese November-Frist antreibt, aber die Zugänglichkeit ist zu wichtig. Wenn Sie starten, bevor Sie sicherstellen, dass diese Grundlagen abgedeckt sind, stellen Sie einen gefährlichen Präzedenzfall für die gesamte Community und das Web im Allgemeinen dar. Diese Barrierefreiheit hat nicht die oberste Priorität und kann auf einen späteren Zeitpunkt warten.

WordPress 5.0 ist erst bereit, wenn es verfügbar ist. Keine andere Frist ist wichtiger. Ganz zu schweigen von der Tatsache, dass es gegen die Kernstandards für Barrierefreiheit verstößt.

WordPress 5.0 ist erst bereit, wenn es verfügbar ist.

@amadesigner spricht die Wahrheit.

Das erklärte Ziel von WordPress ist die "Demokratisierung des Publizierens". Das bedeutet im wahrsten Sinne des Wortes, das Publizieren allen zugänglich zu machen. Die Zugänglichkeit ist für dieses Versprechen von zentraler Bedeutung.

Ich hoffe, es ist keine Zweideutigkeit zu sagen, dass ein Ziel und ein Versprechen nicht dasselbe sind und nicht als solche behandelt werden sollten. 😄

Wie bereits erwähnt, begrüße ich alle externen Beiträge zu Barrierefreiheitsfragen und insbesondere zu den Beiträgen zum Meilenstein "Zusammenführen: Barrierefreiheit" (
https://github.com/WordPress/gutenberg/milestone/43).

Wenn bei der Veröffentlichung festgestellt wird, dass Probleme mit der Barrierefreiheit auftreten, kann ich den Vorschlag von @rianrietveld in Trac erneut lesen , um Benutzer vor Hilfstechnologien vor den spezifischen Problemen mit Gutenberg zu und ihnen vorzuschlagen , den klassischen Editor zu verwenden, wenn Gutenberg sie

Ich bin mir nicht sicher, ob es auf jeden Fall mein Anruf sein würde, aber selbst wenn es so wäre: Ich sehe es nicht als eine gute Entscheidung an, die Version 5.0 wegen Bedenken hinsichtlich der Barrierefreiheit zu verschieben, wenn der klassische Editor als Fallback existiert . Das Ziel / Hauptmerkmal von 5.0 ist Gutenberg, das neue Bearbeitungserlebnis. Ich würde es lieber für die Benutzer freigeben, die es für verwendbar halten (was viele, aber nicht alle Benutzer unterstützender Technologien einschließen sollte), und akzeptieren, dass nicht jeder Gutenberg am ersten Tag verwenden kann. Das ist für viele, die inkompatible Plugins verwenden, bereits Realität. Niemand zwingt jemanden, Gutenberg zu verwenden, wenn 5.0 gestartet wird 🙂

Der klassische Editor existiert, ist aber nicht Teil von WordPress , und das ist ein entscheidender Punkt, den man erkennen muss. Das Erfordernis eines Plug-Ins zur Anpassung des Content-Management-Systems an die Benutzerfreundlichkeit ist eine sehr fragwürdige Lösung. Es ist sicherlich das, was ich den Leuten vorgeschlagen habe; Es gibt jedoch viele Situationen, die von dieser Situation nicht gut abgedeckt werden. Dies bedeutet vor allem, dass nur Personen, die Plugins installieren können, Einfluss darauf haben, ob die Site weiterhin so zugänglich ist wie jetzt. Für das Szenario, in dem jemand die Site einfach aktualisiert und sich dann die Autoren anmelden müssen und keine Inhalte mehr veröffentlichen können, ist dies unzureichend. Der klassische Editor sollte keine Alles-oder-Nichts-Option sein, die von der Großzügigkeit eines Site-Administrators abhängt, um sicherzustellen, dass Menschen mit Behinderungen weiterhin veröffentlichen können. Dies ist der Grund, warum es ein Problem mit der Barrierefreiheit ist, wenn der klassische Editor keine Option ist, die in WordPress Core verfügbar ist.

Super-guter Punkt @joedolson , einer, an den ich nicht

Ich würde es lieber für die Benutzer freigeben, die es für verwendbar halten (was viele, aber nicht alle Benutzer unterstützender Technologien einschließen sollte), und akzeptieren, dass nicht jeder Gutenberg am ersten Tag verwenden kann.

Dies ist ein unglaublich ernüchternder Kommentar, und diese Position ist bestenfalls schlechtes Design und im schlimmsten Fall aktiv ableist. Ich hoffe wirklich, dass dies nicht die Lösung ist.

@tofumatt Ich weiß es zu schätzen, dass Sie versuchen, das Richtige zu tun und viele Bedenken auszugleichen, aber ich finde das unglaublich beunruhigend:

Ich bin mir nicht sicher, ob es auf jeden Fall mein Anruf sein würde, aber selbst wenn es so wäre: Ich sehe es nicht als eine gute Entscheidung an, die 5.0-Version wegen Bedenken hinsichtlich der Barrierefreiheit zu verschieben, wenn der Classic Editor als Fallback existiert. Das Ziel / Hauptmerkmal von 5.0 ist Gutenberg, das neue Bearbeitungserlebnis. Ich würde es lieber für die Benutzer freigeben, die es für verwendbar halten (was viele, aber nicht alle Benutzer unterstützender Technologien einschließen sollte), und akzeptieren, dass nicht jeder Gutenberg am ersten Tag verwenden kann.

Sie sagen einer bereits marginalisierten Population von Benutzern, dass Sie WordPress für sie nutzbar machen werden ... irgendwann. Sie sehen, wie entfremdend das ist, richtig?

Aber vielleicht ist die wichtigere Reihe von Fragen folgende:

• Wessen Aufruf ist es zu entscheiden, ob der neue Editor offiziell bereit ist, in den Kern integriert zu werden?
• Welche Faktoren berücksichtigen sie, um diese Entscheidung zu treffen?
• Was müssen wir als Gemeinschaft tun, um die Zugänglichkeit für diesen Entscheidungsprozess von zentraler Bedeutung zu machen?

@tofumatt zur Verdeutlichung: Das Accessibility-Team hat nicht darum gebeten, die Veröffentlichung zu verzögern. Die einzige offizielle Anfrage bestand darin, einen Hinweis für Benutzer mit Barrierefreiheitsanforderungen hinzuzufügen, sie darüber zu informieren, dass noch Probleme zu lösen sind, sie einzuladen, Gutenberg auszuprobieren, aber den Classic Editor zu empfehlen. Der Vorschlag befand sich in https://core.trac.wordpress.org/ticket/44671, das geschlossen wurde 🙁

Ich würde es lieber für die Benutzer freigeben, die es für verwendbar halten (was viele, aber nicht alle Benutzer unterstützender Technologien einschließen sollte), und akzeptieren, dass nicht jeder Gutenberg am ersten Tag verwenden kann.

Cool, großartig, großartiger Können hier. Wie @briandeconinck sagte, entfremden Sie eine ganze Gruppe von Benutzern, nur weil sie Tastatur und Maus (oder Anzeige) nicht richtig verwenden können. Unsere Universität hat viel Arbeit und Mühe darauf verwendet, unsere WordPress-Erfahrung zugänglich zu machen, und wir arbeiten bis heute daran. Es ist äußerst enttäuschend, wenn ein so großes und wichtiges Stück des WordPress-Kerns möglicherweise gestartet wird und ansonsten anders ist.

@afercia Oh, das weiß ich total! Ich wollte mit Sicherheit nicht implizieren, dass die Position des Accessibility Teams darin bestand, die Veröffentlichung zu verzögern. Einige Leute in den Kommentaren hier fragten, ob das alles sei. Es tut mir wirklich leid, wenn ich das falsch geschrieben und dem Team hinzugefügt habe. ❤️

Dieses Problem wurde geschlossen (teilweise, weil es sich um den "Try" -Aufruf handelt, der wegfällt, möglicherweise gab es eine Fehlkommunikation bezüglich seiner Absicht), aber wie hier erwähnt: Ich bin damit einverstanden, das Konzept der Warnung von Benutzern vor Assistenten umzusetzen Technologien, wenn Gutenberg nicht für sie arbeiten wird.

Ich stimme anderen in diesem Thread zu, die sich für eine verbesserte Zugänglichkeit vor 5.0 einsetzen. Ich möchte auch hinzufügen, dass die Veröffentlichung von 5.0 vom Rest des WP-Ökosystems als grünes Licht interpretiert wird, dass Gutenberg für den realen Einsatz bereit ist. An diesem Punkt werden wir einen Zustrom von Plugins und Themen sehen, die Gutenberg erweitern und sich auf die Standards stützen, die es als Blaupause für ihre eigene Entwicklung aufstellt.

Als Entwickler im WP-Ökosystem seit mehreren Jahren schaue ich ständig auf den WordPress-Kern, um sicherzustellen, dass die Zugänglichkeit, die Stile und das Verhalten meiner eigenen Plugins mit denen des Kerns übereinstimmen. Wenn 5.0 veröffentlicht wird, bevor Probleme mit der Barrierefreiheit behoben werden, sucht die WordPress-Community nach einem unzugänglichen Entwurf als Modell für ihre eigene Entwicklung. Stellen wir sicher, dass die Blaupause den Standards entspricht, die wir für alles andere festgelegt haben.

@tofumatt Schlagen Sie vor, dass das Aufstellen einer Warnung, dass unterstützende Technologien mit Gutenberg nicht funktionieren, eine vernünftige Lösung ist, da der Core Editor zu einem Plugin wird, das installiert werden muss, zusammen mit der Tatsache, dass der Benutzer dies möglicherweise hat oder nicht die Fähigkeit / das Wissen, dieses Plugin zu installieren? Ich hoffe, ich verstehe das falsch. Können Sie das bitte klarstellen?

Wie immer vielen Dank für Ihre Zeit!

Das Classic Editor-Plugin wurde als temporäre Ausfahrt für diejenigen entwickelt, die nicht bereit sind, zu Gutenberg zu wechseln. Es ist bestenfalls dürftig und wird schnell zu einem Problem für Entwickler, die Lösungen für zwei verschiedene Editoren bereitstellen müssen. Das Classic Editor-Plugin kann nicht einmal eine vorübergehende Abzweigung für Personen mit Barrierefreiheitsbedürfnissen sein, da es buchstäblich eine minderwertige Erfahrung aufgrund von Behinderung bietet. Die Mindestanforderung für den WordPress-Administrator ist WCAG 2.0 AA. Alles andere, einschließlich eines Plugins, um die Erfahrung zu verschlechtern, verstößt gegen unsere eigenen Richtlinien. Ich gehe diesbezüglich eine harte Linie, weil wir Regeln haben. Wir versenden keinen Code, der nicht unseren eigenen Konditionsstandards entspricht. Die Zugänglichkeit sollte nicht anders sein.

Wie viele andere hier schätze ich die Bemühungen der Community und der Menschen, die ihre Zeit und Mühe in Gutenberg stecken, um es für 5.0 zugänglich zu machen. Gutenberg ist einfach nicht bereit, weil es nicht vollständig zugänglich ist. Ende der Geschichte.

Bis Gutenberg zugänglich ist, sollte es nicht in den Kern zusammengeführt werden. Der Gedanke, Gutenberg für "diejenigen, die es verwenden können" in den Kern zu bringen, ist nicht nur kurzsichtig, sondern auch schrecklich ausschließend - ich würde sogar sagen, dass dies eine separate, aber gleichwertige Erfahrung für WordPress-Benutzer schafft (und normalisiert). Es ist ein schrecklicher Präzedenzfall und schrecklich arrogant.

Ich hoffe, dass sich die Community durchsetzt und das Kernteam davon überzeugt, die Veröffentlichung von 5.0 zurückzuhalten, bis es vollständig zugänglich ist. Zu diesem Zweck ist eine unabhängige Prüfung eine gute Idee und sollte fortgesetzt werden.

Dieses Problem wurde eingereicht, um meine Arbeit an der Barrierefreiheitsprüfung zu veröffentlichen, um mitzuteilen, dass dies geschehen soll, und um die Freigabe dieser Prüfung in einem Blogbeitrag zu verfolgen. Es ist nicht als Diskussionspunkt darüber gedacht, was als Release-Blocker für WordPress 5.0 angesehen werden sollte. Ich habe die Meinungen der Leute zu diesem Thema notiert und werde sie an @m weiterleiten , der der Release-Lead für WordPress 5.0 ist. Mein Verständnis ist:

1. Ich habe kein Veto gegen 5.0 Versand, aber selbst wenn ich es getan hätte:
2. Ich bin immer noch nicht davon überzeugt, dass es genügend Probleme mit der Barrierefreiheit gibt, die eine Veröffentlichung verhindern

Wenn sich der zweite Punkt ändert, werde ich diese Informationen weiterleiten. Ich habe vor, Anwalt zu werden, aber ich lege keine Zeitpläne fest und ich habe auch keine soliden Daten zur Barrierefreiheit. Das ist der Punkt des Audits: Wir können also von einem Ort mit harten Daten aus sprechen. 🙂

Vielen Dank für all die Beiträge, aber da diese Diskussion vom beabsichtigten Umfang nicht mehr zum Thema gehört, sperre ich die Konversation dieses Problems vorerst. Ich werde es offen lassen und Updates rund um das Audit veröffentlichen.

Es gab einige zusätzliche Diskussionen zu diesem Problem auf Slack: https://wordpress.slack.com/archives/C02RP4X03/p1539300688000100

Ich denke, es hat sich gelohnt, hier darauf einzugehen, damit jeder, der das Problem bisher verfolgt hat, über das Geschehen auf dem Laufenden gehalten werden kann. @ mor10 wies auch darauf hin, dass er der Ansicht sei, dass die Ergebnisse der Prüfung nicht klar kommuniziert würden. Es scheint, dass es in diesem Beitrag viele Missverständnisse in Bezug auf meine Kommunikation gegeben hat: Ich entschuldige mich dafür. Ich werde versuchen, die Dinge so gut wie möglich zu beantworten.

Ich denke, ein Großteil der Verwirrung im geschlossenen Ticket beruht auf mangelnder Klarheit darüber, was passiert, wenn ein Audit nicht rechtzeitig zum Release-Zeitplan abgeschlossen werden kann oder ein Audit zurückkommt und wesentliche Probleme anzeigt, die behoben werden müssen. Aufgrund Ihrer Kommentare ist unklar, ob Sie denken:

• a) Alle Probleme werden innerhalb der aktuellen Zeitachse behoben
• b) Probleme, die nicht innerhalb der Frist behoben werden können, werden auf 5.0.1 verschoben
• c) Wenn wesentliche Fragen aufgeworfen werden, wird der Zeitplan verschoben.

Was Sie bisher gesagt haben, scheint nur a oder b anzugeben, sind Optionen, aber wie ich sagte, es ist unklar. Die Idee, dass die Zugänglichkeit zur Einhaltung einer Veröffentlichungsfrist eingeschränkt wird, ist das, worüber sich die Menschen seit über einem Jahr Sorgen machen, und diese Bedenken wurden nicht ausgeräumt.

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

Basierend auf den aktuellen Problemen im Meilenstein ist es mein Ziel , alle Probleme zu beheben, aber ich denke nicht, dass sie alle Release-Blocker darstellen. Ich werde besser wissen, wie ich sie näher an das endgültige Tagging heranführen kann, daher kann ich dem jetzt nicht viel hinzufügen. Im Moment denke ich, dass es sich um eine realistische Liste von Themen handelt, die vor 5.0 am wichtigsten sind

Probleme, die nicht behoben werden können, sollten auf die nächste WordPress / Gutenberg-Version verschoben werden, ja.

Ich glaube nicht , dass es etwas in dort zur Zeit , dass garantiert die Veröffentlichung verzögern.

Dieses Problem wurde gesperrt, da mein Ziel bei der Erstellung dieses Problems war:

1. meine Arbeit im Auftrag eines Audits zu teilen
2. um meine Arbeit zu teilen und einen Blog-Beitrag über Make / Accessibility zu erstellen, der diesen Beitrag umgibt

Ich freue mich über Beiträge zur Durchführung des Audits und über Probleme im Zusammenhang mit meiner "Backup" -Empfehlung des Classic Editors, wenn die Barrierefreiheit in Gutenberg ein ernstes Problem darstellt. Es ist im Moment erwähnenswert, dass es keinen Bericht gibt, auf den Gutenberg hinweist und der aus Gründen der Zugänglichkeit dagegen empfiehlt. Ich habe es nicht gesehen und niemand ist hier mit einem verbunden. Die Stimmung hier ist um spekulative Misserfolge. Diese Art von Sprache ist demotivierend für die Gutenberg-Entwickler, die hart arbeiten und einen Mangel an vermuteten guten Absichten sehen.

Die Rolle des Accessibility Release Lead ist neu und wurde mir letzte Woche übergeben . Gleichzeitig wurde ein Veröffentlichungstermin am 19. November 2018 festgelegt . Mein erster Instinkt bei der Zuweisung der Release-Hauptrolle war der Versuch, das Geld von Automattic für die Erstellung eines Audits als Zeichen unseres Engagements für Barrierefreiheit auszugeben und ein konkretes Gefühl für die tatsächlichen Probleme zu schaffen, mit denen Gutenberg bei der Arbeit mit assistiver Technologie konfrontiert ist. Ich arbeite an einer eingeschränkten Zeitachse und teile Informationen so gut ich kann und gegebenenfalls mit dem Vorbehalt, dass ich Unternehmen, mit denen ich im Gespräch bin (ich halte das für unprofessionell), nicht öffentlich bewerten möchte, und ich muss die sortieren Beschaffungsseite der Dinge mit Automattic (dieser Aspekt dieser Prüfung kann meines Wissens nicht öffentlich sein).

Ich bin nicht das letzte Wort in einer Veröffentlichung. Ich habe @m zu diesem Thema cc'd ; Er ist der Release-Lead und ruft dazu auf, die Veröffentlichung aufgrund von Problemen mit der Barrierefreiheit zu verzögern. Es wäre nicht meine Empfehlung, die Veröffentlichung aufgrund der derzeit bekannten Probleme zu verzögern, selbst innerhalb des Meilensteins.

Ja, es gibt insgesamt ein größeres Problem mit barrierefreiem Design, aber die Entwicklungs- und Designteams berücksichtigen diese Probleme. Ich beschäftige mich mehr mit Dingen, die wir erkennen und für weniger testen, weil wir größtenteils ein Team von Benutzern mit guten Fähigkeiten sind.

Einige Leute auf Slack haben mir ihre Beobachtung zum Ausdruck gebracht, dass das Problem so aussah, als würde es um Feedback und eine breitere Diskussion bitten. Das war nicht meine Absicht, diese Ausgabe einzureichen, sondern einfach alles offen zu halten; Da wir in GitHub hauptsächlich an diesem Projekt arbeiten, dachte ich, es wäre der beste Ort dafür. Ich habe das Problem gesperrt, weil die Diskussion, obwohl sie möglicherweise für das gesamte Projekt gültig ist, ablenkt:

1. das vorliegende Problem (und Audit und ein Blog-Beitrag mit Ergebnissen)
2. das Team als Ganzes, das durch Issue-Kommentare benachrichtigt wird

Problemkommentare sollten umsetzbar und diskret sein und hoffentlich neue Informationen liefern. Ich hatte das Gefühl, dass die Kommentare hier diese Kriterien nicht erfüllen, deshalb wollte ich die Diskussion auf das vorliegende Thema beschränken.

Ich habe dieses Problem im Meilenstein abgelegt, weil ich möchte, dass es für WordPress 5.0 auftritt. Wenn dies nicht möglich ist, muss es leider verschoben werden. Ich versuche mein Bestes, um unter einem begrenzten Zeitplan mit begrenzten Ressourcen zu arbeiten. Nicht um "Patches willkommen" zu heißen, aber wenn Barrierefreiheit für Sie wichtig ist, würde ich es sehr begrüßen, wenn Sie Ihre Aufmerksamkeit auf unsere Liste offener Barrierefreiheitsprobleme lenken würden, insbesondere auf die in der Liste Meilenstein: Barrierefreiheit .

Ich möchte dieses Problem offen halten, da ich meine Fortschritte bei der Prüfung verfolgen möchte. Wenn Sie weitere Diskussionen zum Thema Barrierefreiheit führen möchten, ist die Schaltfläche "Neues Problem" immer vorhanden. Ich stelle fest, dass während ich diesen Kommentar schrieb, bereits eine neue Ausgabe eingereicht wurde (# 10537): das ist cool 😄

Vielen Dank an alle und einen schönen Freitag. ❤️

@tofumatt Können Sie die Informationen zum Audit aktualisieren?

Das Erste ist das Erste: Ich habe in der vergangenen Woche mit mehreren Unternehmen über die Durchführung eines Audits gesprochen und von ihnen Vorschläge erhalten.

Ich werde sagen, dass ich ziemlich detaillierte Vorschläge erhalten habe von:

• Level Access
• Deque Systems

Und weniger detailliert, aber immer noch gute Antworten von:

• Die Paciello-Gruppe
• Heydon Pickering

Sie schienen alle ihre Sachen zu kennen. Ich werde die Details der Vorschläge nicht teilen, weil ich das nicht für angemessen halte, aber ich habe unglückliche Neuigkeiten in Bezug auf die Prüfung. 😢

Zumindest vorerst hat Automattic beschlossen, auf die Durchführung eines Barrierefreiheits-Audits für Gutenberg zu verzichten. Die Hauptgründe sind:

1. Ein Audit ist aufgrund unseres Veröffentlichungszeitplans nicht umsetzbar, da…
2. Das Audit hat keinen Einfluss auf den Release-Zeitpunkt.
3. Es wäre klüger, in Zukunft ein Audit auf einem weniger überstürzten Zeitplan zu untersuchen

Ich bin zuversichtlich, dass wir in Zukunft eine Prüfung prüfen werden, aber leider wird dies nicht vor dem Zusammenführungsvorschlag geschehen, und daher schließe ich dieses Problem, da es nicht behoben werden kann. Ich möchte immer noch über den Zustand der Gutenberg-Zugänglichkeit bloggen, sowohl über die guten als auch über die schlechten. Wir haben erst diese Woche einige Verbesserungen an der Tastaturnavigation, dem Farbkontrast, dem Fokusverhalten und der Datums- / Farbauswahl vorgenommen.

Tut mir leid, dass ich mir Hoffnungen gemacht habe und dann die Community in diesem Fall gescheitert bin. 😞

Nur eine kurze Anmerkung, um zu sagen, dass ich gerne sehen würde, dass dies fortgesetzt wird, auch wenn es nach 5.0 passiert.
Gibt es einen Grund, es nicht offen zu lassen und es einem anderen Meilenstein oder einer anderen Zukunft zuzuweisen?

Wir waren in letzter Zeit sicher in einer emotionalen Achterbahnfahrt, nicht wahr? 🎢

Zunächst einmal vielen Dank an alle für Ihre Arbeit. 💖 Ich weiß, dass es manchmal nicht einfach ist, ein Anwalt für Barrierefreiheit zu sein. Es kann sich wie ein ständiger Kampf aufwärts anfühlen. Bitte beachten Sie, dass Sie einen Einfluss haben: vom persönlichen (ich habe viel über Barrierefreiheit von den Leuten gelernt, aus denen das WordPress Accessibility-Team besteht) bis zum grundlegenden (menschenzentriertes Design ist eine wesentliche Facette moderner Designpraktiken ).

Ich mag die Idee eines professionellen Audits sehr, obwohl ich mich nicht daran erinnere, dass wir jemals eines davon in WordPress durchgeführt haben, sicherlich keine Bedingung für eine Veröffentlichung. Ich würde gerne sehen, dass so etwas irgendwann passiert. WordPress hat immer versucht, den größten Teil der Barrierefreiheit zu erreichen, indem es sich an gemeinsame Muster und Semantiken hielt. Der Unterschied wurde durch die wichtigsten Bemühungen von Freiwilligen abgedeckt, die alle Mitglieder des Accessibility-Teams beim Testen und Einreichen umsetzbarer Fehlerberichte waren. Gutenbergs Schritt zu einer vollständig JavaScript-basierten Anwendung hat es schwieriger gemacht, diese Muster anzuwenden, aber wir können zusammenarbeiten, um neue Muster zu erstellen, eine neue Basislinie.

Wir wissen, dass Gutenberg noch mehr poliert werden muss - was wir tun! - und wie alles wird es Probleme geben, die wir in den kommenden Monaten und Jahren weiter wiederholen werden. Aufgrund vieler Gespräche scheint es, dass die kritischsten Probleme bereits eingereicht wurden, viele von ihnen wurden behoben, und wir werden sie weiter beheben, sobald sie auftreten.

Es gibt eine Reihe von Problemen , die noch nicht erreicht wurden (vielen Dank insbesondere an alle, die in der letzten Woche oder so Probleme eingereicht haben!). Es wäre gut, ein Bug-Scrub zu sehen, um diese Probleme zu lösen und Prioritäten zu setzen. Wir können sicherstellen, dass die Probleme behoben werden, die Menschen daran hindern, Gutenberg zu verwenden, und uns dann auf die Probleme konzentrieren, die die Verwendung für Benutzer erleichtern sollen.

Ich habe dies bereits erwähnt, aber es muss wiederholt werden: WordPress 5.0 ist nicht die Ziellinie, sondern die Starterpistole. Viele von uns in diesem Thread haben jahrelang an WordPress zusammengearbeitet, bevor Gutenberg anfing, und ich hoffe, wir werden in den kommenden Jahren gemeinsam an WordPress arbeiten. Wir haben im Laufe der Jahre viele neue Funktionen in WordPress gesehen, und keine davon ist so geblieben wie bei ihrer ersten Veröffentlichung. Wir sind auf Herausforderungen gestoßen, die die meisten anderen Projekte als unüberwindbar abschreiben würden, aber wir haben sie zum Laufen gebracht.

Die Mission von WordPress besteht weiterhin darin, das Publizieren zu demokratisieren. Bei Barrierefreiheit geht es darum, Dinge für Menschen zum Laufen zu bringen, die historisch unglaublich marginalisiert waren. Diese sind nicht nur kostenlos, die Mission von WordPress erfordert von Natur aus, dass sie zugänglich sind.

Was wir in WordPress 5.0 veröffentlichen, ist nicht in Stein gemeißelt, wir werden es weiterhin reparieren, überarbeiten, daraus lernen und es verbessern. Gutenberg ist das Fundament, auf dem wir die nächste Generation des Webs aufbauen können, und das Potenzial zur Verbesserung der Zugänglichkeit des gesamten Webs ist ebenfalls vorhanden. Jede Komponente, jeder Block, jede Schnittstelle sollte vollständig zugänglich sein, und jedes Plugin und Thema sollte letztendlich in der Lage sein, dies zu nutzen. Die Gutenberg-Generation sollte standardmäßig eine zugängliche Erfahrung bieten. Darüber hinaus sind die Farbkontrastprüfung und die Warnungen zur Überschriftenhierarchie gute Beispiele dafür, wie Gutenberg das Erstellen barrierefreier Inhalte zum Standardverhalten machen kann.

Ich habe dieses Problem freigeschaltet, erneut geöffnet und einen Meilenstein für die Zukunft gesetzt, aber wir können es zu einem späteren Zeitpunkt problemlos auf einen genaueren Meilenstein verschieben. Ich habe eine spezielle Bitte, dass wir alle versuchen, beim Thema zu bleiben und uns auf produktive Gespräche zu konzentrieren. Ich würde gerne sehen, wie wir das nehmen, was hier begonnen wurde, und einen Rahmen für ein Qualitäts-Barrierefreiheits-Audit finden, das sich auf den Umfang der Gutenberg-Phase 2 und darüber hinaus ausweiten lässt. Wir sind vielleicht noch nicht da, aber wir werden es sein. ❤️

Verwandte # 10537.

WordPress 5.0 ist nicht die Ziellinie, sondern die Starterpistole.

Letztendlich scheint diese Starterpistole jedoch nur für diejenigen ohne unterschiedliche Fähigkeiten zu funktionieren. Eine Starterpistole funktioniert in der Praxis, weil das Geräusch laut genug ist, um ein Nachlaufen in der Luft zu erzeugen, das gehörlose Menschen fühlen können, und weil es einen Blitz / Rauch erzeugt, den sie sehen können. es macht ein Geräusch für Blinde zu hören. Eine Starterpistole ist für jedermann zugänglich; Gutenberg scheint nicht zu sein.

Indem Sie sich weigern, Gutenbergs Veröffentlichung erst nach Durchführung eines a11y-Audits anzuhalten, sagen Sie effektiv jedem, dass Gutenberg physisch nicht verwendet werden

Ich habe das Label "Needs Accessibility Feedback" für Probleme erstellt, für die sich jemand mit Barrierefreiheitskenntnissen anmelden muss. Da dieses Problem jedoch nicht umsetzbar ist, entferne ich das Label 😄

Niemand sagt so etwas, @cgrymala. Wie bereits erwähnt, war eine professionelle Prüfung der Barrierefreiheit nie erforderlich, damit eine Funktion in der Geschichte von WordPress zusammengeführt werden konnte. Ich würde sicherlich gerne ein Audit sehen, aber zu schreiben, dass ein Mangel an Audit "unverantwortlich ... peinlich und gefährlich" ist, ist die Art von Übertreibung, die einem konstruktiven Dialog im Wege steht.

Ich werde meine Anfrage aus meinem früheren Kommentar wiederholen, bitte bleiben Sie beim Thema und konzentrieren Sie sich auf produktive Gespräche .

Genauer gesagt, ein Mangel an Audit hindert uns nicht daran, Probleme zu beheben. Wenn Barrierefreiheit für Sie wichtig ist, wenn Sie (oder jemand, den Sie kennen) unterstützende Technologie verwenden, ist jetzt ein ausgezeichneter Zeitpunkt, um Fehler zu testen und zu melden.

@pento , ich habe nicht bemerkt, dass jemand argumentiert, dass eine Prüfung Präzedenzfall war? Das scheint ein Strohmann-Argument zu sein, und basierend auf diesem Thread war der Präzedenzfall einfach nicht die Entstehung der Prüfungsidee.

Das Audit wurde von @tofumatt vorgeschlagen, da es guten Grund zu der Annahme gibt, dass Gutenberg nicht so zugänglich ist, wie es nach den eigenen Standards von WordPress sein sollte. Warum erwarten Sie, dass die Community ohne ein unabhängiges Audit oder auch nur ein _A_ Audit plötzlich glaubt, dass Gutenberg zugänglich ist? Das Fehlen einer Prüfung ist nicht unverantwortlich und gefährlich, aber diese Art der Entscheidungsfindung und des diktatorischen Managements ist es.

Angesichts der Hürden bei der Authentifizierung denke ich nicht, dass die Einführung in den Kern Vorteile für WP bietet, die über das hinausgehen, was die Community vom Plugin erhält. Ich glaube nicht an den gegenwärtigen Zustand, dass der Nutzen die Kosten überwiegt, und wir sollten uns auf der Seite der Einfachheit irren.

Das hat @m während der WP API-Debatte gesagt. Dies ist ein weiteres Beispiel für die Heuchelei in diesem Recyclingzyklus, beginnend mit der Tatsache, dass das Unternehmen "Fristen sind nicht willkürlich" sich weigerte, einen Veröffentlichungstermin für 5.0 festzulegen, bis es einen fand, den es mochte. Zu diesem Zeitpunkt gab es keinen Raum für Debatten . Ich liebe Gutenberg und benutze es jeden Tag. Es bietet einen hohen Wert als Plugin, und gemäß Matts eigener Heuristik sollten wir uns auf der Seite der Einfachheit irren, bis es wirklich fertig ist.

Die Barrierefreiheit ist für viele Personen in diesem Thread wichtig, die Zeit, Unterstützung und Geld angeboten haben, um uns bei der Bewältigung dieser Sackgasse zu helfen. Es ist unaufrichtig für Sie, vorzuschlagen, dass wir Probleme beheben würden, wenn wir uns wirklich darum kümmern würden.

In Bezug auf die Gründe für die Absage des Audits:

Ein Audit ist aufgrund unseres Veröffentlichungszeitplans nicht umsetzbar, da…
Das Audit hat keinen Einfluss auf den Release-Zeitpunkt.
Es wäre klüger, in Zukunft ein Audit auf einem weniger überstürzten Zeitplan zu untersuchen

Selbst wenn die Idee eines Audits durch Dritte tot ist, wäre die Prüfung von Gutenberg auf Zugänglichkeitsmittel implizit in der Idee von https://github.com/WordPress/gutenberg/issues/10537 enthalten . Die Tatsache, dass Automattic bereit ist, Gutenberg ohne selbst auferlegte Standards für die Barrierefreiheit für Core freizugeben, ist äußerst problematisch . Letztendlich bin ich enttäuscht, daran erinnert zu werden, dass die Interessen von Automattic letztendlich in Bezug auf die Entwicklung und Veröffentlichung von Gutenberg über die der Community hinausgehen.

In diesem Thread geht es um:

1. Durchführung eines Audits
2. Einreichung von Fragen basierend auf der Prüfung
3. Veröffentlichung der Ergebnisse als Bericht im Make / Accessibility-Blog

Wir erkennen die Nützlichkeit eines Audits an und die Leute möchten, dass eines durchgeführt wird. Bitte bewahren Sie Kommentare zum Prozess auf:

1. Durchführung des Audits
2. Umfang des Audits
3. Ergebnisse der Prüfung

Ich verstecke Kommentare außerhalb des Themas, die das Gesagte erneut analysieren und die Bedeutung eines Audits hervorheben. Ich würde gerne eine durchgeführt sehen. Da sind wir uns alle einig. Bitte halten Sie Kommentare zum Thema, produktiv und stellen Sie sicher, dass sie neue Informationen liefern / das vorliegende Problem ergänzen.

@davisshaver Bitte WordPress-Etikette , insbesondere:

Beiträge zum Open Source-Projekt von WordPress kommen der gesamten WordPress-Community zugute, nicht bestimmten Unternehmen oder Einzelpersonen. Alle als Mitwirkender ergriffenen Maßnahmen sollten im besten Interesse der Gemeinschaft erfolgen.

Das Open Source-Projekt von WordPress ist eine von Freiwilligen betriebene Community. Selbst in Fällen, in denen Mitwirkende von Unternehmen gesponsert werden, wird diese Zeit zugunsten der gesamten Open Source-Community gespendet.

Während @pento , @tofumatt , @m und andere von Automattic gespendet werden, arbeiten sie für die Verbesserung des Projekts. Automattic ist nicht derjenige, der entscheidet, wann Gutenberg veröffentlicht wird.

Die Prüfung kann und wird fortgesetzt, wie von @pento angegeben :

Jetzt ist ein ausgezeichneter Zeitpunkt, um Fehler zu testen und zu melden.

Alles, was getan werden kann, um zu diesem Test- und Berichterstattungsprozess beizutragen, ist von Vorteil. Es gibt eine Reihe älterer Probleme, bei denen mithilfe von Tests festgestellt werden kann, ob es sich immer noch um ein Problem handelt, für dessen Test keine spezielle Hilfstechnologie erforderlich ist. Dies wäre eine große Hilfe und zum Teil eine unabhängige Prüfung.

Mir war nicht bewusst, dass Matt als Release Lead von WordPress.org seine treuhänderische Verantwortung gegenüber Automattic fallen ließ. Während Sie argumentieren könnten, dass der Konflikt minimal ist oder dass Matt aktiv daran arbeitet, den Konflikt zu mildern, ist die von Ihnen zitierte WordPress-Etikette eine Empfehlung und keine Beschreibung der Welt ... Letztendlich gibt es einen Konflikt.

Ich bin mir sicher, dass im Moment viele Leute dieses Thema lauern, und ich werde sagen, wenn Sie interessiert sind und helfen möchten, aber noch keine unterstützende Technologie verwendet haben (Screenreader), nehmen Sie an der Diskussion unter https: // make teil .wordpress.org / chat / im Barrierefreiheitskanal. Fühlen Sie sich frei, mich sogar mit einem DM zu erreichen. Sie werden überrascht sein, wie einfach es ist, NVDA / Voice Over / JAWS einzurichten, damit Sie mit dem Testen beginnen können.

Darüber hinaus stehen zahlreiche Tools zum Testen der WCAG-Anforderungen zur Verfügung:
Chromaxt:
https://chrome.google.com/webstore/detail/axe/lhdoppojpmngadmnindnejefpokejbdd

Kontrastprüfung für WCAG: https://chrome.google.com/webstore/detail/wcag-contrast-checker/plnahcmalebffmaghcpcmpaciebdhgdf?hl=de

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

Derzeit sind 113 offene Probleme mit dem Barrierefreiheits-Label offen:
https://github.com/WordPress/gutenberg/labels/Accessibility

Ob wir den aktuellen Entscheidungen zustimmen oder nicht, ich denke, wir können uns alle einig sein, dass es noch viel Arbeit gibt, an der wir alle mitwirken können, um bei der Lösung zu helfen. Selbst wenn keine offizielle Prüfung vorliegt, kann die Community dazu beitragen, eine zugänglichere Erfahrung zu bieten.

Dieses Problem wurde eingereicht, um meine Arbeit an der Barrierefreiheitsprüfung zu veröffentlichen, um mitzuteilen, dass dies geschehen soll, und um die Freigabe dieser Prüfung in einem Blogbeitrag zu verfolgen. Es ist nicht als Diskussionspunkt darüber gedacht, was als Release-Blocker für WordPress 5.0 angesehen werden sollte. Ich habe die Meinungen der Leute zu diesem Thema notiert und werde sie an @m weiterleiten , der der Release-Lead für WordPress 5.0 ist. Mein Verständnis ist:

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

Wenn sich der zweite Punkt ändert, werde ich diese Informationen weiterleiten. Ich habe vor, Anwalt zu werden, aber ich lege keine Zeitpläne fest und ich habe auch keine soliden Daten zur Barrierefreiheit. Das ist der Punkt des Audits: Wir können also von einem Ort mit harten Daten aus sprechen. 🙂

Vielen Dank für all die Beiträge, aber da diese Diskussion vom beabsichtigten Umfang nicht mehr zum Thema gehört, sperre ich die Konversation dieses Problems vorerst. Ich werde es offen lassen und Updates rund um das Audit veröffentlichen.

Buchstäblich jede Person mit Behinderungen, die Gutenberg sowohl kürzlich als auch zu Beginn getestet hat, hat Blockierungsprobleme darauf hingewiesen, warum es nicht zugänglich ist. Benutzertests sind für die Barrierefreiheit genauso wichtig wie die AA-Konformität der WCAG 2.0-Stufe. Wahrscheinlich sollte an dieser Stelle WCAG 2.1 AA stehen, aber WCAG 2.0 bringt Sie immer noch viel näher an den Ort, an dem Sie sein müssen. Zu sagen, dass Sie keine Daten haben, ist bestenfalls ungenau.

Das Fehlen eines Audits ist in diesem Fall unverantwortlich, da für den Anfang im Gegensatz zu WordPress in der Vergangenheit ein Framework ausgewählt wurde, das nicht sofort mit barrierefreien Komponenten ausgestattet ist, und Sie das Dokument im Gegensatz zu früheren WordPress-Programmen stark ändern Das Objektmodell mit Gutenberg sowie das Entfernen von Dingen aus dem Eingabehilfenbaum und im Fall von Browsern sind das DOM und der Eingabehilfenbaum buchstäblich die Art und Weise, wie die unterstützende Technologie Informationen abruft, um sie zu interpretieren. Selbst wenn Sie die assistive Technologie auslassen, wie Gutenberg derzeit steht, ist die kognitive Belastung enorm. Das klassische Editor-Plugin ist ein völlig inakzeptabler Ersatz. Für den Anfang ist es Site-weit. Wenn also eine Site Gutenberg verwendet und ich etwas mit Inhalten tun muss, kann ich das nicht auf Benutzerbasis tun, und ich kann das klassische Editor-Plugin nicht installieren, meine Arbeit erledigen und dann deinstallieren es und erwarten, dass sich alles so verhält, wie es sollte, sobald die Rückkehr zu Gutenberg stattfindet. Und ja, ich habe das getestet. Die Tatsache, dass die Barrierefreiheit nachträglich verlassen wird, ist buchstäblich der Grund, warum WordPress in das Chaos geraten ist, in dem es sich 2011/2012 befand, als das Barrierefreiheitsteam zum ersten Mal auf den Weg gebracht wurde. Und das Projekt macht buchstäblich wieder genau den gleichen Fehler und bittet uns zu vertrauen, dass es irgendwann wieder richtig wird. Es tut mir leid, aber wie oft müssen Menschen mit Behinderungen zum Wohle der Allgemeinheit in den hinteren Teil des Busses geschickt werden? Wie oft müssen wir uns mit vielen hübschen Worten über Barrierefreiheit zufrieden geben, darüber, wie wir versprechen, dass wir es beim nächsten Mal besser machen werden, nur um herauszufinden, wenn es um Messingnägel geht, dass Barrierefreiheit wirklich keine ist Priorität?

Zumindest vorerst hat Automattic beschlossen, auf die Durchführung eines Barrierefreiheits-Audits für Gutenberg zu verzichten. Die Hauptgründe sind:

1. Ein Audit ist aufgrund unseres Veröffentlichungszeitplans nicht umsetzbar, da…
2. Das Audit hat keinen Einfluss auf den Release-Zeitpunkt.
3. Es wäre klüger, in Zukunft ein Audit auf einem weniger überstürzten Zeitplan zu untersuchen

@tofumatt @pento Können Sie klarstellen, ob sich die hier erwähnte Zeitleiste auf ein Veröffentlichungsdatum vom 19. November 2018 oder 22. Januar 2019 bezieht, wie im vorgeschlagenen Umfang und Zeitplan von WordPress 5.0 angegeben ?

Das Datum des 22. Januar 2019 würde mehr als drei Monate zwischen heute und der Veröffentlichung von 5.0 ermöglichen, um eine Prüfung abzuschließen und Maßnahmen zu ergreifen. Die oben genannten Gründe deuten darauf hin, dass wir ein Audit nicht abschließen und die Zugänglichkeit in drei Monaten erheblich verbessern können. Wenn dies zutrifft, ist dies umso mehr ein Grund, den Prozess jetzt zu starten und auf das Audit zu reagieren, indem so viele Probleme wie möglich vor Version 5.0 behoben werden.

Die Idee, dass die Zeitleiste nach 5.0 weniger überstürzt wird (wenn sie in den Händen realer Benutzer liegt, die sie am dringendsten benötigen), macht überhaupt keinen Sinn.

Websites, die der WCAG 2.0-Stufe AA entsprechen, aber mit Gutenberg bearbeitete neue Inhalte nicht kompatibel sind, wenn 5.0 veröffentlicht wird, lösen einen legalen Albtraum aus.

Vielen Dank an alle, die hier bisher kommentiert und die Diskussion zum Thema geführt haben. Ich weiß das wirklich zu schätzen: Da in WordPress 5.0 so viel los ist, kann ich die Zeit, die dieses Problem verdient, wirklich beiseite legen. 🙂

@amandarush : Du hast einige Bedenken erwähnt, ich werde versuchen, sie alle zu beantworten, aber bitte lass es mich wissen, wenn ich etwas vermisse.

Buchstäblich jede Person mit Behinderungen, die Gutenberg sowohl kürzlich als auch zu Beginn getestet hat, hat Blockierungsprobleme darauf hingewiesen, warum es nicht zugänglich ist.

Ich bin allen wirklich dankbar, die diese Probleme gemeldet haben. Ich hatte gedacht, dass wir diese Probleme vernünftigerweise angegangen sind, als sie auftauchten, aber es gibt eindeutig mehr zu tun. Wenn @tofumatt sich auf "keine Daten haben" bezieht, glaube ich, dass er es aus der Perspektive betrachtet, dass wir viele Probleme mit der Barrierefreiheit behoben haben. Wir haben keine vollständige Vorstellung vom aktuellen Stand der Dinge, also wollen wir Machen Sie sich ein klareres Bild von der Schwere der verbleibenden Probleme.

Das Fehlen eines Audits ist in diesem Fall unverantwortlich, da für den Anfang im Gegensatz zu WordPress in der Vergangenheit ein Framework ausgewählt wurde, das nicht sofort mit barrierefreien Komponenten geliefert wird

Beziehen Sie sich hier auf Reagieren? Ich verstehe, dass mit React erstellte Anwendungen für jede andere Bibliothek, die das DOM dynamisch aktualisiert, auf ähnliche Weise zugänglich sind. Vorausgesetzt, wir verwenden die Attribute aria-* angemessen (und stellen eine vorhersehbare Tastaturfokussierung sicher), sollte sie mit unterstützender Technologie verwendet werden können. Ist das nicht richtig?

Das klassische Editor-Plugin ist ein völlig inakzeptabler Ersatz. Für den Anfang ist es Site-weit. Wenn also eine Site Gutenberg verwendet und ich etwas mit Inhalten tun muss, kann ich das nicht auf Benutzerbasis tun, und ich kann das klassische Editor-Plugin nicht installieren, meine Arbeit erledigen und dann deinstallieren es und erwarten, dass sich alles so verhält, wie es sollte, sobald die Rückkehr zu Gutenberg stattfindet.

Vielen Dank, dass Sie diesen Anwendungsfall angesprochen haben. Dies ist ein gutes Beispiel dafür, wo das Classic Editor-Plugin derzeit fehlschlägt. Wir können sicherlich eine Option pro Benutzer hinzufügen.

Und das Projekt macht buchstäblich wieder genau den gleichen Fehler und bittet uns zu vertrauen, dass es irgendwann wieder richtig wird. Es tut mir leid, aber wie oft müssen Menschen mit Behinderungen zum Wohle der Allgemeinheit in den hinteren Teil des Busses geschickt werden? Wie oft müssen wir uns mit vielen hübschen Worten über Barrierefreiheit zufrieden geben, darüber, wie wir versprechen, dass wir es beim nächsten Mal besser machen werden, nur um herauszufinden, wenn es um Messingnägel geht, dass Barrierefreiheit wirklich keine ist Priorität?

Es tut mir Leid. Trotz der besten Absichten aller im Gutenberg-Team haben wir nicht genug getan. Ich kann ehrlich sagen, dass die Barrierefreiheit immer eine Priorität war, aber es war keine ausreichend hohe Priorität, und wir haben schlecht kommuniziert, wo die Barrierefreiheit verbessert wurde. Ich habe einige dieser Verbesserungen in meinem früheren Kommentar erwähnt, aber diese Verbesserungen sind nicht von Vorteil, wenn wir die Basiserfahrung nicht erreicht haben.

Natürlich ist eine Entschuldigung ohne Maßnahmen nicht sinnvoll, um sie richtig zu machen. Deshalb schlage ich Folgendes vor. Derzeit sollen so viele Barrierefreiheitsprobleme wie möglich priorisiert und behoben werden. Wir haben bereits Hunderte behoben, und für einige der offenen Probleme werden bereits Korrekturen durchgeführt. Wir werden natürlich testen, aber wir brauchen die Erfahrung von Leuten, die unterstützende Technologie verwenden, um Fehler aufzudecken. Alle Tests und Fehlerberichte, für die Sie sich Zeit nehmen können, werden sehr geschätzt.

Obwohl ich glaube, dass wir den Blockeditor zum Zeitpunkt der Veröffentlichung von 5.0 in einen Zustand bringen können, in dem er eine akzeptable Benutzeroberfläche für Benutzer von Hilfstechnologien hat, erkenne ich, dass es eine Möglichkeit gibt, die wir nicht können. Wie können wir, abgesehen von der von Ihnen vorgeschlagenen Benutzereinstellung, sicherstellen, dass das Plugin für den klassischen Editor eine sinnvolle Option für Benutzer ist, bis sie mit dem Status des Blockeditors zufrieden sind?

Ich würde immer noch gerne ein unabhängiges Barrierefreiheits-Audit sehen, aber ohne den überstürzten Zeitplan der Version 5.0. Hier kann dieses Problem verwendet werden, um den Rahmen für eine umfassende Prüfung zu schaffen. Da Probleme aufgedeckt werden, können sie in 5.0.x-Versionen behoben werden. Sie müssen sicherlich nicht auf 5.1 warten.

@kevinwhoffman : Die Zeitleiste bezieht sich auf das Veröffentlichungsdatum am 19. November (oder spätestens am 27. November). Wenn wir das Veröffentlichungsdatum auf den 22. Januar verschieben, haben wir nicht viel mehr Zeit: zwischen WCUS (und der Vorbereitung, die erforderlich ist, um eine Veröffentlichung von WordPress 4.9.9 zu organisieren) und den Leuten, die über Weihnachten und Neujahr im Urlaub sind, Wir könnten zwei volle volle Arbeitswochen gewinnen, wenn wir das Veröffentlichungsdatum um zwei Monate verschieben. Weitere drei Monate klingen nach einer großzügigen Summe, aber sie würden uns nur sehr wenige tatsächliche Ergebnisse bringen, und wir würden immer noch eine schnelle Prüfung benötigen, damit wir im November daran arbeiten könnten, sie anzugehen.

@rcemory : Obwohl Ihr Kommentar nicht zum Thema gehört, ist es erwähnenswert, dass sich diese Diskussion auf die Blockeditor-Oberfläche selbst bezieht und nicht auf den Inhalt, den er für die Anzeige im Front-End Ihrer Website erstellt. Wie jetzt bei WordPress ist auf Inhalte zugegriffen, die im Blockeditor erstellt wurden. In vielen Fällen ist es leichter zugänglich als zuvor, da der Blockeditor besser geeignete aria-* -Labels hinzufügt. Er warnt Sie, wenn Sie Farbkombinationen verwenden, die nicht WCAG-konform sind, oder wenn Sie dies tun Überschriftenelemente in die falsche Reihenfolge bringen.

Das klassische Editor-Plugin ist ein völlig inakzeptabler Ersatz. Für den Anfang ist es Site-weit. Wenn also eine Site Gutenberg verwendet und ich etwas mit Inhalten tun muss, kann ich das nicht auf Benutzerbasis tun, und ich kann das klassische Editor-Plugin nicht installieren, meine Arbeit erledigen und dann deinstallieren es und erwarten, dass sich alles so verhält, wie es sollte, sobald die Rückkehr zu Gutenberg stattfindet.

Vielen Dank, dass Sie diesen Anwendungsfall angesprochen haben. Dies ist ein gutes Beispiel dafür, wo das Classic Editor-Plugin derzeit fehlschlägt. Wir können sicherlich eine Option pro Benutzer hinzufügen.

Das wäre großartig, aber dies ist ein Anliegen, das vor mehr als einem Jahr angesprochen wurde und bisher nicht angesprochen wurde. Da ein Beitrag nach dem aktuellen Stand der Dinge nicht mehr auf "normal" und dann wieder auf GB zurückgesetzt werden kann, während alle relevanten Informationen erhalten bleiben.
Daher ist der Plan, eine benutzerbasierte Option zu haben, einfach nicht realistisch, da es für Redakteure, die sich von GB abmelden, schwierig sein wird, Inhalte zu bearbeiten, die von Autoren erstellt wurden, die GB verwenden.

Die Kommentare von @amandarush sind kraftvoll und von Herzen. Und ich weiß, basierend auf den Erfahrungen der Vergangenheit, die Barrierefreiheit in WordPress zu verbessern.

Seit ich im Accessibility Team tätig bin, wurden im Admin-Bereich 4 (meiner Meinung nach) wichtige Funktionserweiterungen vorgenommen: Benutzerdefinierter Menü-Builder, Medienmanager, Customizer und jetzt Gutenberg.

Wie ursprünglich konzipiert und gebaut, waren alle diese Komponenten für Benutzer von Bildschirmleseprogrammen und sehenden Tastaturen so gut wie (oder völlig) unzugänglich. Meiner Ansicht nach liegt dies daran, dass die Barrierefreiheit in der Grafikdesign- und UX-Phase überhaupt nicht berücksichtigt wird. Nachdem das Accessibility-Team schlecht geweint hat, wurden alle 4 Verbesserungen der Barrierefreiheit vorgenommen, aber das zugrunde liegende Design und UX bleiben weitgehend gleich.

Deshalb teile ich ihre Ansicht, dass WordPress immer wieder den gleichen Fehler macht. Und leider teile ich ihre Skepsis, wenn wir hören, dass "Zugänglichkeit für uns wirklich wichtig ist". Es ist sehr frustrierend und einer der Gründe, warum ich selten mehr zu WP beitrage.

Es ist jetzt unwahrscheinlich, dass Bedenken hinsichtlich der Barrierefreiheit den Vorstoß zur Veröffentlichung von WP5.0 im November stoppen werden. Dies ist natürlich eine große Enttäuschung, nachdem die Liste der Barrierefreiheitsblocker im Frühjahr dieses Jahres erstmals erstellt wurde. Und der oft zitierte Wunsch von WP, das Web zu demokratisieren, und das Versprechen, keine Funktionen zu veröffentlichen, die nicht WCAG2.0-konform sind.

Ich denke jedoch, dass eine unabhängige Überprüfung der Barrierefreiheit, bei der nicht nur WCAG2.1 getestet wird, sondern auch ordnungsgemäße Benutzertests durchgeführt werden, jetzt sinnvoll ist. Zumindest auf diese Weise würden wir alle wissen, wo wir stehen, und es kann ein angemessener Fokus darauf gelegt werden, die Zugänglichkeitsfehler / -probleme in zukünftigen Versionen zu priorisieren und zu beheben.

Als Antwort darauf von @pento

Beziehen Sie sich hier auf Reagieren? Ich verstehe, dass mit React erstellte Anwendungen für jede andere Bibliothek, die das DOM dynamisch aktualisiert, auf ähnliche Weise zugänglich sind. Vorausgesetzt, wir verwenden Arienattribute angemessen (und stellen eine vorhersehbare Tastaturfokussierung sicher), sollte sie mit unterstützender Technologie verwendbar sein. Ist das nicht richtig?

Ja, das stimmt, aber die Entwickler müssen verstehen, wie sie ihre Komponenten in Bezug auf Design, Semantik, Betrieb, Fokusverwaltung und den richtigen Einsatz von ARIA zugänglich machen können. Leider passiert dies meiner Erfahrung nach selten.

Wenn Automattic den Weg eines Audits beschreitet, kann es sich lohnen, nicht nur kritische Abläufe / Benutzerreisen zu identifizieren, sondern auch häufig zu überprüfende Widgets zu überprüfen. Wenn diese Widgets allein identifiziert und geprüft werden können, können sie auch die Grundlage für eine zugängliche Musterbibliothek bilden. Dies kann dazu beitragen, die Barrierefreiheitsrisiken zu verringern, da mithilfe dieser Muster mehr Funktionen erstellt werden.

Es kann sich lohnen, nicht nur kritische Abläufe / Benutzerreisen zu identifizieren, sondern auch häufig zu überprüfende Widgets. Wenn diese Widgets allein identifiziert und geprüft werden können, können sie auch die Grundlage für eine zugängliche Musterbibliothek bilden. Dies kann dazu beitragen, die Barrierefreiheitsrisiken zu verringern, da mithilfe dieser Muster mehr Funktionen erstellt werden.

@aardrian Dies ist möglicherweise ein interessanter Ausgangspunkt, der für das Audit erforderlich ist, mit dem wir jetzt möglicherweise Maßnahmen ergreifen können: Ich habe keine Benutzerreisen für Gutenberg gesehen, und dies ist wahrscheinlich der naheliegendste Ausgangspunkt dafür Beginn des Audits.

@karmatosed @jwold - Wissen Sie, ob die genannten Flüsse / Reisen für die Nutzung von Gutenberg bereits vorhanden sind? Vielleicht eine Liste von "Widgets" oder "Mustern" wie hier beschrieben?

Ich denke, während dieser allgemeine Thread eine Menge Emotionen hat (und ich stimme zu, dass Gutenberg für alle nutzbar sein und versendet werden muss, wenn er fertig ist), würde ich gerne Gemeinsamkeiten und die nächsten Schritte finden. Ich würde gerne die Gesprächsorte verschieben, um herauszufinden, wo wir zum Handeln bereit sind.

Dieser Benutzerfluss würde uns auch eine Aufgabenliste mit zu prüfenden Stellen für Entwickler, Tester und Fehlerjäger geben, damit diese sich aufteilen und nach Berichten suchen können.

@postphotos , ich denke, @afercia hat oben in https://github.com/WordPress/gutenberg/issues/10318#issuecomment -428957684 eine Reihe guter Abläufe beschrieben.

@aardrian Einverstanden, das ist ein großartiger Ort, um zu beginnen! 👍 Danke, dass Sie sich daran erinnert haben.

Meine Frage bleibt bestehen - ich würde gerne wissen, ob es über diesen anfänglichen kritischen Ablauf hinaus zusätzliche Arbeit gibt, die bereits in Benutzerreisen gesteckt wurde, da sie sich auf Funktionen bezieht, da dies zur Validierung der Arbeit beiträgt, die wir hier ausführen. Möglicherweise möchten wir (diese Gruppe) andere Elemente zur ursprünglichen Liste von @afercia hinzufügen oder nach einer ersten Prüfung eine Sequenz

Zum Beispiel haben wir die Inhaltsstrukturfunktion, das Rückgängigmachen / Wiederherstellen usw. oder das Anzeigen eines Beitrags nicht aufgerufen, und die Aufgaben, auf die wir uns möglicherweise einigen, sind wichtig und hilfreich, damit Benutzer sie verwenden können - die Dinge, die wir vereinbaren, machen Gutenberg aus unglaublich nützlich und sollte zugänglich sein. Es wäre großartig, aktiv einen Konsens zu finden, wenn wir können.

Ein zusätzlicher Vorteil bei der Durchführung eines Audits ist der Beitrag zum größeren React-Projekt. React hat seine eigenen Probleme mit der Barrierefreiheit, und eine Prüfung von Gutenberg kann sowohl Probleme als auch Lösungen identifizieren, die sich auf den React-Kern beziehen und ihm helfen können.

Nun, das sind aufregende Neuigkeiten: https://make.wordpress.org/core/2018/10/18/regarding-accessibility-in-gutenberg/

Tastaturkürzel für die Regions- und Blocknavigation, Schrägstrichbefehle, Verbesserungen der fokussierbaren Symbolleiste und Seitenleiste durch verbesserte ARIA-Orientierungspunkte und -Rollen, automatisierte End-to-End-Tests und mehr.

ICYMI: Die WPCampus-Organisation organisiert ein Barrierefreiheits-Audit von Gutenberg.

Wir haben unsere Ausschreibung abgeschlossen und wählen nun einen Lieferanten aus.

Wie die meisten von Ihnen wahrscheinlich wissen, ist eine professionelle Prüfung der Barrierefreiheit für eine kleine gemeinnützige Organisation wie WPCampus ein großer Aufwand.

Wir bitten Sie um Ihre Hilfe bei der Finanzierung des Audits, um sicherzustellen, dass diese wichtige Forschung abgeschlossen ist.

Sie können mehr über die Initiative lesen und auf unserer Website spenden :

Hallo Rachel,

Ich sehe, Sie bitten uns, für das Audit zu spenden.
Ich frage mich, ob Sie über meinen Beitrag zu diesem Thread, den ich geschrieben habe, nachgedacht haben
Vor ein paar Monaten wurde angeboten, die Prüfung der Barrierefreiheit zu spenden
würde eine verbleibende Finanzierungslücke vollständig schließen?
Einige der führenden Regierungen und Fortune 500-Unternehmen der Welt vertrauen uns
mit solchen Projekten!

Folgendes habe ich am 11. Oktober 2018 gepostet:

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

@tofumatt https://github.com/tofumatt Ich bin auch sehr besorgt
WordPress-Zugänglichkeit und bemüht, Ihnen zum Erfolg zu verhelfen. Ich kann unsere haben
Organisation führen eine vollständige WCAG-EM-konforme Barrierefreiheitsprüfung für
Welches Standardniveau Sie auch bevorzugen, sowohl technisch als auch funktional
Testen * und spenden Sie den Teil der Arbeit, den Sie * benötigen, um Ihren Anforderungen zu entsprechen
Budget.

Ich würde denken, wir sollten uns sowohl ATAG als auch WCAG AA ansehen, und vielleicht
WCAG 2.1 statt 2.0. Wir könnten auch Empfehlungen geben und
Coaching, das Ihnen hilft, den besten und nachhaltigsten Weg zu finden, um einen zu schließen
Lücken entdeckt.

Wir sind bequem von Ihrer Entwicklungsgemeinschaft entfernt und wissen es dennoch
WordPress seit vielen Jahren gut. Ich besitze alle IAAP-Zertifizierungen und habe geführt
Dutzende solcher Audits auf der WordPress-Plattform über viele Jahre für beide
privater und öffentlicher Sektor. Bitte überprüfen Sie unsere gutgläubigen unter

davidberman.com/about, um zu entscheiden, wie wir am besten helfen können.

Gedanken?

• David

Am Mittwoch, 28. November 2018, um 10:10 Uhr, Rachel Cherry [email protected]
schrieb:

ICYMI: Die WPCampus-Organisation organisiert ein Barrierefreiheits-Audit von
Gutenberg.

Wir haben unser RFP beendet
https://wpcampus.org/2018/10/gutenberg-a11y-audit-rfp/ und sind jetzt
Auswahl eines Anbieters.

Wie die meisten von Ihnen wahrscheinlich wissen, ist dies jedoch ein Profi
Die Prüfung der Barrierefreiheit ist für einen kleinen gemeinnützigen Verein wie WPCampus ein großer Aufwand.

Wir bitten Sie um Ihre Hilfe, um das Audit zu finanzieren und dies sicherzustellen
Forschung ist abgeschlossen.

Sie können mehr über die Initiative lesen und auf unserer Website spenden:
https://wpcampus.org/2018/11/fundraising-for-wpcampus-gutenberg-accessibility-audit/

- -
Sie erhalten dies, weil Sie kommentiert haben.
Antworte direkt auf diese E-Mail und sieh sie dir auf GitHub an
https://github.com/WordPress/gutenberg/issues/10318#issuecomment-442480511 ,
oder schalten Sie den Thread stumm
https://github.com/notifications/unsubscribe-auth/ABz4pIgVSgZmWJRL2n3Uy-i8Ov7NXnj1ks5uzqdcgaJpZM4XG_WQ
.

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

Hochrangiger Berater, Vereinte Nationen | Eingeladener Experte, W3C | Ico-D
Lehrstuhl für Nachhaltigkeit | Carleton U. Access Network Stuhl

In Kürze: Toronto | New Orleans | Montreal | Buenos Aires | Tampa | Tel Aviv
Barrierefreiheitskurs: Besuchen Sie uns online unter

Diese Nachricht kann proprietäre Informationen enthalten. Nicht autorisiert
Offenlegung / Vervielfältigung / Verbreitung von Inhalten verboten.

@tofumatt , ich habe das am 29. November in Matt Mullenwegs persönlichem Blog gesehen :

Schließlich wird Automattic eine Barrierefreiheitsstudie zu WordPress, Gutenberg und eine Bewertung der Best Practices im gesamten Web finanzieren, um sicherzustellen, dass WordPress vollständig zugänglich ist, und neue Standards für das Web insgesamt setzen.

Können Sie uns als Automattic-Mitarbeiter mitteilen, ob das Automattic-Audit vom WPCampus-Audit getrennt ist oder ob Automattic stattdessen das WPCampus-Audit finanziert?

Einerseits hasse ich es zu sehen, dass WPCampus es über Crowdfunding finanzieren muss. Auf der anderen Seite gefällt mir die Idee, zwei Audits von zwei Firmen zu vergleichen und gegenüberzustellen.

Matt antwortete auf meine Frage in seinem Blog:

Ich denke, es ist auch gut, zwei zu haben. Ich werde mit Rachel darüber sprechen, wie die Finanzierung läuft.

Für diejenigen, die mitmachen, haben Sie sich verpflichtet, alle Rachels Projektanforderungen auf der Seite des WP-Campus und in der Lieferantenauswahlphase für die von Automattic gesponserte vollständig zu finanzieren. Letzteres ist das Ziel, auch die Best-Practice-Ansätze für die Barrierefreiheit anderer Schnittstellen im Blockeditor-Stil im modernen Web zu ermitteln.

@m Danke für das Update. Es ist sehr ermutigend zu sehen, wie sich das weiterentwickelt, und ich kann es kaum erwarten zu sehen, wohin es führt. Ich würde es lieben, wenn WordPress eines Tages das Beispiel dafür ist, wie Barrierefreiheit behandelt werden sollte.

@m

Für diejenigen, die mitmachen, haben sich verpflichtet, alles, was Rachels Projekt benötigt, auf der Seite des WP-Campus vollständig zu finanzieren

Das ist großartig und wertvoll. Gibt es einen Grund, warum Sie es heute nicht nur insgesamt finanzieren? Es scheint seltsam, die Leute zu bitten, weiter zu spenden, wenn sie wissen, dass es trotzdem vollständig finanziert wird.

@aardrian Das ist nicht im Sinne dessen, was wir tun. Wir möchten, dass dies ein Gemeinschaftsprojekt ist und Menschen und Organisationen die Möglichkeit gibt, teilzunehmen und Unterstützung zu zeigen, wenn sie dazu in der Lage sind.

Ende 2018 veröffentlichte WPCampus eine Aufforderung zur Einreichung von Vorschlägen zur Durchführung einer Barrierefreiheitsprüfung des WordPress-Blockeditors, auch bekannt als Gutenberg. Anfang 2019 gaben wir unsere Auswahl von Tenon, LLC für die Durchführung der Prüfung zu einem Preis von 31.200 USD bekannt.

Heute freuen wir uns, Tenons Bericht über die Zugänglichkeit des neuen Editors zu veröffentlichen.

Weitere Informationen finden Sie unter https://wpcampus.org/2019/05/gutenberg-audit-results/

Ich denke, es schließt dieses Problem 🎉🎉🎉🎉🎉

Alle gemeldeten Probleme werden im Rahmen dieses Projekts verfolgt:
https://github.com/WordPress/gutenberg/projects/25

Alle gemeldeten Probleme werden im Rahmen dieses Projekts verfolgt

Nicht ganz richtig. Der WPCampus / Tenon-Bericht enthält zusätzliche wichtige Überlegungen, die in der Liste der Probleme auf GitHub nicht behandelt werden. Insbesondere zeigen die Zusammenfassung und der Usability-Bericht (mit Daten), dass es in Gutenberg umfassendere strukturelle Zugänglichkeitsprobleme gibt, die nicht in kleinen, umsetzbaren GitHub-Problemen behoben werden können und stattdessen Lösungen auf einer höheren Ebene erfordern.

Dies soll klarstellen, dass selbst wenn alle gemeldeten Probleme gelöst wurden, wichtige Zugänglichkeitsprobleme noch zu lösen sind. Diese beziehen sich normalerweise auf das allgemeine Design des Editors.

Als Referenz füge ich hier zwei der Dokumente bei, die unter https://wpcampus.org/2019/05/gutenberg-audit-results/ veröffentlicht wurden.

Zusammenfassendes Dokument, das die Usability-Tests von Tenon beschreibt
Gutenberg_UX_Report.pdf

Zusammenfassung
Gutenberg_Executive_Summary.pdf

Ich schlage vor, ein neues Problem oder sogar ein neues Projekt zu eröffnen, um die im Bericht aufgedeckten Usability-Probleme zu lösen.