Für blinde Menschen gibt es kaum etwas Frustrierenderes, als zu versuchen, eine App zu nutzen, und dann festzustellen, dass die App nicht zugänglich ist. Vielleicht kann Ihr Bildschirmlesegerät einen wichtigen Teil der App nicht lesen, oder vielleicht kann es überhaupt nichts lesen. Wenn Anwendungen mit Standardschaltflächen, Eingabefeldern, Listenfeldern, Tabellen oder anderen Elementen der Benutzeroberfläche entwickelt werden, ist es nicht schwer, sie zugänglich zu machen. Manche Anwendungen werden jedoch mit einem nicht standardisierten Toolkit für die Benutzeroberfläche entwickelt, und diese Toolkits sind völlig unzugänglich. Es ist schwierig und zeitaufwändig, die Barrierefreiheit in einem Toolkit für Benutzeroberflächen von Grund auf neu zu implementieren, daher wird dies in der Regel nicht gemacht, außer in den wenigen Top-Toolkits für Benutzeroberflächen, die von großen Unternehmen unterstützt werden. Manchmal ist es für einen App-Entwickler wirklich notwendig, ein benutzerdefiniertes Toolkit für die Benutzeroberfläche zu verwenden, und manchmal nicht, aber trotzdem enden wir mit unzugänglichen Apps.
Dieses Problem ist besonders dringlich bei Anwendungen, die für bestimmte Aufgaben wichtig sind. Es ist nicht ungewöhnlich, dass eine blinde Person einen bestimmten Job nicht bekommen kann, weil der Job die Verwendung einer App erfordert, die nicht zugänglich ist. Dabei handelt es sich oft um Nischenanwendungen, für die der übliche wirtschaftliche Anreiz zur Einführung von Barrierefreiheit, nämlich der Verkauf an Behörden und Bildungseinrichtungen, nicht gegeben ist. Wir brauchen also dringend eine Lösung, die so viele Barrieren wie möglich aus dem Weg räumt, um den Long Tail der Apps zugänglich zu machen.
Wie bei der Arbeit von Pneuma Solutions an der Verbesserung von Dokumenten und Konferenzinhalten kann maschinelles Lernen bei diesem Problem helfen. Apple ist in diesem Bereich mit der in iOS integrierten Funktion zur Bildschirmerkennung führend, und die bisherigen Ergebnisse sind vielversprechend. Allerdings ist diese Technologie noch nicht auf allen Computern und Geräten verfügbar, und die Ergebnisse sind oft nicht zufriedenstellend. Wir können nicht warten, bis diese Lösung ausgereift ist und sich durchgesetzt hat; wir brauchen einen anderen Ansatz, der kurzfristig praktikabel ist. Außerdem sind viele Entwickler von Anwendungen und Benutzeroberflächen-Toolkits bereit, ihre Software zugänglich zu machen, wenn es nur nicht so schwierig und zeitaufwendig wäre. Diese Entwickler sind bereits bereit, uns auf halbem Weg entgegenzukommen; jetzt müssen wir das Gleiche tun.
An dieser Stelle kommt mein neues Open-Source-Projekt AccessKit ins Spiel. Ziel von AccessKit ist es, eine gemeinsame Infrastruktur für die Zugänglichkeit von Anwendungen auf möglichst vielen Plattformen und in möglichst vielen Programmiersprachen bereitzustellen. Mit AccessKit muss ein Entwickler, der mit mehreren Plattformen arbeitet, die Barrierefreiheit nicht für jede Plattform von Grund auf neu implementieren. Ein weiteres Ziel von AccessKit ist es, besser dokumentiert und einfacher zu verwenden zu sein als die bestehenden plattformspezifischen Barrierefreiheits-APIs wie UI Automation für Windows oder Cocoa Accessibility für Apple-Plattformen. Schließlich kann eine fehlerhafte Implementierung von Barrierefreiheit fast so frustrierend sein wie gar keine Barrierefreiheit.
AccessKit befindet sich noch in einem frühen Stadium des Designs und der Entwicklung, aber es stößt bereits auf Interesse bei anderen Entwicklern, einschließlich Code-Beiträgen von einem anderen Entwickler. Und jetzt habe ich das große Privileg, eine Finanzierung von Google zu erhalten, um in Teilzeit an diesem Projekt zu arbeiten, beginnend mit der Windows-Implementierung. Ich freue mich auf brauchbare Ergebnisse bis zum Ende dieses Jahres.
Ich bin sicher, dass alle Entwickler, die dies lesen, mehr darüber wissen wollen, wie AccessKit funktionieren wird. Die Kurzfassung ist, dass AccessKit eine plattformübergreifende Abstraktion für Barrierefreiheit bieten wird, die stark von der Chromium-Browser-Engine inspiriert ist. Diese Abstraktion basiert auf serialisierbaren Datenstrukturen, wodurch der Aufwand für die Schnittstellen zwischen Programmiersprachen minimiert wird. AccessKit wird hauptsächlich in der Programmiersprache Rust implementiert, die eine einzigartige Kombination aus Zuverlässigkeit und Effizienz bietet. AccessKit wird jedoch von einer Vielzahl von Programmiersprachen aus nutzbar sein. Weitere Einzelheiten sind im AccessKit GitHub-Repository verfügbar.
Als Open-Source-Projekt braucht AccessKit die Beteiligung der Entwicklergemeinschaft, um erfolgreich und nachhaltig zu sein. Ich würde mich insbesondere über Beiträge von Entwicklern freuen, die die Programmiersprache Rust beherrschen. Das Gesamtdesign von AccessKit ist noch im Fluss, daher ist es zu früh für mich, viel Implementierungsarbeit zu delegieren. Was ich zu diesem Zeitpunkt brauche, ist ein Peer-Review, insbesondere von Entwicklern, die mehr Erfahrung mit der Sprache Rust haben als ich selbst. Wenn Sie interessiert sind, können Sie uns auf GitHub unterstützen.
Abschließend möchte ich sagen, dass ein wichtiger Grund, warum ich Microsoft verlassen habe, um Pneuma Solutions mitzugründen, der ist, dass ich die Freiheit haben möchte, an Projekten zu arbeiten, die sich auf Barrierefreiheit beziehen und von denen ich glaube, dass sie einen großen positiven Einfluss auf unsere Gemeinschaft haben werden, und zwar über eine einzelne Plattform hinaus. Ich bin immer noch begeistert von der Arbeit, die wir bei Pneuma Solutions leisten, und diese Arbeit wird fortgesetzt. Mit AccessKit habe ich nun die Möglichkeit, ein Problem zu lösen, das mir seit vielen Jahren am Herzen liegt. Ich freue mich darauf, mit der Softwareentwicklergemeinschaft zusammenzuarbeiten, um viele weitere Anwendungen zugänglich zu machen.
Schreibe einen Kommentar