Firefox 70, der im Oktober erschien, enthält als eine neue Funktion einen Bericht zur Aktivitätenverfolgung. Dieser eigentlich sehr grafische Bericht ist auch für die Nutzer von Screen Readern zugänglich.
Der Bericht zeigt detailliert an, welche verschiedenen Online-Tracker Firefox in den letzten sieben Tagen blockiert hat. Firefox kennt zur Zeit fünf Typen: Inhalte zur Aktivitätenverfolgung, Cookies zur seitenübergreifenden Aktivitätenverfolgung, Skripte zur Aktivitätenverfolgung durch soziale Netzwerke, Identifizierer (Fingerprinter) und heimliche Digitalwährungsberechner (Krypto-Miner). Das Diagramm zeigt für die letzten sieben Tage jeweils einen Block mit Balken für jeden an diesem Tag blockierten Typ von Onlineverfolgern an. Jeder Balken ist der prozentuale Anteil am Gesamtwert von 100%. Die Tage sind horizontal angeordnet, die Balken reichen jeweils vertikal in die Höhe. Außerhalb gibt es dann noch für jeden Typ einen Auswahlschalter, der den jeweiligen Typ in der Grafik deutlich einfärbt und eine ausführliche Erklärung zu diesem Typ einblendet.
Der Code hierfür ist gar nicht so kompliziert, es werden lediglich diverse Div-Elemente mit CSS-Füllungen versehen, die den prozentualen Werten aus der Datenbank entsprechen. Die Daten lagen also schon in auch textuell verwertbarer Form vor, wie dies übrigens meistens bei grafisch aufbereiteten Materialien der Fall ist. Mir war von vornherein klar, dass dies eine Tabelle werden musste, die die Werte darstellt.
Die Frage war nur, gehe ich nach Typ des Trackers vor oder nach Tagen? Für sehende ist die Darstellung ganz klar nach Tagen gruppiert. Ich entschied mich also dafür, dass jedem Tag in der Tabelle eine Zeile zukommt. Die erste Spalte, also die Zeilenüberschrift, beinhaltet demzufolge den Namen des Tages. Die zweite Spalte enthält immer die Gesamtzahl an diesem Tag blockierter Onlineverfolger. Ab Spalte 3 folgen dann die einzelnen für diesen Tag blockierten Typen mit ihrem Anteil am gesamten Tag. Diese Tabelle hat also maximal sieben Spalten, aber da nicht an jedem Tag jeder Typ auftritt, sind die Zeilen unterschiedlich lang.
Ich begann also, Teile des Design Patterns für Tabellen (öffnet in neuem Tab) auf das vorhandene Markup anzuwenden. Jeder Tag wurde eine Zeile, jede Angabe eine Zelle. Die grafischen Informationen hatten keinen eigenen Text, also musste ich ein aria-label mit den Angaben erzeugen. Da es gute Praxis ist, einem Element, das ein aria-label hat, eine vernünftige Rolle zu geben, gab ich diesen grafischen Informationen folgerichtig die Rolle „img“. Dies war übrigens das erste Mal in über 11 Jahren, in denen ich mit WAI-ARIA zu tun habe, dass ich für diese Rolle tatsächlich eine praktische Verwendung hatte. Außerdem hätte ich sie eh gebraucht, denn beim Testen stellte sich zwischendurch heraus, dass NVDA zwar mit einem Div-Element mit einem aria-label klar gekommen wäre, JAWS dieses aber vollkommen ignorierte. Erst durch die Rolle „img“ erkannte JAWS, dass es diesen Text im aria-label tatsächlich benutzen sollte und erkennt die Grafik seitdem ordentlich und liest sie vor.
Ordnung ins Chaos bringen 🔗
Nachdem ich die Tabellensemantik hinzugefügt hatte, stellte sich heraus, dass die Anordnung der Elemente im Barrierefreiheits-Baum gar nicht stimmte. Das ist der Objektbaum, über den assistierende Technologien die Informationen über die Website (öffnet in neuem Tab) beziehen. Die Tage selbst waren gar nicht in der Tabelle, und sie waren auch noch in umgekehrter Reihenfolge zu der tatsächlichen Anordnung der restlichen Informationen im DOM angeordnet.
Um nicht das ganze Markup umzustellen und somit mit weiterem CSS usw. wieder alles richtig hinbiegen zu müssen, musste es aria-owns (öffnet in neuem Tab) richten. aria-owns bekommt als Wert eine Liste von ID-Elementreferenzen und ordnet diese an dieser Stelle im Barrierefreiheits-Baum an, ändert also die Zuordnung potentiell ganzer Teile des Objektbaums zu anderen Elementen. Wenn man weiß, was man tut, ist dies also ein mächtiges Werkzeug, einen durch Markup und CSS eigentlich recht unlogischen Elementbaum für assistierende Technologien so hinzubekommen, dass er beim Vorlesen Sinn macht. Mit Hilfe dieses Attributes sortierte ich nun also die Tage neu und ordnete sie ihren jeweiligen Tabellenzeilen zu, stellte sie sogar als erste in selbige. Das Ergebnis ist eine wunderschön mit Screen Readern lesbare Tabelle, während für Sehende weiter ganz normal die Grafen zu sehen sind.
Ich möchte allerdings noch einmal ausdrücklich die Warnung wiederholen, dies ohne Vorkehrungen zu Hause auszuprobieren. aria-owns kann zu einem richtigen Minenfeld werden, mit dem ihr euch die Zugänglichkeit eures Projekts richtig schön versauen könnt, wenn ihr es falsch anpackt. Wenn allerdings in entsprechend komplexen Situationen richtig angewandt, ist es ein ebenso mächtiges Werkzeug für eine bessere Zugänglichkeit. Daher den Baum immer schön mit dem Barrierefreiheits-Inspector überprüfen, auch mit einem Screen Reader drüber gehen oder testen lassen, und immer die erste Regel von WAI-ARIA beachten: Nicht einsetzen, wenn es nicht unbedingt gebraucht wird.
Probiere es selbst aus! 🔗
Wenn Du diesen Beitrag mit Firefox liest, kannst Du Dir Deinen ganz persönlichen Bericht zu den Aktivitätenverfolgern ansehen, indem Du CTRL+T (CMD+T auf dem Mac) drückst und about:protections in die Adresszeile eingibst. Wenn Du lernen willst, wie ich es gemacht habe, kannst Du Dir den Patch bei Mozilla-Central, die gesamte Code-Datei und die zugehörigen Tests ansehen. Alle diese öffnen in einem neuen Tab. Viel Spaß!