Wenn Leute mir eine Nachricht schicken, finde ich häufig Emojis darin. Auf meinen mobilen Geräten werden sie in meiner Sprachausgabe übersetzt. Das gilt auch für meine Desktop-Rechner. Die Ergebnisse sind jedoch unterschiedlich.
Emojis in Nachrichten versuche ich zu ignorieren. Wenn jemand „Hallo“ und eine 👋 dazu packt, spricht mein Screenreader „Hallo winkende Hand“. Und wenn drei 👋 zur Nachricht hinzugefügt werden, kriege ich „Hallo winkende Hand winkende Hand winkende Hand“. Gelegentlich muss ich vielleicht bei einem Emoji schmunzeln, aber generell sagen sie mir nichts.
Emojis sind Text
Emojis sind eine Teilmenge von Unicode. Es handelt sich um genormte Zeichen, die in unterschiedlichen Anwendungen in Textform eingegeben werden können. Die Emoji-Zeichen werden von Anwendungen, so wie sind, an den Accessibility Tree des Betriebssystems weitergeleitet.
Da die Zeichen, so wie sie sind, im Accessibility-Tree abgelegt werden, erhalten Assistenztechnologien wie Screenreader die Zeichen ebenfalls so wie sind. Die Übersetzung in Worte oder gesprochene Sprache muss die Assistenztechnologie vornehmen.
Woher die Übersetzung eines Emojis herkommt, hatte ich mir bislang keine echten Gedanken gemacht. Ich vermutete, dass es irgendwo eine Datenbank gibt, die alle Systeme oder Screenreader anzapfen können. Listen und Erklärungen gibt es beispielsweise direkt beim Unicode Consortium.
Unterschiedliche Übersetzungen
Wenn verschiedene Screenreader Emojis und andere Unicode-Zeichen „übersetzen“, sind regelmäßig Abweichungen festzustellen. Einige Übersetzungen stimmen überein und andere weichen leicht voneinander ab. Was Screenreader aus einigen willkürlich ausgewählten Emojis ausgeben, kann der folgenden Tabelle entnommen werden.
| Emojis | Unicode | JAWS | NVDA | Voiceover | TalkBack |
|---|---|---|---|---|---|
| 🦁 | 129409 | Löwengesicht | Löwe | Löwenkopf | Löwenkopf |
| 🎁 | 127873 | Geschenk | Geschenk | Geschenk | Verpacktes Geschenk |
| 😀 | 128512 | Grinsendes Gesicht | Grinsendes Gesicht | Grinsendes Gesicht | Grinsendes Gesicht mit geöffneten Augen |
| 🙈 | 128584 | Augen verschließender Affe | Sich die Augen zuhaltendes Affengesicht | Affe, nichts Böses sehen | nichts Böses sehen, Affe |
| 🙉 | 128585 | Ohren verschließender Affe | Sich die Ohren zuhaltendes Affengesicht | Affe, nichts Böses hören | nichts Böses hören, Affe |
| 🙊 | 128586 | Mund verschließender Affe | Sich den Mund zuhaltendes Affengesicht | Affe, nichts Böses sagen | nichts Böses sagen, Affe |
| ☰ | x2630 | Trigramm für Himmel | – | Trigram for Heaven | Trigramm für Himmel |
| 🖶 | 128438 | Drucker Symbol | – | – | – |
| 🛒 | 128722 | Einkaufswagen | Einkaufswagen | Einkaufswagen | Einkaufswagen |
Die Textübersetzungen können Nutzende im Übrigen anpassen. Im Screenreader NVDA gibt es beispielsweise eine eigene Maske dafür:
In der Liste der Ersetzungen kann „Löwe“ mit „Katze“ ersetzt werden. Auch können Unicode-Zeichen direkt eingegeben werden und eine neue Textübersetzung erhalten. Danach liest NVDA für das Emoji den überschriebenen/eingetragenen Text vor.
Bei vielen Emojis dürfte der genaue Wortlaut des Ersatztextes nicht wirklich wichtig sein, aber es gibt einige Emojis, die eine funktionale Bedeutung vermitteln. Wenn diese in Screenreader nicht korrekt übersetzt werden, dann kann der Einsatz solcher Emojis eine Einschränkung der Barrierefreiheit bedeuten.
Wenn beispielsweise das 🖶 als Beschriftung für eine Schaltfläche eingesetzt wird, dann muss der Name der Schaltfläche durch die Webentwicklung festgelegt werden:
<button aria-label="Drucken"> 🖶</button>
Die Schaltfläche hat jetzt den Namen „Drucken“ und das 🖶 wird in Screenreadern ignoriert.
Emojis im Fließtext
Wenn Nutzende die Bedeutung eines Emojis verstehen müssen oder wenn die Bedeutung eines Emojis immer gleich sein soll, können Webentwickler den Emoji selbst bezeichnen. Dazu kann das aria-label-Attribut eingesetzt werden. Elemente können allerdings nicht beliebig einen Namen erhalten. Die Vergabe von Namen ist nach ARIA 1.2 nur für bestimmte Rollen zulässig. Ein einfaches span-Element kann beispielsweise nicht mit dem aria-label-Attribut einen Namen erhalten.
Emojis können mit der Zuweisung einer zulässigen (beschriftbaren) Rolle einen neuen Namen mit dem aria-label-Attribut erhalten:
<span role="img" aria-label="Drei Affen"> 🙈 🙉 🙊</span>
Hinweis: Im Beispiel wird kein img-Element verwendet und ein Alternativtext (alt-Attribut) kann nicht vergeben werden. Die Textalternative kann nur mit den aria-label- oder aria-labelledby-Attributen bestimmt werden.
Die Rolle des Elements wird als Grafik festgelegt. Dann darf das Element einen Namen erhalten. In einem Screenreader erfahren Nutzer an der Stelle „Grafik Drei Affen“. Die Emojis selbst sind nicht mehr im Accessibility-Tree vorhanden und für Screenreadernutzer praktisch nicht existent.
Persönliche Einschätzung
Auch wenn die Technik mit dem role-Attribut unter den Best-Practice-Techniken der WCAG 2.2 aufgelistet wird, so bin ich von dieser Vorgehensweise nicht überzeugt. Aus meiner Sicht handelt es sich um eine Notlösung. Bei Emojis handelt sich um eine eigenständige Ausdrucksweise, die nicht immer mit den gleichen Worten übersetzt werden kann. Zugegebenermaßen ist die Ausdrucksweise visuell orientiert, was die barrierefreie Gestaltung für Screenreader erschwert.
In einem Beitrag vonDaniela Schubert wird ein anderes Beispiel gezeigt:
<span aria-label="du bist" role="img">👉🏾</span> <span aria-label="wundervoll" role="img">🫶🏽</span>
Ohne die neuen Namen wäre die Ausgabe im Screenreader JAWS „Nach rechts zeigender Finger, Handrücken Emoji modifizierendes Zeichen, braune Haut Hände, die Herz bilden, Emoji modifiziertes Zeichen, leicht bräunliche Haut“. Mit dem neuen Namen lautet die Passage „grafik Du bist Grafik wundervoll“. Das Ergebnis ist definitiv leichter zu verstehen, aber reiner Text „Du bist wundervoll“ ist noch leichter zu verstehen.
In dem Beitrag werden neben diesen eher technischen Aspekten auch Aspekte der Kommunikation besprochen. Wer sich für barrierefreie Emojis interessiert, sollte im den oben verlinkten Beitrag von Daniela Schubert weiter lesen.