Teil meiner erweiterten/veränderten Position im Platform-Engineering-Team für Accessibility bei Mozilla ist es in diesem Quartal, die Zugänglichkeitsschnittstelle zwischen Browser und assistierenden Technologien zu beschleunigen. Teil der gefühlten Verschlechterung unter Windows seit Firefox Quantum ist die Tatsache, dass Screen Reader jetzt nicht mehr direkten Zugriff auf die zugänglichen Objekte eines Dokuments haben, sondern Anfragen dazu immer über eine Prozessgrenze hinweg laufen müssen.

Und eine Idee ist, die Antwortzeiten dadurch zu verkürzen, dass wir die Menge an Daten, also Objekten, reduzieren, nach denen der Screen Reader fragen muss. Als Teil davon werden in Zukunft weniger html:div-Elemente in zugängliche Objekte übersetzt werden als bisher. Divs sind Hauptbestandteile vieler Webanwendungen fürs Aussehen und das Sortieren von Elementen auf dem Bildschirm, bieten aber für unsere Zwecke oft keinen Mehrwert. Wir filtern sie in Zukunft also stärker.

Das reduziert den Zugänglichkeitsbaum und somit die Datenmenge. Der Patch für diese Filterung wird voraussichtlich Anfang kommender Woche zu Beginn des Zyklus für Firefox Version 67 eingepflegt werden. Erste Messungen zeigen einen Gewinn zwischen 10 und 30 %. Gemessen wird die Zeit, die es braucht, dass der Screen Reader zu sprechen anfängt, nachdem der Anwender eine Taste zum Navigieren im Web gedrückt hat, also z. B. die Pfeiltasten beim navigieren mit dem virtuellen Cursor.

Auf einem schnellen Computer reduzieren sich die Antwortzeiten von 120-150 Millisekunden auf Zeiten zwischen 80 und 100. Auf einem langsamen Computer hingegen schon von 230 bis 250 auf 180 bis 220. Bei komplexen Anwendungen wie Gmail ist die Ersparnis etwa ein Drittel der zeit. Multipliziert man das mit zig Anschlägen pro Minute, ergibt sich definitiv ein sehr viel flüssigeres Gefühl als ohne diese Verbesserung. Dies trifft vor allem auf dynamische Anwendungen wie Gmail Twitter oder Mastodon zu.

Follow

Diese Änderung wird, wie gesagt, Anfang kommender Woche in Firefox Nightly 67 eingepflegt und ist dann zum Testen verfügbar. Wir hoffen natürlich auf ein paar mutige Tester, die auch ggf. Fehler finden, so dass wir die Filterung weiter verbessern können.
Hoffen wir also mal auf nicht zu viele Bugs! Aber eine tatsächliche Verbesserung für uns Screen Reader Nutzer, die von dieser Änderung ohne Zweifel am meisten spüren werden. Screen Reader sind die intensivsten Nutzer des Zugänglichkeitsbaums. ;)

@marco Danke Marco für diese Infos! hab die ESR-Version des FF im Einsatz - was ist dennn die nightly-Version?

@marco Gibt es denn Aussichten, die #A11Y-Performance wieder auf den Stand von vor Quantum zu bekommen? Ich habe auf vielen Seiten zeitweise schon mit Vivaldi surfen müssen, da sie mit dem Firefox absolut nicht mehr zu gebrauchen waren/sind. Eine Minute warten zu müssen, bis der Screenreader die längst geladene Website verarbeitet hat, ist echt nicht schön.

@schulle4u Aus technischen Gründen muss das Zurückgewinnen der Performance über Optimierungen in der neuen Architektur erfolgen. Wir sind gezwungen, dass Tabs jetzt in eigenen Prozessen laufen und die Informationen über die Dokumente über Prozessgrenzen hinweg kommuniziert werden müssen. Gerade unter Windows ist das leider sehr langsam, dank Windows COM. Screen Reader wollen ja immer das ganze Dokument kennen, und das geht jetzt langsamer als vorher.

@schulle4u Das Zurückgewinnen der Geschwindigkeit kommt also durch optimierte Anfragen, also vorausschauendes Kommunizieren von mehr Informationen, als gerade abgefragt wurden, und Zwischenspeichern dieser Informationen. Wenn ein Screen Reader also nach der Rolle fragt, holen wir gleich Namen, Zustände und andere Infos mit ab, in einem Aufruf anstatt dreien oder vieren. Das geht aber nur bis zu einem gewissen Grad. Siehe Unterschiede zwischen Firefox 57 (sehr langsam) und 59 (wieder ganz OK).

@schulle4u Das Reduzieren der Datenmenge, nach der gefragt werden kann, wie ich das in diesem Thread beschrieben habe, ist ein weiterer Versuch, einiges der verlorenen Geschwindigkeit wiederzugewinnen. Wir haben auch noch ein paar weitere Ideen. Ob das aber tatsächlich wieder so schnell wird wie zu Zeiten, als das alles innerhalb eines Prozesses und superschnell lief, wage ich zu bezweifeln. Das gibt die erzwungene (unter anderem auch durch Spectre) neue Architektur schlicht nicht her.

@schulle4u Chromium-basierte Browser wie Vivaldi, Chrome oder Opera cachen den gesamten Accessibility-Tree im Hauptprozess des Browsers, schlürfen ihn also auch vom jeweiligen Webseiten-Prozess rüber und müssen immer zwei Kopien des Baums synchron halten. Die kommunizieren also genauso viel wie wir, verteilen die Last aber anders. Sie mogeln z. B., indem sie erst einmal nur einen kleinen Teil des Dokuments bereitstellen.

@schulle4u Das fühlt sich natürlich schnell an, sorgt aber für Probleme, wenn der Anwender schnell ans Ende springen will. Eventuell ist das ganze Dokument dann noch gar nicht da. Hab ich schon mehrfach bei Wikipedia-Artikeln nachvollziehen können. Das bricht dann einfach mittendrin ab, und irgendwann ein, zwei, manchmal drei Sekunden später, kriegt der Screen Reader dann noch ein Update, und dann ist das Dokument erst vollständig da.

@schulle4u Dadurch, dass Chrome am Anfang gar nicht zugänglich war, hatten sie Jahre Zeit, das halbwegs so hinzukriegen, dass die große Mehrzahl der Anwender das gar nicht merkt. Wir hingegen mussten von einem existierenden Standpunkt aus uns erst verschlechtern, weil die Zeit nicht gereicht hat und Quantum veröffentlicht werden musste, um jetzt wieder die Performance und das Vertrauen der User zurückzugewinnen. Das ist kurz gefasst die Geschichte dahinter.

@marco Danke für die ausführliche Erklärung. Ich schaue mir natürlich gern eure Fortschritte an, vielleicht bringt es ja tatsächlich wieder etwas mehr Performance.

@marco Das von dir beschriebene Verhalten in Vivaldi und Co. kann ich zwar teilweise bestätigen, mich persönlich stört es aber sehr viel weniger als das momentane Ladeverhalten vom Firefox. Normalerweise liest man ja Websites auch eher nicht rückwärts, da ist mir ein bisschen Mogelei egal. 😉

@schulle4u Schon klar, dass diese Mogelei weniger störend ist, weil einfach beim in solchen Fällen üblichen Verhalten Chrome genug Zeit hat, den Rest im Hintergrund in den Puffer des Screen Readers zu schaufeln. Und uns stören die langsamen Lade- und Updatezeiten ebenfalls, deswegen stecken wir da ja so viel Arbeit in die Verbesserungen.

Sign in to participate in the conversation
chaos.social

chaos.social - because anarchy is much more fun with friends.
chaos.social is a small Mastodon instance for and by the Chaos community surrounding the Chaos Computer Club. We provide a small community space - Be excellent to each other, and have a look at what that means around here.
Follow @ordnung for low-traffic instance-related updates.
The primary instance languages are German and English.