iOS 12.2: Warnung vor folgenschwerer neuer VoiceOver-Einstellung

[Update 28.05.2019] iOS 12.3 ist inzwischen erschienen und hat diese Optionen wieder entfernt. Sie basierten auf veralteten Spezifikationen des Accessibility Object Model (AOM).

iOS 12.2 erschien am 25.03.2019 und bringt eine neue Einstellung in der Bedienungshilfe VoiceOver mit. Diese ist standardmäßig eingeschaltet, mit schwerwiegenden Implikationen für die Privatsphäre.

Die Einstellung findet sich unter Einstellungen/Allgemein/Bedienungshilfen/VoiceOver im neuen Unterpunkt „Web“, der neu ganz am Ende der Liste der Einstellungen hinzugekommen ist. Sie heißt Bedienungshilfen-Events und ist standardmäßig eingeschaltet. Apple selbst erklärt darunter die Einstellung wie folgt:

Die Option „Bedienungshilfen-Events“ ermöglicht es Websites, ihr Verhalten für Hilfstechnologien wie z. B. VoiceOver anzupassen. Wenn die Option aktiviert wird, zeigt sich, ob auf deinem iPhone Hilfstechnologien aktiv sind.

Im Klartext heißt dies, dass, sofern diese Einstellung nicht geändert wird, jede Webseite, die ihr mit dem Safari besucht, abfragen kann, ob VoiceOver oder eine andere Hilfstechnologie des iPhones aktiv ist und darauf reagieren. Im am wenigsten schlimmen Fall kriegt ihr nur eine Nur-Text-Version. Die 1990er haben angerufen und wollen ihren Lynx-Browser zurück. Im schlimmsten anzunehmenden Fall jedoch werdet ihr aktiv diskriminiert. Entweder werden Angebote nicht angezeigt, weil man euch aufgrund einer vermeindlichen Behinderung nicht für geschäftsfähig hält, oder es werden schlicht und einfach Daten erhoben, die einem gierigen Chefetagen-Menschen zeigen, wie viele oder wenige Leute mit einer vermeindlichen Behinderung die Webseite besuchen. Daraufhin trifft dieser gierige Chefetagen-Mensch dann die Entscheidung, dass es gar nicht nötig ist, die Webseite in Zukunft zugänglich zu machen. Andere Dinge sind viel wichtiger, um seine Taschen mit dem nächsten Quartalsbonus noch weiter zu füllen als die paar Behinderten, die eventuell mal zufällig auf der Seite seiner Firma vorbeischauen könnten.

Es wird hier also aktiv mitgeteilt, ob ihr eine Behinderung haben könntet. Das ist ein Fakt, der, meiner Meinung nach, keinen Webseitenbetreiber etwas angeht, es sei den, ihr entschließt euch dazu, es selbst mitzuteilen, weil es z. B. eine Ermäßigung gibt. Aber ohne weitere Zustimmung dies automatisiert mitzuteilen halte ich für höchst verwerflich. Das zusammen mit den Möglichkeiten des Browser-Fingerprintings, also der eindeutigen Identifizierung durch diverse Verfolgungs-Techniken, ermöglicht auch politisch nicht freundlich gesinnten Organisationen eine aktive Verfolgung von Menschen mit Behinderung im Web.

Diese Idee ist nicht neu. Schon 2013 gab es im Rahmen des damaligen IndieWeb-Projekts Bestrebungen, unter anderem betrieben von Apple, eindeutig identifizierbar zu machen, ob jemand, der eine Webseite besucht, einen Screen Reader oder ähnliches verwendet. Das Projekt scheiterte, unter anderem auch wegen Blog Posts von Léonie Watson, mir und einigen anderen Aktivistinnen und Aktivisten, die sich ganz klar gegen eine solche Praxis aussprachen.

Dass Apple jetzt einen eigenen Weg geht und Nutzern im Rahmen eines eigentlich kleineren Updates diese weitreichende Änderung unterjubelt, ist ein sehr schändliches Verhalten. Es musste dafür nicht mal eine neue Version einer Datenschutzrichtlinie für diese doch sehr persönliche und personenbezogene Angabe erteilt werden. Ich halte das für sehr sehr üble Geschäftspraxis, die allem entgegen steht, was Apple öffentlich so über Nichtdiskriminierung oder ähnliches sagt. Der Grundsatz „Don’t be evil“ (sei nicht bösartig“ scheint im Silicon Valey allgemein nicht mehr zu gelten.

Meine Empfehlung also: Nach dem Update sofort diese Option abschalten und regelmäßig kontrollieren, ob weitere Updates sie nicht vielleicht doch wieder aktivieren.

Nachtrag

Per E-Mail erreichte mich soeben der Hinweis, dass auch das MacOS Update auf 10.14.4, das am gleichen Tag erschien wie iOS 12.2, diesen Eintrag enthält, im VoiceOver Dienstprogramm, Unterpunkt Web, auf der Registerkarte Allgemein. Also auch mac-OS-Nutzer, die VoiceOver laufen haben, übermitteln im Safari zukünftig standardmäßig diese Information an Webseiten. Vielen Dank an Peter für den Hinweis!

Werbeanzeigen

Veröffentlicht von Marco

Jahrgang 1973, 80er-Jahre-Kind, Katzenliebhaber, verheiratet mit der besten Ehefrau von der Welt, blind, Barrierefreiheit, technikaffin

Beteilige dich an der Unterhaltung

22 Kommentare

  1. Es wird *vermutet*, dass man JAWS benutzt. Weil sie eine Heuristik einsetzen, die oft richtig liegt, aber eben nicht immer. Dasselbe sieht man auch bei Recaptcha, mal klappt die Checkbox „Ich bin kein Roboter“, mal nicht. Unterschied: Bei Apple ist es fest voreingestellt.

    Gefällt mir

  2. Über diese Meldung war ich heute sehr erschrocken, denn so viel Polemik bin ich von Dir nicht gewohnt. Mich ärgert diese einseitige Sichtweise, weil sie einerseits den Webdesignern unterstellt, sie wollen uns mit Nur-Text-Versionen abspeisen und noch mehr, uns diskriminieren.

    Wir sind jedoch im Internet genau dieselben Menschen wie im realen Leben, und auch dort kennzeichnen wir uns mit dem weißen Stock. Dies tun wir nicht, weil wir den so toll finden, modern sein wollen oder uns von anderen abgrenzen, nein, wir tun es, weil wir möchten, dass man Rücksicht auf uns nimmt.

    Genau dies ist seit jeher, auch schon unter Windows und auch bei der Programmierung von IOS-Apps gängige Praxis. Populäre Beispiele dafür waren HAFAS unter Windows und Quizduell unter IOS. In Quizduell erhalten blinde Benutzer keine Bilderfragen.

    Da Apple inzwischen seinen App-Entwicklern verschlüsselte Kommunikation vorschreibt, weiß wahrscheinlich niemand, ob Quizduell oder andere Apps diese Informationen sammeln oder anderweitig damit verfahren. Alle, die unter VoiceOver Quizduell spielen, nehmen dies in Kauf. Warum soll nun nicht auch eine Webseite erkennen, dass ein Screenreader läuft? Ich jedenfalls hoffe sehr, dass uns in Zukunft weniger Captchas aufgezwungen werden und weniger animierte Bilder dafür sorgen, dass sich Seiten ständig neu aufbauen.

    Was ich jedoch sehr verfrüht finde, ist die harsche Kritik an Apple, obwohl mit keinem Wort erwähnt wurde, ob wirklich die Übermittlung der Information neu ist, oder vielleicht nur die Möglichkeit, die bereits früher vorhandene Funktion auszuschalten. In diesem Fall hätte Apple mit dem Update sogar etwas für und nicht gegen den Datenschutz getan.

    Wie auch immer, ich werde die neue Funktion nicht nur eingeschaltet lassen, sondern überprüfen und sicher stellen, dass sie wirklich eingeschaltet ist.

    Gefällt mir

    1. Hallo Johannes,

      zum einen hat der weiße Stock oder die Binde o. ä. im Straßenverkehr durchaus einen versicherungstechnischen Sinn und dient nicht nur der Funktion, mit mehr Rücksicht behandelt zu werden. Der Vergleich hinkt also durchaus etwas.

      Und zum anderen sind Apps noch einmal etwas anderes als Webseiten. Webseiten haben von Natur aus weniger Rechte als Apps, sie können z. B. nicht aufs lokale Dateisystem zugreifen. Ein x-beliebiges Blog, die Seite einer politischen Partei o. ä. geht es schlicht und einfach nichts an, dass ich, der ich auf ihre Seite surfe, eine Behinderung habe.

      Und wie ich schon im Artikel selbst schrieb, können diese Erhebungen durchaus dazu herangezogen werden, Daten zu erheben, die „rechtfertigen“ (bewusst in Anführungszeichen gestellt) sollen, warum man eine Seite eben nicht barrierefrei gestalten muss, beim Relaunch. Aus leidiger Erfahrung aus meinen verschiedenen Consultings weiß ich, dass das immer und immer wieder das Hauptargument ist „wir haben keine behinderten Kunden, brauchen wir nicht“. Das sind nicht die Webdesigner oder Programmierer, es sind die Chefetagen, denen ich ignorantes oder Böswilliges Verhalten unterstelle und denen durch diese neue Funktion mehr „Argumente“ an die Hand gegeben werden, ihr ignorantes oder böswilliges Verhalten zu untermauern. Und wie es mit z. B. Werbetrackern ist, so wird es auch hiermit sein, wenn wir als Betroffene dem keinen Riegel vorschieben: Ist die Technologie da, wird sie missbraucht werden. An das vornehmlich Gute kann ich nach über 25 Jahren in diesem Geschäft leider kaum noch glauben, das, was daraus mehr erwachsen wird, wird uns zum nachteil gereichen, nicht zum Vorteil.

      Gefällt mir

      1. Hallo Marco,

        das Argument mit der geringen Anzahl blinder oder sehbehinderter Nutzer können wir weder mit noch ohne Übermittlung des Screenreader-Flags entkräften. Wir sind eine Minderheit, und damit müssen wir uns leider abfinden. So oder so müssen wir also an die gesellschaftliche Verantwortung appellieren. Wirtschaftliche Interessen werden hierzu nicht ausreichen.

        Das Screenreader-Flag gibt Webdesignern aber die Möglichkeit, stark auf visuelle Benutzung ausgerichtetes Verhalten zu unterlassen. Beispielsweise ist es mehr als lästig für Sehbehinderte, wenn der Inhalt eines Bereichs einer Seite sich ändert, nur weil die Maus darüber streicht. Sehbehinderte sehen nämlich oft nur einen kleinen Abschnitt des Bildes, weil sie diesen stark vergrößern. Die Vergrößerungssoftware folgt u. a. dem Mauszeiger. Wenn man also nun die Maus nutzt, um eine bestimmte Stelle näher zu betrachten, und diese verschwindet, ist die Seite für Sehbehinderte kaum bedienbar. Heutzutage sind Webseiten jedoch so stark auf visuelle Effekte ausgerichtet, dass es nicht gelingen wird, die Gestalter davon zu überzeugen, diese Effekte für die große Masse der Benutzer abszuschalten, schon aber für die geringe Anzahl Sehbehinderter, die die Effekte ohnehin nicht würdigen.

        Daher plädiere ich ohne wenn und aber für das Flag. Generell begegnet mit zwar sehr oft nicht die Bereitschaft, das Design zu ändern, wohl aber Verständnis für meine Situation. Diskriminierung sehe ich daher weniger als Problem.

        Gelingt es uns also, die „normalen“ Seiten im Urzustand zu belassen, kann es uns eher gelingen, für uns bestimmte Änderungen durchzusetzen.

        Gefällt mir

      2. Siehst Du, und genau hier ist das Problem. Das Problem, das Du beschreibst, ist für Menschen mit motirischen Einschränkungen, z. B. zittrigen Händen bei an Parkinson Erkrankten, genau so ein Problem wie für Sehbehinderte. Auch sie können solche Seiten nicht richtig bedienen, weil sie die Maus nicht ruhig halten können. Sie verwenden aber in der Regel keine Hilfstechnologien, die ein solches Flag an die Webseite senden könnten. Und nun? Sehbehinderte bekommen das vielleicht von den Designern extra eingebaute „Feature“, die an Parkinson erkrankte Person aber nicht. Zack, eine Benutzergruppe ausgesperrt, weil man sich auf ein Flag verlässt, das nur von Hilfstechnologien generiert wird. Das ist eben der Punkt, den ich versuche klarzumachen: Man weiß als Webdesigner nie, wer tatsächlich die Seite nutzen wird. Und man weiß auch nicht, ob das, was man extra für eine Nutzergruppe einbaut, nicht auch anderen zugute kommt, an die man gerade gar nicht denkt. So fällt mir spontan noch eine weitere Gruppe ein, die vielleicht sogar die Webseite zoomen würde, damit sie sie besser lesen kann, aber die Maus auch nicht mehr ganz ruhig halten kann: Senioren. Eine Überschneidung, und sie würden nach Deinem Beispiel ebenfalls draußen bleiben, weil der einfache Browser-Zoom einer Seite das Flag nicht generieren wird. Und das sind dann schon zwei völlig unabhängige Benutzergruppen, die ausgeschlossen wären.

        Deshalb ist universelles Design so verdammt wichtig, keine Insellösungen, die auf irgendwelchen Flags beruhen, die manche Hilfstechnologien generieren könnten.

        Gefällt mir

      3. Hallo Marco ,
        ja generell ist inclusives Disign der beste Weg – aber ob es wirklich möglich ist eine Darstellung zu bauen die für alle menschen gleich einfach zu handhaben ist ? Ich habe vor einiger Zeit einen Text in leichter Sprache mit dem Screenreader gelesen. Hier wurden u. a. lange Worte mit einem Zeichen optisch gegliedert – einem kleinen Punkt , aber nicht einem „Satzpunkt “ sondern einem Punkt in der Mitte der vertikalen Textzeilenausrichtung . Der Screenreader las das Zeichen als „Mittelpunkt“ vor – im Ergebnis wurde der Text für einen Screenreadernutzer , dem leichte Sprache hülfe, noch schwerer erfaßbar dargestellt. Und das obwohl beide Anpassungen auf ihrer jeweiligen Ebene nach den vereinbarten Regeln funktionierten. Von daher wären Accessibility-Tags vielleicht gar nicht schlecht um hier eine bessere Abstimmung zwischen Informationsanbieter und -nutzer zu erlauben. Das dann aber als WEbstandard und nicht als Lösung die sich jeder selber baut .

        Gefällt mir

      4. Lieber Marco

        Vielen Dank für deine Ausführungen.
        Laut Applevis.com muss damit die Einstellung funktioniert auch im Safari unter erweiterten Einstellungen und dort bei den experimental Features das „Accessibility Object Model“ aktiviert werden.
        Ich finde es wichtig, dass du über so etwas informierst.
        Ich sehe aber das auch als Chance. Natürlich zeigt auch meine Erfahrung, welche auf 9 Jahren in diesem Bereich basiert, dass die Zahlen ein meist wichtiges Argument sind um eine Webseite nicht barrierefrei zu machen. Vielleicht würden aber genau solche Zahlen, die erstmalig zuverlässig erhoben werden können eine Diskussionsgrundlage bilden, welche auf Fakten basiert.
        Denkst du nicht, dass dies in den USA ziemlich viele Klagen mit sich führen würde, wenn Webseitenbetreiber Menschen mit Behinderung aufgrund dieser Information aussperren?

        Also ich wünsche mir, dass wir weiterhin den Glauben nicht verliehren und alle als böse und profitgierige Manager hinstellen.

        Gefällt mir

  3. Habe soeben den Hinweis erhalten, dass auch das VoiceOver unter Mac OS 10.14.4 diese Info fleißig nach Hause telefoniert. Angaben hierzu oben im Artikel unter der Überschrift „Nachtrag“.

    Gefällt mir

  4. Nein, ich sehe das nicht so. Es besteht die Gefahr eines Zwei-Klassen-Webs, in dem wir dann wieder mit einfachen, abgespeckten und höchstwahrscheinlich mit veralteten Daten ausgestatteten Versionen abgespeist werden, wie bei den Nur-Text-Versionen früher. Riesen Rückschritt.

    Gefällt mir

  5. Grundsätzlich muss ich Marco hier schon Recht geben. Sobald solch ein Flag automatisch standardmäßig (!) mitgesendet wird, ist es viel einfacher bestimmte Gruppen an Users zu identifizieren. Wenn so etwas schon von diesen Gruppen erwünscht ist, dann sollte jene Personengruppe aber bewusst (!) jene Entscheidung für alle Websites/Domains bzw. für jede neu aufgerufene Website/Domain erteilen oder halt eben ablehnen. Aber so, wie es jetzt implementiert wurde, schadet es jener Nutzer-Gruppe hinsichtlich Privatsphäre und datenschutz mehr, als es optisch oder funktionell einen Nutzen aufweisen kann, es sei denn, man stellt dies manuell ab. Zudem können diese optischen und funktionellen Spielereien auch ohne dieses Flag durch bewusstes Setzen eines Cookies per Klick auf einem bestimmten Link erreicht werden. Hierfür braucht man dieses VO-Flag für Websites nun wirklich nicht.

    Trotzdem sei noch festgehalten, dass die Situation bei Programmen unter Windows oder Apps unter iOS/Android/Fire OS eine ähnliche ist. Zumindest NVDA unter Windows teilt Programmen ein dementsprechendes Flag mit, was sich aber durch das Kommandozeilen-Parameter „–no-sr-flag“ abschalten lässt. Und unter iOS ist’s – abgesehen vom Kommandozeilen-parameter – dasselbe mit VoiceOver. Ergo war es zuvor ohne diese neue Funktion unter iOS 12.2 theoretisch bereits möglich aufgrund einer App mit Werbe-Bannern und Analytics-Zeugs diese VO-User gezielt herauszufiltern, wenn man sämtliche Daten miteinander in Verbindung bringt. Und oftmals dürfte hierzu der Zeitstempel bereits ausreichend sein. Diese Problematik bei Apps unter iOS ist jetzt folglich nicht neu.

    TL;DR: Aufklärung ist das A und O, nur leider lesen kaum Leute die Datenschutzbestimmungen, weil oftmals viel zu lang und teils wirr und unverständlich geschrieben, sofern sie überhaupt in der Muttersprache vorliegen. Zudem fehlt bei sehr vielen Personen überhaupt mal das nötige Grundwissen hinsichtlich Software-Technik, um das alles auch hinsichtlich ihrer Folgen verstehen zu können.

    Interessantes Detail am Rande: In den deutschen Release Notes zu iOS 12.2 ist u.a. folgendes zu lesen:
    Zitat: „• Entfernung der Unterstützung für den nicht mehr gültigen „Do Not Track“-Standard, um potentiellen Missbrauch als Erkennungsvariable (Fingerprinting) zu verhindern; Intelligent Tracking Prevention verhindert nun standardmäßig websiteübergreifendes Tracking.“ — Zitat-Ende
    Quelle: https://support.apple.com/de-at/HT209084

    Sowohl in den deutschen, wie auch in den englischen Release Notes steht rein gar nichts zu diesem neuen VO-Flag für Websites, was meiner Meinung nach ein großer Fehler ist.
    Siehe hierzu auch: https://support.apple.com/en-us/HT209084

    Gefällt mir

  6. Hallo Marco und alle ,
    ich hatte dazu auch schon in einigen Mailinglisten etwas geschrieben. Grundsätzlich könnte ich mich mit dieser „hier wird Hilfstechnologie eingesetzt“-Signalisierung anfreunden, wenn sie mir Vorteile bringt. Aber ich möchte gefragt werden. Johannes, um bei Deinem Vergleich mit der Kenntlichmachung im Verkehr zu bleiben: natürlich freue ich mich wenn jemand mir seine Hilfe anbietet z. B. eine Kreuzung zu überqueren weil er den Stock gesehen hat. Aber ich will gefragt werden! Apple hat sich in diesem Fall verhalten wie die „Helferlein“ die eines der Standard-Ärgernisse in unserer „Szene“ sind: ungefragt am Arm packen und über die Straße schieben. Webbrowser fragen ja auch ab, ob ich meinen Standort an eine Seite weitergeben möchte und bieten sogar an , das nicht nur abzulehnen , sondern auch nur einmal oder generell für diese Seite zu erlauben. Wäre aus meiner Sicht der richtige WEg gewesen und auch den Apple-eigenen Ansprüchen an Wertschätzung ihren Kunden gegenüber gerecht geworden. Ich bin durchaus der Ansicht daß Apple hier nichts „böses“ wollte, ich betrachte die Welt doch eher mit den Blicken einen Optimisten . Es war sicher gut gemeint aber schlecht gemacht . Ich werde das so an accessibility@apple.com schreiben, die Einstellung selber aber wohl aktiviert lassen und ggf mal spielen wie WEbseiten mit und ohne „ankommen“.

    Gefällt mir

  7. Ich hatte die Option neulich gesehen und sie zunächst auch als nicht so problematisch empfunden, aber das sind schon recht stichhaltige kritische Argumente. Vielleicht sollte man das mal beobachten, ob es irgendwo negative Folgen hat, etwa mit schlechteren Versionen von Seiten.

    Gefällt mir

  8. Hallo Marco, ich halte die im Artikel angesprochenen Negativbeispiele für ziemlich konstruiert, schlagen sie doch in die Kerbe, dass alles schlecht ist und natürlich jeder erst einmal böse Absichten hegt. Don’t be evil war übrigens der Leitsatz von Google, nicht von Apple. Es ist doch nicht neu, dass ein Browser neben Geodaten auch lokale Informationen des Endgeräts erfasst und übermittelt, schon deshalb könnte ein Apple-Nutzer wohlabender sein, als ein Nutzer des Internet Explorers, der bestimmt noch mit alten Systemen unterwegs ist. Meldungen diesbezüglich gab es genug, siehe Pricing und die Anpassung an das Surfverhalten, Maus- und inzwischen auch Gestenerkennung, sonstige Daten, wie installierte Aps und was alles erfasst wird. Dass Du als Entwickler tatsächlich vermutest, dass jetzt eine weltweite Diskriminierungs-Welle über das Netz schappt, zumal die Anzahl blinder Nutzer alleine nicht mal den Aufwand für eine barrierefreie Webseite oder App generell rechtfertigen würden, steht glaube ich nicht ganz im Verhältnis zur Funktion.

    Sicher ist es richtig darauf hinzuweisen, dass diese Funktion werkseitig aktiv ist und schön ist das keineswegs. Ob das aber den Ruf eines Herstellers, der seit Jahren Wegwerfcomputer baut und inzwischen durch unrealistische Preiserhöhungen den eigenen Absatz schädigt, so dass man keine Stückzahlen verkaufter iPhones angibt, ist sicher unrealistisch. Apple weiß inzwischen ohnehin nicht mehr, was sie tun und mich wundert es, dass man sich überhaupt wundert, dass VoiceOver überhaupt noch im Fokus steht. Wenn man sich aber über etwas Sorgen machen kann, gäbe es durchaus brisantere Themen, wie Artikel 13.

    Gefällt mir

  9. Pingback: Domingos
  10. Bei Heise war gestern zu lesen, dass mehrere Browser, darunter Firefox, die Einstellung Bewegung reduzieren ebenfalls übermitteln. Darüber hat sich niemand beschwert. Die Einstellung ist ebenfalls für Sehbehinderte hilfreich. Wer also im Glashaus sitzt…

    Gefällt mir

  11. Ich habe hier ein Artikel von Apple, was ich sporadisch übersetzt habe.

    Informationen über Bedienungshilfen-Events

    Bedienungshilfen-Events ist eine experimentelle Webentwicklungsfunktion, die für macOS 10.14 und höher sowie für iOS 12 und höher verfügbar ist. Hierfür muss die Funktion „Accessibility Object Model“ in den erweiterten Einstellungen in Safari aktiviert sein.

    Wie werden Bedienungshilfen-Events verwendet?

    Mit der neuen Funktion Bedienungshilfen-Events können Webentwickler sicherstellen, dass Benutzer ihrer assistiven Technologien auf ihre benutzerdefinierten Steuerelemente (z. B. benutzerdefinierte Schieberegler) zugreifen können. Diese Aktionen können jetzt durch assistive Technologien wie VoiceOver und Schaltersteuerung oder über allgemeine Eingabegeräte wie Tastaturen ausgelöst werden. Bedienungshilfen-Events ist ein Teil des Projekts Accessibility Object Model (AOM), einer aufstrebenden Web-Technologie, die derzeit gemeinsam von Apple, Google und der Mozilla Foundation W3C entwickelt wird. Das AOM ist in iOS und macOS standardmäßig deaktiviert.

    Bedienungshilfen-Events aktivieren

    Auch wenn das Steuerelement Bedienungshilfen-Events standardmäßig aktiviert ist, funktioniert die Funktion nur, wenn die AOM-Einstellung aktiviert ist, was eine Entwicklerfunktion ist, die standardmäßig deaktiviert ist.

    So aktivieren Sie Bedienungshilfen-Events auf Ihrem Mac:

    1. Wählen Sie Safari> Einstellungen.
    2. Klicken Sie auf Erweitert und wählen Sie Entwicklungsmenü in der Menüleiste anzeigen.
    3. Wählen Sie in der Safari-Menüleiste > Experimental Features> Accessibility Object Model.
    4. Stellen Sie sicher, dass Bedienungshilfen-Events unter > Systemeinstellungen> Bedienungshilfen> VoiceOver> VoiceOver-Dienstprogramm öffnen> Web> Allgemein> Bedienungshilfen-Events aktiviert ist.

    Auf einem mac beachtet Schaltersteuerung die Einstellung Bedienungshilfen-Events im VoiceOver Dienstprogramm.

    So aktivieren Sie Bedienungshilfen-Events auf Ihrem iPhone, iPad oder iPod touch:

    1. Gehen Sie zu Einstellungen> Safari> Erweitert> Experimental Features.
    2. Tippen Sie, um das Accessibility Object Model zu aktivieren.
    3. Tippen Sie auf Einstellungen> Allgemein> Bedienungshilfen, um sicherzustellen, dass die Bedienungshilfen-Events für VoiceOver und Schaltersteuerung aktiviert sind. Tippen Sie für VoiceOver auf VoiceOver> Web> Bedienungshilfen-Events. Oder tippen Sie für Schaltersteuerung auf Schaltersteuerung> Web> Bedienungshilfen-Events.

    Privatsphäre

    Apple setzt sich für Barrierefreiheit und Datenschutz ein. Mit der Funktion „Bedienungshilfen-Events“ können Websites weder spezifisch abfragen, ob Personen einen Bildschirmleser oder eine andere spezifische unterstützende Technologie verwenden, noch Informationen über die Fähigkeit oder Behinderung eines Benutzers bereitstellen. Webentwickler können möglicherweise erkennen, dass assistive Technologien auf einem Gerät aktiv sind, um eine Website bereitzustellen, die mit der assistiven Technologie kompatibel ist.

    Veröffentlichungsdatum: ‎10‎. ‎April‎ ‎2019

    Gefällt mir

  12. Unter iOS 12.3 als auch bei Mac OS 10.14.5, ist diese Option nun nicht mehr vorhanden. Die Frage stellt sich mir, ob man es nun nicht mehr aktivieren oder deaktivieren kann, oder ob es nun per default aktiviert ist und schlicht nur die Option es zu deaktivieren entfernt wurde…

    Gefällt mir

    1. Soweit ich weiß, wurde die Option entfernt, weil sie mit einer inzwischen veralteten Version der Spezifikation arbeitete und somit gar nicht mehr gültig war.

      Gefällt mir

  13. Sehr gut analysiert, vielen Dank für diesen Beitrag. Es hat sich leider noch gar nicht so weit herumgesprochen, dass behindert nicht gleich geschäftsunfähig ist.

    Gefällt mir

Kommentar hinterlassen

Schreibe eine Antwort zu Anonymous Antwort abbrechen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden /  Ändern )

Google Foto

Du kommentierst mit Deinem Google-Konto. Abmelden /  Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden /  Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden /  Ändern )

Verbinde mit %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d Bloggern gefällt das: