Lass uns über Speech CSS sprechen

Boston hat, wie viele Großstädte, ein U-Bahn-System. Pendler sind es gewohnt, regelmäßige Durchsagen zu hören.

Fahrgäste schalten manche Durchsagen einfach aus, wie die vorab aufgezeichneten Stationsnamen, die immer wieder wiederholt werden. Oder Durchsagen von lokalen Politikern und Prominenten – wieder, irgendwie repetitiv und nicht wert, darauf zu achten, nach dem ersten Mal. Am wichtigsten sind Service-Meldungen, die typischerweise direkte und sofortige Informationen liefern, auf die die Fahrgäste reagieren müssen.

Eine informelle Priorität

Das Ohr eines regelmäßigen Fahrgastes trainiert sich, um nach wichtigen Durchsagen zu lauschen, passiv, während man am Handy daddelt oder nach einem anstrengenden Arbeitstag abschaltet. Es ist kein perfektes System – gelegentlich finde ich mich in einem Zug gefangen, der zum Expresszug umfunktioniert wurde.

Aber wir sollten Durchsagen mit geringerer Priorität nicht entfernen. Es ist unklar, welche Art von Informationen für wen wichtig sein wird: Touristen, neue Bewohner oder besuchende Freunde und Familie, um nur einige zu nennen.

Ein kleines Gedankenexperiment: Könnte diese Priorität durch Sounddesign formalisiert werden? Die Idee wäre, verschiedene Stimmen konsistent zu verwenden oder bestimmte Durchsagen mit spezifischen Tönen zu versehen. Ich habe ein aufkommendes Verhalten von den Zugführern bemerkt, das dem ähnelt: Manchmal verwenden sie einen kurzen Funksignalton, um die Aufmerksamkeit der Fahrgäste vor einer Durchsage zu erregen.

Möglichkeiten

Ich habe mich gefragt, ob diese Art des Denkens auf die Gestaltung besserer Web-Erlebnisse für alle ausgedehnt werden kann. Schließlich erlebt der Ton im Web eine Renaissance: Die Web Audio API hat eine großartige Unterstützung, und die meisten gängigen Betriebssysteme werden mittlerweile mit integrierten Erzähltools ausgeliefert. Digitale Assistenten wie Siri sind fast allgegenwärtig, und Podcasts und Hörbücher sind ein normaler Bestandteil der Medienkost der Menschen.

Tief in der – ähm – Labyrinth-Dokumentation von CSS finden sich Verweise auf zwei Medientypen, die das Problem ansprechen: aural und speech. Die Kernidee ist ziemlich einfach: audio-orientiertes CSS sagt einer digitalisierten Stimme, wie sie Inhalte vorlesen soll, genau wie reguläres CSS dem Browser sagt, wie er Inhalte visuell darstellen soll. Von beiden ist aural veraltet. Die Erkennung des speech Medientyps ist ebenfalls schwierig, da ein Screenreader seine Anwesenheit möglicherweise nicht an den Browser kommuniziert.

Das CSS 3 Speech Module, die weiterentwickelte Version des aural Medientyps, sieht am vielversprechendsten aus. Wie display: none; ist es Teil des kleinen Teils von CSS, der Auswirkungen auf das Verhalten von Screenreadern hat. Es verwendet traditionelle CSS-Eigenschaft/Wert-Paare neben bestehenden Deklarationen, um ein Audio-Erlebnis zu schaffen, das eine Entsprechung zum visuellen Box-Modell hat.

code {
  background-color: #292a2b;
  color: #e6e6e6;
  font-family: monospace;
  speak: literal-punctuation; /* Reads all punctuation out loud in iOS VoiceOver */
}

Nur weil man es kann, heißt das nicht, dass man es tun sollte

In seinem Buch Building Accessible Websites, das 2003 veröffentlicht wurde, führt der Autor/Journalist/Accessibility-Forscher Joe Clark einige solide Gründe an, niemals die Art und Weise zu ändern, wie gesprochenes Audio generiert wird. Besonders hervorzuheben ist

Unterstützung

Viele Browser unterstützen die Technologie nicht, sodass das Schreiben des Codes eine Verschwendung von Mühe wäre. Einfach und direkt.

Kompetenz

Clark argumentiert, dass Entwickler nicht an der Art und Weise herumbasteln sollten, wie gesprochene Inhalte vorgelesen werden, weil ihnen die Ausbildung fehlt, um „Computerstimmen zu gestalten, sie im dreidimensionalen Raum zu positionieren und Hintergrundmusik und Töne für spezielle Komponenten festzulegen.“

Das mag für manche zutreffen, aber wir sind eine Branche der Polymaths. Ich kenne viele Ingenieure, die tagsüber eine technische Architektur im Unternehmensmaßstab entwickeln und nachts Musik komponieren. Dazu kommt die Tatsache, dass wir das irgendwie schon getan haben.

Der Punkt, auf den er hinauswill – eine allumfassende Audioerfahrung zu schaffen, ist eine unmögliche Aufgabe – ist wahr. Aber die Situation hat sich geändert. Ein ganzes audio-Universum muss nicht mehr von Grund auf neu geschaffen werden. Digitale Stimmen werden inzwischen von den meisten Betriebssystemen bereitgestellt, und die Anzahl günstiger/kostenloser Stock-Sounds und Audiobearbeitungsressourcen ist nahezu überwältigend.

Angemessenheit

Für Benutzer von Screenreadern ist die Stimme des Readers ihre Schnittstelle zum Web. Infolgedessen können Benutzer sehr leidenschaftlich über die Stimme ihres Screenreaders sein. In diesem Licht argumentiert Clark dafür, nicht zu ändern, wie ein Screenreader Inhalte ausspricht, die nicht in seinem Wörterbuch enthalten sind.

Screenreader haben sehr durchdachte Standardeinstellungen für die Verarbeitung digitaler Schnittstellen und behandeln wahrscheinlich Inhaltstypen, an die viele Entwickler nicht einmal denken würden. Zum Beispiel verwenden bestimmte Screenreader spezialisierte Sound-Cues, um Verhaltensweisen zu signalisieren. NVDA verwendet eine Reihe von Tönen, um eine aktive Fortschrittsleiste zu signalisieren.

Die Veränderung des Screenreader-Verhaltens verändert effektiv die erwartete Erfahrung des Benutzers. Plötzliche, unangekündigte Änderungen können sehr desorientierend sein und auf Angst, Wut und Verwirrung stoßen.

Ein guter Vergleich wäre, wenn Entwickler die Art und Weise ändern würden, wie eine Maus scrollt und klickt, websitebasiert. Diese Art von Unvorhersehbarkeit ist kein Fall von jemandem verärgern, sondern ein Fall, in dem unbeabsichtigt Inhalte schwerer verständlich gemacht werden oder die Standardoperation auf etwas Unbekanntes geändert wird.

Meine Stimme ist nicht deine Stimme

Die Stimme eines Screenreaders ist typischerweise an die Region und die Spracheinstellung des Betriebssystems gebunden.

Zum Beispiel enthält iOS eine Einstellung nicht nur für Englisch, sondern für Variationen, die Vereinigtes Königreich, Irland, Singapur, Neuseeland und fünf weitere umfassen. Ein Benutzer, der britisches Englisch wählt, wird unter anderem feststellen, dass seine Funktion „Farben umkehren“ in „Invert Colours“ umbenannt wird.

Die Spracheinstellung eines Benutzers muss jedoch nicht seine Hauptsprache, die Sprache seines Herkunftslandes oder die Sprache des Landes, in dem er gerade lebt, sein. Mein Lieblingsbeispiel ist mein amerikanischer Freund, der die Stimme auf seinem iPhone auf britisches Englisch eingestellt hat, damit Siri wie ein Butler klingt.

Britisches Englisch ist auch eine hervorragende Erinnerung daran, dass regionale Unterschiede ein wichtiger Gesichtspunkt sind, Leute.

Eine weitere Überlegung ist biologischer und umweltbedingter Hörverlust. Er kann sich mit einem Spektrum von Schweregraden manifestieren, sodass die Eigenschaft voice-balance das Potenzial haben könnte, die Stimme außerhalb des hörbaren Bereichs einer Person zu „bewegen“.

Auch die Geschwindigkeit, mit der die Stimme Inhalte vorliest, kann für manche zu schnell oder für andere zu langsam sein. Erfahrene Screenreader-Nutzer können die Sprechgeschwindigkeit erhöhen, ähnlich wie manche Benutzer eine Seite schnell scrollen, um benötigte Informationen zu finden. Ein neuer Benutzer von Screenreadern oder ein Benutzer, der über ein unbekanntes Thema liest, wünscht sich möglicherweise eine langsamere Sprechgeschwindigkeit, um nicht überfordert zu werden.

Und doch

Clark räumt ein, dass einige seiner Einwände nur im akademischen Bereich existieren. Er zitiert den Fall eines technikaffinen blinden Benutzers, der die Stärke der CSS-Interoperabilität nutzt, um seine Leseerfahrung angenehm zu gestalten.

Nach meinen (passablen) Recherchefähigkeiten wurde in den vierzehn Jahren seit der Veröffentlichung des Buches nicht viel unternommen, um Screenreader-Benutzer nach ihren Präferenzen für diese Art von Technologie zu fragen. Es ist auch wichtig zu bedenken, dass Screenreader-Benutzer nicht zwangsläufig blind sind und auch nicht zwangsläufig technologisch analphabetisch.

Die Idee hier wäre, CSS-Audio-Manipulation als etwas zu behandeln, in das sich ein Benutzer einklinken kann, entweder global oder websitebasiert. Denken Sie an Web-Erweiterungen wie Greasemonkey/Tampermonkey, oder wenn Websites die Erlaubnis zur Anzeige von Benachrichtigungen erfragen. Es könnte so einfach sein wie die Arten von Präferenz-Schaltern, mit denen Benutzer bereits vertraut sind.

Es gibt bereits einen Präzedenzfall dafür. Accessibility Engineer Léonie Watson stellt fest, dass JAWS – ein weiterer beliebter Screenreader – „ein integriertes Sound-Schema hat, das verschiedene Stimmen für verschiedene Teile von Webseiten ermöglicht. Dies deutet darauf hin, dass vielleicht ein gewisses Interesse daran besteht, das Audio-Erlebnis für Screenreader-Benutzer aufzupeppen.“

Opt-in setzt auch Funktionen wie Whitelists voraus, um potenzielle Missbräuche von CSS-manipulierter Sprache zu verhindern. Zum Beispiel könnte ein Benutzer nur bestimmte Websites mit CSS-manipulierten Inhalten zulassen, die gelesen werden, oder Dinge wie zwielichtige Werbenetzwerke blockieren, die skrupellose Praktiken anwenden, um Aufmerksamkeit zu erregen.

Meinungen: Ich habe ein paar

In bestimmten Situationen kann ein Screenreader den Kontext von Inhalten nicht erkennen, kann aber eine vom Menschen verfasste Vorgabe akzeptieren, wie er sie korrekt parsen soll. Zum Beispiel stellt James Craigs WWDC-Video von 2011 die Verwendung von speak-as-Werten vor, um Straßennamen und Code korrekt vorlesen zu lassen (beginnt bei 15:36, erfordert Safari zur Ansicht).

In der Programmierung zählt jedes Symbol. Die Fähigkeit, die Beziehung zwischen Dingen im Code selbstbewusst darzustellen, ist ein grundlegender Aspekt der Programmierung. Der Fall, dass thisOne != thisOtherOne als „this one is equal to this other one“ gelesen wird, obwohl die Absicht „this one is not equal to this other one“ war, ist ein besonders überzeugendes Anliegen.

Aus dem Stegreif fallen mir weitere Beispiele ein, bei denen diese Art der Audio-Manipulation wünschenswert wäre:

• Sicherstellen, dass Namen richtig ausgesprochen werden.
• Stummschalten der Aussprache von Icons (insbesondere von mit Web-Fonts erstellten Icons) in Situationen, in denen der Entwickler den HTML-Code nicht bearbeiten kann.
• Verwendung von Soundeffekt- Cues für interaktive Komponenten, für die der Screenreader keine integrierten Verhaltensweisen hat.
• Erstellen eines Cloud-synchronisierten Dienstes, der die persönliche Sammlung von Sprachpräferenzen und Aussprache-Ersetzungen eines Benutzers speichert.
• Möglichkeit, eine Begleitstimme einzustellen, die spezielle Inhalte wie transkribierte Interviews oder Codebeispiele vorliest.
• Emotikons. Bis wir etwas erreichen, das EmotionML-Unterstützung nahekommt, könnte dies eine gute Möglichkeit sein, die emotionale Absicht des Autors anzunähern (Nein, Emojis zählen nicht).
• Aufpeppen. Wenn ein Benutzer das Art-Design einer Website nicht sehen kann, hängt seine Erfahrung vom Können des Autors oder Sound-Editors ab – im Internet kann das manchmal zu wünschen übrig lassen.

Die Realität der Situation

Das CSS Speech Module-Dokument wurde zuletzt im März 2012 geändert. VoiceOver unter iOS implementiert Unterstützung unter Verwendung der folgenden speak-as-Werte für die speak-Eigenschaft, wie in dieser Demo von Accessibility-Berater Paul J. Adam gezeigt wird.

• normal
• digits
• literal-punctuation
• spell-out

Anscheinend honorieren die iOS-Barrierefreiheitsfunktionen „Speak Selection“ und „Speak Screen“ diese Eigenschaften derzeit nicht.

Trotz der Tatsache, dass das CSS 3 Speech Module noch ratifiziert werden muss (und daher noch Änderungen unterworfen ist), signalisiert die VoiceOver-Unterstützung, dass ein De-facto-Standard etabliert wurde. Die Beliebtheit von iOS – Millionen von Geräten, von denen 76 % die neueste Version von iOS verwenden – macht die Implementierung überlegenswert. Für diejenigen, die von der durch diese Deklarationen gebotenen Klarheit profitieren würden, könnte dies potenziell einen großen Unterschied machen.

Sei inklusiv, sei explizit

Nutze die Stärken von CSS und nimm kleine, chirurgische Anpassungen an Website-Inhalten vor, um die gesamte Benutzererfahrung zu verbessern, unabhängig von Gerät oder Nutzungskontext. Beginne mit semantischem Markup und einer Progressive Enhancement-Denkweise. Überschreibe bestehende Audio-Cues nicht um der Eitelkeit willen. Verwende von iOS unterstützte speak-as-Werte, um Klarheit zu schaffen, wo VoiceOver-Standardwerte eine fundierte Empfehlung benötigen.

Kleine Utility-Klassen zu schreiben und sie auf semantisch neutrale span-Tags anzuwenden, die um problematische Inhalte gewickelt sind, wäre ein guter Ansatz. Hier ist eine Aufnahme von VoiceOver, die diesen CodePen liest, um dies zu demonstrieren.

Achte darauf, ausgiebig zu testen, um sicherzustellen, dass diese Anpassungen andere Screenreader-Software nicht beeinträchtigen. Wenn Sie nicht bereits mit Screenreadern testen, gibt es keinen besseren Zeitpunkt als jetzt, um damit zu beginnen!

Leider ist die aktuelle Unterstützung für CSS Speech begrenzt. Aber zu lernen, was es kann und was nicht, und in welchen Situationen es eingesetzt werden könnte, ist für Entwickler immer noch von entscheidender Bedeutung. Durchdachte und gut überlegte Anwendung von CSS ist ein Schlüsselelement bei der Erstellung robuster Schnittstellen für alle Benutzer, unabhängig von deren Fähigkeiten oder Umständen.